「監視しているのになぜ気づかない」を解消した3つの施策（SRE / Datadog）

概要¶

Zenn 記事「監視しているのになぜ気づかない」を解消した3つの施策（solwat 著）を matsuu が紹介。「監視ツールは入れているのにユーザーから障害を教えてもらう」状態の原因と解決策をまとめたSRE実践記事。

元記事: https://zenn.dev/solwat/articles/f8e2c7a3b9d1f4

詳細¶

根本原因: 「監視できている」の定義がずれていた¶

「インフラが正常かどうか」を監視の目的にすると、CPU・メモリ・エラーレートがすべてグリーンなのに、ユーザーは「画面が真っ白」「ボタンが押せない」という状態が発生する。特定ブラウザのJavaScriptエラーはサーバーサイドのログには出ない。インフラは正常、アプリは壊れている。

施策1: ユーザー体験の計測（RUM）¶

フロントエンドで起きていること（JSエラー、描画速度、セッション中断）はサーバーログには出ない。

解決策: RUM（Real User Monitoring）を導入する。 - ツール例: Datadog RUM、Sentry - SDKを数行追加するだけで計装できる

// Datadog RUM の初期化例
import { datadogRum } from '@datadog/browser-rum';
datadogRum.init({
  applicationId: 'YOUR_APP_ID',
  clientToken: 'YOUR_CLIENT_TOKEN',
  site: 'datadoghq.com',
  service: 'your-app',
  sessionSampleRate: 100,
  trackUserInteractions: true,
});

難しいポイント: 導入の技術的ハードルより「フロントエンドの健全性をどう定義するか」を決める方が難しい。エラーをユーザーへの影響度で並べ直し（「エラーが出ている」→「この画面でセッションが途中で終わっている」）、優先度の判断基準を作ることが本質。

施策2: ログ整理（「捨てる」ではなく「分ける」）¶

「ログは取っている」が「多すぎて調査に使えない」状態は多い。「後で必要かも」で何でも残すのが問題。

解決策: ERROR/WARN と DEBUG/INFO を分離する。

ERROR・WARN → 専用インデックス（長期保持、常時参照）
DEBUG・INFO → 保持期間を短く or 取り込まない
ヘルスチェック・定期バッチ正常完了ログ → 削除対象

Datadog: Log Indexes 機能でフィルタリング条件ごとに別インデックスへ振り分け
ELK: インデックス分割 or OpenSearch/Elasticsearch のデータストリーム

「エラーだけを見に行く場所」を作ることで障害調査の最初の一手が変わる。設定変更は1日で完了するが、「このログは調査に使わない」という組織合意が一番時間がかかる。

施策3: アラート設計（信頼を失ったアラートは音と同じ）¶

毎日30件以上のアラートがSlackに流れているが、誰も見ていないチームが実在した。「重要かどうかわからないから全部流している」状態。

信頼が失われる2つの理由: 1. 鳴りすぎる 2. 鳴っても何もしなくていいことがある

解決手順: 1. 「このアラートが鳴ったとき、誰が何をするか」を全部書き出す 2. 答えられないものは一度止める 3. 残ったものの閾値の根拠を確認する（「なんとなく」が多い） 4. インフラ数値ベースの閾値 → ユーザー体験への影響ベースに置き換える

結果: アラート数が半分以下に。件数が減ることで「アラートが来たら見る」という文化が戻った。

3つに共通すること¶

設定を変えることより、判断の基準を変えることの方が時間がかかった。

「何を監視に値する状態と定義するか」はツールの問題ではなくチームの問題。ツールを変えてもこの問いは消えない。

なぜ重要か / いつ使うか¶

新規プロジェクトの監視設計時: インフラ監視だけでなくRUMを最初から組み込む
「障害はユーザーから教えてもらっている」と感じたとき: 3つの施策のどれが欠けているかを診断する
アラート疲れが起きているとき: 「このアラートが鳴ったら誰が何をするか」を書き出すワークショップを実施する
振り返りの起点: 直近1週間の障害1件を選び「監視で気づけたか／何が見えていなかったか」をレビューする