ログと監視 — 誰より先に、壊れていることに気づく

What — 3つの役割を分ける

http_requests_total{status="500"} 42
http_request_duration_seconds{quantile="0.99"} 1.8
db_connections_active 47

→ グラフにできる
→ 閾値でアラートを出せる
→ 個々のリクエストの詳細は分からない

構造化ログ

// 文字列を連結する：後から検索・集計できない
logger.info(`ユーザー ${userId} が注文 ${orderId} を作成（${ms}ms）`);

// 構造化する：フィールドで検索・集計できる
logger.info('注文を作成', { userId, orderId, durationMs: ms, traceId });

構造化しておくと、こういう問い合わせができます。

• durationMs > 1000 のログだけを抽出する
• userId ごとのエラー件数を集計する
• 特定の traceId に関するログを全部集める

文字列連結で書くと、これらは正規表現との戦いになります。

何をログに出してはいけないか

// 絶対に出さない
logger.info('ログイン', { password, creditCard, sessionToken });

// 個人情報も慎重に
logger.info('注文', { email, phone, address });   // ← 保存期間と閲覧権限を考える

ログは複数の場所にコピーされます。 ログ基盤、バックアップ、開発者のローカル、監視 SaaS。一度出力すると回収できません。

Why — なぜアラートは「少ないほど良い」のか

監視の目的は「異常に気づくこと」です。しかし気づくのは人間なので、人間が処理できる量を超えると機能しなくなります。

冒頭の事故は、監視の不足ではなく過剰が原因でした。

アラートの設計で守るべき原則は1つです。

アラートは、人間が今すぐ行動すべきときにだけ鳴らす。

• CPU 使用率が 80% を超えた → 行動できない（放っておけば戻る）
• エラー率が 5% を超え、5分継続した → 行動すべき
• ディスク使用率が 95% → 行動すべき（数時間以内に埋まる）

「知っておくといい情報」はダッシュボードに置きます。アラートにはしません。

症状で監視する

監視の対象は、原因ではなく症状にします。

❌ 原因ベース: CPU が高い / メモリが多い / ディスク I/O が多い
   → 高くても利用者が困っていないことがある
   → 低くても利用者が困っていることがある

✅ 症状ベース: エラー率が高い / レスポンスが遅い / 処理が滞留している
   → 利用者が困っていることと直結する

利用者が困っていないなら、CPU が 90% でも問題ではありません。 逆に、CPU が 20% でもエラーが出ていれば問題です。

Google の SRE では「4つのゴールデンシグナル」として次が挙げられます。

SLO で判断を機械化する

SLO: 直近30日で、リクエストの 99.9% が成功する

エラーバジェット = 0.1% = 30日で約 43 分の失敗が許容される

この数字があると、判断が機械的になります。

• バジェットが余っている → 新機能のリリースを進めてよい
• バジェットを使い切った → 機能開発を止めて安定性に投資する

「安定性と開発速度のどちらを優先するか」という議論を、数字で決着させられます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。