このページでは、Monitoring Query Language（MQL）ベースの条件を使用する一部のアラート ポリシーが意図したものと異なる動作をする理由を説明し、そのような状況に備えるための方法を紹介します。
データの欠落
MQL ベースの条件でアラート ポリシーを作成し、MQL クエリ結果には、報告されたデータに予期しない欠落が表示されています。
特定のタイムスタンプで計算結果が null 値になった場合、配置が調整されたデータに欠落が表示されます。たとえば、次のデータテーブルは、30 秒間のクエリに関連しています。
テーブル A1
| タイムスタンプ | 値 |
|---|---|
| 00:00:00 | 1 |
| 00:00:30 | 2 |
| 00:01:30 | 3 |
| 00:02:00 | 4 |
期間は 30 秒であるため、タイムスタンプは 00:01:00 に表示されると想定します。このような欠落はさまざまな原因で発生する可能性があります。
配置による欠落
整列指定子の期間が過剰に短いと、データの欠落が生じる可能性があります。たとえば、以下の配置が調整されていない指標の元データの表は、約 30 秒ごとに書き込まれます。
テーブル B1
| タイムスタンプ | 値 |
|---|---|
| 00:00:01 | 1 |
| 00:00:28 | 2 |
| 00:01:01 | 3 |
| 00:01:32 | 4 |
next_older(30s) オペレーションを使用してデータの配置を調整するクエリを 00:02:00 に実行すると、次の出力が表示されます。この出力には 00:01:00 の時点でデータが欠落しています。
テーブル B2
| タイムスタンプ | 値 |
|---|---|
| 00:00:30 | 2 |
| 00:00:28 | 3 |
| 00:01:01 | 4 |
このデータの欠落は、00:01:00 に終了する 30 秒間の期間に対応するポイントがないために生じます。このような欠落を回避するには、期間を拡張します。たとえば、next_older(1m) オペレーションでは、データの欠落がないテーブルが生成されます。
テーブル B3
| タイムスタンプ | 値 |
|---|---|
| 00:00:01 | 1 |
| 00:00:28 | 2 |
| 00:01:01 | 3 |
| 00:01:32 | 4 |
一般に、データが S 秒ごとに書き込まれる場合は、S より長い配置調整の期間を使用します。これにより、データポイントの時間分布が不均一になることを考慮できます。
テーブル オペレーションによる欠落
一部のテーブル オペレーションでは、予期しない欠落が生じる可能性があります。たとえば、join オペレーションは、すべての入力テーブルに値を持つタイムスタンプでのみ出力を生成します。
join などのテーブル オペレーションで欠落が生じる場合があります。たとえば、配置が調整された次の 2 つのテーブルを結合します。
テーブル C1
| タイムスタンプ | 値 |
|---|---|
| 00:00:30 | 2 |
| 00:01:30 | 3 |
| 00:02:00 | 4 |
テーブル C2
| タイムスタンプ | 値 |
|---|---|
| 00:00:30 | 4 |
| 00:01:00 | 3 |
| 00:01:30 | 2 |
| 00:02:00 | 1 |
次の出力が表示されます。
テーブル C3
| タイムスタンプ | 値 A | 値 B |
|---|---|---|
| 00:00:30 | 1 | 4 |
| 00:01:30 | 2 | 2 |
| 00:02:00 | 3 | 1 |
テーブル C1 に 00:01:00 の値がないため、このテーブルには 00:01:00 に値がありません。
欠損値による欠落
関数によっては、出力を変換できない場合や出力が未定義の場合に欠落が生じます。たとえば、次の文字列値のテーブルに value.string_to_int64 を適用します。
テーブル D1
| タイムスタンプ | 値 |
|---|---|
| 00:00:30 | '4' |
| 00:01:00 | '3' |
| 00:01:30 | 'init' |
| 00:02:00 | '1' |
MQL では 'init' を整数に変換できないため、生成されたテーブルには 00:01:30 の時点に欠落が見られます。
テーブル D2
| タイムスタンプ | 値 |
|---|---|
| 00:00:30 | 4 |
| 00:01:00 | 3 |
| 00:01:30 | null |
| 00:02:00 | 1 |
適格性を欠く値や欠損値によるデータの欠落を回避するには、has_value 関数または or_else 関数を使用してこれらの値を処理します。
has_value は、引数が null と評価される場合に false を返します。それ以外の場合は true を返します。たとえば、value has_value(1 / val()) をテーブル D2 に適用した場合、結果に欠落は見られません。
テーブル D3
| タイムスタンプ | 値 |
|---|---|
| 00:00:30 | true |
| 00:01:00 | true |
| 00:01:30 | false |
| 00:02:00 | true |
MQL グラフでしきい値を超えていないことが示される場合にしきい値アラートが発生する
仮想マシン（VM）の CPU 使用率が大きく変動した場合に通知を受け取るには、指標 compute.googleapis.com/instance/cpu/utilization をモニタリングするアラート ポリシーを作成します。6 時間ごとの CPU 使用率がしきい値 50% を超えた場合にインシデントを生成する条件を作成して構成します。条件では、次のクエリを使用します。
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) | condition val() > 0.5
30 秒後にアラートが表示されます。ただし、MQL グラフには、使用率のデルタがしきい値を超えていないことが表示されます。
アラート ポリシーの出力ウィンドウは 30 秒です。期間を定義しないままにするか、クエリで別の期間を定義することで、この期間を上書きすることはできません。たとえば、次のクエリでは引き続き 30 秒の出力ウィンドウが使用されます。
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) # period not 30 seconds | condition val() > 0.5
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() # undefined period | condition val() > 0.5
評価の最初の 30 秒間で指標のしきい値を超えたため、Cloud Monitoring によってアラートが送信されました。この問題を回避するには、クエリの末尾に | every 30s を追加して、出力ウィンドウが意図した結果を生成することを確認します。次に例を示します。
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() | every 30s # explicit 30 second output window | condition val() > 0.5
エラー: アラート ポリシーを保存できませんでした。リクエストに無効な引数が指定されています。
MQL ベースの条件でアラート ポリシーを作成しました。アラート ポリシーを保存すると、次のエラー メッセージが表示されます。
Error: Unable to save alerting policy. Request contains an invalid argument.
group_by など、一部の MQL テーブル オペレーションでは、入力をアライメントする必要があります。クエリが入力の配置を調整しない場合は、MQL が自動的にデータを配置調整します。ただし、この自動アライメントでは、無効な引数が生成される場合があります。
この問題を回避するには、クエリでテーブル オペレーションを使用している場合は、クエリにデータ アライメントが含まれていることを確認してください。データ アライメント関数の一覧については、MQL リファレンス ドキュメントのアライメント セクションをご覧ください。
しきい値線が MQL グラフに表示されない
MQL ベースの条件で指標しきい値のアラート ポリシーを作成しました。ただし、しきい値線は MQL グラフに表示されません。
Cloud Monitoring は、クエリに 2 つの値を比較するブール式が含まれている場合にのみ、しきい値線を描画します。ここで、1 つの値は列であり、1 つの値はリテラルです。たとえば、次の式はしきい値線をグラフ化します。
val() > 5'GBy'
ただし、次の式はしきい値線をグラフ化しません。
val(0) > val(1) #one of the values must be a literal
5 > 4 #one of the values must be a column
val() #the expression must be a comparison