Cloud Monitor:概要

動的しきい値とは

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

制限事項

動的しきい値ベースのアラート機能は、招待プレビュー中です。この機能を使用するには、チケットを送信 してください。

シナリオ

リソース使用量、周期的な変化、分散の変動など、クラウドリソースのメトリックの統計的特性は、ビジネスシナリオによって異なります。たとえば、日中のトラフィックが多く、夜間のトラフィックが少ない場合、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 をストレージに使用し、毎日 00:00:00 に 30 日前に生成された既存データをクリアするスケジュールされたタスクを設定します。ただし、スケジュールされたタスクの実行中は、ApsaraDB RDS の IOPS 使用率が瞬時に 100% に近づき、アラートが生成されます。その後、IOPS 使用率はすぐに通常に戻ります。誤検知は毎日スケジュールどおりに生成されます。

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

自動例外検出

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

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

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

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

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

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

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

しきい値の構成とメンテナンスコストの削減

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

• 特定のしきい値設定

  ECS インスタンスのトラフィック、帯域幅、クエリ/秒（QPS）など、物理的な上限がないメトリックのアラートルールを構成する場合、このようなメトリックの値は桁違いに異なる場合があり、一般的で適切な値を指定することは困難です。このようなメトリックの実際の値が O&M の変更またはビジネスの変更に伴って変化し、関連するしきい値をそれに応じて変更する必要がある場合は、誤検知または検知漏れを防ぐためにしきい値を調整する必要があります。

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

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

ベストプラクティス

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

ユーザーは、オフラインレンダリングに 1 つの ECS インスタンスを使用し、オンラインビジネスサポートに他の ECS インスタンスを使用します。オフラインレンダリングに使用される ECS インスタンスのメモリ使用量は、オンラインタスクに使用される他の ECS インスタンスのメモリ使用量よりも大幅に高くなります。ユーザーが単一メトリックのアラートルールを構成する場合、メモリ使用量のしきい値を 80% より大きく設定します。その結果、オフラインレンダリング用の ECS インスタンスで 1 週間アラートが常にトリガーされ、合計 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 の一部のメトリックの量は、インスタンスでメッセージが送信される回数やインスタンスで消費されるメッセージの数など、サービスに関連しています。さらに、メッセージの消費量は、グループと Topic によって大きく異なります。その結果、異なるサービスのメッセージキューを監視するための共通のしきい値を設定することは困難です。これにより、検知漏れや検出の遅延などのエラーが発生する可能性があります。

自動アラート機能により、動的しきい値ベースのアラート機能はアラートルールの構成を簡素化し、メンテナンスコストを削減できます。この機能は、2 ～ 3 分以内に例外を迅速に検出し、サービスの平均修復時間（MTTR）を効果的に短縮できます。

たとえば、ApsaraMQ for Kafka の累積メッセージ数が急激に増加した場合、この機能は例外をリコールし、アラート通知を送信します。

次の表にリストされている ApsaraMQ for Kafka のメトリックに対して、動的しきい値ベースのアラートルールを構成することをお勧めします。