observability-logging

オブザーバビリティロギング

包括的なオブザーバビリティ戦略の中核要素としてログを活用し、メトリクス、トレース、アラート、ダッシュボードと統合することで、システムを深く理解し、優れた運用を実現します。

どのような場合に使用するか

次のような場合に、このスキルを使用します。

• 包括的なオブザーバビリティプラットフォームを構築する
• 完全なオブザーバビリティを実現するため、ログをメトリクスやトレーシングと統合する
• ログパターンに基づくアラートと監視システムを設計する
• ログから得た知見と他のテレメトリを組み合わせたダッシュボードを作成する
• ログデータを使用して SLO／SLA 監視を実装する
• ログ分析に基づくインシデント対応ワークフローを構築する
• 優れた運用を実現するためのプラクティスを確立する
• オンコール手順とランブックを設計する
• ログパターンを使用して予知保全を実装する
• オブザーバビリティのシグナルに基づく自己修復システムを構築する

できること

1. ログ駆動型メトリクス

• ログからメトリクスを抽出する（エラー率、レイテンシのパーセンタイル、スループット）
• ログパターンと相関関係から派生メトリクスを作成する
• ビジネスイベントと運用イベント向けに、ログベースのカウンターを実装する
• ログデータからサービスレベル指標（SLI）を計算する
• ログから導出したメトリクスを使用して、サービスレベル目標（SLO）を監視する
• エラーバジェットの消費量に対するバーンレートアラートを実装する
• 過去のログパターンから傾向分析を作成する

2. ログによるトレーシングの強化

• トレースにログコンテキストを追加して、より深い洞察を得る
• トレースのスパンとログイベントを関連付け、リクエストを包括的に把握する
• レガシーシステムやトレースされていないシステム向けに、ログベースのスパン作成を実装する
• 分散システムにおけるトレーシングの欠落をログで補う
• ログとトレースを組み合わせた統合オブザーバビリティビューを作成する
• シームレスな調査のため、ログとトレースの連携を実装する
• 相関付けと分析のために、ログでトレースコンテキストを使用する

3. アラートと監視

• 重大なパターンや異常を検知するログベースのアラートを設計する
• ログソース間でのアラートの重複排除と相関付けを実装する
• ログパターンの重大度に基づくエスカレーションポリシーを作成する
• 適切なチームや担当者へのアラートルーティングを設計する
• 診断を迅速化するため、ログコンテキストによるアラートの拡充を実装する
• 既知の問題やメンテナンス期間に対する抑制ルールを作成する
• アラートの有効性を監視し、過去のデータに基づいてしきい値を調整する

4. ダッシュボードと可視化

• ログ、メトリクス、トレースを組み合わせた運用ダッシュボードを作成する
• ログから導出した健全性指標を使ったサービス健全性ダッシュボードを設計する
• リアルタイムのログストリーミング可視化を実装する
• ログパターンの変化を示す傾向ダッシュボードを作成する
• 関連データを使ったインシデント調査ダッシュボードを設計する
• さまざまな関係者のニーズに合わせたカスタマイズ可能なビューを実装する
• ログデータに対する機械学習を使った予測ダッシュボードを作成する

5. インシデント対応

• よくある問題に対するログ駆動型ランブックを設計する
• ログパターンに基づく自動修復を実装する
• ログの相関付けからインシデントのタイムラインを作成する
• 包括的なログデータを使った事後分析を設計する
• オブザーバビリティデータを活用した非難のない振り返りを実施する
• 解決済みのインシデントとログパターンからナレッジベースを作成する
• オブザーバビリティのシグナルに基づくエスカレーション手順を設計する

オブザーバビリティの柱の統合

ログ＋メトリクス＋トレース＝完全なオブザーバビリティ

例：API サービスのオブザーバビリティ

Logs (What happened):
- "API call to /api/users failed with 500 error"
- "Database connection timeout after 5000ms"
- "Cache miss for user:123"

Metrics (How much/how often):
- Error rate: 5.2%
- P95 latency: 245ms
- Throughput: 1,234 requests/second

Traces (Where in the flow):
- Request flow: API Gateway → Auth Service → User Service → Database
- Time spent: 45ms in Auth, 120ms in User Service, 80ms in Database
- Bottleneck identified: Database query in User Service

統合データモデル

observability_data:
  logs:
    source: application, infrastructure, audit
    format: structured (JSON)
    fields: [timestamp, level, service, message, context]
    
  metrics:
    source: logs (derived), application (direct), infrastructure
    types: counter, gauge, histogram, summary
    dimensions: [service, endpoint, status_code, user_type]
    
  traces:
    source: instrumentation, log-derived
    context: trace_id, span_id, parent_span_id
    attributes: [service.name, operation.name, duration, status]
    
  correlations:
    log_to_metric: "error logs → error rate metric"
    log_to_trace: "trace_id field links logs to traces"
    metric_to_trace: "high latency metric → trace analysis"

ログ駆動型 SLO 監視

ログからのエラーバジェット計算

def calculate_error_budget_from_logs(logs, slo_target, time_window):
    """
    Calculate error budget consumption from log data
    
    Args:
        logs: List of log entries with timestamp and success status
        slo_target: SLO target (e.g., 0.999 for 99.9%)
        time_window: Time window for calculation in seconds
    
    Returns:
        error_budget_consumption: Percentage of error budget consumed
    """
    total_requests = len(logs)
    successful_requests = sum(1 for log in logs if log.get('status') != 'error')
    
    success_rate = successful_requests / total_requests if total_requests > 0 else 1.0
    error_rate = 1.0 - success_rate
    
    # Calculate error budget consumption
    allowed_errors = (1.0 - slo_target) * total_requests
    actual_errors = total_requests - successful_requests
    error_budget_consumption = actual_errors / allowed_errors if allowed_errors > 0 else float('inf')
    
    return {
        'total_requests': total_requests,
        'successful_requests': successful_requests,
        'success_rate': success_rate,
        'error_rate': error_rate,
        'slo_target': slo_target,
        'allowed_errors': allowed_errors,
        'actual_errors': actual_errors,
        'error_budget_consumption': error_budget_consumption,
        'error_budget_remaining': max(0, 1.0 - error_budget_consumption)
    }

バーンレートアラート

alerting:
  error_budget_burn_rate:
    # Alert when burning error budget too quickly
    - name: "high_error_budget_burn_rate"
      condition: "error_budget_burn_rate > 10"
      # Burning 10x faster than allowed
      window: "1h"
      severity: "critical"
    
    - name: "medium_error_budget_burn_rate"
      condition: "error_budget_burn_rate > 2"
      # Burning 2x faster than allowed
      window: "6h"
      severity: "warning"
    
  slo_violation:
    - name: "slo_violation_imminent"
      condition: "error_budget_remaining < 0.1"
      # Less than 10% error budget remaining
      window: "7d"
      severity: "warning"
    
    - name: "slo_violation_occurred"
      condition: "success_rate < slo_target"
      # Actual violation occurring
      window: "1h"
      severity: "critical"

例

# Extract metrics from logs for SLO monitoring
npm run observability:extract-metrics -- --slo-target 0.999 --window 7d --output slo-metrics.json

# Create unified observability dashboard
npm run observability:create-dashboard -- --services "api,auth,db" --data-sources "logs,metrics,traces"

# Design log-based alerting rules
npm run observability:design-alerts -- --patterns "error_rate > 5%,latency_p95 > 1000ms" --escalation-policy "team-rotation"

# Implement incident response workflow
npm run observability:incident-workflow -- --trigger "error_spike" --actions "page,create-incident,notify-slack"

# Correlate logs with metrics and traces
npm run observability:correlate -- --time-range "last-1h" --output correlation-analysis.json

出力形式

オブザーバビリティプラットフォームの構成：

observability:
  data_sources:
    logs:
      collection: [filebeat, fluentd, otel-collector]
      processing: [parsing, enrichment, correlation]
      storage: [elasticsearch, s3]
      
    metrics:
      collection: [prometheus, otel-collector]
      processing: [aggregation, derivation]
      storage: [prometheus, thanos]
      
    traces:
      collection: [otel-collector, jaeger-agent]
      processing: [sampling, enrichment]
      storage: [jaeger, tempo]
  
  correlation:
    fields:
      trace_id: ["trace_id", "trace.id", "X-Trace-Id"]
      service: ["service", "service.name", "component"]
      user_id: ["user_id", "user.id", "userId"]
    
    rules:
      - when: "log.level == 'ERROR'"
        then: "increment_metric('errors_total', labels=log.labels)"
      - when: "trace.duration > 1000"
        then: "log.warning('slow_trace', trace_attributes)"
      - when: "metric.name == 'error_rate' and metric.value > 0.05"
        then: "create_alert('high_error_rate', severity='warning')"
  
  dashboards:
    - name: "Service Health"
      panels:
        - type: "timeseries"
          title: "Error Rate"
          query: "rate(error_logs_total[5m])"
        - type: "histogram"
          title: "Request Latency"
          query: "histogram_quantile(0.95, rate(request_duration_seconds_bucket[5m]))"
        - type: "log_stream"
          title: "Recent Errors"
          query: "level:ERROR"
    
    - name: "Business Metrics"
      panels:
        - type: "counter"
          title: "User Signups"
          query: "log.message:'User signed up'"
        - type: "timeseries"
          title: "Payment Success Rate"
          query: "successful_payments / total_payments"
  
  alerting:
    rules:
      - alert: "HighErrorRate"
        expr: "rate(error_logs_total[5m]) > 0.05"
        for: "5m"
        labels:
          severity: "critical"
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value }} which is above 5% threshold"
        
      - alert: "SLOErrorBudgetBurn"
        expr: "error_budget_burn_rate > 10"
        for: "1h"
        labels:
          severity: "warning"
        annotations:
          summary: "Error budget burning too fast"
          description: "Error budget burn rate is {{ $value }}x faster than allowed"
  
  incident_response:
    workflows:
      - trigger: "alert.severity == 'critical'"
        actions:
          - "create_incident"
          - "page_on_call"
          - "notify_slack('#alerts')"
          - "start_zoom_war_room"
      
      - trigger: "incident.created"
        actions:
          - "gather_observability_data"
          - "correlate_logs_metrics_traces"
          - "suggest_runbooks"
          - "update_status_page"

オブザーバビリティ成熟度の評価：

Observability Maturity Assessment
────────────────────────────────
Organization: Example Corp
Assessment Date: 2026-02-26
Overall Score: 72/100

Pillar Scores:
- Logging: 85/100 (Structured, correlated, well-managed)
- Metrics: 65/100 (Basic metrics, limited derivation)
- Tracing: 56/100 (Partial implementation, gaps in coverage)
- Alerting: 70/100 (Effective but could be smarter)
- Visualization: 74/100 (Good dashboards, could be more unified)

Integration Assessment:
✅ Logs include trace context (trace_id, span_id)
✅ Metrics derived from logs (error rates, throughput)
⚠️  Traces not fully correlated with logs (60% coverage)
⚠️  Alerting not using derived SLO metrics
✅ Dashboards combine multiple data sources

Gap Analysis:
1. Missing: Unified observability data model
2. Missing: Automated correlation across pillars
3. Missing: Predictive analytics on observability data
4. Missing: Self-healing based on observability signals
5. Missing: Comprehensive SLO monitoring

Observability ROI Analysis:
- Current MTTR (Mean Time To Resolution): 45 minutes
- Target MTTR with improved observability: 15 minutes
- Estimated reduction in incident impact: $15,000/month
- Estimated improvement in developer productivity: 20%
- Estimated reduction in on-call burden: 30%

Recommendations:
1. HIGH PRIORITY: Implement unified observability data model
2. HIGH PRIORITY: Improve trace coverage and correlation
3. MEDIUM PRIORITY: Implement SLO-based alerting
4. MEDIUM PRIORITY: Add predictive analytics capabilities
5. LOW PRIORITY: Explore self-healing automation

Implementation Roadmap:
- Phase 1 (1 month): Unified data model and correlation
- Phase 2 (2 months): SLO monitoring and alerting
- Phase 3 (3 months): Predictive analytics
- Phase 4 (6 months): Self-healing capabilities
- Ongoing: Continuous improvement and optimization

注意事項

• 可観測性は目的地ではなく、継続的な取り組みです - 継続的な改善が欠かせません
• まず答える必要のある質問を明確にします - その質問を中心に可観測性を設計します
• 個々のデータソースを深く分析するより、データソース間の相関を把握することのほうが価値があります
• 可観測性にかかるコストを考慮します - 価値と費用のバランスを取ります
• すべての関係者を巻き込みます - 開発者、運用担当者、ビジネスチーム、経営陣が対象です
• 可観測性の有効性を測定します - MTTR、インシデントの発生頻度などを追跡します
• 可観測性の実践内容を文書化します - ランブック、ダッシュボード、アラートの定義などが対象です
• 定期的に見直し、改善します - システムの進化に合わせて、可観測性のニーズも変化します
• 自動化と人間の洞察のバランスを取ります - 必要な人間の判断まで自動化しないようにします
• セキュリティとコンプライアンスを考慮します - 可観測性データに機密情報が含まれる場合があります