このページでは、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 ソケットによるログ収集 を参照してください。コンテナ化されたアプリケーションがコンテナ内のログファイルに書き込んでいる場合、ログ収集が複雑になる可能性があります。log collection from a file を参照してください。

セットアップ

ログ収集

アプリケーションログの収集を開始する前に、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」機能が有効になっていると、Datadog Agent はデフォルトのタグセットを使用して、検出されたすべてのコンテナのログを報告します。

フィルタリング

「Container Collect All」が有効になっている場合、ログを収集するコンテナを設定できます。これは、必要に応じて Datadog Agent のログの収集を防ぐのに役立ちます。これは、Datadog Agent に取得対象を制御する設定を渡すか、特定のログをより明示的に除外するための設定を Kubernetes Pod に渡すことで実現できます。

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

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

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

タグ付け

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

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

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

インテグレーションログ

Autodiscovery では、テンプレートを使ってコンテナ上でログ収集 (およびその他の機能) の構成を行うことができます。これを使用して、ログ収集の有効化、タグ付けのカスタマイズ、および高度な収集ルールの追加を行えます。Autodiscovery を使用してインテグレーションのログ収集を構成するには、次のいずれかを実行します。

• 特定の Pod に Autodiscovery アノテーションとしてログ設定を指定し、特定のコンテナのルールを構成します (推奨)
• 構成ファイルとしてログ設定を指定し、イメージごとに一致する各コンテナのルールを構成します。

最低限、これらのログ設定には source および service タグが必要です。source タグを Datadog の 標準のログパイプライン のいずれかに一致させることで、ログを自動的に強化できます。Datadog の パイプラインライブラリ も参照できます。

Autodiscovery アノテーション

Autodiscovery では、Agent が自動的にすべてのポッドアノテーションを対象にインテグレーションテンプレートを検索します。

特定のコンテナに特定の構成を適用するには、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>'
# (...)

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 の出力ストリームを使用することを推奨しています。これにより、ログ収集を自動的に設定できます。詳細については、Recommended configurations を参照してください。

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

たとえば、共有 hostPath ボリュームを使用してこれを行うことができます。以下の Pod は、ファイル /var/log/example/app.log にログを出力しています。これは /var/log/example ディレクトリで行われており、ボリュームと 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 コンテナに同等のボリュームと VolumeMount パスを設定し、同じログファイルを読み込むことができるようにする必要があります。

  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 を使用して Fargate 上の Amazon EKS のログを監視します。ブログ アプリケーショントレースの収集よくあるご質問 Prometheus メトリクスの収集よくあるご質問 アプリケーションのメトリクスとログを自動で収集よくあるご質問 データ収集をコンテナのサブセットのみに制限よくあるご質問 コンテナから送信された全データにタグを割り当てよくあるご質問 コンテナログ収集のトラブルシューティングよくあるご質問