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