トレーシングベースのアラート・通知設定 - プロアクティブ監視の実装 ​

トレーシングの価値は、問題が発生してから調査するだけではなく、問題が発生する前に予測し、事前に対応できることにあります。このセクションでは、トレーシングデータを活用したアラート・通知体制の構築方法を、各ツール別に実務的に解説します。

トレーシングベースのアラート設計 ​

アラート設定において重要な3つの要素があります。

1. 監視対象メトリクス ​

トレーシングデータから導き出されるメトリクス：

  • エラー率: 特定時間内でエラーが発生したトレースの割合（%）
  • レイテンシ（遅延）: P50、P95、P99などの応答時間パーセンタイル
  • スループット: 秒あたりのリクエスト数
  • エラーメッセージ数: 特定の例外が発生した回数

2. しきい値設定 ​

メトリクスごとに正常・警告・アラートの3段階を定義します。

エラー率の例:

  • 正常: 0-1%
  • 警告: 1-5%
  • アラート: 5%以上

レイテンシ（P99）の例:

  • 正常: 0-500ms
  • 警告: 500-1000ms
  • アラート: 1000ms以上

3. 通知チャネル ​

異なる重大度に応じた通知先：

  • 警告: Slack #alerts チャネル（自動記録）
  • アラート: PagerDuty（オンコール担当者呼び出し）
  • Critical: SMS、電話（重大な本番障害）

Jaegerのアラート実装 ​

Jaegerそのものにはネイティブアラート機能がありません。代わりに、以下のアプローチでアラートを実現します。

アプローチ1：PrometheusメトリクスとAlertmanager ​

Jaegerは内部メトリクスをPrometheus形式で公開できます。

Prometheus設定例:

yaml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'jaeger'
    static_configs:
      - targets: ['localhost:14269']

Alertmanagerルール例 (alert_rules.yml):

yaml
groups:
  - name: jaeger_alerts
    interval: 30s
    rules:
      - alert: JaegerHighErrorRate
        expr: rate(jaeger_traces_received_total{error="true"}[5m]) > 0.05
        for: 5m
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value | humanizePercentage }}"

      - alert: JaegerHighLatency
        expr: histogram_quantile(0.99, rate(jaeger_span_duration_seconds[5m])) > 1
        for: 5m
        annotations:
          summary: "High P99 latency detected"
          description: "P99 latency is {{ $value }}s"

このルールにより：

  • エラー率が5分間で5%を超え、5分以上継続 → アラート
  • P99レイテンシが1秒を超え、5分以上継続 → アラート

アプローチ2：カスタムスクリプトによる定期確認 ​

Jaeger APIを使用してトレースを定期的にチェックするスクリプトを実装。

Python例:

python
import requests
import os
from datetime import datetime, timedelta

JAEGER_API = "http://localhost:16686/api"
SLACK_WEBHOOK = os.getenv("SLACK_WEBHOOK_URL")

def check_error_rate():
    """過去1時間のエラー率を確認"""
    now = datetime.utcnow()
    lookback = int((now - timedelta(hours=1)).timestamp()) * 1e6

    # Jaeger APIでエラートレース取得
    response = requests.get(
        f"{JAEGER_API}/traces",
        params={
            "service": "payment-service",
            "tags": "error=true",
            "lookback": lookback
        }
    )

    error_traces = response.json()["data"]

    # 全トレース数を取得（APIのlimitに注意）
    response_total = requests.get(f"{JAEGER_API}/traces", params={"service": "payment-service", "lookback": lookback})
    total_traces = len(response_total.json().get("data", []))

    error_rate = (len(error_traces) / total_traces * 100) if total_traces > 0 else 0

    if error_rate > 5:
        # Slackに通知
        send_slack_alert(
            f"⚠️ High error rate: {error_rate:.1f}%",
            f"Service: payment-service\nError rate: {error_rate:.1f}%"
        )

def send_slack_alert(title, message):
    """Slackにアラートを送信"""
    requests.post(SLACK_WEBHOOK, json={
        "text": title,
        "blocks": [{"type": "section", "text": {"type": "mrkdwn", "text": message}}]
    })

このスクリプトを定期実行（cronで5分ごと等）することで、アラートを実現できます。

Datadog APMのアラート機能 ​

Datadogはネイティブのアラート機能を備えており、セットアップが最も直感的です。

Watchdog - AI駆動の異常検知 ​

Datadogの「Watchdog」機能は、機械学習により異常を自動検出します。

特徴:

  • ゼロコンフィグレーション（設定不要）
  • 過去データとの比較で自動的に異常判定
  • 誤検知を自動フィルタリング

Watchdogが検出した異常は、Datadogのダッシュボードに自動表示され、通知設定により即座にアラート可能です。

カスタムアラート設定 ​

より細かい条件でのアラートを設定できます。

Datadogコンソール操作フロー:

Monitors → Create Monitor → APM
  ↓
Metric: Trace Queries を選択
  ↓
Metric: service.errors{service:payment-service}
Threshold: > 0.05 （エラー率5%以上）
Duration: 5 minutes
  ↓
Notify: @slack-alerts @pagerduty

設定YAML例:

yaml
name: "Payment Service High Error Rate"
type: metric_alert
query: |
  sum:trace.requests.errors{service:payment-service}.as_count() /
  sum:trace.requests{service:payment-service}.as_count() > 0.05
thresholds:
  critical: 0.05
  warning: 0.02
notification_channels:
  - slack_alerts
  - pagerduty

複合アラート ​

複数の条件を組み合わせたアラートも可能です。

例: エラー率がX%以上かつレイテンシがY秒以上 → アラート

yaml
query: |
  (avg:trace.errors{service:api} > 0.05)
  AND
  (avg:trace.latency{service:api,p:99} > 1000000000) # 1000ms = 1s

AWS X-Rayのアラート設定 ​

AWS X-RayはCloudWatch Alarmsと統合して、アラート機能を実現します。

CloudWatch Alarmsベースのアラート ​

AWS Management Consoleでの設定フロー:

CloudWatch → Alarms → Create Alarm
  ↓
Metric: AWS/X-Ray
Service: X-Ray
  ↓
Metric Name: TracedRequestCount（トレースリクエスト数）
Statistic: Sum
Period: 5 minutes
Threshold: < 100 （リクエスト数が100未満）
  ↓
Actions: SNS topic → 通知

カスタムメトリクス用アラーム ​

X-Rayから特定メトリクスを抽出してCloudWatchメトリクスに変換し、アラームを設定。

CloudWatch Logsインサイト を使用した例:

fields @timestamp, @message, @duration, @error
| stats count() as error_count by bin(5m)
| filter error_count > 10

このクエリ結果をメトリクスに変換し、アラームを作成。

DevOps Guru による自動推奨 ​

DevOps Guruはアノマリ検出と改善提案を自動生成します。

有効化フロー:

  1. DevOps Guru コンソールで有効化
  2. X-Ray データの自動分析開始
  3. 異常検出時に自動通知
  4. 改善提案をダッシュボードに表示

ツール別アラート機能比較 ​

機能JaegerDatadogAWS X-Ray
ネイティブアラート✗◎○
AI異常検知✗◎（Watchdog）○（DevOps Guru）
カスタムしきい値△（Prometheus経由）◎◎
通知チャネル△◎◎
複合条件アラーム○（Alertmanager）◎○

実務的なアラート戦略 ​

アラート疲れ対策 ​

不適切なしきい値設定により、アラートが頻繁に鳴る「アラート疲れ」は、実際には重要な問題を見落とさせます。

対策方法:

  1. 段階的しきい値設定

    • Warning: 通知のみ
    • Alert: オンコール担当者へ
    • Critical: 複数チャネルへ即座に通知

  2. 自動解除機能の活用

    • アラート発生後、条件が改善されたら自動的に解除
    • 手動での確認・承認ステップを不要にする

  3. 定期的な見直し

    • 実際に発火したアラートと、見落とされた問題を定期（月1回等）で分析
    • しきい値を継続的に調整

サービス・チームごとの通知先分離 ​

大規模組織では、通知先を明確に分離することが重要です。

組織構造例:

Payment Service エラー率 > 5%
  → PagerDuty: on-call-payment
  → Slack: #payment-alerts

Order Service レイテンシ P99 > 2s
  → PagerDuty: on-call-order
  → Slack: #order-alerts

Shared Infrastructure
  → PagerDuty: on-call-infra
  → Slack: #infra-alerts

外部API制限への先制アラート ​

外部サービス（決済API、SNS等）の制限に達する前にアラートを設定。

例: 決済API呼び出しレート制限1000 req/minの場合

  • Warning: 800 req/min
  • Alert: 950 req/min

これにより、制限に達する前に対応が可能です。

トレーシングアラートのベストプラクティス ​

1. ビジネスインパクトを考慮 ​

ビジネスの影響度が高い操作ほど、厳しいしきい値でアラート。

Critical（即座に対応が必要）:
  - 決済処理
  - ユーザー認証

High（1時間以内に対応）:
  - 注文作成
  - レコメンデーション取得

Medium（4時間以内に対応）:
  - ユーザープロフィール更新
  - ログ処理

2. 文脈情報の包含 ​

アラートメッセージには、対応に必要な情報を全て含める。

❌ 不十分: "High error rate detected"

✅ 十分:
"⚠️ Payment Service: Error rate 8% (threshold: 5%)
Duration: Last 5 minutes (13:45-13:50 JST)
Affected operations: process_payment (120 errors)
Action: Check Dashboard [ダッシュボードへのリンク] | PagerDuty page [PagerDutyページへのリンク]"

3. アラート無音化（Silencing）機能の活用 ​

計画的なメンテナンスやデプロイ中にアラートを一時的に無音化。

Datadog例:

Downtime を設定
  時刻: 2025-11-10 14:00-16:00
  範囲: payment-service
  理由: Database migration

まとめ：アラート体制の構築ロードマップ ​

Phase 1（初期段階） ​

  • エラーレートの基本的なアラート設定
  • 単一チャネル（Slack）への通知

Phase 2（成長段階） ​

  • 複数メトリクス（レイテンシ、エラーレート、スループット）の監視
  • サービス別の通知先分離
  • PagerDutyによるオンコール統合

Phase 3（成熟段階） ​

  • AI異常検知の導入
  • 複合条件アラーム
  • 自動修復・スケーリングのトリガー

シリーズ完了: このガイドで、トレーシング可視化ツール選択から運用まで、一連の実務的なナレッジをカバーしました。環境に応じた適切なツール選択と、段階的なアラート体制構築により、堅牢で効率的な分散トレーシング基盤を実現できます。