本番環境の監視とアラート: 完全なセットアップ ガイド

生産インシデントの平均的なダウンタイムは 1 分あたり 5,600 ドルです。 成熟した監視を導入している企業は 5 分未満で問題を検出しますが、監視を導入していない企業は検出まで平均 197 分かかります。これは、軽微な障害と顧客を失う大惨事の差です。

このガイドでは、何を測定するか、どのように収集するか、どこで視覚化するか、いつアラートを出すかなど、エンドツーエンドの生産監視のセットアップについて説明します。

重要なポイント

• 可観測性の 3 つの柱 (メトリクス、ログ、トレース) は異なる目的を果たし、3 つすべてが必要です
• 症状 (エラー率、遅延) に関するアラートは (CPU 使用率) を引き起こさず、ノイズを 80% 削減します
• すべてのアラートに添付されたランブックにより、誰が電話に出ているかに関係なく一貫したインシデント対応が保証されます
• 5 つの重要なアラートから始めて、ベースラインを理解した場合にのみ拡張します

---

可観測性の 3 つの柱

メトリクス

一定期間にわたってサンプリングされた数値測定値。メトリクスは「今何が起こっているのか?」に答えます。

アプリケーションのメトリクス:

• リクエスト率 (1 秒あたりのリクエスト数)
• エラー率 (1 秒あたり 5xx 応答)
• レイテンシー分布 (P50、P95、P99)
• アクティブなセッション/同時ユーザー

インフラストラクチャのメトリクス:

• サービスごとの CPU 使用率
• メモリ使用量とガベージコレクション
• ディスク I/O と空き容量
• ネットワークスループット

ビジネス指標:

• 1分あたりの注文数
• カート放棄率
• 時間当たりの収益
• エンドポイントごとの API 呼び出し

ログ

個別のイベントのタイムスタンプ付きの構造化された記録。ログは「なぜそうなったのか？」と答えます。

{
  "timestamp": "2026-03-16T14:32:01.234Z",
  "level": "error",
  "service": "api",
  "requestId": "req_abc123",
  "userId": "usr_456",
  "message": "Payment processing failed",
  "error": "Stripe API timeout after 30000ms",
  "endpoint": "POST /billing/checkout",
  "duration": 30142
}

ベスト プラクティスをログに記録します:

• プレーンテキストではなく、構造化された JSON ログを使用します
• サービス間の相関 ID (requestId) を含める
• 適切なレベルでのログ (障害の場合はエラー、機能低下の場合は警告、主要なイベントの場合は情報)
• 機密データ (パスワード、トークン、完全なクレジット カード番号) を決して記録しないでください。

トレース

分散システムを介したエンドツーエンドのリクエスト パス。トレースは「ボトルネックはどこですか?」という質問に答えます。

e コマース チェックアウトに対する 1 人のユーザー リクエストは、次のような影響を与える可能性があります。

1. Nginx (2ms)、Next.js フロントエンド (50ms)、NestJS API (120ms)、PostgreSQL (45ms)、Stripe API (800ms)、電子メール サービス (200ms)

トレースしないと、「チェックアウトには 1.2 秒かかります」と表示されます。トレースすると、「Stripe API がチェックアウト遅延の 67% を占めている」ことがわかります。

---

監視スタックのセットアップ

Prometheus + Grafana (自己ホスト型)

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:10.3.0
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3030:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false

  loki:
    image: grafana/loki:2.9.0
    volumes:
      - loki-data:/loki
    ports:
      - "3100:3100"

  alertmanager:
    image: prom/alertmanager:v0.27.0
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus-data:
  grafana-data:
  loki-data:

プロメテウスの構成

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: "api"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:3001"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "postgres"
    static_configs:
      - targets: ["postgres-exporter:9187"]

  - job_name: "redis"
    static_configs:
      - targets: ["redis-exporter:9121"]

---

NestJS アプリケーションのメトリクス

Prometheus メトリクスの公開

// metrics.module.ts
import { Module } from '@nestjs/common';
import { PrometheusModule } from '@willsoto/nestjs-prometheus';
import {
  makeCounterProvider,
  makeHistogramProvider,
  makeGaugeProvider,
} from '@willsoto/nestjs-prometheus';

@Module({
  imports: [
    PrometheusModule.register({
      path: '/metrics',
      defaultMetrics: { enabled: true },
    }),
  ],
  providers: [
    makeCounterProvider({
      name: 'http_requests_total',
      help: 'Total HTTP requests',
      labelNames: ['method', 'path', 'status'],
    }),
    makeHistogramProvider({
      name: 'http_request_duration_seconds',
      help: 'HTTP request duration in seconds',
      labelNames: ['method', 'path'],
      buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
    }),
    makeGaugeProvider({
      name: 'active_connections',
      help: 'Number of active connections',
    }),
  ],
  exports: [PrometheusModule],
})
export class MetricsModule {}

---

アラート設定

5 つの重要なアラート

すべての実稼働システムには、初日から次のアラートが必要です。

# alerts/essential.yml
groups:
  - name: essential
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is down"
          runbook: "https://wiki.example.com/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 latency above 2 seconds"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"} < 0.2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk space below 20% on {{ $labels.instance }}"

      - alert: SSLCertExpiringSoon
        expr: |
          probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "SSL certificate expires within 14 days"

アラートルーティング

# alertmanager.yml
global:
  slack_api_url: "${SLACK_WEBHOOK_URL}"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: "${PAGERDUTY_KEY}"
        severity: '{{ .GroupLabels.severity }}'

  - name: 'slack'
    slack_configs:
      - channel: '#alerts-warnings'
        title: '{{ .GroupLabels.alertname }}'

アラート品質ルール

---

Grafana ダッシュボード

ダッシュボードの階層

1. 概要ダッシュボード: すべてのサービスにわたる高レベルの健全性。これは、インシデント発生中に誰もが最初に見る画面です。
2. サービス ダッシュボード: 各サービス (API、Web、ワーカー) の詳細なメトリクス。
3. インフラストラクチャ ダッシュボード: ノードレベルのメトリクス (CPU、メモリ、ディスク、ネットワーク)。
4. ビジネス ダッシュボード: 収益、注文、ユーザー アクティビティ。

サービス ダッシュボードの RED メソッド

すべてのサービスについて、以下を表示します。

• Rate: 1 秒あたりのリクエスト数
• Errors: エラー率 (パーセンテージ)
• Duration: レイテンシー分布 (P50、P95、P99)

これにより、認知的な過負荷を発生させることなく、サービスの健全性を即座に把握できるようになります。

---

Sentry によるエラー追跡

// sentry.config.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.1,
  integrations: [
    Sentry.postgresIntegration(),
  ],
  beforeSend(event) {
    // Strip sensitive data
    if (event.request?.headers) {
      delete event.request.headers['authorization'];
      delete event.request.headers['cookie'];
    }
    return event;
  },
});

Sentry は以下を提供します:

• 自動エラーのグループ化と重複排除
• ソースマップを使用したスタックトレース
• リリース追跡 (どのデプロイでエラーが発生したか)
• パフォーマンス監視（トランザクション追跡）

---

よくある質問

監視スタックのコストはいくらですか?

セルフホスト (Prometheus + Grafana + Loki): ホスティング リソースとして月額約 50 ～ 100 ドル。マネージド型の代替案: Datadog は、インフラストラクチャが月額 1 ホストあたり 15 ドル、ログが 1 GB あたり 0.10 ドルから始まります。 Sentry Cloud のチームプランは月額 26 ドルです。中小企業の妥当な開始予算は、月額合計 100 ～ 200 ドルです。

モニタリングとオブザーバビリティの違いは何ですか?

監視により、何か問題があると通知されます。可観測性がその理由を教えてくれます。監視とは、既知の障害モードに対する事前定義されたダッシュボードとアラートに関するものです。可観測性とは、メトリクス、ログ、トレースを使用して、システムの動作について任意の質問をする機能のことです。両方必要ですが、監視が基礎です。

アラート疲労を回避するにはどうすればよいですか?

3 つのルール: (1) すべてのアラートには人間のアクションが必要である、(2) 理論上の理想ではなく実際のベースラインに基づいてしきい値を設定する、(3) アラートを毎月確認して調整する。アクションを必要とせずにアラートが週に 1 回以上発生する場合は、根本的な問題を解決するか、しきい値を上げてください。アラート疲れに悩まされているチームは、重要なアラートを含むすべてのアラートを無視します。

ERP システムを別の方法で監視する必要がありますか?

ERP システムには独自の監視要件があります。標準的な Web メトリクスに加えて、データベース接続プールの使用状況、バックグラウンド ジョブ キューの深さ、統合同期ステータス (Shopify、支払いゲートウェイ)、スケジュールされたレポートの実行時間、モジュールごとのユーザー セッション数を監視します。 ECOSIRE は、サポート パッケージの一部として マネージド Odoo モニタリング を提供します。

---

次に何が起こるか

モニタリングは、実稼働インフラストラクチャの目であり耳です。導入の信頼性を高めるために CI/CD 自動化 と組み合わせ、復元力を高めるために 災害復旧計画 と組み合わせます。包括的な DevOps ロードマップについては、中小企業向けの DevOps ガイド を参照してください。

セットアップおよび管理されたインフラストラクチャ サービスの監視については、ECOSIRE にお問い合わせください。

---

ECOSIRE が発行 -- 企業が生産において何が重要かを理解できるように支援します。