デモ：ベテランの“勘”をAIが代替──RCA workbenchで挑む障害調査の自動化
2点目のデモは障害発生時の原因分析から対応までの迅速化だ。Grafana Cloudの独自機能となる「RCA（Root Cause Analysis：根本原因分析）workbench」を使う。
一般的には障害が起きると、メトリクスを確認し、ログを調べ、設定変更がないかを確認するなど、複数の画面を行き来して調査する必要がある。一方、Grafanaに実装されているRCA workbenchでは、障害の原因分析プロセスを1つのタイムラインで進めることができる。
例えばある日、運用担当者が使うSlackに「プロダクトカタログサービスにて障害が発生」と通知が届いたとする。そこで担当者がGrafanaを開くと、KubernetesのPodのクラッシュが多発していることや、エラー割合がしきい値を超えたことを確認できる。
さらに原因特定に役立つ情報が自動的に抽出される。ここでは最近「フィーチャーフラグ」という設定が変更されたことが操作履歴などから表示されていた。アプリケーションで新しい機能をリリースするとき、何らかの設定を変更することはよくある。こうした何気ない変更がKubernetesに影響を与えていたのだ。
ではどうして設定変更から障害につながってしまったのか。RCA workbenchでは、障害が起きているサービスがどのようなコンポーネントから呼び出されているのか、依存関係のグラフをマップ形式で自動生成する。そうして追っていくと「PostgreSQLのクライアント接続数エラーが発生している」と原因を特定できる。
こうした作業はベテラン運用者であればすぐできるかもしれない。しかし経験が浅い、または現場に参加して間もなく、システム構成を把握できていないと、手間取ってしまう。RCA workbench機能ではログやメトリクスを多角的に分析し、「設定変更による連鎖障害」といった形で、結論を日本語で回答してくれる。
原因特定後には復旧支援も行う。RCA workbenchでは、時系列で重要なアラートや変更履歴を示してくれる。このデモでは、フロントエンドでクリティカルなAPIエラーがアラートとして表示されていた。ここでGrafana Assistantに「復旧策を提示してください」と入力すると、AIが復旧策を提案してくれる。デモでは設定変更による連鎖障害だったため、即時対応としてロールバックが提案された。加えて恒久的な対策として、設定の見直しや、接続数制限の調整などが提案された。
ここまではPrometheusにあるメトリクス情報だけで分析が進められていたが、「ログも含めて影響範囲を調査して」と依頼すると、ログを横断検索して該当する時間帯にあるエラーを抽出する。これまで運用担当者が各種ログにアクセスしてgrepで抽出するといった作業をGrafana Assistantが同時並行で実施する。
続いてレポート作成のためのInvestigation機能だ。こちらもGrafana Cloudに実装されている。今回のエラーに対して調査プロセス全体をドキュメント化するため、事後の振り返り（ポストモーテム）にそのまま使える形に集約する。
なお「AIだからハルシネーションが起こるのでは」という懸念に対しては、AIがどのログの何行目を見て判断したのか証跡も残しているため、リスクを最小化できる。もし見当違いのログを見ていたら、再調査させることも可能だ。
最後に角田氏は「AIはコンテキストが重要。必要なデータがなければAIも宝の持ち腐れとなる。そしてGrafanaほど豊富なデータを持つものはない。Grafanaはエンドツーエンドのオブザーバビリティプラットフォームで、圧倒的な洞察力、テレメトリデータ、そしてコンテキストを提供できる」とGrafanaおよびGrafana Cloudの強みを強調した。
Grafana Labsからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
