Cloud Monitor:しきい値トリガーアラートルールが遅延でトリガーされるのはなぜですか?

次の2つの概念に精通している必要があります。

• メトリックの期間

  メトリックの期間は、2つの連続するデータポイント間の間隔とメトリック値の集計期間を示します。 たとえば、メトリックの期間が60秒の場合、データポイントは60秒ごとに生成されます。 メトリック値は、前回の値、または過去60秒間のメトリックデータに基づいて計算された集計値です。

• アラート検出期間

  アラートルールの検出期間は、メトリックの期間によって決まります。 マルチメトリック式に複数のピリオドが含まれている場合、最短ピリオドが優先されます。 たとえば、検出期間が60秒の場合、Alert Serviceは60秒ごとに最新のメトリックデータを照会します。

アラートルールのメトリックの期間が長い場合 (たとえば、300秒または900秒) 、メトリックデータのディスクへの書き込みが遅れるか、データポイントがアラートが検出された時点よりもわずかに早い場合があります。 結果として、アラートは、1つの検出期間の遅延でトリガされ得る。 メトリックの期間が短い場合、大きな遅延は発生しません。

アプリケーショングループの可用性モニタリングアラートおよびグループプロセスモニタリングアラート、クラウドサービスのメトリックベースのアラート、サイトモニタリングアラート、およびHybrid cloud monitoringのPromQLステートメントを使用して作成されたアラートには、単一のメトリック、複数のメトリック、複雑な式、および期間ベースの比較に関係なく、固定のしきい値の式があります。 単一のメトリックの単純な式は、次の2つの問題で使用されます。

問題1: メトリックデータは定期的に報告されます。 データはN回連続してアラート条件を満たしますが、アラートはほぼ1期間の遅延でトリガーされます。

原因

アラートが検出された時点は、データポイントよりわずかに早い。 その結果、アラートはほぼ1周期の遅延でトリガーされます。

例

メトリックの期間が300秒であると仮定すると、アラートの検出期間も300秒です。 アラート条件は、平均メトリック値が3つの連続した期間のしきい値よりも大きい場合にアラートがトリガーされることです。 次の表にデータポイントを示します。

アラートが最初に10:06:00に検出されたと仮定します。これは、データポイント10:06:30よりわずかに前です。 10:06:00に照会されたメトリックデータは、最後の期間の値5であり、メトリックしきい値に達していません。

• アラートは10:11:00に2回目に検出されます。 照会されたメトリックデータは値15であり、これは初めてメトリックしきい値に達します。

• アラートは3回目の10:16:00に検出されます。 照会されたメトリックデータは値14であり、2回目のメトリックしきい値に達します。

• アラートは10:21:00に4回目に検出されます。 照会されたメトリックデータは値13であり、3回目のメトリックしきい値に達します。 アラート通知が送信されます。

上記のデータから、顧客は、3回目の閾値を満たすメトリックデータが10:16:30に現れると考えられる。 ただし、アラートは1周期に近い4.5分の遅延でトリガーされます。

問題2: メトリックデータは、まばらに、かつ非周期的に報告される。 アラートは1周期の遅延でトリガーされます。

原因

メトリックデータが非周期的またはまばらに報告されると、ディスクへのデータの書き込みが遅延します。

例

• 例1: メトリックの期間が300秒または900秒であると仮定します。 データがまばらにまたは非周期的に報告される場合、データポイントは5分までの遅延を有し得る。 たとえば、データポイント10:00:00 at 10:01:00のデータを照会した場合、結果は返されません。 10:05:00にデータポイント10:00:00のデータを照会すると、結果が返されます。 したがって、現在のデータは、アラートが検出された時点では利用できない可能性があり、アラートは1周期の遅延でトリガされる。

• 例2: アラート条件は、しきい値が10を超えるとアラートがトリガーされることです。 次の表に、アラート検出プロセスを示します。