ObservabilityCON on the Road Tokyoレポート第1回

Grafana Labsがミニカンファレンスを開催。共同創業者と新規プロダクト担当シニアディレクターのセッションを紹介

Grafana Labsがミニカンファレンスを開催。共同創業者と新規プロダクト担当シニアディレクターのセッションを紹介する。

6:00

オブザーバビリティのGrafana Labsが都内でObservabilityCON on the Road Tokyoを開催。これはGrafana Labsが世界各地で行っているロードショーを模したシングルトラックのミニカンファレンスだ。このカンファレンスは2025年2月にも東京で開催され、CEOのTom Wilkie氏が来日して講演を行った。その際にインタビューも行っているので、以下の記事を参考にして欲しい。

●参考：Grafana Labs CTOのTom Wilkie氏インタビュー。スクラップアンドビルドから産まれた「トラブルシューティングの民主化」とは

Grafana Labsは2つのカンファレンスを開催している。今回紹介するObservabilityCONが、Grafana Labsが提供する最新のテクノロジーの実践の場でもあるGrafana Cloudの最新情報やユースケースを伝えるイベントであるのに対し、GrafanaCONはオープンソースのGrafana関連のソフトウェアに対するコミュニティ向けのイベントという位置づけである。これら2つのカンファレンスを使い分けているのが特徴的だ。

GrafanaCONに関しても2025年5月にシアトルで開催された際のレポートを参照してみてほしい。

●参考：GrafanaCON 2025開催、最新のGrafana関連の情報を解説。キーノートから見るリアルな運用現場に対応したAIアシスタントとは？

今回のカンファレンスはGrafana Labsの共同創業者であるAnthony Woods氏と新規プロダクト担当シニアディレクターであるMarc Chipouras氏によるキーノートから始まった。この稿では2名のプレゼンテーションの内容とその後に行われたChipouras氏の講演を交えて紹介する。

Chipouras氏（左）とWoods氏（右）

ObservabilityCONとGrafanaCONについては冒頭で解説が行われた。ここではObservabilityCONはオブザーバビリティのフラッグシップカンファレンス、GrafanaCONはオープンソースコミュニティイベントであるというように違いが説明されている。

GartnerのリサーチでもGrafana Labsはリーダーの地位に

GartnerのリサーチでもGrafana Labsはリーダーの地位にいることを説明し、各社が激しい競争を繰り広げているオブザーバビリティの領域で評価されていることを強調した。

Grafana Cloudがオープンであることを強調

このスライドではオープンであることが重要であると強調し、DatadogやNew Relic、DynatraceといったSaaS専業のオブザーバビリティベンダーとの違いを暗に見せた形になった。

そしてGrafana Cloudが「安価なコスト」「シンプル」「実務で使えるAI」という特徴を備えていることをここから解説するという流れになった。

SaaSのオブザーバビリティベンダーに付きまとう高価であることをアンチテーゼとして提示

安価であることのポイントはAdaptive Telemetryであるとして、Metrics、Logs、TracesそしてProfilesにAdaptive、つまり状況に合わせて適応できる安価なソリューションであること、つまりデータ量を削減したオブザーバビリティを実現できていることを解説した。

2023年から始まったAdaptive Telemetryの開発タイムライン。最新はProfileに適用

このスライドでは2023年から2025年に至る時間の中でメトリクス、ログ、トレースなどにおいてデータを必要に応じて削減することで、高価であると非難の対象になりがちなオブザーバビリティSaaSの課題を解決しようとしていることを解説した。

トレーシングでは価値のあるデータだけを保存することでデータ量を削減

この結果、90％のトレースデータを削減することができると説明した。

トレースデータの90％を削減可能となった

プロファイリングについてもすべてのプロファイリングデータを取得するもののインテリジェントにサンプリングすることで85％のデータを削減可能となったと説明。

またデータ量が膨大になるエンタープライズ向けには、Grafana Cloud以外にオープンソースのインスタンスを自社で実装する方法や自社が使っているクラウドサービスにGrafana Cloudを実装するBYOC（Bring Your Own Cloud）の実装方法も選択可能であることを説明した。セッションの最後に行われた質疑応答ではどの程度のデータ量になればコストが逆転するのか？という質問も出たが、具体的な数値は提示することはなかった。

クラウドサービスからBYOCまでの利用方法を説明。コストとデータ量のバランスの問題

またアメリカ以外では関係のないトピックではあるが、米国政府機関向けのGrafana Federal Cloudもサービスとして一般提供が始まったこと、データベースそのものに対するオブザーバビリティ機能、Database Observabilityもパブリックプレビューとして公開が始まったことなどを説明した。

データベースのオブザーバビリティ機能を発表

他にもFleet Management、Instrumentation Hubなどの新機能を簡単に解説したが、障害時の対策という意味で大きな内容となったのはナレッジグラフを使った原因分析の機能だろう。

グラフデータベースを使ってコンテキストを理解する原因分析を可能に

フルスタックであるという点を強調、これはフロントエンドからデータベースまで網羅するオブザーバビリティを提供することを意味している。

またGrafana製の生成AIを使ったアシスタントとしてGrafana Assistantを紹介。ここでは多くの機能が大規模言語モデルを使って提供されていることが示されている。生成AIとしてどのモデルを使っているのか？についてはここでは解説されなかった。

グラフデータベースを使ったナレッジグラフ機能

システム運用者を助けるという発想でチャットをベースにしたアシスタント機能は他社も発表している機能だが、MCPの実装に合わせてさまざまなオブザーバビリティのためのエージェントが用意されていることを紹介。

AIによるチャットからエージェントによる自動実行へ

単にチャット機能による実装でないことは、次に紹介されたInvestigationsという新機能からも見て取れる。これは名前からわかるように発生した障害を詳しく捜査するという新しい機能である。

Assistantの新機能、Invesitigationsを紹介

Chipouras氏はInvestigationsのUIを見せながら、レイテンシーが悪化した障害の根本原因を追及していくようすをデモで見せた。

InvestigationsのUIをデモで紹介

なおGrafana Assistantは1ユーザーに対して$20／月の課金が必要である。他方Invesitigationsのほうは、パブリックプレビューという状態であるため、すでにGrafana Cloudを利用しているユーザーはAssistantを利用することで、Invesitigationsの機能を評価することが可能となる。

Grafana Assistantは1ユーザーに対して20ドル／月で利用可能

次に紹介するのはこのキーノートセッションの2つ後に実施されたMarc Chipouras氏によるセッション「AI+Grafana Cloud IRM、SLO、アラート機能でサービスの安定稼働を担保する組織風土をつくる」と題されたセッションだ。これはIncident Response Management（IRM）、障害に対する対応管理を生成AIの助けを借りて行うという内容となっている。

企業においてインシデント処理は信頼性を保つためには必須であるという切り出しから始まったセッションは、生成AIがコードを大量に生成する時代になったことで、デベロッパーがその内容を正確に理解することが徐々に難しくなっていることを指摘。これは人間がコードを書かないことでソースコードに起因する障害時の切り分けが難しくなっていることを意味していると思われるが、実際にはコードに対するコメントが充実していることや記法の揺れが少ないなどコードを生成AIが作ることの利点もあることも記憶にとどめておくべきだろう。

コードを生成AIが書くことでコードの理解が難しくなることを指摘

インシデント対応が遅れることの原因を挙げて、「アラートが出過ぎることで疲弊してしまうこと」「初期のレスポンスが遅れること」「チーム間の連携の悪さ」などを紹介した。

インシデント対応が遅れる要因を解説。疲弊してしまうことが最も大きな原因

インシデント対応のためのツールスタックが分断されていることで、対応のためのコストが増加してしまうことも指摘。これはオブザーバビリティツールに加えてSlackやPagerDutyなどのソリューションが別途必要になることを指摘していると思われる。

Grafana IRMはオブザーバビリティデータを中心にしたインシデント管理のツール群

実際にここからはデモを行ってコマースサイトのチェックアウトが遅くなったことで離脱率が上がってしまったというシナリオに基づいて解説を行った。

IRMのためにはCommanderとInvestigatorというロールのユーザーが必要

ここで注目したいのは、インシデント管理は個人で行う仕事ではないというGrafana Labsの考え方だ。これはインタビューで繰り返しChipouras氏から発言があった内容だが、インシデントが発生してそれに対する対応を行うのはチームの仕事であるべきという発想だ。コーディングアシスタントであれば、利用者は個人だが、担当する分野が違うエンジニアが対応にあたるインシデント管理においてはチームとして仕事が行われるのが現実的なあり方だろう。それを先行するPagerDutyと同じように実装しているのは良い方向だ。

実際にはすでにSlackやMicrosoft Teamsなどを使っているユーザー向けには連携機能が用意されており、スムーズに利用が可能であることがデモで示されていた。