メトリクス
メトリクスは、作成された時間順に保持される一連の数値データです。環境内のサーバー数、ディスク使用量、1 秒あたりのリクエスト数、リクエストの完了までのレイテンシーなど、あらゆるものを追跡するために使用されます。
しかし、メトリクスはインフラストラクチャやアプリケーションの監視に限定されるものではありません。むしろ、あらゆる種類のビジネスやワークロードで、売上、コールキュー、顧客満足度などを追跡するために使用できます。実際、メトリクスは運用データとビジネスメトリクスの両方を組み合わせることで最も有用となり、システムの包括的な可視化を実現します。
メトリクスに関する追加のコンテキストを提供している OpenTelemetry のドキュメントページ を参照することをお勧めします。
KPI (重要業績評価指標) を把握し、測定しましょう！
メトリクスにおいて 最も 重要なことは、適切なものを測定する ことです。それは誰にとっても異なります。E コマースアプリケーションでは 1 時間あたりの売上が重要な KPI となる可能性がありますが、パン屋では 1 日あたりのクロワッサンの生産数に関心があるかもしれません。
ビジネス KPI の完全で包括的な単一のソースは存在しません。プロジェクトやアプリケーションを十分に理解し、目標とする成果 を把握する必要があります。
最初のステップは、高レベルの目標を定義することです。そしてほとんどの場合、これらの目標はインフラストラクチャだけから得られる単一のメトリクスとしては表現されません。上記の E コマースの例では、1 時間あたりの売上 を測定するという メタ 目標を特定したら、商品購入前の検索時間、チェックアウトプロセスの完了時間、商品検索結果のレイテンシーなどの詳細なメトリクスに遡ることができます。これにより、システムを観察するために関連情報を意図的に収集することができます。
KPI を特定したら、ワークロードのどのメトリクスがそれらに影響を与えるかを Working Backwards で確認できます。
運用メトリクスデータとの相関関係
Web サーバーの CPU 使用率が高くなると応答時間が遅くなり、その結果、顧客の不満が高まり、最終的に収益が低下する場合、CPU 使用率の測定はビジネスの成果に直接影響を与えるため、絶対に 測定する必要があります！
逆に、エフェメラルなクラウドリソース（Amazon EC2 フリートや、他のクラウドプロバイダー環境の同様のリソース）でバッチ処理を実行するアプリケーションがある場合、バッチを最も費用対効果の高い方法で完了するために、CPU を可能な限り使用することを 望む かもしれません。
いずれの場合も、運用データ（CPU 使用率など）とビジネスメトリクスを同じシステムに保存し、両者の相関関係を分析する必要があります。
ビジネスメトリクスと運用メトリクスを同じシステムに保存し、両者への影響を観察して結論を導き出せるようにしましょう。
正常な状態を把握しましょう！
正常なベースラインを理解することは難しい場合があります。多くの人は、正常なメトリクスがどのようなものかを理解するために、ワークロードにストレステストを実施する必要があります。しかし、ニーズに応じて、既存の運用メトリクスを観察することで、正常なしきい値について安全な結論を導き出すことができる場合もあります。
正常なワークロードとは、KPI の目標を達成しながら、回復力、可用性、コスト効率のバランスが取れているものです。
パフォーマンスが要求される水準を下回るか上回った場合にアラームを作成できるよう、KPI には必ず正常な範囲を特定しておく必要があります。
異常検知アルゴリズムを使用する
正常な状態を把握すること の課題は、システム内の すべての メトリクスについて正常な閾値を把握することが現実的ではない場合があることです。 リレーショナルデータベース管理システム (RDBMS) は数十のパフォーマンスメトリクスを出力することができ、マイクロサービスアーキテクチャと組み合わせると、KPI に影響を与える可能性のあるメトリクスが数百に及ぶ可能性があります。
このような大量のデータポイントを監視し、個々の上限と下限の閾値を特定することは、人間が行うには必ずしも現実的ではありません。 しかし、機械学習はこのような反復的なタスクが 非常に 得意です。 自動化と機械学習は、気付かなかった問題を特定するのに役立つため、可能な限り活用してください！
機械学習アルゴリズムと異常検知モデルを使用して、ワークロードのパフォーマンスの閾値を自動的に計算します。