- Grafana製品群は、短い周期で主要コンポーネントを頻繁に廃止または置き換えるため、長期運用が難しい構造になっている
- 新しいソリューションを導入するたびに、設定方法、DSL、Helmチャート、Operatorなどが繰り返し変わり、安定した保守が難しい環境になっている
- Prometheus OperatorエコシステムとCRDの互換性が完全ではなく、ServiceMonitor・PodMonitorは使えても、AlertmanagerConfigなどの重要機能には対応の空白が生じる
- Mimir 3.0はApache Kafkaへの依存を強制的に追加し、クラスターの複雑さと運用負荷を大きく高める
- Grafana Cloudと、Mimir・Loki・Grafana製品群全体で設定箇所やエンドポイントが変更されやすく、一度構築して長く使い続けにくい構造が繰り返されている
Grafana製品群における頻繁な構造変更
- Grafana Agent、Flow Mode、OnCallなどの中核機能で、1〜3年以内に廃止・置き換えが繰り返されている
- AngularベースのGrafana UIはReactへ移行され、既存ダッシュボードのかなりの部分が壊れた
- Helmチャートの一部は、もはやメンテナンスされていない
Alloy導入による複雑性の増加
- All-in-oneを掲げるGrafana Alloyが既存のAgentを置き換えたが、初期には安定性の問題があった
- 独自DSL（HCLに類似）を採用し、従来のYAMLベースのフローと断絶している
- Alloy Operatorまで追加され、構成要素はさらに複雑になった
Prometheus Operatorエコシステムとの不完全な整合性
- K8sモニタリング標準である
ServiceMonitor、PodMonitorには対応しているが
PrometheusRulesは追加設定が必要AlertmanagerConfigは未対応- Mimirが独自のAlertmanagerを使用するため、バージョン差異と細かな非互換性が生じる
Mimir 3.0におけるKafka依存の導入
- 従来より高いスケーラビリティを目指したものの
- 中核構成にKafkaを必須で追加し、運用難易度が大きく上昇
- 単一Helmインストール → 複数コンポーネントの調整へと、複雑性が指数関数的に増大した
安定運用が難しいエコシステム
- Grafana Cloudのingestion endpointは、新しい管理システムの導入によってさらに見つけにくくなった
- 主要コンポーネントのアップグレード・廃止サイクルが速く、「退屈なくらい安定したモニタリング」を望む組織には合わない
- 技術そのものの問題というより、製品管理のやり方と変化の速さが信頼性を損なう中核要因として作用している
5件のコメント
influxdbで基本提供されるダッシュボードも、それなりにシンプルな用途なら使えます
Grafanaがいまひとつだという点には共感しますが、Grafanaほど多くのデータソースに対応しているソリューションで、ほかにおすすめできるものはあるでしょうか？
これといった代替がないんですよね
Grafanaでも昇進や職務経歴書の見栄えを良くしたい人が多かったようですね
Hacker Newsの意見
私も筆者と同じ理由で、Grafanaを完全に捨てるべきか真剣に悩んでいる
毎年ダッシュボードを作り直し、アラートを再設定し、新機能を追いかけなければならないのはうんざりだ
サービスが死んだときだけ知らせてくれればよく、データソースやメトリクスが変わらない限り、10年間同じダッシュボード定義を維持したい
昔はサイドバーに主要リンクが4〜5個あるだけだったのに、今はメニュー内のサブメニューが多すぎて、基本機能（ダッシュボード、アラート）を見つけるのも難しい
月に1回くらいしか見ないUIを毎回学び直さなければならないのは、あまりにも非効率だ
サービス寿命が2〜3年しかない状況で複数の製品を積み上げると、結局は技術的負債の山だけが大きくなっていく感覚がある
四半期ごとに何か大きなものを置き換えなければならない現実がつらい
Mimirは、まったく別次元の規模のメトリクスを処理するために設計されたシステムだ
そのレベルではKafkaが実際に必要になる
しかし大半のユーザーはそこまでのスケーラビリティを必要としていない
専用のKubernetesクラスターでMimirを動かしていないなら、過剰設計だ
素直にPrometheusを使うほうが現実的だ
単一インスタンスモードでも驚くほどよく動作し、拡張も非常に簡単だ
複数の組織や個人プロジェクトで使ってきたが、いつも満足していた
だが、AWSのAmazon Managed PrometheusはCortexベースで、OpenObserveもすでにペタバイト規模で運用されている
単一バイナリでデプロイが簡単で、OpenTelemetryと互換性があり、後から別のOTELプロバイダーへ移行できるものが理想的だ
OTELベースで新しいソリューションを作るなら、Prometheus/Grafanaの代替として何が最も有望なのか気になる
ログやトレースを扱うには、さらに複雑なコンポーネントが必要だった
そこでGreptimeDBを見つけ、メトリクス・ログ・トレースの統合処理が可能だった
OpenTelemetryで収集し、Grafanaで可視化している
SQLでダッシュボードを作れるので、チームのスキルセットにも合っている
シンプルな構成のおかげで、プラットフォームエンジニアとして満足している
GrafanaとElasticの複雑さを解消するために作られ、単一コンテナでログ・メトリクス・トレース・ダッシュボード・アラートをすべて処理できる
（投稿者はOpenObserveのメンテナー）
オープンソースで活発に開発されており、チームとのコミュニケーションも良い
複数のバックエンドを自分で扱わなければならないGrafanaの複雑さを避けたいユーザーが多く移ってきている
（投稿者はSigNozのメンテナー）
なぜ開発者たちが毎週設定を変えながら最新技術を追いかけるのか分からない
私は2017年からGrafana + Prometheusの組み合わせを使ってきたが、今でも問題なく動いている
1〜2年に一度、LTS版にだけ更新している
ダッシュボードはいまだに完璧で、何の問題もない
ほとんどの人にとって、この退屈だが安定した組み合わせが最善だ
もしかして旧バージョンをそのまま使っているのか聞いてみたい
オープンソースでGrafanaを置き換えられるダッシュボードビルダーはあるだろうか？ 会社でもGrafanaを広く使っている
あるいはPrometheusのコンソールテンプレートやVictoriaMetrics内蔵ダッシュボードを使うこともできるが、機能はかなり限定的だ
Grafanaダッシュボード自体は、VictoriaMetrics + ClickHouseの組み合わせで使うぶんにはかなり快適だ
RRDやNagiosのような名前だけがうっすら記憶に残っている
Grafanaの絶え間ない変化には、むしろ慣れてしまった
major releaseのたびにダッシュボードが壊れたりUIが変わったりするが、もうそういうものだと思っている
本当の問題はPrometheusのPromQLロックインだ
メトリクス名を変えると、すべてのルール、アラート、ダッシュボードを修正しなければならない
PromQLは構文エラー以外ほとんどエラーを出さないので、pintのようなツールで検証する必要がある
単一サーバーへのデプロイでは、Prometheus Pushgateway + Grafanaをdocker-composeテンプレートとしてよく使う
シンプルでうまく動くが、メトリクス量が増えると複雑さが爆発する
Prometheusがもっと効率的な転送フォーマットを維持していれば、この問題はもう少し軽かったはずだ
テキストフォーマットではなくコンパクトなバイナリメトリクス形式があれば、数百万単位のラベルでも無理なく処理できただろう
SigNozは良い選択肢で、活発に開発されている
以前はクラウド監視プラットフォームにかなりの費用を払っていたが、今はHetznerのボックスにself-hosted SigNozを載せて月10ドルで済ませている
PrometheusとGrafanaがそれぞれフルスタックソリューションを志向していたところにOTELが登場し、状況が複雑になった
OTELはメトリクス・トレース・ログ用のプロトコルだが、これをサポートする単一のDBはない
ほとんどはPrometheus（メトリクス）+ OpenSearch（ログ）を組み合わせている
結局OTELはコレクターの置き換えと再構成を要求するものになっている