Skip to content

OpenTelemetryを統合したログ管理

ファイルログと同様に、OpenTelemetryログは重要なイベント、ステータス情報、エラーメッセージを記録し、開発者や運用チームがアプリケーションの挙動を理解しトラブルシューティングを行うのに役立ちます。ただし、OpenTelemetryログは標準化されたログフォーマットを採用している点が異なり、ログの解析や分析、処理が容易になります。さらに、OpenTelemetryログはTrace ID、タグ、属性などの豊富なコンテキスト情報をレコードに追加することをサポートしています。

本ページでは、EMQXとOpenTelemetryログハンドラーを統合して高度なログ管理を実現するための包括的なガイドを提供します。OpenTelemetry Collectorのセットアップ、EMQXにおけるOpenTelemetryログハンドラーの設定とログのエクスポート、ログ過負荷の管理方法について説明します。この統合により、EMQXのログイベントをOpenTelemetryログデータモデルに準拠した形式でフォーマットし、設定済みのOpenTelemetry Collectorやバックエンドシステムにエクスポートでき、監視やデバッグ機能が向上します。

OpenTelemetryログをDynatraceに直接エクスポートする方法については、OpenTelemetryとDynatraceの統合をご覧ください。

OpenTelemetry Collectorのセットアップ

EMQXのOpenTelemetryログを有効にする前に、OpenTelemetry CollectorおよびOpenTelemetry対応のログ収集システムをデプロイし設定する必要があります。本ガイドでは、OpenTelemetry Collectorのデプロイ方法と、デバッグエクスポーターを使用してログをstdoutにリダイレクトする設定方法を説明します。

  1. otel-logs-collector-config.yamlという名前でOpenTelemetry Collectorの設定ファイルを作成します。

    yaml
    receivers:
      otlp:
        protocols:
          grpc:
    
    exporters:
      logging:
        verbosity: detailed
    
    processors:
      batch:
    
    extensions:
      health_check:
    
    service:
      extensions: [health_check]
      pipelines:
        logs:
          receivers: [otlp]
          processors: [batch]
          exporters: [logging]
  2. 同じディレクトリにDocker Composeファイルdocker-compose-otel-logs.yamlを作成します。

    yaml
    version: '3.9'
    
    services:
      # Collector
      otel-collector:
        image: otel/opentelemetry-collector:0.90.0
        restart: always
        command: ["--config=/etc/otel-collector-config.yaml", "${OTELCOL_ARGS}"]
        volumes:
          - ./otel-logs-collector-config.yaml:/etc/otel-collector-config.yaml
        ports:
          - "13133:13133" # ヘルスチェック拡張機能
          - "4317:4317"   # OTLP gRPCレシーバー
  3. Docker Composeを使ってCollectorを起動します。

    bash
    docker compose -f docker-compose-otel-logs.yaml up
  4. 起動後、OpenTelemetry Collectorはhttp://localhost:4317でアクセス可能になります。

EMQXでOpenTelemetryログハンドラーを有効化

  1. EMQXがローカルで動作している前提で、cluster.hoconファイルに以下の設定を追加します。

    bash
    opentelemetry {
      exporter {
        endpoint = "http://localhost:4317"
        headers {
          authorization = ""Basic dXNlcjpwYXNzd29yZA=="
        }
      }
      logs {enable = true, level = warning}
    }

    また、ダッシュボードの Management -> Monitoring にある Integration タブからOpenTelemetryログ統合の設定も可能です。

    注意事項

    opentelemetry.logs.levelの設定は、EMQXログハンドラーで設定されたデフォルトのログレベルによって上書きされます。例えば、OpenTelemetryのログレベルがinfoでも、EMQXのコンソールログレベルがerrorの場合、error以上のレベルのイベントのみがエクスポートされます。

  2. EMQXノードを起動します。

  3. ダッシュボードからアクセスできないHTTPサービスへのブリッジ作成など、EMQXのログイベントを発生させます。

    Otel-logs-HTTP-bridge-example
  4. 数秒後(デフォルトは約1秒)、Otel CollectorにHTTPブリッジ接続失敗などのEMQXログイベントが表示されます。

    Otel-collector-logs-debug-output

ログ過負荷の管理

EMQXはログイベントを蓄積し、一定間隔でバッチ単位でエクスポートします。
このエクスポート頻度はopentelemetry.logs.scheduled_delayパラメーターで制御され、デフォルトは1秒です。
バッチングログハンドラーには過負荷保護機構が組み込まれており、蓄積可能なイベント数の上限が設定されています。デフォルトは2048件です。以下の設定で上限を変更できます。

bash
opentelemetry {
  logs { max_queue_size = 2048 }
}

max_queue_sizeの上限に達すると、新しいログイベントは現在のキューがエクスポートされるまで破棄されます。

注意事項

OpenTelemetryログの過負荷保護は、デフォルトのEMQXログハンドラーの過負荷保護とは独立して動作します。
そのため、設定によっては同じログイベントがOpenTelemetryハンドラーで破棄されても、デフォルトのEMQXログハンドラーでは記録される場合や、その逆もあり得ます。