メトリクス利用量分析と管理 - Metric Usage Analytics / Metric Pipeline Management

相変わらずの年末進行で、記事の投稿も遅れてしまいました。

Splunk Advent Calendar 19日目です。

https://qiita.com/advent-calendar/2024/splunk

オブザーバビリティに欠かせないメトリクスとその管理

現在のシステムやソフトウェアのステータスを傾向として把握するために利用されるのがメトリクスです。
あるメトリクスには、さまざまなラベル情報が付与されていることがあります。
例えば以下の場合、http_requests_total というメトリクスに対して、method と endpoint というラベルが含まれています。
「/home を GET したHTTPリクエスト数（http_requests_total）は 100 である」といった形で理解ができるはずです。

http_requests_total{method="GET", endpoint="/api"} 100

こういった <label_name>=<label_value> が存在することで、得られる情報が増え、分析などの際にも役立つことは想像に難くないでしょう。例えば、同じ /api に対するHTTPリクエストであっても、GET と POST 、どちらが支配的なのかを理解できるようになります。

http_requests_total{method="GET", endpoint="/api"} 100
http_requests_total{method="POST", endpoint="/api"} 5

一方でこういったラベルがあまり細かく分かれすぎてしますと、管理が大変になる懸念は十分にあります。
例えば、なんらか生成されたUUIDがラベルとして入っていたとします。

http_requests_total{method="GET", endpoint="/api", uid="372843b1-5129-1e2e-5cd4-55945ffb6434"} 100
http_requests_total{method="GET", endpoint="/api", uid="f1187d1e-4b1a-7eba-4367-97a8bdbb5384"} 21
http_requests_total{method="GET", endpoint="/api", uid="007b2864-05a1-1bc8-0ba2-40ff555ac24e"} 38
http_requests_total{method="GET", endpoint="/api", uid="b33d21cc-d827-9418-4f02-907b537f7a34"} 99
http_requests_total{method="POST", endpoint="/api", uid="f20c76aa-1ef5-c3d0-42ee-cb75cd549c65"} 8
http_requests_total{method="POST", endpoint="/api", uid="fb85ecb7-fec1-337e-825b-4bfcb66308e4"} 10
http_requests_total{method="POST", endpoint="/api", uid="57ea1e8c-0937-7b54-7e1e-6b30969617db"} 9
http_requests_total{method="POST", endpoint="/api", uid="1a7780bd-9e70-9fe8-0b17-5300a43804ce"} 22

UUIDはユニークIDとなるので、ラベルの値のバリエーションが非常に高い状態になります。こういったデータのことを「カーディナリティが高い」状態と言います。
基本的にはカーディナリティが高い方が粒度の細かな分析ができるようになるわけですが、一方で、こういったデータを効率的に処理するためにかかる計算機コストは高くなります。また、データ量も増えるため、ストレージコストも高くなってしまいます。
実際問題、この UID によって何か分析をすることがあるならばまだいいですが、そうではないなら、ただただ無駄なデータとなってしまいかねません。
SaaS型のオブザーバビリティバックエンドを利用している場合、これがそのままコストに跳ねる可能性もあります。
なんとかしたいところですね。

まずは状況を把握しよう

さて、じゃあ、どうするか。
Splunk Observability Cloudでは、取得されているメトリクスの取り込み・利用状況を確認することができます。
Metric Usage Analyticsという機能を見てみましょう。

"Metric Time series (MTS)" と書かれているパネルで、表示期間におけるMTS数、つまり、メトリクス名とディメンションの一意の組み合わせの総数を確認いただけます。また、そのMTSの推移が右のグラフです。

例えば、splunk_mpm.mean_latency_ms というメトリクスが存在しますが、

このメトリクスは、MTS数として 4567 が記録されているようです。その割に Utility score は高くないので、あまり活用されていないメトリクスのようです。
メトリクス名をクリックして、もう少し見てみましょう。

さて、この Dimensions のタブを見てみましょう。

どうやらこのメトリクスには3つのディメンション（上の例でいうところの「ラベルの名前」）が含まれているようです。
この中でも splunk_uid というディメンションに関しては、 Average hourly dimension values および Maximum hourly dimension values が 499 と記録されています。つまり、このディメンションに関しては499通りのデータが含まれているということです。他のディメンションは対してカーディナリティが高くなさそうですね。

ちなみに、その他のタブでは、

• Tokens タブ: メトリクス取り込みに利用しているアクセストークン（Splunk Observability Cloudへのデータ送信に利用する認証トークン）と、それぞれのMTS数
• Charts タブ: このメトリクスを利用しているダッシュボードとチャート名のリスト
• Detectors タブ: このメトリクスに基づいて設定されている監視アラート設定のリスト

を確認できます。このメトリクスがどう取り込まれて、どう利用されているかを確認できるわけです。

例えば、Charts タブを開いてみましょう。

どうやら splunk_mpm.mean_latency_ms by API というチャートの中でこのメトリクスが利用されているようです。
これを開いてみましょう。

赤枠のところを見てみると Maximum by splunk_api_id と設定されています。splunk_api_id というディメンション別の最大値を算出するようにしているようです。チャートを見ても 0, 1 ,2 という3つの項目でグラフ表示されています。

つまり、なんと splunk_uid というディメンションは高カーディナリティなデータを提供しているものの、実際は活用されておらず、結果的にMTS数を大幅に押し上げているということが分かったわけです。
データ量を増やす要因になっているにも関わらず、活用されていないということです。
うーん、これによって課金に影響を及ぼしていたら大変です。なんとかしなければなりません。

活用されていないメトリクスを節約しよう

お気づきかもしれませんが、先ほどの画面の右上のパネルに Create rules to reduce MTS count と書かれています。
この赤枠の中のボタンを押すと、Metric Pipeline Managementという機能に移動することができます。
（ここからは、上の例とはすこし異なるメトリクスを例にしています）

移動すると、こんな画面が表示されます。まずは Ingestion の下にあるパネルを開くと、

取得されるこのメトリクスをどのように処理するかを選択できます。

Real-Time は、取得されたメトリクスをそのまま利用しつづけます。既に利用されているチャートなどにもそのまま表示されつづけます。
Archived は、アーカイブ層にメトリクスを保存します。リアルタイムにチャートで表示したり、監視アラートに利用することはできませんが、問題が発生した時にこのメトリクスを改めて取得しなおし調査に使用することができます。アーカイブ層にデータを保管するので、メトリクスにかかるコストも抑えることができます。
Dropped は、取得されたメトリクスを破棄します。不要なメトリクスに関してはこれで削除してしまうことができます。例えば OpenTelemetry Collector などの、データ取得に関わるエージェント側の設定を変えずに済むのが嬉しいところです。

例えばここで Dropped を選択すると、メニュー画面が以下のように変化します。

Destination の下で Dropped MTS タブに -3897 と表示されています。つまり、3897のMTSを削減できたわけですね。

ただし、当然、「特定のディメンションを含むメトリクスだけは使い続けたい」と言った要望もあるはずです。
そのために、中央部の Added by rule というメニューが存在します。

例えば Route exceptions パネルを開いてみると、例外ルールを作成することができます。

例外ルール名を指定し、Filter MTS population for real-time routing の部分でルールを指定してあげます。
今回の例ですと cluster というディメンションについて MGMT という値が入っている場合、メトリクスを Drop することはせずに、Real-Time に利用できるようにしてあげています。

他にも Aggregate by Rule を用いると、特定のディメンションのみを持つ（＝取得されたメトリクスから特定のディメンションのみを削除したり、特定のディメンションのみを維持したりした）メトリクスを生成し、Real-Time にルーティングすることができるようになったりもします。

さあ、最終的にどうなったかというと、

当初は3897MTSを取得していたメトリクスのうち、不要な3711MTSは削減して、本当に必要なメトリクス（186MTS分）だけをリアルタイムに分析・監視用途で取り込み続けることができるようになった わけですね。
これで無駄使いしているわけではないんだと胸を張って言えることでしょう。

まとめ

いかがでしたでしょうか。
みなさんの関わっている事業や、それを支えるシステムが成長していくにつれて、システムにかかるコストというのもどうしても膨れ上がってしまうことかと思います。まして、マイクロサービスでどんどん機能を追加していって…という感じになっていくと、あるタイミングでメトリクス量が爆発してしまうはずです。
そのメトリクス量を、データ取得・計装の設定変更ではなく、オブザーバビリティバックエンド側で管理・コントロールできると便利なのではないでしょうか？
もし、こういったメトリクス管理にご興味を持っていただけましたら、お気軽にご連絡くださいませ。

それでは、良い年末をー。