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