このページでは、Kubernetes のログファイルからログを収集する方法について説明します。

コンテナ化されたアプリケーションが標準出力および標準エラー (stdout/stderr) にログを書き込む場合、コンテナランタイムと Kubernetes が自動的にログを管理します。デフォルトでは、Kubernetes はこれらのログストリームをファイルとして保存します。保存先はホスト上の /var/log/pods フォルダと、各 Pod およびコンテナのサブフォルダです。

Datadog Agent は、以下の手順でこれらのコンテナの Kubernetes のログファイルを収集できます。このオプションは、Kubernetes が作成する Pod の一時的な性質に適しており、Docker ソケットからログを収集するよりもリソース効率が高くなります。Datadog は、Kubernetes でのログ収集にこの方法を推奨しています。

また、Datadog Agent は、Docker ソケット経由で Docker API に繰り返しリクエストを送信してログを収集することもできます。ただし、Kubernetes クラスターのコンテナランタイムとして Docker が必要です。これには、ログファイルを使用する場合よりも多くのリソースが必要です。Docker ソケットを使用してログを収集する方法については、Docker ソケットを使用したログの収集 を参照してください。コンテナ化されたアプリケーションがコンテナ内に保存されたログファイルに書き込んでいる場合、ログ収集が複雑になる可能性があります。ファイルからのログ収集を参照してください。

セットアップ

ログ収集

アプリケーションログの収集を開始する前に、Kubernetes クラスターで Datadog Agent が実行されていることを確認してください。

DaemonSet でログ収集を手動で構成する方法については、DaemonSet ログ収集 を参照してください。それ以外の場合は、以下の手順に従ってください。

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>

  features:
    logCollection:
      enabled: true
      containerCollectAll: true

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

datadog:
  logs:
    enabled: true
    containerCollectAll: true

非特権

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>

  features:
    logCollection:
      enabled: true
      containerCollectAll: true

  override:
    nodeAgent:
      securityContext:
        runAsUser: <USER_ID>
        supplementalGroups:
          - <DOCKER_GROUP_ID>

datadog:
  securityContext:
    runAsUser: <USER_ID>
    supplementalGroups:
      - <DOCKER_GROUP_ID>

ログの検出

Kubernetes の Datadog Agent は、DaemonSet (Datadog Operator または Helm によって管理) によってデプロイされます。この DaemonSet は、クラスターの各ノードに Agent Pod のレプリカを 1 つずつスケジュールします。各 Agent Pod は、それぞれのノードにある他の Pod やコンテナのログを報告します。[Container Collect All] 機能が有効な場合、Agent は検出されたすべてのコンテナのログをデフォルトのタグセットとともに報告します。

フィルタリング

[Container Collect All] が有効な場合、ログの収集対象とするコンテナを設定できます。これは、必要に応じて Datadog Agent のログが収集されるのを防ぐのに役立ちます。これを行うには、Datadog Agent に構成を渡して収集対象を制御するか、Kubernetes Pod に構成を渡して特定のログをより明示的に除外します。

DD_CONTAINER_EXCLUDE_LOGS や ad.datadoghq.com/logs_exclude のような方法でログをフィルタリングする場合、Autodiscovery アノテーション、DatadogInstrumentation CRD、または Autodiscovery 構成ファイル で明示的に定義されたログ収集構成に関係なく、Agent はログ収集を無視します。

[Container Collect All] が無効 (デフォルト) の場合、すべてがデフォルトで除外されるため、フィルタリングを追加する必要はありません。選択した Pod のみを収集対象にするには、対象の Pod に対して Autodiscovery アノテーション、DatadogInstrumentation CRD、または Autodiscovery 構成ファイル を使用してログ構成を有効にします。

フィルタリングの詳細については、コンテナ検出の管理 を参照してください。

タグ付け

Datadog Agent は、Kubernetes コンテナからのログにデフォルトの Kubernetes タグ と、抽出されたカスタムタグを付与します。[Container Collect All] が有効な場合、Agent はコンテナのショートイメージ名と一致する source タグおよび service タグを持つコンテナのログを報告します。例えば、gcr.io/owner/example-image:latest コンテナイメージを使用するコンテナからのログには、source、service、および short_image タグの値として example-image が設定されます。

service タグは、Unified Service Tagging の Pod ラベル tags.datadoghq.com/service: "<SERVICE>" によって設定することもできます。source および service 属性について詳しくは、予約済み属性 を参照してください。

source タグはログにとって重要です。これは、すぐに使用できるログパイプライン がこのタグを使用してフィルタリングされるためです。ただし、これらのパイプラインは必要に応じて完全にカスタマイズできます。ログのタグをさらにカスタマイズする手順については、以下のインテグレーションログセクションを参照してください。

インテグレーションログ

Autodiscovery を使用すると、テンプレートを使用してコンテナのログ収集やその他の機能を構成できます。ログ収集を構成するには、次のいずれかの方法を使用します。

• Autodiscovery アノテーション (推奨)
• DatadogInstrumentationCRD (新規)
• Autodiscovery 構成ファイル

これらのログ構成に source タグおよび service タグを設定することを強く推奨します。source タグを Datadog の すぐに使用できるログパイプライン のいずれかに一致させると、ログが自動的に強化されます。また、Datadog のパイプラインライブラリ も参照できます。service タグは Unified Service Tagging を強化し、ログを同じサービスのメトリクスやトレースとリンクさせます。source と service が省略された場合、Agent は (設定されている場合は) Unified Service Tagging の service タグにフォールバックし、それ以外の場合はコンテナのショートイメージ名を使用します。

Autodiscovery アノテーション

Autodiscovery を使用すると、Agent はすべての Pod アノテーションからインテグレーションテンプレートを自動的に検索します。

特定のコンテナに特定の構成を適用するには、JSON 形式のログ構成を含むアノテーション ad.datadoghq.com/<CONTAINER_NAME>.logs を Pod に追加します。

注: Autodiscovery アノテーションは、イメージではなく、名前でコンテナを識別します。<CONTAINER_NAME> を .spec.containers[i].name と照合しようとします。.spec.containers[i].image とは照合しません。

単一のコンテナを構成する

Pod 内の特定のコンテナのログ収集を構成するには、Pod に次のアノテーションを追加します。

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME>.logs: '[<LOG_CONFIG>]'
    # (...)
spec:
  containers:
    - name: '<CONTAINER_NAME>'
# (...)

ログ Autodiscovery アノテーションの例

次の Pod アノテーションは、例として示すコンテナのインテグレーションテンプレートを定義します。これは Deployment 自体ではなく、Pod テンプレートのアノテーション内で定義されます。このログ構成は、app コンテナからのすべてのログに、source:java、service:example-app、および追加タグ foo:bar を設定します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
  labels:
    app: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
      annotations:
        ad.datadoghq.com/app.logs: '[{"source":"java", "service":"example-app", "tags":["foo:bar"]}]'
    spec:
      containers:
        - name: app
          image: owner/example-image:latest

2 つの異なるコンテナを構成する

Pod 内の 2 つの異なるコンテナ <CONTAINER_NAME_1> および <CONTAINER_NAME_2> に 2 つの異なるインテグレーションテンプレートを適用するには、Pod に次のアノテーションを追加します。

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME_1>.logs: '[<LOG_CONFIG_1>]'
    # (...)
    ad.datadoghq.com/<CONTAINER_NAME_2>.logs: '[<LOG_CONFIG_2>]'
spec:
  containers:
    - name: '<CONTAINER_NAME_1>'
    # (...)
    - name: '<CONTAINER_NAME_2>'
# (...)

DatadogInstrumentation CRD

Pod や Deployment にアノテーションを付ける代わりに、DatadogInstrumentation カスタムリソース を使用してログ収集を構成できます。次の例は、app Deployment の一部である example コンテナ用です。

apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: example-logs
  namespace: <WORKLOAD_NAMESPACE>
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example
  config:
    logs:
      - containerName: app
        source: java
        service: example-app
        tags:
          - foo:bar

Autodiscovery 構成ファイル

Datadog Agent に構成ファイルを提供することで、一致するイメージ識別子を使用するコンテナを検出した際に、Agent が指定されたインテグレーションを実行するようにできます。これにより、一連のコンテナイメージに適用される汎用的なログ構成を作成できます。

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  #(...)
  override:
    nodeAgent:
      extraConfd:
        configDataMap:
          <INTEGRATION_NAME>.yaml: |-
            ad_identifiers:
            - <CONTAINER_IMAGE>

            logs:
            - source: example-source
              service: example-service

datadog:
  #(...)
  confd:
    <INTEGRATION_NAME>.yaml: |-
      ad_identifiers:
      - <CONTAINER_IMAGE>
      logs:
      - source: example-source
        service: example-service

etcdctl mkdir /datadog/check_configs/redis
etcdctl set /datadog/check_configs/redis/logs '[{"source": "redis", "service": "redis", "tags": ["env:prod"]}]'

config_providers:
  - name: etcd
    polling: true
    template_dir: /datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    username:
    password:

  - name: consul
    polling: true
    template_dir: datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    ca_file:
    ca_path:
    cert_file:
    key_file:
    username:
    password:
    token:

  - name: zookeeper
    polling: true
    template_dir: /datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    username:
    password:

/datadog/
  check_configs/
    <CONTAINER_IMAGE>/
      - logs: ["<LOGS_CONFIG>"]
    ...

コンテナのショートイメージ名よりも細かい粒度でログ構成を一連のコンテナに適用するには、Autodiscovery コンテナ識別子 を参照してください。

高度なログ収集

Autodiscovery ログラベルを使用して、高度なログ収集処理ロジックを適用します。例:

• Datadog に送信する前にログをフィルタリング。
• ログから機密データを削除。
• 複数行の集約に進む。

コンテナのローカルログファイルから

Datadog では、コンテナ化されたアプリケーションに対して stdout および stderr 出力ストリームを使用することを推奨しています。これにより、ログ収集をより自動的に設定できます。

ただし、Agent はアノテーションに基づいてファイルから直接ログを収集することもできます。これらのログを収集するには、ad.datadoghq.com/<CONTAINER_NAME>.logs および type: file 構成で path を使用します。このようなアノテーションが付いたファイルから収集されたログには、コンテナ自体から送信されるログと同じタグセットが自動的に付与されます。Datadog では、コンテナ化されたアプリケーションに対して stdout および stderr 出力ストリームを使用することを推奨しています。これにより、ログ収集を自動的に設定できます。詳細については、推奨構成を参照してください。

これらのファイルパスは、Agent コンテナからの相対パスです。そのため、Agent が適切にログファイルを参照できるように、ログファイルを含むディレクトリをアプリケーションコンテナと Agent コンテナの両方にマウントする必要があります。

例えば、共有 hostPath ボリュームを使用してこれを行うことができます。以下の Pod は、/var/log/example/app.log というファイルにログを出力しています。これは /var/log/example ディレクトリで行われ、volume と volumeMount によってこれが hostPath として設定されています。

apiVersion: v1
kind: Pod
metadata:
  name: logger
  annotations:
    ad.datadoghq.com/busybox.logs: |
      [{
          "type": "file",
          "path": "/var/log/example/app.log",
          "source": "example-source",
          "service": "example-service"
      }]
spec:
  containers:
   - name: busybox
     image: busybox
     command: [ "/bin/sh", "-c", "--" ]
     args: [ "while true; do sleep 1; echo `date` example file log >> /var/log/example/app.log; done;" ]
     volumeMounts:
     - name: applogs
       mountPath: /var/log/example
  volumes:
     - name: applogs
       hostPath:
         path: /var/log/example

Agent コンテナが同じログファイルを読み取れるように、対応する volume および volumeMount パスを Agent コンテナに設定する必要があります。

  containers:
  - name: agent
    # (...)
    volumeMounts:
    - mountPath: /var/log/example
      name: applogs
    # (...)
  volumes:
  - name: applogs
    hostPath:
      path: /var/log/example
    # (...)

推奨構成

• この方法は特定の Pod では有効ですが、この方法を使用するアプリケーションが複数あると煩雑になる可能性があります。複数のレプリカが同じログパスを使用している場合も、問題が発生する可能性があります。可能であれば、Datadog は Autodiscovery テンプレート変数 %%kube_pod_name%% を活用することを推奨します。例えば、path を設定して、この変数 "path": "/var/log/example/%%kube_pod_name%%/app.log" を参照させることができます。その場合、アプリケーション Pod もこの新しいパスに合わせてログファイルを書き込む必要があります。Downward API を使用して、アプリケーションが自身の Pod 名を特定できるようにします。

• コンテナでこの種のアノテーションを使用する場合、stdout および stderr のログはコンテナから自動的に収集されません。コンテナの出力ストリームとファイルの両方から収集する必要がある場合は、アノテーションでこれを明示的に有効にします。例:

  ad.datadoghq.com/<CONTAINER_IMAGE>.logs: |
    [
      {"type":"file","path":"/var/log/example/app.log","source":"file","service":"example-service"},
      {"source":"container","service":"example-service"}
    ]
  

• この種の組み合わせを使用する場合、source および service にはファイルから収集されるログのデフォルト値がないため、アノテーションで明示的に設定する必要があります。

トラブルシューティング

トラブルシューティングの手順については、コンテナログ収集のトラブルシューティング を参照してください。

詳細情報

役立つドキュメント、リンク、記事:

Datadog を使用して Amazon EKS on Fargate のログを監視するブログ アプリケーションのトレースを収集するドキュメント Prometheus のメトリクスを収集するドキュメント アプリケーションのメトリクスやログを自動的に収集するドキュメント データ収集を一部のコンテナのみに制限するドキュメント コンテナから出力されるすべてのデータにタグを付けるドキュメント コンテナのログ収集のトラブルシューティングドキュメント コンテナアプリの監視: ログアーキテクチャセンター