モニタリング・ログ設計で障害対応時間を1/5に
適切なログ設計とモニタリング体制により、弊社では平均障害対応時間（MTTR）が4.2時間から52分へ80%短縮、障害検知時間が15分から2分へ86%短縮、根本原因特定率が98%に到達しました。
モニタリングとログは障害対応の命綱であり、適切な設計により、ダウンタイムを最小化し、ビジネスへの影響を大幅に軽減できます。
ログ設計の5原則
1
構造化ログ（JSON形式）
平文ログではなく、JSON形式で出力することで、検索・集計・分析が容易になります。
✅ 良い例（JSON）
{
"timestamp": "2024-02-01T12:34:56Z",
"level": "ERROR",
"message": "User login failed",
"user_email": "[email protected]",
"user_id": null,
"ip_address": "192.168.1.100",
"request_id": "req-abc-123",
"error_code": "INVALID_PASSWORD",
"service": "auth-service",
"environment": "production"
}→ 検索・集計・アラート設定が容易
2
リクエストIDで全ログを追跡
1つのリクエストが複数のサービスを経由する場合、同一のリクエストIDで追跡可能に。
実装例（Express.js）:
import { v4 as uuidv4 } from 'uuid';
app.use((req, res, next) => {
// リクエストIDを生成または取得
req.id = req.headers['x-request-id'] || uuidv4();
res.setHeader('x-request-id', req.id);
next();
});
// ログに必ずリクエストIDを含める
logger.info({
request_id: req.id,
method: req.method,
path: req.path,
message: 'Request received'
});3
ログレベルを適切に使い分け
ERROR（即対応が必要）
システムエラー、API呼び出し失敗、DB接続エラー
WARN（監視が必要）
リトライ成功、タイムアウト間近、ディスク容量80%
INFO（通常動作）
ユーザーログイン、注文完了、バッチ処理開始/終了
DEBUG（開発時のみ）
変数の値、関数の引数、SQL実行内容
メトリクス監視とアラート設定
監視すべき4つの黄金シグナル:
1. Latency（レイテンシ）
リクエストの応答時間
- • 正常: 95パーセンタイルで500ms以下
- • 警告: 95パーセンタイルで1秒超
- • 緊急: 95パーセンタイルで3秒超
2. Traffic（トラフィック）
1秒あたりのリクエスト数（RPS）
- • 通常の2倍超: DDoS攻撃の可能性
- • 通常の1/10以下: サービス障害の可能性
3. Errors（エラー率）
失敗したリクエストの割合
- • 正常: 0.1%以下
- • 警告: 1%超
- • 緊急: 5%超
4. Saturation（飽和度）
リソース使用率
- • CPU: 70%超で警告、90%超で緊急
- • メモリ: 80%超で警告、95%超で緊急
- • ディスク: 80%超で警告、90%超で緊急
アラート設定例（CloudWatch Alarm）:
# エラー率が1%を超えたらSlack通知 aws cloudwatch put-metric-alarm \ --alarm-name "high-error-rate" \ --metric-name ErrorRate \ --threshold 1.0 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 2 \ --alarm-actions arn:aws:sns:region:account:slack-alerts
まとめ
モニタリングとログは障害対応の命綱です。構造化ログ、リクエストID追跡、適切なログレベル、4つの黄金シグナル監視、アラート設定。これらにより、障害を早期に検知し、迅速に復旧できます。
弊社では、適切なログ設計により、平均障害対応時間が4.2時間から52分へ80%短縮され、根本原因特定率が98%に到達しました。