博士

やあ、ロボ子！今日のITニュースはGrafana製品についてじゃ。

ロボ子

Grafanaですか、博士。最近よく耳にしますね。どんな内容なのでしょう？

博士

この記事の筆者は、Grafana製品を初期の頃から使っているみたいじゃな。Loki、Prometheus、Grafanaを使い、Kubernetes環境への移行時にMimirとGrafana Agentを採用したそうじゃ。

ロボ子

なるほど。初期からのユーザー視点での記事なのですね。

博士

そうじゃ。GrafanaがDataDogの顧客獲得を狙って、Grafana OnCall等の新機能を開発したり、Helm chartsやGrafana Operatorを推進したりしたことにも触れておるぞ。

ロボ子

DataDogの顧客獲得ですか。競争が激しいのですね。

博士

じゃが、Grafana OnCallとGrafana Agent/Agent Flowは2～3年で廃止され、AngularからReactへの移行で既存ダッシュボードが破損したらしいぞ。技術の進化は早いものじゃ。

ロボ子

それは残念ですね。安定性を求めるユーザーには厳しいかもしれません。

博士

Grafana Alloyもリリースされたが、kube-prometheusコミュニティの標準であるServiceMonitor、PodMonitor、PrometheusRulesのAPIグループCRDを完全にはサポートしていないらしい。

ロボ子

標準との互換性は重要ですよね。移行の障壁になる可能性があります。

博士

Mimir 3.0ではApache Kafkaが必須になったり、Grafana Cloudの取り込みエンドポイントが探しにくくなったりしたそうじゃ。変更が頻繁だと、ユーザーは混乱するかもしれんの。

ロボ子

確かにそうですね。ドキュメントの整備も重要になりそうです。

博士

筆者は、Grafana製品の技術的な品質は高いものの、変更の速さとキャリア主導の開発により、安定性を求めるユーザーには不向きだと考えているようじゃ。

ロボ子

なるほど。技術力は高いけれど、変化が激しいのですね。

博士

OpenShiftのアプローチ（kube-prometheus-stackとThanos）が最も安定している可能性があるとも言っておるぞ。OTELの早期安定化を期待し、ベンダーロックインを避けたいとも。

ロボ子

ベンダーロックインは避けたいですよね。柔軟な選択肢があるのは良いことだと思います。

博士

Grafana製品は、常に最新技術を追いかけたい人には向いているかもしれんが、安定性を重視する人には、他の選択肢も検討する余地があるということじゃな。

ロボ子

よくわかりました。博士、ありがとうございました。

博士

どういたしまして。しかし、Grafanaの変更の速さには驚かされるのじゃ。まるで、私が昨日作ったプリンが、今日にはもう新しいフレーバーになっているようなものじゃ！

ロボ子

それは困りますね。博士のプリン、楽しみにしていたのに。