本番の Node において logging と monitoring にどう取り組みますか？

Question

Accepted Answer

**logging** はアプリが何をするかを記録し、**monitoring** はその健全性とパフォーマンスを追跡します。両者を合わせると**可観測性（observability）** — 稼働中の本番システムを理解しデバッグする能力 — が得られます。`console.log` はこれには不十分で、構造化ログ、メトリクス、アラートが必要です。

## 構造化ログ（console.log ではなく）

```js
import pino from "pino";
const logger = pino();

// ✅ 構造化された JSON ログ — 機械が解析可能で、検索でき、コンテキストを持つ
logger.info({ userId: 123, action: "login", ip: req.ip }, "user logged in");
logger.error({ err, requestId }, "failed to process order");
```

一貫したフィールドを持つ **JSON** を出力する構造化ロガー（pino/winston）を使いましょう。JSON ログは、自由形式の `console.log` 文字列と違い、ログ集約ツールで検索・フィルタリングできます。すべてのログにコンテキスト（user id、request id）を含めます。

## ログレベルと何をログに記録するか

```text
レベル: error > warn > info > debug（環境ごとに閾値を設定する）
記録する: リクエスト、スタックトレース付きのエラー、重要なビジネスイベント、遅い処理
記録しない: パスワード、トークン、PII、シークレットを含むフルペイロード（セキュリティ/プライバシー）
```

## 相関 ID（correlation ID）でサービスをまたいでリクエストを追跡する

```js
// リクエストごとに一意の ID を付与し、そのリクエストのすべてのログに含める
app.use((req, res, next) => {
  req.id = crypto.randomUUID();
  res.setHeader("X-Request-Id", req.id);
  next();
});
// これで 1 つのリクエストのすべてのログをフィルタできる — microservices では不可欠
```

**相関/リクエスト ID** があれば、複数のサービスをまたいでいても、単一リクエストの全体像を再構築できます。分散システムのデバッグには不可欠です。

## ログを集約する

```text
ログを中央プラットフォーム（ELK/Elasticsearch, Datadog, Grafana Loki, CloudWatch）に送る
→ すべてのインスタンスを横断して検索/集計できる；個々のサーバーでファイルを grep しない。
```

## monitoring：メトリクス、アラート、トレーシング

```text
メトリクス: リクエストレート、エラーレート、レイテンシー（p50/p95/p99）、CPU/メモリ、event-loop lag
          （多くは Prometheus + Grafana、または Datadog/New Relic のような APM 経由）
ヘルス:   ロードバランサーとオーケストレータ向けの /health & /ready エンドポイント
アラート: エラーレートの急増やレイテンシーの悪化時に通知（PagerDuty/Slack）
トレーシング: サービスをまたいでリクエストを追う分散トレーシング（OpenTelemetry）
エラー:   集約された例外のためのエラートラッキング（Sentry）— スタックトレースとコンテキスト付き
```

注視すべき主要なメトリクスは**「ゴールデンシグナル（golden signals）」**：レイテンシー、トラフィック、エラー、飽和度（saturation）です。これらにアラートを設定すれば、ユーザーが報告する前に問題を捉えられます。

## なぜ重要なのか

本番ではデバッガをアタッチできません。**logging と monitoring による可観測性こそが、稼働中のシステムを理解し、デバッグし、運用する手段**です。

相関 ID 付きの構造化 JSON ログはインシデントを診断可能にし（特に microservices をまたいで）、集中集約はログを大規模でも使えるものにし、メトリクス・ヘルスチェック・分散トレーシング・アラートによる monitoring は、ユーザーが苦情を言う前に問題を先回りして検知・対応することを可能にします。

これを（障害が起きた後に後付けするのではなく）あらかじめ組み込むことが、信頼性の高い本番 Node サービスを運用する上での決定的なプラクティスです。