はじめに

本投稿は、Datadog アドベントカレンダー 2023の12/13の記事になります。

OpenTelemetryへの入門としてDatadog Exporterを利用してメトリクスやログの連携を行う手順について紹介できればと思います。

OpenTelemetryとは

OpenTelemetryは、分散トレーシング、メトリクス、およびログのためのオープンな規格とライブラリのセットであり、クラウドネイティブ環境でアプリケーションの観測性を向上させるために使用されます。具体的には、アプリケーションの内部で何が起こっているか、どのように実行されているかを理解し、トラブルシューティングや最適化を行うのに役立ちます。

CNCFのプロジェクトの一つとして進められているオープンな規格であるため、クラウドプロバイダやベンダに依存しない形で異なる環境での利用が可能です。

OpenTelemetry Collectorを検討した背景

1. ベンダーロックインを避けたい

分散トレーシングを実現するにあたり、特定のベンダや製品に依存しない標準としてはデファクトスタンダートになりつつあると個人的に感じています。

複数のリージョンやクラウドプロバイダ上にサービスを展開していくにあたり、クラウドポータビリティを考慮した仕組みを考慮していくことも必要かなと思っています。

2. 中国においてDatadog利用がサポートされていない

前述の話とも関連しますが、特定のリージョンではDatadogのサポートが行われておらず、各国の地政学的なリスクを考慮した運用監視の実現が求められました。
このため、ベンダーに依存しないOpenTelemetryを使用して、さまざまなノウハウを蓄積していきたいと考え始めました。

Datadog Services are neither designed nor certified for any legal, operational, or regulatory requirements in mainland China (“PRC”). As such, Datadog does not enter deals with PRC entities (directly or via a third party) and Datadog does not provide specific support for any use of its Services in the PRC.

検証内容&構成

Datadog exporter設定手順を参考に、OpenTelemetry Collector Helm Chartを利用して、アプリケーションログやノードのメトリクスがDatadogへの連携ができるか試みました。

OpenTelemetry Collector設定

OpenTelemetry Collectorのデプロイに関してはTerraformのHelm providerを利用して行いました。

事前にkubernetesクラスタの構築が完了している前提です。
また、DatadogのAPI Keyの管理に関してはAWS Secret Managerを利用しています。

opentelemetry_collector.tf

resource "helm_release" "opentelemetry_collector" {
  chart       = "opentelemetry-collector"
  description = "opentelemetry-collector"
  name        = "opentelemetry-collector"
  namespace   = "opentelemetry"
  repository  = "https://open-telemetry.github.io/opentelemetry-helm-charts"
  version     = "0.77.0"
  timeout     = 60
  values = [
    "${file("../path/to/values.yaml")}"
  ]

  set {
    name  = "config.exporters.datadog.api.key"
    value = jsondecode(data.aws_secretsmanager_secret_version.datadog.secret_string)["api-key"]
  }
}

secret_manager.tf

resource "aws_secretsmanager_secret" "datadog" {
  name = "datadog-credential"
}

data "aws_secretsmanager_secret_version" "datadog" {
  secret_id = aws_secretsmanager_secret.datadog.id
}

次にHelm chartで定義するvalues.yamlの設定を行いました。
datadog siteは利用中の環境に合わせて修正ください。

values.yaml

mode: daemonset
presets:
  logsCollection:
    enabled: true
    includeCollectorLogs: true
  hostMetrics:
    enabled: true
  kubernetesAttributes:
    enabled: true
    extractAllPodLabels: true
    extractAllPodAnnotations: true
  kubeletMetrics:
    enabled: true
  kubernetesEvents:
    enabled: true

config:
  receivers:
    hostmetrics:
      collection_interval: 10s
      scrapers:
        cpu:
        load:
        memory:
        network:
  processors:
    batch:
      send_batch_max_size: 100
      send_batch_size: 10
      timeout: 10s
  exporters:
    datadog:
      api:
        site: datadoghq.com
  service:
    pipelines:
      metrics:
        receivers:
        - hostmetrics
        - otlp
        processors:
        - batch
        exporters:
        - datadog
      logs:
        receivers:
        - otlp
        processors:
        - batch
        exporters:
        - datadog

結果

Otel Collecotor経由でメトリクスがDatadogへ連携されていることを確認しました。

サンプルアプリケーションのログに関しても、以下の通りDatadog Log Explorerにて可視化されていることを確認しました。

まとめ

今回は、Otel Collectorを介してメトリクスやログが連携されていることを確認しました。
Datadogをバックエンドとして連携しましたが、exportersの設定を追加することで、Grafanaやfluent-bit、Vectorなどのさまざまなサードパーティツールへの連携も簡単にでき、目的に応じたデータ処理や可視化が期待できそうでした。
Helm Chartを使うことで比較的簡単に実装を進めることができましたが、次はTraceデータの連携も試してみたいと思います。