CloudMonitor:概要

ダイナミックしきい値とは

動的しきい値は、機械学習アルゴリズムを適用して、メトリックの周期性、傾向、変動などの履歴データパターンの特性を動的に識別します。 動的しきい値は、特定のクラウドサービスのメトリックを統合して、各インスタンスのしきい値の上限と下限を自動的に計算します。

制限事項

動的しきい値トリガーアラート機能は招待プレビューにあります。 この機能を使用するには、チケットを起票してください。

シナリオ

リソース使用量、定期的な変更、分散変動など、クラウドリソースのメトリックの統計的特性は、ビジネスシナリオによって異なります。 たとえば、昼間はトラフィックが多く、夜間は軽い場合、Elastic Compute Service (ECS) インスタンスまたはAlibaba Cloud CDNドメイン名のゲートウェイトラフィックやApsaraMQメッセージの蓄積などのメトリックは、それに応じてピーク値とオフピーク値を示します。 I/O集中型サービスとコンピューティング集中型タスクにより、異なるECSインスタンスでCPU使用率または負荷しきい値 (load.1m、load.5m、およびload.15m) が発生します。

アラートしきい値は、前述の複雑なビジネスシナリオには適していない単一メトリックのアラートルールでは固定されています。 その結果、一部の高負荷インスタンスでは一定のアラートが発生します。 ただし、低負荷インスタンスの一部のビジネス例外は、関連するアラートのしきい値に達することができないか、しきい値に達すると30分以上続く例外があります。 アラートエクスペリエンスを向上させ、例外検出時間を短縮するために、CloudMonitorは、機械学習アルゴリズムとアラートルールの専門的なエクスペリエンスに基づいた動的なしきい値トリガーアラート機能を提供します。 動的閾値トリガ型警報機能のコアアルゴリズムは、周期的パターン、変動、およびメトリックの使用など、データパターンの履歴特性を動的に識別することができる。 このアルゴリズムは、特定のクラウドサービスのメトリックを統合して、各インスタンスのしきい値の上限と下限を自動的に生成します。 この機能を使用すると、しきい値効果を視覚化して表示でき、感度パラメータの調整、ホワイトボクシングの実装を提供します。

メリット

単一メトリックまたは複数メトリックのアラートルールと比較して、動的しきい値トリガーアラートルールには次の利点があります。

アラートのノイズ除去

動的しきい値トリガーアラート機能は、各インスタンスのメトリックデータを収集し、堅牢な時系列分解や予測などのモデルを使用して、さまざまなインスタンスメトリックのデータ使用量やビジネスの変化に合わせます。 この機能は、履歴アラートクラスタリングと類似性マッチングに基づいて異常ノイズも除外し、アラートの精度を向上させます。 この機能は、次のシナリオに適しています。

• さまざまな使用レベルのインスタンスメトリクス

  たとえば、ゲーム会社はオフラインコンピューティングとオンラインサービスに異なるECSインスタンスを使用します。 ほとんどの場合、同じアラートテンプレートが使用されます。 この場合、CPU使用率、負荷使用率、メモリ使用率などのメトリックが80を超えると、アラートがトリガーされます。 その結果、アラートは高負荷インスタンスで常に予期せずトリガーされます。

• スケジュールされたタスクによる負荷スパイク

  たとえば、ユーザーはストレージにApsaraDB RDSを使用し、30日前に生成された履歴データを毎日00:00:00に消去するようにスケジュールタスクを設定します。 ただし、スケジュールされたタスクが実行されている場合、ApsaraDB RDSのIOPS使用量はすぐに100% に近づき、アラートが生成されます。 すると、IOPS使用量は速やかに正常になる。 偽陽性は、毎日予定通りに生成される。

上記のシナリオでは、動的しきい値トリガーアラート機能により、誤検出率を80% 90% に効果的に減らすことができます。 この機能により、ビジネスの例外に集中し、モニタリングとO&Mエクスペリエンスを向上させることができます。

自動例外検出

クラウドサービスインスタンスのメトリックの例外は、通常、アップストリームとダウンストリームのサービスとトラフィックの変更、またはクラウドサービスインスタンスにデプロイされたアプリケーションとデータの変更によって発生します。 動的しきい値トリガーアラート機能は、インターネット接続のServer Load Balancer (SLB) 接続やApsaraMQの大量の蓄積メッセージなどのサービス例外を迅速に検出できます。 この機能を使用して、基本リソースのECSメトリックの例外を検出し、ビジネス例外の根本原因を特定できます。

シングルメトリックまたはマルチメトリックのアラートルールを設定する場合、過度の誤検知を防ぐために高いしきい値を設定します。 また、このようなアラートルールは、アプリケーショングループまたはすべてのリソースに適用されます。 その結果、特定のサービスまたはインスタンスに対してパラメータを調整することはできません。 動的なしきい値トリガーのアラートルールを使用して、メトリック値の急激な増加または減少を迅速かつ正確に検出できます。 このようなアラートルールは、次のシナリオに適しています。

• コード変更後のメトリック例外の検出

  たとえば、開発者がアプリケーションコードを変更した後、プログラムでメモリリークが発生し、その結果、完全なガベージコレクションが発生し、CPU使用率が大幅に増加します。 ただし、この場合、CPU使用率が高い場合の単一メトリックアラートはトリガーできません。

• サービスが利用できなくなる前のタイムリーな警告

  たとえば、アップストリームサービスのトラフィックが突然増加した場合、動的なしきい値でトリガーされるアラートルールは、例外をすばやく検出し、単一メトリックのアラートルールで指定された使用しきい値に達する前にアラートをトリガーするのに役立ちます。 これにより、継続的に高いトラフィックが原因でダウンストリームサービスが利用できなくなるのを防ぎます。

上記のビジネスシナリオでは、動的なしきい値トリガーのアラートルールを使用して、クラウドサービスのコアメトリックを監視できます。 これにより、CloudMonitorは、メトリック例外が発生してから3分以内に85% 以上の問題と障害をリコールできます。

しきい値設定とメンテナンスコストの削減

動的しきい値に値を指定する必要はありません。 しきい値設定を完了するには、動的しきい値トリガーのアラートルールを作成し、対応するアラート条件 (境界を超えて、上限より上に、または下限より下に) を選択するだけです。 動的なしきい値トリガーアラート機能は、構成コストとメンテナンスコストを大幅に削減し、次のシナリオに適しています。

• 特定のしきい値設定

  ECSインスタンスのトラフィック、帯域幅、1秒あたりのクエリ数 (QPS) など、物理的な上限がないメトリックのアラートルールを設定すると、そのようなメトリックの値は桁違いに異なる場合があり、共通の適切な値を指定することは困難です。 このようなメトリックの実際の値がO&Mの変更やビジネスの変更に伴って変化し、関連するしきい値をそれに応じて変更する必要がある場合は、しきい値を調整して、偽陽性または偽陰性を防ぐ必要があります。

• 異なるしきい値と異なる期間でアラートをトリガーする複数のルールの設定

  一部のメトリックの値が異なる期間で有意なピーク値とオフピーク値を示す場合、複数のルールを設定し、異なる有効時間を指定する必要があります。

ベストプラクティス

ECS基本リソースのアラートノイズ除去

ユーザーは、オフラインレンダリングにECSインスタンスを使用し、オンラインビジネスサポートにその他のECSインスタンスを使用します。 オフラインレンダリングに使用されるECSインスタンスのメモリ使用量は、オンラインタスクに使用される他のECSインスタンスのメモリ使用量よりも大幅に高くなっています。 ユーザーが単一メトリックアラートルールを設定すると、ユーザーはメモリ使用量のしきい値を80% より大きく設定します。 その結果、1週間のオフラインレンダリングのためにECSインスタンスで一定のアラートがトリガーされ、合計200のアラートが生成されます。 ユーザーが動的なしきい値でトリガーされるアラートルールを設定した後、1週間に5つ未満のアラートが生成され、誤検出の収束率が95% されます。

アラートノイズ除去のベストプラクティスは、ECSインスタンスのメモリ使用量以外のメトリックにも適用されます。 次の表に記載されているメトリックに対して、動的なしきい値トリガーアラートルールを設定することを推奨します。

ApsaraDB RDSのスケジュールされたタスクによる偽正の収束

ユーザー指定のスケジュールされたタスクを実行して、毎日早朝に履歴データを消去すると、ApsaraDB RDS for MySQLデータベースのQPSがすぐに急上昇します。 単一メトリックのアラートルールは、スケジュールされたタスクが実行されるときに誤検出をトリガーします。 アラートルールを動的しきい値トリガーアラートルールに変更すると、スケジュールされた誤検出は発生しなくなります。

スケジュールされたタスクに起因する誤検出収束のベストプラクティスは、ApsaraDB RDS for MySQLデータベースのQPS以外のメトリックにも適用されます。 次の表に記載されているメトリックに対して、動的なしきい値トリガーアラートルールを設定することを推奨します。

OSSまたはCDNでの例外の検出

Object Storage Service (OSS) とAlibaba Cloud CDN (CDN) は、それぞれサービスのストレージ依存型と高速化されたコンテンツ配信最適化コンポーネントとして機能します。 OSSとCDNの例外は、サービス機能の可用性に直接影響します。 ただし、一般的に、アプリケーションの可用性モニタリングはOSSとCDNの可用性をカバーできません。 その結果、OSSまたはCDNで例外が発生した場合にアラートがトリガーされることはありません。

たとえば、CDNのBPSがゼロに落ちた場合、動的しきい値トリガーアラート機能は、時間内に例外を検出して呼び出すことができ、アラート通知を送信します。

動的なしきい値トリガーのアラートルールを使用すると、OSSとCDNのモニタリングアラートをすばやくカバーし、サービスが利用できなくなる前に事前に例外を検出できます。 次の表に記載されているメトリックに対して、動的なしきい値トリガーアラートルールを設定することを推奨します。

ApsaraMQ for Kafkaの簡易O&M設定

ApsaraMQ for Kafkaの一部のメトリックの量は、インスタンスでメッセージが送信された回数やインスタンスで消費されたメッセージの数など、サービスに関連しています。 さらに、メッセージの消費量はグループやトピックによって大きく異なります。 その結果、異なるサービスのメッセージキューを監視するために共通の閾値を設定することは困難である。 これは、偽陰性および遅延検出などのエラーにつながる可能性がある。

自動アラート機能により、動的なしきい値トリガーアラート機能により、アラートルールの設定を簡素化し、メンテナンスコストを削減できます。 この機能により、2〜3分以内に例外をすばやく検出できるため、サービスの平均修復時間 (MTTR) を効果的に短縮できます。

たとえば、ApsaraMQ For Kafkaの累積メッセージ数が突然増加した場合、この機能は例外を呼び出し、アラート通知を送信します。

次の表に示すApsaraMQ for Kafkaのメトリックに対して、動的なしきい値トリガーのアラートルールを設定することを推奨します。