ログサービスを使用すると、ダッシュボードのグラフに基づいてアラートを設定し、サービスのステータスをリアルタイムでモニタリングできます。

クエリの時間範囲と実行間隔の設定

構成されたクエリステートメントは、指定されたクエリ時間範囲で生成されたログをクエリするために、実行間隔に基づいて定期的に実行されます。 クエリ結果は、アラート条件のパラメーターとして使用されます。 アラート条件の計算結果が真の場合、アラートがトリガーされます。

クエリの時間範囲を実行間隔と同じ期間に設定しないでください。 たとえば、実行間隔が 1 分で、クエリの時間範囲も 1 分である場合です。 その理由は次のとおりです (例として、実行間隔を 1 分とした場合を取りあげます)。
  • データがログサービスに書き込まれた後、クエリが実行されるまでに待機時間が発生します。 待機時間が短くても、データのクエリに失敗する可能性があります。 アラートの実行時間が 12:03:30 で、クエリの時間範囲が 1 分、つまり [12:02:30, 12:03:30) であるとします。 12:03:29 に書き込まれたログは、12:03:30 には照会できません。
    • アラートの精度に対する高い要件がある場合 (アラートの繰り返しが許可されない、アラートの欠落が許可されないなど)、クエリの時間範囲をたとえば 70 秒前から 10 秒前に進めることができます。 たとえば、アラートの実行時間が 12:03:30 の場合、クエリの時間範囲を[12:02:20, 12:03:20) に設定します。 バッファ期間を 10 秒に設定することにより、インデックス作成の遅延によるアラートの欠落を回避できます。
    • リアルタイムのパフォーマンスに高い要件がある場合 (つまり、アラートが繰り返し生成されても、生成されたアラートを受け取りたい場合) は、クエリの時間範囲を、たとえば 70 秒前から現在に進めることができます。 たとえば、アラートの実行時間が 12:03:30 の場合、クエリの時間範囲を [12:02:20, 12:03:30) に設定します。
  • 同じ分の異なる時点のログがログサービスに書き込まれる場合、ログサービスのインデックス方法により、新しいログのインデックスが以前のログの時点に該当する場合があります。 アラートの実行時間が 12:03:30 で、クエリの時間範囲が 1 分、つまり [12:02:30, 12:03:30) であるとします。 12:02:50 に複数のログが書き込まれ、これらのログは 12:02:20 や 12:02:50 など、同じ分の異なる時点で生成されます。 この場合、ログのインデックスは 12:02:20 の時点に該当する可能性があり、指定されたクエリ時間範囲でログを照会することはできません。
    • アラートの精度に対する高い要件がある場合 (アラートの繰り返しが許可されない、アラートの欠落が許可されないなど)、クエリの時間範囲に 1 分、5 分、1 時間などの整数を使用し、実行間隔を同じ期間、つまり、1 分、5 分、1 時間に設定します。
    • リアルタイムのパフォーマンスに高い要件がある場合 (つまり、アラートが繰り返されているかどうかに関係なく、アラートが生成されたら受信する必要がある場合)、アラート実行時間の少なくとも 1 分前をクエリの実行時間範囲に含めることができます。 たとえば、アラートの実行時間が 12:03:30 の場合、クエリの時間範囲を [12:02:00, 12:03:30) に、実行間隔を 1 分に設定します。

クエリ結果に基づくアラートのトリガー

クエリの結果が空でない限り、アラート条件が満たされていると想定します。 特定のフィールドが存在する場合にアラートがトリガーされるように、アラートルールを設定できます。 たとえば、IP アドレス 10.240.80.234 を含むログを検索します。IP アドレス 10.240.80.234 を含むログが見つかった場合、アラートがトリガーされます。 任意のフィールドに基づいて、常に真であるアラート条件を設定できます。 client_ip フィールドは各ログに存在し、空の文字列にすることはできないと仮定します。 client_ip フィールドが空でない限りアラートがトリガーされるように、アラートルールを設定できます。

分析結果に基づくアラートのトリガー

分析結果に基づくアラートのトリガーは、最も一般的なアラートシナリオの 1 つです。 たとえば、特定のフィールドの集計後にアラートがトリガーされます。 次のクエリステートメントを実行して、ERROR キーワードを含むログの数に関する統計を収集します。 ERROR キーワードを含むログの数がしきい値より大きい場合にアラートがトリガーされるように、アラートルールを設定します。
ERROR | select count(1) as errorCount
アラート条件は、errorCount > 0 のように、errorCount がしきい値より大きくなるように設定できます。

関連付けクエリに基づくアラートのトリガー

ダッシュボードでアラートを作成する場合、アラートクエリの入力として複数のグラフを選択できます。
  • 異なる時間範囲でのクエリ結果の組み合わせに基づいてトリガーされるアラートを構成します。
    たとえば、15 分以内の PV が 100,000 を超え、1 時間以内の UV が 1,000 未満の場合にアラートがトリガーされるように、アラートルールを設定します。ダッシュボードでのアラートの作成
    複数のグラフが選択されている場合、クエリの時間範囲は互いに独立しています。 トリガー条件では、${Number}.{Field} 形式を使用してクエリ結果のフィールドを参照します。 たとえば、$0.pv > 100000 && $1.uv < 1000 とします。
  • 一部のグラフに基づいてトリガーされるアラートを構成します。 他のチャートのクエリ結果は、補助情報として使用されます。
    次のステートメントを実行して、ログレベルが ERROR であるログの数に関する統計を収集します。
    level: ERROR | select count(1) as errorCount
    ログレベルが ERROR であるログの数がしきい値より大きい場合にアラートがトリガーされるように、アラートルールを設定します。
    errorCount > 10
    ログレベルが ERROR であるログをアラート通知で表示するには、次のクエリステートメントを実行します。
    level: ERROR
    アラート通知を次のように設定します。
    ${results[1].RawResultsAsKv}
    ログレベルが ERROR のログを表示できます。

アラートの抑制

アラートがトリガーされると、一定期間内に通知を複数回受け取る場合があります。 データのジッタによって引き起こされる誤ったアラートやアラートの繰り返しを防ぐために、次の 2 つの方法でアラートを抑制できます。
  • トリガー条件を設定します。

    アラートは、連続する複数の検出のそれぞれについてアラート条件が満たされた場合にのみトリガーされます。

    たとえば、アラート実行間隔が 1 分で、トリガーしきい値が 5 の場合、5 つの連続するアラート検出のそれぞれがアラート条件を満たしたときにのみ通知が送信されます。 検出された 5 つの連続するアラートのいずれかがアラート条件を満たすことができない場合、カウントはリセットされます。

  • 通知間隔を設定します。
    アラートの実行間隔を短く設定すると、2 つの通知の最小間隔を設定して、頻繁な通知を防ぐことができます。 たとえば、アラートの実行間隔が 1 分で、通知間隔が 30 分である場合、アラートが 30 分以内にトリガーされても通知は受信されません。通知間隔

アラート通知の無効化

アラート通知を受け取ったら、次の図に示すように、アラートの概要ページに移動して、一時的に通知機能を無効にすることができます。[アラート通知の無効化] ダイアログボックスで、通知を無効にする期間 (30 分など) を選択します。アラートがトリガーされても、30 分以内に通知は送信されません。 30 分後、通知機能は自動的に復元されます。

DingTalk グループメンバーによるアラートの処理の許可

DingTalk グループは、最も一般的なアラート通知チャンネルの 1 つです。 DingTalk 通知を構成する場合、次の図に示すように、@ を使って DingTalk グループメンバーを宛先とすることで、対応するアラートを処理できます。
対応するメンバーの携帯電話番号は、Tagged List フィールドと Content フィールドの両方に指定する必要があります。 Tagged List フィールドは、Content フィールド内のアットマーク (@) がリマインダーであるか一般的な文字であるかを判別するために使われます。

テンプレート変数を使用した高度な通知

通知方法を設定する際に、テンプレート変数を使用して高度な通知を行うことができます。 テンプレート変数は、電子メールのタイトル、DingTalk メッセージのタイトル、およびメッセージのコンテンツに使用できます。 アラートがトリガーされるたびに、アラートコンテキストが生成されます。 コンテキスト内の各変数は、テンプレート変数として使用できます。 詳細については、「アラーム通知の設定」をご参照ください。
  • Project、AlertName、および Dashboard 変数は、大文字と小文字を区別せずに ${project} 形式で参照できます。
  • 各クエリのコンテキストは、Results 配列に含まれています。 配列の各要素は、アラートに関連付けられたチャートに対応しています。 ほとんどの場合、要素は 1 つだけです。
    {
      "EndTime": "2006-01-02 15:04:05",
      "EndTimeTs": 1542507580,
      "FireResult": {
        "__time__": "1542453580",
        "field": "value1 ",
        "count": "100"
      },
      "FireResultAsKv": "[field:value1,count:100]",
      "Truncated": false,
      "LogStore": "test-logstore",
      "Query": "* | SELECT field, count(1) group by field",
      "QueryUrl": "http://xxxx",
      "RawResultCount": 2,
      "RawResults": [
        {
          "__time__": "1542453580",
          "field": "value1",
          "count": "100"
        },
        {
          "__time__": "1542453580",
          "field": "value2",
          "count": "20"
        }
      ],
      "RawResultsAsKv": "[field:value1,count:100],[field:value2,count:20]",
      "StartTime": "2006-01-02 15:04:05",
      "StartTimeTs": 1542453580
    }
    フィールドの詳細については、「アラームログフィールド」をご参照ください。 Results 配列のフィールドは、次のようにして参照できます。
    • 配列型のフィールドは、${fieldName[{index}]} 形式で参照します。 index の値は 0 から始まります。 たとえば、${results[0]} は、Results 配列の最初の要素が参照されることを示します。
    • オブジェクトタイプのフィールドは、${object.key} 形式で参照します。 たとえば、${results[0].StartTimeTs} の結果は 1542453580 です。
    RawResults と FireResult のフィールドのみがクエリ結果です。 これらのフィールドでは大文字と小文字が区別されます。 その他のフィールドは大文字と小文字を区別しません。

アラートがトリガーされない理由のトラブルシューティング

アラートを設定した後、アラート統計を表示できます。 詳細については、「アラームログの表示と使用」をご参照ください。 次の図に示すように、内部アラート履歴ログストアで単一のアラートのコンテキストを表示できます。フィールドの詳細については、「アラームログフィールド」をご参照ください。

実行するたびに、一意のアラート ID と対応するログが生成されます。 ログには、アラート実行ステータスとクエリ結果が含まれます。 クエリ結果が 2 KB を超える場合、切り捨てられます。 ログを使用して、アラートがトリガーされない理由をトラブルシューティングできます。