MQL アラート ポリシーのベスト プラクティス

このページでは、Monitoring Query Language（MQL）ベースの条件を使用してポリシーにアラートを送信するためのベスト プラクティスのインデックスを紹介します。ここで収集した情報は、MQL ベースの条件でアラート ポリシーを構成する際に留意すべきことのクイック リファレンスとして使用できます。

このページでは、アラート ポリシーで MQL クエリを使用する方法の基本については説明しません。新しいユーザーの方は、MQL のアラート ポリシーをご覧ください。

アラート ポリシーの評価には、複数の内部サービスが含まれます。これらのサービスが MQL とやり取りする方法を考慮して、他のオペレーションではなく特定の MQL オペレーションを使用することを強くおすすめします。たとえば、delta_gauge ではなく delta を使用すると、誤った時間にアラートがトリガーされる可能性があります。

次の表に、回避すべきオペレーションと、その代わりに使用する推奨オペレーションの一覧を示します。

してはいけないこと 推奨
adjacent_rate rate
adjacent_delta delta_gauge
delta delta_gauge
window sliding

アラート ポリシーで every 30s ステートメントを使用する

アラート ポリシーは 30 秒ごとに条件を評価します。この時間の範囲を出力ウィンドウといいます。この期間の視覚的なリマインダーとして、条件に明示的な every 30s オペレーションを含めることをおすすめします。

たとえば、次のアラート ポリシー MQL クエリには、明示的な every 30s ステートメントが含まれています。

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 30s

every オペレーションに異なる値を使用する MQL クエリでアラート ポリシーを保存した場合、アラート ポリシーがアクティブなときに Cloud Monitoring は引き続き 30 秒の値を使用します。たとえば、次のクエリのアラート ポリシーには、まだ 30 秒の出力ウィンドウがあります。

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 90s

クエリの効率向上

大量のデータを処理する場合は、クエリの実行に時間がかかります。クエリの効率を向上させるには、クエリが処理するデータ量を減らしてみてください。以降のセクションでは、クエリで評価するデータの量を減らすためのいくつかのオプションについて説明します。

クエリの早い段階でフィルタを配置する

クエリの早い段階でフィルタを配置すると、クエリでデータに対するオペレーションを実行する前に不要なデータを除外できます。たとえば、次のクエリについて考えてみます。

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by [resource.zone], .sum
| filter zone = 'us-west1-b'
| condition val() > 5'GBy'

group_by オペレーションの前に filter オペレーションを移動すると、クエリの実行速度が速くなる可能性があります。

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| filter zone = 'us-west1-b'
| group_by [resource.zone], .sum
| condition val() > 5'GBy'

クエリ アライメント期間を短くする

クエリで align オペレーションを使用する場合、アライメント ウィンドウが小さいほど、Cloud Monitoring が時系列の各ポイントについて評価する時間範囲が小さくなります。そのため、align オペレーションの値を減らしてクエリの効率を向上させることが可能です。たとえば、次のクエリには 2 時間のアライメント ウィンドウが設定されています。

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(2h)
| every 30s
| condition val() > 2'GBy'

ただし、1 時間の時間枠のデータを表示する必要がある場合は、アライメント ウィンドウを 1 時間に短縮できます。

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(1h)
| every 30s
| condition val() > 2'GBy'

詳細については、アライメントをご覧ください。

アラート ポリシーの期間時間枠を短縮する

アラート ポリシーの期間時間枠は、各測定がアラートが送信されるまでに条件に違反しなければならない期間を表します。 クエリ アライメント ウィンドウを増やさずにアラート ポリシーの期間時間枠を短縮すると、Cloud Monitoring はアラート ポリシー条件を評価するポイントが少なくなります。

詳細については、期間時間枠をご覧ください。

null メタデータにデフォルト値を割り当てる

メタデータ値が null の場合、クエリで予期しない結果が生じる可能性があります。予期しない結果を回避するには、or_else 関数を使用して、null 値を持つメタデータにデフォルト値を割り当てます。

たとえば、すべてのデータを集計するクエリを実行します。

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

このクエリは 10MBy の結果を生成します。次に、クエリを実行して、10MBy がノードゾーン間でどのように分散されているのかを確認します。

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

分散クエリから次の結果が返されます。

node_zone egress_byte_count
us-central1-f 7.3MBy
us-west1-b 2.5MBy

これらの結果は、予想される 10MBy ではなく、合計 9.8MBy となっています。この不一致は、次のデータセットのように、集計されたメタデータ ラベルのいずれかに null 値がある場合に発生することがあります。

value メタデータ値
7.3MBy us-central1-f
2.5MBy us-west1-b
0.2MBy

null メタデータの問題を回避するために、メタデータ参照を or_else オペレーションでラップできます。これにより、メタデータ列に値がない場合のデフォルト値を指定できます。たとえば、次のクエリでは、or_else を使用して、値のないメタデータ列に対してメタデータ値 no zone を設定しています。

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

この新しいクエリにより、次の結果が生成されます。合計 10MBy になります。

node_zone egress_byte_count
us-central1-f 7.3MBy
us-west1-b 2.5MBy
ゾーンなし 0.2MBy