インシデントにラベルでアノテーションを付ける

このドキュメントでは、ユーザー定義のラベルを付けてインシデントを整理し、優先順位を付ける方法について説明します。これらのラベルはアラート ポリシーで構成され、アラート ポリシーとインシデントに一覧表示されます。構成によっては、特定の通知にラベルも一覧表示されます。

ラベルについて

ラベル(Key-Value ペア)は、時系列、アラート ポリシー、インシデント、通知に情報を添付するために使用されます。たとえば、時系列のラベルには、データが収集された特定の仮想マシン(VM)インスタンスが識別されます。ラベルはユーザー定義または事前定義のいずれかです。

ユーザー定義のラベル

ユーザー定義ラベルには、指定した情報が含まれます。これらのラベルには、静的または動的な値を指定できます。

ラベルのキーは小文字で始める必要があります。ラベルキーとラベル値の両方に使用できるのは、小文字、数字、アンダースコア、ダッシュのみです。

定義済みのラベル

事前定義されたラベルはリソース記述子に含まれます。時系列データの書き込み時にこれらのラベルに値を代入する必要があります。これらのラベルには、収集される指標または指標が書き込まれるリソースに関する情報が表示されます。たとえば、時系列のラベルで、仮想マシン(VM)、ゾーン、Google Cloud プロジェクト、デバイスタイプを識別することができます。Monitoring がその時系列に基づいてインシデントを作成すると、インシデントはこれらのラベルを継承します。

ラベルの表示方法

アラート ポリシーまたはインシデントのラベルは、インシデントの詳細ページアラート ポリシーの詳細ページ、および一部の通知で表示できます。

  • アラート ポリシー: 静的なユーザー定義のラベルは、[ユーザーラベル] セクションに一覧表示されます。動的なユーザー定義ラベルと事前定義のラベルは表示されません。
  • インシデント: 静的ユーザー定義ラベルはポリシーラベルセクションに一覧表示され、動的ユーザー定義ラベルは指標ラベルセクションに一覧表示されます。事前定義ラベルは、モニタリング対象リソースラベル指標ラベルのセクションに一覧表示されています。
  • 通知: 事前定義されたラベルとユーザー定義ラベルは、次の通知タイプで一覧表示されます。

    • メール
    • Google Chat
    • PagerDuty
    • Pub/Sub
    • Webhook

例: 動的な値を使用してユーザー定義ラベルを追加する

MQL を使用してラベルを構成し、時系列データに基づいてその値が動的に変化するようにすることができます。たとえば、モニタリング対象の CPU 使用率指標の値に応じて値が変化する criticality ラベルをインシデントに割り当てるとします。

fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
    add[
      criticality:
        if(val() >= 90 '%', 'CRITICAL',
          if(val() >= 80 '%', 'WARNING',
            if(val() >= 70 '%', 'INFO', 'GOOD')))
    ]
| condition val() >= 70 '%'

次の図は、MQL クエリを使用するアラート ポリシーが、モニタリング対象の時系列データを処理する仕組みを示しています。

アラート ポリシーによってモニタリング対象時系列が処理される仕組みを示す図。

ポリシー ハンドラは、CPU 使用率データを処理し、条件が満たされるタイミングを示す時系列を出力します。上記の例では、CPU 使用率が 70% 以上のときに条件が満たされます。ポリシー ハンドラは入力時系列ごとに、次の 4 つの時系列のいずれかを生成できます。

出力の時系列名 条件が満たされました 説明
「Good」 × この時系列には、入力の時系列と同じラベルが付けられます。重大度のラベルは付いていません。
「Critical」 CPU 使用率が 90% 以上。出力時系列には、「Good」時系列と同じラベルと値「CRITICAL」の重大度ラベルがあります。
「Warning」 CPU 使用率が 80% 以上 90% 未満。出力時系列には、「Good」時系列と同じラベルと値「WARNING」の重大度ラベルがあります。
"INFO" CPU 使用率が 70% 以上 80% 未満。出力時系列には、「Good」時系列と同じラベルと値「INFO」の重大度ラベルがあります。

ポリシー ハンドラによって生成された時系列データは、インシデント マネージャーへの入力です。インシデント マネージャーは、インシデントが作成およびクローズされるタイミングを決定します。インシデントをクローズするタイミングを判断するために、インシデント マネージャーは、durationevaluationMissingData、および autoClose フィールドの値を使用します。

おすすめの方法

値が動的に設定されるラベルを作成する際、一度に最大 1 つのインシデントを開始させるには、次の操作を行います。

  • MetricThreshold オブジェクトで、次のフィールドのデフォルト値をオーバーライドします。

    • duration フィールド: ゼロ以外の値に設定します。
    • evaluationMissingData フィールド: データの到着が停止したときにインシデントがクローズされるように設定します。Cloud Monitoring API を使用する場合は、このフィールドを EVALUATION_MISSING_DATA_INACTIVE に設定します。Google Cloud コンソールを使用する場合は、フィールドを「条件に違反しない値として扱われる欠落しているデータポイント」に設定します。
  • AlertStrategy オブジェクトで、autoClose フィールドを最小値の 30 分に設定します。Cloud Monitoring API を使用する場合は、このフィールドを 30m に設定します。

詳細については、部分的な指標データをご覧ください。

インシデント フロー

アラート ポリシーの作成時に CPU 使用率の測定値が 70% 未満であるとします。次のシーケンスは、インシデントの開始と終了の仕組みを示しています。

  1. CPU 使用率の測定値は 70% 未満であるため、ポリシー ハンドラは「Good」の時系列を生成し、インシデントは開かれません。

  2. 次に、CPU 使用率が 93% に増加したとします。ポリシー ハンドラは、「Good」時系列データの生成を停止し、「CRITICAL」時系列のデータの生成を開始します。

    インシデント マネージャーは、条件を満たす新しい「CRITICAL」時系列を確認し、インシデントを開始します。通知には、値が CRITICAL の重大度ラベルが設定されます。

  3. CPU 使用率が 75% に低下したとします。ポリシー ハンドラは、「Critical」時系列の生成を停止し、「INFO」時系列の生成を開始します。

    インシデント マネージャーは、条件を満たす新しい「INFO」時系列を確認し、インシデントを開始します。通知には、値が INFO の重大度ラベルが設定されます。

    インシデント マネージャーは、「Critical」時系列のデータが届いていないこと、その時系列のインシデントが対応待ちであることを認識します。このポリシーは、データが到着しなくなったときにインシデントを閉じるように構成されているため、インシデント マネージャーは「Critical」時系列に関連付けられたインシデントを閉じます。したがって、重大度ラベルの値が INFO のインシデントのみがオープンのままになります。

  4. 最後に、CPU 使用率が 45% に低下したとします。この値はすべてのしきい値より小さいため、ポリシー ハンドラは「INFO」時系列の生成を停止し、「Good」時系列の生成を開始します。

    インシデント マネージャーは、「Info」時系列のデータが届いていないこと、その時系列のインシデントが対応待ちであることを認識します。ポリシーでは推奨設定が使用されているため、インシデントがクローズされます。

evaluationMissingData フィールドに推奨値を使用しない場合、データの受信が停止しても、対応待ちのインシデントはすぐにクローズされません。その結果、同じ入力時系列に対して複数の対応待ちインシデントが表示されることがあります。詳細については、部分的な指標データをご覧ください。

次のステップ