Grafana Faro：Webアプリケーションのユーザー体験（RUM）を可視化する「監視の目」 – ITFROMZERO

Table of Contents

ダッシュボードが「正常」でも、ユーザーが離脱している理由

午前2時、スマートフォンが激しく振動する。Prometheusのダッシュボードを確認すると、CPU使用率はわずか15％、メモリも十分、Nginxのログもすべて200 OKを返している。一見、すべてが完璧に見える。しかし、Facebookページでは顧客から「『購入』ボタンを何度押しても反応しない」という不満が寄せられていた。

PrometheusやZabbixのような従来のモニタリングツールは、主にサーバー側の状態しか把握できません。ユーザーのブラウザ内で何が起きているかについては、完全に「盲目」です。JSファイルの読み込みエラー、不安定なネットワーク、あるいはレンダリングを妨げている5MBもの巨大なCSSファイルが原因かもしれません。

Grafana Faroは、この問題を解決するための最後のピースです。これはクライアント側の微細な挙動を可視化するReal User Monitoring（RUM）ソリューションです。ログにLoki、トレースにTempoをすでに使用しているなら、Faroを導入することで真の「フルスタック・オブザーバビリティ」を実現できます。

バックエンドの設定：データ収集ステーションの構築

ブラウザからのデータはデータベースに直接送信されるわけではありません。中間コレクターを経由する必要があります。以前はGrafana Agentが使われていましたが、現在はより柔軟で最適化されたGrafana Alloyが推奨されます。

ステップ1：Grafana Alloyの設定

サーバー上にconfig.alloyファイルを作成します。ブラウザ側のFaro SDKからデータを受信するためのエンドポイントを開放する必要があります。

faro.receiver "default" {
  server {
    listen_address = "0.0.0.0"
    listen_port = 12347
    cors_allowed_origins = ["https://yourdomain.com"] 
  }

  output {
    logs   = [loki.write.local.receiver]
    traces = [otelcol.exporter.otlp.tempo.receiver]
  }
}

重要な注意点： プロダクション環境では、決して cors_allowed_origins = ["*"] と設定しないでください。見知らぬドメインからデータが送りつけられ、1日に10GBものゴミログで溢れかえり、ストレージ費用が無駄に膨れ上がった事例を私は見てきました。

ステップ2：Lokiへの接続

次に、ログの保存先を定義します。Lokiをセルフホストしている場合は、以下の設定にサーバーのIPアドレスを正確に入力してください。

loki.write "local" {
  endpoint {
    url = "http://loki-server:3100/loki/api/v1/push"
  }
}

フロントエンドへのFaro SDKの組み込み

「収集ステーション」の準備ができたら、Webアプリケーションにセンサーを取り付けます。FaroはReact、Vue、Angular、そして純粋なJavaScriptを強力にサポートしています。

ライブラリのインストール

npmを使用して、プロジェクトにSDKを追加します。

npm install @grafana/faro-web-sdk

ソースコードでのFaro의 初期化

アプリケーションがロードされた瞬間からエラーを逃さないよう、index.jsやmain.tsなど、最初に実行されるファイルに初期化コードを記述してください。

import { initializeFaro } from '@grafana/faro-web-sdk';

initializeFaro({
  url: 'https://telemetry.yourcompany.com/collect',
  app: {
    name: 'ecommerce-frontend',
    version: '1.2.0',
    environment: 'production',
  },
  instrumentations: [
    ...getWebInstrumentations(),
    new TracingInstrumentation(),
  ],
});

ノイズを避けるコツ： すべてをログに記録しないでください。私は以前、通常の console.log までキャプチャするという失敗をしました。その結果、開発チームの大量の不要なログに埋もれて、重要なエラーが見えなくなってしまいました。uncaught exceptions（未捕捉の例外）と error logs に絞って監視しましょう。

データの活用：数値をアクションに変える

データがGrafanaに届き始めると、これまで「推測」するしかなかった情報が明らかになります。

1. 実際のWeb Vitals指標

Faroはユーザー体験を評価するための重要な指標を提供します。

LCP (Largest Contentful Paint): この数値が2.5秒を超える場合は、画像を最適化してください。5MBのバナー画像1枚が、ユーザー離脱の主犯かもしれません。
CLS (Cumulative Layout Shift): レイアウトのガタつきを測定します。ロード中にボタンの位置が勝手に動くようなサイトを好むユーザーはいません。

2. JavaScriptエラーの追跡

GrafanaのExploreメニューでは、各エラーのスタックトレースを詳細に確認できます。Faroはブラウザ、OS、さらには画面解像度の情報まで提供します。これにより、QAチームは顧客に「どの端末で、どこをクリックしましたか？」と聞き出す手間を省き、迅速にエラーを再現できます。

3. ネットワーク遅延（Network Latency）

サーバー側の処理はわずか50msなのに、Faroではユーザーが2秒待たされていると報告されることがあります。この差に気づくことで、ネットワーク経路の問題や、APIのペイロードが重すぎてブラウザの処理が追いついていないといった原因を特定できます。

実導入からのアドバイス

Faroの導入は難しくありませんが、データをいかにフィルタリングするかが鍵となります。まずはJSエラーとWeb Vitalsの監視から始め、徐々に分散トレーシング（Distributed Tracing）へと広げていくのが良いでしょう。

Faroを導入してから、深夜の緊急電話が激減しました。推測に頼るのではなく、ダッシュボードを開いて「地域XのユーザーがChromeのバージョンYでエラーに遭遇している」と明確に指摘できるようになったからです。これこそが、プロフェッショナルなシステム運用の姿です。