あなたが DevOps であろうと、SRE であろうと、単なるデータ駆動型の個人であろうと、おそらくダッシュボードとメトリクスにはまっています。メトリクスを見て、インフラストラクチャ、アプリケーション、またはビジネス レベルでシステムがどのように機能しているかを確認します。私たちは、システムのステータスと動作不良の場所を示すメトリクスを信頼しています。しかし、メトリクスは実際に何が起こったのかを示していますか?そうでない場合が多いことに驚かれることでしょう。

この投稿では、メトリクスの背後にある数学とメカニズム、いくつかの一般的な誤解、正確なメトリクスを得るために必要なこと、そしてそのようなものがあるかどうかを調べます.

メトリクスの要点

メトリクスは、本質的に生のイベントのロールアップです。このロールアップ プロセス中に、イベントは数値データ ポイントに変換されます。簡単な例は、エラーをカウントするための簡単なメトリックを使用して、システムで発生するエラーです。メトリクスには、応答時間が 1 秒を超えるリクエストの数など、複数の変数が含まれる場合もあります。経時的に測定すると、これらのデータ ポイントは時系列を形成します。

メトリクスには、カウンター、ゲージ、ヒストグラムなど、さまざまな種類があります。上記の例で見たように、カウンターはイベントの累積カウントに使用されます。通常、ゲージは最新の測定値を表します。さらに、構成可能な「バケット」または「ビン」でイベントをカウントすることにより、メトリック値の分布をサンプリングできるヒストグラムなどのより精巧なタイプがあります。たとえば、特定の時点でクラスター全体のポッドによってセグメント化されたメモリ使用率を理解したい場合があります。

メトリクスの仕組み

理想的な世界では、すべての生のイベントを取り込んで保存し、クエリ時間でメトリックを計算します。これにより、必要な方法でイベントを細かく分割し、必要なアドホックな質問をすることができます。

ただし、現実の世界では、大量のデータがあるため、すべての未加工のイベントを長期間保持すると、法外なコストがかかる可能性があります。これを克服するために、イベントはコレクション パイプラインのメトリックに頻繁にロールアップされますが、生のイベントは破棄されるか、短期間だけ保持されます。多くの場合、これはメトリクス コレクター エージェントの単純な構成の問題です。

コストの削減に加えて、収集時の集計は、より高い頻度でより高いメトリクスの送信と取り込み率を使用してリアルタイム分析のパフォーマンスを向上させ、クエリ時の重い集計と計算を回避することができます。

一言で言えば指標の計算

このロールアップ プロセスには、いくつかの計算が含まれます。応答時間の平均または中央値、またはパーセンタイル、または時間枠での集計を計算したい場合があります。複数のイベントを 1 つの複合メトリックにロールアップすることもできます。たとえば、クラスター全体の特定のサービスのすべてのポッドの 95 パーセンタイル (一般に P95 として知られている) を計算したい場合があります。

数学が苦手でも、メトリクスでは避けられません。さまざまな集計関数と、質問したい質問と、それに答えるために必要なメトリックおよび集計との関係を理解する必要があります。例として Average 関数を見てみましょう。多くの場合、Average 関数から開始する傾向があります。定義上、平均は物事を滑らかにし、異常な行動や外れ値を洗い流すのにはあまり適していません。たとえば、レイテンシの問題を調査する場合、平均メトリック値を見るのはまったく役に立ちません。パーセンタイルを見る方がよいでしょう。

質問を決定し、それに応じて指標を設計します

ある意味では、これらのメトリクスは非可逆圧縮と考えることができます。その間、生のイベントからデータとコンテキストが失われます。生のイベントを保持しない場合は、事前に何が重要かを判断する必要があります。たとえば、データの平均値のみを計算すると、事前に集計されたデータについて後で P95 (95 パーセンタイル) について尋ねることができなくなります。

どの質問に答えたいか、何が重要かを判断し、それに応じてメトリックと集計を設計する必要があります。よくある間違いは、人々がこの設計段階を避け、選択したメトリック コレクターですぐに提供されるプリセット メトリックとデフォルト値を使用することです。これらのデフォルトは何らかの業界標準を表していると思われるかもしれませんが、これらは多くの場合、非常に古いものであり、ほとんどの場合、特定のニーズに適合していません。

測定の問題

物理学と同じように、サンプリング レートを決定するサンプリング間隔と呼ばれる離散間隔で (一見) 連続的なプロパティを測定すると、測定の問題が発生します。これにより、歪んだ表現が作成され、メトリクスが最初に測定されたプロパティを実際に反映していない可能性があります。たとえば、CPU 使用率を 60 秒ごとに測定する場合、これらのサンプリング ポイント間で発生する CPU の外れ値は目に見えません。

さらに、連続した線を描画するために、視覚化ツールは連続したデータ ポイントを平均化することが多く、滑らかな線のように見えて誤解を招きます。実際には存在しないメトリクスのピークなど、実際には存在しないメトリクスのアーティファクトが得られる場合もあります。これは、計算が行われているため、ストレージ バックエンド内で集計を実行しているときに発生する可能性があります。

検出までの平均時間

サンプリング期間は、システムの変化がメトリックに表示される速度にも影響します。ほとんどのアルゴリズムでは、傾向を検出するために 5 つのデータ ポイントが必要です。サンプリング間隔が 60 秒の場合、単純な計算では、問題が発生するまでに 5 分 (つまり、60 秒 X 5 データ ポイント) かかることがわかります。システムがクラッシュしたことがわかるまで、5 分間待つ余裕はありますか?サンプリング間隔を短くする (つまり、サンプリング レートを高くする) と、この期間が短くなり、より迅速に検出して対応できるようになります。もちろん、サンプリング レートを高くすると、CPU とストレージのオーバーヘッドが発生するため、ニーズに合った適切なバランスの構成を見つける必要があります。

さまざまな解像度とダウンスケーリング

一般的な方法は、コストを削減するために、階層化されたアプローチでさまざまな解像度でメトリクスを保存することです。たとえば、初日は 10 秒ごとにメトリクスを保存し、次の週は 5 分ごとに保存し、1 か月またはそれ以降は 1 時間ごとに保存することができます。このプラクティスは、システムに問題がある場合に必要になる可能性がある、ほぼリアルタイムの期間に最も細かい粒度が必要であることを前提としていますが、長期間にわたる調査には大規模な傾向が必要です。

さまざまな粒度は、メトリックをダウンスケーリングすることによって実現できます。つまり、粒度の高いメトリックから粒度の低いメトリックを計算します。これは完全に合理的に聞こえますが、一部の集計関数は特定の計算と互換性がなく、後で集計できないため、数学が干渉する可能性があります。たとえば、パーセンタイルは加法的ではなく、合計できません。したがって、上記の例に従って、10 秒の解像度でサンプリングされた P99 パーセンタイルがある場合、それらを 5 分の解像度にロールアップすることはできません。集計関数の互換性を認識し、パーセンタイルなどの互換性のない関数を使用する場合は、必要な解像度について設計上の決定を下し、これらの時系列を前もって計算することが重要です。

変化する分解能は、時間要因だけに限定されません。もう 1 つの例は、ポッドごとのデータを保存してから、ノードまたはクラスターを「グループ化」したい場合です。ここでも同じ制約が適用されます。つまり、ノードごと、リージョンごと、名前空間ごと、またはクラスター全体にわたってパーセンタイル ベースのメトリックをスライスおよびダイシングすることに関心がある場合は、それに応じて事前に集計する必要があります。

別のアプローチは、ヒストグラムを使用して、計算の互換性を得るために測定の精度をあきらめることです。いくつかのサーバーのヒストグラムを取得してそれらを合計するか、複数の時間枠のヒストグラムを取得してそれらを合計してから縮小することができます。問題は、この場合、パーセンタイルが正確ではなく推定値になることです。また、すべてのサンプルは単一の数値ではなく、いくつかのサンプル (バケットごとに 1 つ) であるため、ヒストグラムはストレージとスループットに時間がかかることに注意することも重要です。

概要

メトリクスは、アプリケーションを監視するための強力な方法です。しかし、それらは必ずしも実際のシステムの状態を表しているわけではありません。メトリクスが必要な質問に答えるのに実際に有用であることを確認するには、メトリクスの数学と性質、および慎重な設計を理解する必要があります。メトリックに加えて生データにアクセスできることは常に良いことです。これが最終的には真実の情報源だからです。

もっと学びたいですか？ OpenObservability Talks のエピソードをチェックしてください:すべてのメトリックが正しくなく、一部はSpotify 、 Apple Podcastsまたはその他のポッドキャスト アプリで有用です。

この記事はもともとここにありました。