指標を選択して構成する

このドキュメントでは、アラート ポリシーの条件を構成するときに設定するフィールドについて説明します。アラート ポリシーは通常、仮想マシンの CPU 使用率などの時系列データが一定の条件を満たしている場合に通知を受け取りたい場合に作成します。このコンテンツは、ログベースのアラート ポリシーには適用されません。ログに特定のメッセージが表示されたときに通知する、ログベースのアラート ポリシーの詳細については、ログのモニタリングをご覧ください。

このドキュメントでは、Google Cloud コンソールのメニュー形式のインターフェースで使用される用語を使用します。ただし、その考え方は、アラート ポリシーの作成に使用できるすべての手法に適用できます。 Cloud Monitoring API の使用方法については、Cloud Monitoring API のアラート ポリシーをご覧ください。

表示するデータを選択する

アラート ポリシーを作成する際、表示する指標を指定するには、指標とリソースタイプの値を指定します。

アラート ポリシーで条件を構成するには、Cloud Monitoring API か Google Cloud コンソールを使用します。Google Cloud コンソールでアラート ポリシーを作成するために使用するデフォルトのダイアログは、メニュー ドリブンです。ただし、Monitoring Query Language（MQL）を使用する場合は、Google Cloud コンソールを構成して MQL エディタを有効にできます。

すべての時系列が指標とリソースモデルで表されるわけではありません。たとえば、仮想マシン（VM）で実行されているプロセスの数をモニタリングする場合は、指標とリソースを指定できません。このような場合は、Google Cloud コンソールを構成してダイレクト フィルタ モードを開きます。

デフォルトのモード

特定のリソースタイプに対する指標タイプをモニタリングする条件を構成し、Monitoring Query Language（MQL）を使用しない場合は、デフォルトのモードを使用します。デフォルトの場合、メニューにはデータを受信した指標のみが表示されます。トグルスイッチにより、Google Cloud のすべての指標を表示できます。

• [指標] フィールドは、モニタリング対象リソースから収集される測定値を識別します。これには、測定対象および測定値がどのように解釈されるかについての説明が含まれます。指標 は、指標タイプの短縮形です。コンセプトについては、指標タイプをご覧ください。

• [リソースタイプ] フィールドは、指標データがキャプチャされるリソースを指定します。リソースタイプは、モニタリング対象リソースタイプまたはリソースとも呼ばれます。コンセプトについては、モニタリング対象リソースをご覧ください。

デフォルト モードを使用するには、次の操作を行います。

1. Google Cloud コンソールで [Monitoring] を選択するか、次のボタンをクリックします。
   [Monitoring] に移動
2. ナビゲーション パネルで [アラート] を選択します。
3. [Create Policy] をクリックします。
4. [指標の選択] メニューを使用して、リソースと指標を選択します。
5. フィルタを追加してデータ変換を指定し、アラート ポリシー ダイアログを完成させます。詳細については、指標ベースのアラート ポリシーの作成をご覧ください。

MQL モード

Monitoring Query Language（MQL）を使用して条件を記述するか、指標の比率をモニタリングするには、[MQL] を使用します。

MQL を使用するには、次の操作を行います。

1. Google Cloud コンソールで [Monitoring] を選択するか、次のボタンをクリックします。
   [Monitoring] に移動
2. ナビゲーション パネルで [アラート] を選択します。
3. [Create Policy] をクリックします。
4. ツールバーで [MQL] を選択します。
5. MQL 式を入力します。MQL の使用方法については、Monitoring Query Language の使用をご覧ください。
6. アラート ポリシー ダイアログを終了します。詳細については、MQL によるアラート ポリシーの管理をご覧ください。

ダイレクト フィルタモード

次のいずれかを行う場合は、ダイレクト フィルタ モードを使用します。

• サービスレベル目標（SLO）をモニタリングする。
• まだデータのないカスタム指標のアラートを構成する。
• VM 上で実行されているプロセスの数をモニタリングする。
• API コマンドに含めるフィルタ ステートメントの構文を確認する。
• まだデータがないユーザーラベルを指定するアラートを構成する。

ダイレクト フィルタモードを使用する場合、時系列を選択するには、モニタリング フィルタを入力します。たとえば、グラフ中の次のモニタリング フィルタは、名前に nginx が含まれるプロセスの数を表示します。

select_process_count("monitoring.regex.full_match(\".*nginx.*\")")
resource.type="gce_instance"

次のフィルタでは、us-central1-a ゾーンにある Compute Engine VM の Disk write bytes 時系列を選択します。

metric.type="compute.googleapis.com/instance/disk/write_bytes_count"
resource.type="gce_instance"
resource.label."zone"="us-central1-a"

モニタリング フィルタや時系列セレクタを入力するには、次の操作を行います。

1. Google Cloud コンソールで [Monitoring] を選択するか、次のボタンをクリックします。
   [Monitoring] に移動
2. ナビゲーション パネルで [アラート] を選択します。
3. [Create Policy] をクリックします。
4. [?] を選択して[指標の選択] ヘッダーをクリックして、ツールチップの [ダイレクト フィルタモード] を選択します。

5. モニタリング フィルタまたは時系列セレクタを入力します。構文については、次のドキュメントをご覧ください。

   • モニタリング フィルタ
   • SLO データの取得
   • プロセスの状態のフィルタ

6. データ変換を指定して、アラート ポリシー ダイアログを完成させます。詳細については、プロセスの状態のアラート ポリシーを作成するをご覧ください。

選択したデータをフィルタする

モニタリング対象となっているデータの量を減らすには、フィルタ条件を指定するか、集計を適用します。フィルタにより、一定の条件を満たす時系列のみが使用されるようになります。フィルタを適用すると、評価する時系列が減り、アラートのパフォーマンスが向上します。

複数のフィルタ条件を指定すると、対応するグラフには、すべての条件を満たす時系列（論理 AND）だけが表示されます。

フィルタを追加するには、[フィルタを追加] をクリックし、ダイアログを完成させて、[完了] をクリックします。ダイアログで [Filter] フィールドを使用し、フィルタリング条件を選択します。たとえば、リソース グループ、名前、リソースラベル、ゾーン、指標ラベルでフィルタリングできます。フィルタ条件を選択したら、比較演算子と値を選択してフィルタを完成させます。次の表の各行には、比較演算子とその意味、例が示されています。

演算子	意味	例
=	平等	resource.labels.zone = "us-central1-a
!=	等しくない	resource.labels.zone != "us-central1-a"
=~	正規表現 2 等式	monitoring.regex.full_match("^us.*")
!=~	正規表現 2 に一致しない	monitoring.regex.full_match("^us.*")
starts_with	値の先頭に次の項目が配置されている	resource.labels.zone = starts_with("us")
ends_with	値の末尾に次の項目が配置されている	resource.labels.zone = ends_with("b")
has_substring	値が次の項目を含む	resource.labels.zone = has_substring("east")
one_of	次のいずれか	resource.labels.zone = one_of("asia-east1-b", "europe-north1-a")
!starts_with	値の先頭に次の項目が配置されていない	resource.labels.zone != starts_with("us")
!ends_with	値が次の項目で終わらない	resource.labels.zone != ends_with("b")
!has_substring	値が次の項目を含まない	resource.labels.zone != has_substring("east")
!one_of	値が次の項目のいずれにも一致しない	resource.labels.zone != one_of("asia-east1-b", "europe-north1-a")

データの変換

時系列を選択したら、次のステップでは、各時系列の処理方法（アライメントとも呼ばれます）と、アライメントされた時系列の組み合わせ方を指定します。

このページの残りの部分では、これらのオプションについて簡単に説明します。詳細については、時系列の操作をご覧ください。

時系列を配置する

アライメントは、Monitoring によって受信された時系列を、固定間隔でデータポイントを持つ新しい時系列に変換するプロセスです。アライメントのプロセスは、次のステップで構成されます。

1. 時系列を一連の固定長の間隔に分割する。
2. 各間隔で受信したすべてのデータポイントを集め、それらのデータポイントを結合する関数を適用する。たとえば、この関数ですべてのサンプルの平均を計算するように選択できます。
3. 前のステップで計算された値にタイムスタンプを関連付け、アライメントされた時系列にそのペアを追加します。

アライメントの概要については、アライメント: 系列内の正則化をご覧ください。

アラート ポリシーの条件を作成するときは、アライメント パラメータを指定する必要があります。Google Cloud コンソールを使用する場合は、これらのパラメータのデフォルト値が指定されます。

• ローリング ウィンドウ: このフィールドは、特定の時点までの間隔です。たとえば、その値が 5 分の場合、午後 1 時の時点では、午後 12 時 55 分から午後 1 時の間に受信したサンプルが揃います。午後 1 時 1 分の時点では、午後 12 時 56 分から午後 1 時 1 分の間に受信したサンプルが揃います。アラート ポリシーにおけるアライメント期間は、過去を見るスライディング ウィンドウとして捉えることができます。このフィールドの詳細については、アライメント期間と期間時間をご覧ください。

• ローリング ウィンドウ関数: このフィールドは、過去の期間内のすべてのデータポイントを結合するために使用される関数を指定します。Cloud Monitoring API では、このフィールドは整列指定子と呼ばれます。使用可能な整列指定子についての詳細は、API リファレンスの Aligner をご覧ください。一部の整列指定子関数では、データの整列と別の種類の指標への変換の両方が行われます。詳細については、種類、タイプ、変換をご覧ください。

時系列を結合する

異なる時系列を組み合わせることで、指標に対して返されるデータの量を減らすことができます。複数の時系列を組み合わせるには、通常、グループ化と関数を指定します。グループ化はラベル値で行います。関数は、グループ内のすべての時系列を新しい時系列に結合する方法を定義します。

時系列を集約するオプションにアクセスするには、[時系列をまたぐ] セクションの [もっと見る] をクリックします。

時系列をラベル値によって結合するには、テキスト [時系列のグループ化の基準] をクリックし、メニューから選択します。このメニューは、選択した時系列に基づいて動的に作成されます。

最初のラベルを追加すると、次のようになります。

• [時系列の集計] フィールドが [none] に設定されているため、エラーが表示されます。このエラーを解決するには、時系列を同じラベル値と組み合わせるために使用する関数を選択します。

• グラフには、[時系列グループ条件] フィールドに列挙されたラベルの値ごとに 1 つの時系列が表示されます。

グループ化オプションを指定せずに集計関数を指定すると、関数は選択したすべての時系列に適用され、1 つの時系列になります。

複数のラベルでグループ化できます。グループ化の選択肢が複数ある場合は、選択したラベルに対して同じ値を持つ一連の時系列にアグリゲータが適用されます。

結果のグラフには、ラベル値の組み合わせごとに 1 つの時系列が表示されます。ラベルを指定する順序は問題になりません。

たとえば、次のスクリーンショットは、user_labels.version と system_labels.machine_image によるグループ化を示しています。

図のように、両方のラベルでグループ化すると、値のペアごとに 1 つの時系列が取得されます。この方法では、ラベルの組み合わせごとに時系列が作成されるため、1 つのグラフに作成する場合よりも多くのデータが作成されます。

グループ化を指定した場合、またはアグリゲータを選択した場合、グラフ化された時系列には、プロジェクト識別子などの必要なラベルと、グループ化で指定されたラベルのみが含まれます。

グループ別条件を削除するには、次の操作を行います。

1. グループ別ラベルを削除します。
2. アグリゲータを none に設定します。

注: group-by ラベルの削除だけを行うと、グラフにはアグリゲータ適用後のすべてのデータを表す線が 1 本だけ表示されます。グループ化を取り消すには、グループ別ラベルを削除し、アグリゲータを none にリセットする必要があります。

二次集計

プライマリ データ変換の後に複数の時系列が表示されており、アラート ポリシーで 1 つの時系列をモニタリングする必要がある場合は、[セカンダリ データ変換] フィールドを使用します。

データがない場合の動作

Google Cloud コンソール

データの到着が停止した場合に Monitoring で指標しきい値の条件を評価する方法を構成できます。たとえば、インシデントが対応待ちで、予想される測定値が届かない場合、Monitoring でインシデントを開いたままにするか、すぐにクローズしますか？同様に、データの到着が停止し、対応待ちのインシデントがない場合、インシデントをオープンしますか？最後に、データの到着が停止した後、インシデントをオープンにしておく期間はどれくらいですか？

データが到着しなくなったときに Monitoring で指標しきい値の条件を評価する方法を指定する 2 つの構成可能なフィールドがあります。

• 欠落データを置換する値を Monitoring が決める仕組みを構成するには、[条件トリガー] ステップで設定した [欠落データの評価] フィールドを使用します。再テスト ウィンドウが [再テストなし] に設定されている場合、このフィールドは無効になります。

• データの受信が止まってから対応待ちのインシデントを閉じるまで Monitoring が待機する時間を構成するには、[Incident autoclose duration] フィールドを使用します。[通知] ステップで自動クローズの期間を設定します。デフォルトの自動クローズ期間は 7 日間です。

欠落データ フィールドに関するさまざまなオプションは次のとおりです。

Google Cloud コンソール [欠落データの評価] フィールド	Summary	詳細
欠落データがない	対応待ちのインシデントはオープンのままです。 新しいインシデントはオープンされません。	条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、データが送られてこない場合、自動クローズ タイマーは 15 分以上の時間をおいて開始されます。タイマーの期限が切れると、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。
欠落データポイントが、ポリシーに違反する値として扱われる	対応待ちのインシデントはオープンのままです。 新しいインシデントをオープンできます。	条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、自動クローズ期間に 24 時間を加えた期間にデータが到着しない場合、インシデントはクローズされます。 条件が満たされない場合は、この設定により、指標しきい値の条件が metric-absence condition のように動作します。再テストの時間枠で指定された時間内にデータを受信しない場合は、条件が満たされたと評価されます。条件が 1 つのアラート ポリシーでは、条件が満たされるとインシデントが開始されます。
欠落データポイントが、ポリシーに違反しない値として扱われる	対応待ちのインシデントはクローズされます。 新しいインシデントはオープンされません。	条件が満たされている場合、データの受信が停止すると、その条件は満たされなくなります。この条件のインシデントが対応待ちの場合、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。

API

データの到着が停止した場合に Monitoring で指標しきい値の条件を評価する方法を構成できます。たとえば、インシデントが対応待ちで、予想される測定値が届かない場合、Monitoring でインシデントを開いたままにするか、すぐにクローズしますか？同様に、データの到着が停止し、対応待ちのインシデントがない場合、インシデントをオープンしますか？最後に、データの到着が停止した後、インシデントをオープンにしておく期間はどれくらいですか？

データが到着しなくなったときに Monitoring で指標しきい値の条件を評価する方法を指定する 2 つの構成可能なフィールドがあります。

• 欠落データを置換する値を Monitoring が決める仕組みを構成するには、MetricThreshold 構造の evaluationMissingData フィールドを使用します。duration フィールドがゼロの場合、このフィールドは無視されます。

• データが到着しなくなった後に対応待ちのインシデントを閉じるまで Monitoring が待機する時間を構成するには、AlertStrategy 構造の autoClose フィールドを使用します。

欠落データ フィールドに関するさまざまなオプションは次のとおりです。

API 　　　　　　evaluationMissingData フィールド	概要	詳細
EVALUATION_MISSING_DATA_UNSPECIFIED	対応待ちのインシデントはオープンのままです。 新しいインシデントはオープンされません。	条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、データが送られてこない場合、自動クローズ タイマーは 15 分以上の時間をおいて開始されます。タイマーの期限が切れると、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。
EVALUATION_MISSING_DATA_ACTIVE	対応待ちのインシデントはオープンのままです。 新しいインシデントをオープンできます。	条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、自動クローズ期間に 24 時間を加えた期間にデータを受信しない場合、インシデントはクローズされます。 条件が満たされない場合は、この設定により、指標しきい値の条件が metric-absence condition のように動作します。「期間」フィールドで指定された時間内にデータを受信しない場合は、条件が満たされたと評価されます。条件が 1 つのアラート ポリシーでは、条件が満たされるとインシデントが開始されます。
EVALUATION_MISSING_DATA_INACTIVE	対応待ちのインシデントはクローズされます。 新しいインシデントはオープンされません。	条件が満たされている場合、データの受信が停止すると、その条件は満たされなくなります。この条件のインシデントが対応待ちの場合、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。