指定されたクエリ文は、指定された期間に指定されたチェック頻度で実行され、データをクエリします。 クエリ結果はトリガー条件のパラメーターとして計算に使用されます。 アラート条件の計算結果が true の場合、アラートがトリガーされます。 このトピックでは、アラートモニタリングの適時性について説明します。
- アラートモニタリングルールを作成する際、クエリの期間をチェック頻度パラメーターに指定した相対時間と同じ値にしないことを推奨します。
たとえば、期間を 1 分 (相対) に設定し、チェック頻度パラメーターを 1 分の固定間隔に設定します。
この例では、チェック頻度パラメーターは 1 分の固定間隔に設定されています。 データが Log Service に書き込まれてからクエリが可能となるまでに遅延が生じます。 遅延が小さい場合でも、全データのクエリに失敗する可能性があります。たとえば、アラートモニタリングルールが 12:03:30 に実行され、期間が 1 分間 (相対) に設定されている場合、範囲が [12:02:30, 12:03:30) であることを示します。この場合、Log Service に 12:03:29 に書き込まれたログは、12:03:30 の時点ではクエリできない場合があります。- アラートの重複や欠落が許されないなど、アラートの精度に関する要件が高い場合は、期間を前に設定します。 期間の開始時刻および終了時刻を元の設定よりも 10 ~ 70 秒前に設定します。 たとえば、アラートモニタリングルールが 12:03:30 に実行されたとします。 この場合、期間を 10 秒前 [12:02:20,12:03:20) に設定します。 このように設定することで、インデックス作成の遅延によって発生するアラートの欠落を防止できます。
- リアルタイムのパフォーマンスに対する要件が高い場合は、期間を前に設定します。 たとえば、アラートの重複に関係なく、アラートのトリガー直後にアラート通知を受信する場合、 期間の開始時刻を元の設定の 0 ~ 70 秒前に設定します。 たとえば、アラートモニタリングルールが 12:03:30 に実行されたとします。 期間を 70 秒 (相対) に設定すると、期間は [12:02:20,12:03:30) となります。
- 異なる時点で別々に生成されたログが同時に書き込まれると、問題が発生する可能性があります。 この場合、後のログのインデックスが前のログの特定の時点に書き込まれる可能性があります。
この問題の原因は、Log Service がインデックスの作成に使用する方法にあります。
たとえば、アラートモニタリングルールが 12:03:30 に実行され、期間が 1 分 (相対) に設定されている場合、期間は [12:02:30, 12:03:30) となります。 12:02:50 に複数のログエントリが書き込まれ、これらのエントリが 12:02:20 や 12:02:50 など、同じ分の異なる時点で生成されている場合、 これらのログエントリのインデックスは 12:02:20 の時点に書き込まれる可能性があります。 すると、[12:02:30,12:03:30) の期間ではログエントリをクエリできないという問題が発生する可能性があります。
- アラートの重複や欠落が許容されないなど、アラートの精度に関する要件が高い場合は、期間をを時間枠に設定できます。 たとえば、期間を 1 分 (時間枠)、5 分 (時間枠)、または 1 時間 (時間枠) に設定します。 続いて、チェック頻度パラメーターを同じ期間 (1 分、5 分、または 1 時間) に設定します。
- リアルタイムのパフォーマンスに対する要件が高い場合は、期間を特定の期間に設定することを推奨します。 期間には、現在の時刻に対して少なくとも 1 分前の時刻が含まれるように設定します。 この方法により、重複するアラートに関係なく、アラートのトリガー直後にアラート通知を受信できます。 たとえば、アラートモニタリングルールが 12:03:30 に実行されたとします。 期間を 90 秒 (相対) に設定すると、期間は [12:02:00,12:03:30) となります。 続いて、チェック頻度パラメーターを 1 分に設定します。