Grafana Labsが、Kubernetes Monitoring Helm chartの v4 を出しました。
Helm chartというのは、ざっくり言うと Kubernetesにアプリや監視基盤をまとめて入れるための設定テンプレート です。
このchartは、Kubernetesクラスタから metrics（数値の監視情報）・logs（ログ）・traces（処理の流れ）・profiles（性能解析情報） を、Grafana Cloudや自前のGrafana環境へ送るためのものです。
監視の世界では、こういう「まとめて面倒を見てくれるセット」は便利な反面、ユーザーが増え、環境が複雑になるほど設定のつらさが目立ってきます。今回のv4は、まさにその“つらさ”を解消するための大改修だといえます。
InfoQの記事によると、v4は 約6か月の計画と開発 を経て投入され、GrafanaのPete Wall氏とBeverly Buchanan氏は「これまでで最も重要な更新」と位置づけています。
この言い方はかなり強めですが、内容を見るとたしかに大げさではないと思います。実運用で効いてくる変更が多いです。
これがかなり大きいです。
v3では、送信先（destination）を list（順番つきの一覧） で定義していました。
一見わかりやすそうですが、複数クラスタを同じ設定ファイル群で管理したり、Argo CD / Terraform / Flux みたいなGitOpsツールを使ったりすると、「順番」に依存する設定 が地味に危険になります。
たとえば、パスワードだけ差し替えたいとき、リストの何番目かを指定して上書きする必要がありました。
でも、後から並び順が変わると、意図しない送信先に設定が当たる 可能性があるわけです。これは怖い。かなり怖い。設定ミスというより、設定が静かにすり替わる タイプの事故が起きうるので。
v4では、destinationに 安定した名前 が付きます。
そのため destinations.prometheus.auth.password のように、名前で確実に対象を指せる ようになりました。
Helmはmap同士のマージが得意なので、複数ファイルを重ねるGitOps運用でも、かなり扱いやすくなります。
v3では alloy-metrics、alloy-logs、alloy-singleton のような ハードコードされたcollector名 がありました。
しかも、どの機能がどのcollectorに載るかは chart内部のロジックに隠れていて、設定ファイルを見ただけでは追いにくかったのです。
これ、運用者からするとかなりモヤっとします。
「設定したはずなのに、実際どこに入るの？」がコードを読まないと分からないのは、あまり親切ではありません。
v4ではcollectorを mapとして定義 し、それぞれに clustered、statefulset、daemonset みたいな preset を割り当てます。
そのうえで、各機能をどのcollectorに紐づけるかを 明示的に指定 します。
つまり、chartの内部に隠れていたロジックを、ユーザーが見える設定に引っ張り出した感じです。
これはとても健全だと思います。便利さよりもまず「読めること」「予測できること」を優先している。運用ツールとしては正解寄りです。
Grafana側も「指定し忘れたら、勝手に選ぶのではなく、どのfeatureをcollectorに割り当てる必要があるかメッセージで教える」と説明しています。
この“勝手にやらない”方針は地味ですが重要です。自動化が多いほど、静かな誤動作 は本当に嫌われますから。
v3では、たとえば clusterMetrics を有効にすると、裏側で Node Exporter、kube-state-metrics、OpenCost なども黙って入ることがありました。
これ、初回導入なら「おお便利」と思うかもしれませんが、すでに同じサービスを別で動かしている環境ではかなり厄介です。
気づいたら同じものが2つ動いていた、というのは監視基盤あるあるです。
しかも監視は“壊れてもすぐ見えない”ことがあるので、重複や競合が地味に効いてきます。
v4では telemetryServices というキーが導入され、サービスのデプロイを明示的に扱う ようになりました。
つまり、すでにNode Exporterがあるなら、それを使うようにして chart側では新規デプロイしない という運用が可能です。
Grafanaの言う “no more surprise deployments” は、まさに運用者の心を代弁している感じがあります。
勝手に増えるものほど、現場では信頼されません。
v3では clusterMetrics の中に、Kubernetesのクラスタメトリクスだけでなく、Linux/Windowsのホストメトリクス、Keplerによるenergy metrics、OpenCostによるcost metricsまで全部入っていました。
1つの設定ブロックに詰め込みすぎです。正直、これは読むだけで息が詰まるタイプの設計だと思います。
v4ではこれが以下に分かれました。
clusterMetricshostMetricscostMetricsそれぞれ別のvalues fileになり、設定もその機能に関係あるものだけが見えるようになります。
この分割はかなり好印象です。設定項目が減るだけでなく、「何を有効にしているか」が人間の目でもわかりやすくなる からです。
ここも実運用ではかなり重要です。
v3では、Kubernetes Podのlabelsやannotationsをいったん 全部ログラベルとして付けてから、labelsToKeep で不要なものを削る仕組みでした。
これだと、場合によっては 何百ものラベルをメモリに乗せてから捨てる ことになります。無駄が大きい。
実際に、ログ収集用のAlloyインスタンスでメモリ問題が出たユーザーもいたようです。
これは想像しやすいです。ログ基盤はただでさえデータ量が多いので、余計な膨張はかなり痛いです。
v4では labelsToKeep を廃止し、最初から全部は付けない方針になりました。
必要なラベルだけを 明示的にpromoteする 形です。
Grafanaのドキュメントによると、ラベル追加も以前よりずっと簡単で、1行で済む ようになったとのこと。
この変更は、派手さはないけれど実に良いです。
「速い」より「太らない」。監視系ではこういう改善のほうが長く効くと私は思います。
今回のv4は、単に新機能を足したというより、運用で嫌われるポイントを丁寧に削った リリースです。
こういう更新は、デモでは地味に見えることがあります。でも、現場ではかなり効きます。
特に印象的なのは、全体を通して “暗黙の自動化” を減らしている ことです。
勝手に順番で解決しない、勝手にcollectorを選ばない、勝手にサービスを増やさない。
この方向性は、複雑なクラスタをたくさん抱えるチームにとってはありがたいはずです。
一方で、設定の書き方は少し変わるので、既存ユーザーは移行作業が必要になります。
ただ、それでもv3のまま複雑さを抱え続けるより、v4に寄せたほうが長期的には楽ではないか、というのが率直な感想です。
逆に、単一クラスタで単純な構成しか触っていないなら、「そこまで大きな話ではない」と感じるかもしれません。
でも、監視基盤は最初は小さくても、気づくとすぐ複雑になります。だからこそ、今回のような整理は先回りとして価値があると思います。
GrafanaのKubernetes Monitoring Helm chart v4は、見た目の派手さよりも、運用のしんどさを減らす実務的な改善 が詰まったアップデートです。
特に、listからmapへの変更や、collector・telemetryServicesの明示化は、GitOpsやマルチクラスタ運用でかなり効いてきそうです。
監視ツールは「動く」だけでは足りません。
予測できること、壊れにくいこと、後から読めること が大事です。
今回のv4は、その基本にかなり忠実な改善だと感じました。
参考: Grafana's Kubernetes Monitoring Helm Chart v4 Brings Multiple Fixes - InfoQ