Kubernetes ログの収集

注: このオプションは Windows ではサポートされません。代わりに Helm オプションを使用してください。

DaemonSet によるログの収集を有効にするには

1. datadog.yaml Agent マニフェストの env セクションで、DD_LOGS_ENABLED 変数と DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL 変数を true に設定します。

    # (...)
     env:
       # (...)
       - name: DD_LOGS_ENABLED
         value: "true"
       - name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
         value: "true"
       - name: DD_CONTAINER_EXCLUDE
         value: "name:datadog-agent"
    # (...)
   

   注: DD_CONTAINER_EXCLUDE を設定すると、Datadog Agent で自身のログ収集および送信が実行されなくなります。Datadog Agent ログを収集する場合は、このパラメーターを削除します。詳細については、コンテナのディスカバリー管理を参照してください。OpenShift 環境内で ImageStreams を使用する場合は、DD_CONTAINER_INCLUDE にコンテナの name を設定してログを収集します。

2. 再起動やネットワーク障害の際にコンテナログを失わないように、pointdir ボリュームをマウントします。/var/log/pods がこのディレクトリへのシンボリックリンクであるため、Kubernetes ログファイルからログを収集するよう /var/lib/docker/containers もマウントします。

     # (...)
       volumeMounts:
       #  (...)
         - name: pointdir
           mountPath: /opt/datadog-agent/run
        - name: logpodpath
          mountPath: /var/log/pods
        # Docker runtime directory, replace this path
        # with your container runtime logs directory,
        # or remove this configuration if `/var/log/pods`
        # is not a symlink to any other directory.
        - name: logcontainerpath
          mountPath: /var/lib/docker/containers
     # (...)
     volumes:
      # (...)
       - hostPath:
           path: /opt/datadog-agent/run
         name: pointdir
       - hostPath:
           path: /var/log/pods
         name: logpodpath
       # Docker runtime directory, replace this path
       # with your container runtime logs directory,
       # or remove this configuration if `/var/log/pods`
       # is not a symlink to any other directory.
       - hostPath:
           path: /var/lib/docker/containers
         name: logcontainerpath
       # (...)
   

   pointdir は、Agent がログを収集するすべてのコンテナへのポインターを含むファイルを格納するために使用されます。これは、Agent が再起動したり、ネットワークに問題があった場合でも、何も失われないようにするためです。

Helm によるログの収集を有効にするには、次のログ収集コンフィギュレーションで datadog-values.yaml ファイルを更新してから、Datadog Helm チャートをアップグレードします。

datadog:
  ## @param logs - object - required
  ## ログ Agent を有効にし、カスタムコンフィグを提供
  #
  logs:
    ## @param enabled - boolean - optional - default: false
    ## これを有効にし、Datadog Agent のログの収集を開始します。
    #
    enabled: true

    ## @param containerCollectAll - boolean - optional - default: false
    ## これを有効にし、すべてのコンテナのログの収集を可能にします。
    #
    containerCollectAll: true

インテグレーションテンプレートは、Kubernetes のポッドアノテーションに格納できます。オートディスカバリーを使用して、Agent は、自身が Kubernetes 上で実行されているかどうかを検出し、すべてのポッドアノテーションでインテグレーションテンプレートを自動的に探します。

特定のコンフィギュレーションを特定のコンテナに適用するために、オートディスカバリーはコンテナをイメージではなく、名前で識別します。つまり、<コンテナ識別子> は、.spec.containers[0].image とではなく .spec.containers[0].name との一致が試みられます。ポッド内の特定の <コンテナ識別子> で Datadog インテグレーションのオートディスカバリーを構成するには、以下のアノテーションをポッドに追加します。

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<ポッド名>'
  annotations:
    ad.datadoghq.com/<コンテナ識別子>.logs: '[<ログ_コンフィグ>]'
    # (...)
spec:
  containers:
    - name: '<コンテナ識別子>'
# (...)

ポッド内の 2 つの異なるコンテナ <CONTAINER_IDENTIFIER_1> と <CONTAINER_IDENTIFIER_2> に 2 つの異なるインテグレーションテンプレートを適用するには、次のアノテーションをポッドに追加します。

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<ポッド名>'
  annotations:
    ad.datadoghq.com/<コンテナ識別子_1>.logs: '[<ログ_コンフィグ_1>]'
    # (...)
    ad.datadoghq.com/<コンテナ識別子_2>.logs: '[<ログ_コンフィグ_2>]'
spec:
  containers:
    - name: '<コンテナ識別子_1>'
    # (...)
    - name: '<コンテナ識別子_2>'
# (...)

注: kind: Pod を使用して Kubernetes ポッドを直接定義する場合は、各ポッドのアノテーションを metadata セクションの直下に追加します。Replication Controller、Replica Set、または Deployment を使用してポッドを間接的に定義する場合は、ポッドアノテーションを .spec.template.metadata の下に追加します。

テンプレートをローカルファイルとして保存し、それをコンテナ化 Agent 内にマウントする場合は、外部サービスや特定のオーケストレーションプラットフォームを必要としません。この方法の欠点は、テンプレートを変更、追加、または削除するたびに、Agent コンテナを再起動する必要がある点です。Agent は、マウントされた /conf.d ディレクトリでオートディスカバリーテンプレートを探します。

Agent v6.2.0 (および v5.24.0) 以降、デフォルトテンプレートはポートを自動検出するのではなく、監視対象ソフトウェアのデフォルトポートを使用します。別のポートを使用する必要がある場合は、Docker コンテナラベルまたは Kubernetes ポッドアノテーションで、カスタムオートディスカバリーテンプレートを指定します。

デフォルトのインテグレーションテンプレートは、基本的なケース向けです。追加オプションを有効にするためにカスタム Datadog インテグレーション構成が必要な場合は、別のコンテナ識別子を使用します。あるいは、テンプレート変数インデックスを使用して、独自のオートディスカバリー構成ファイルを作成します。

1. ホストに conf.d/<INTEGRATION_NAME>.d/conf.yaml ファイルを作成し、カスタムオートディスカバリー構成を追加します。
2. ホスト の conf.d/ フォルダーをコンテナ化 Agent の conf.d フォルダーにマウントします。

オートディスカバリー構成ファイル例:

ad_identifiers:
  <インテグレーションオートディスカバリー識別子>

logs:
  <ログ_コンフィグ>

<INTEGRATION_AUTODISCOVERY_IDENTIFIER> の詳細については、オートディスカバリーコンテナ識別子のドキュメントを参照してください。

注: Agent はファイル名から直接 <INTEGRATIONS_NAME> を推測するため、この名前を設定する必要はありません。

Kubernetes では、ConfigMaps を使用できます。以下のテンプレートとKubernetes カスタムインテグレーションに関するドキュメントを参照してください。

kind: ConfigMap
apiVersion: v1
metadata:
  name: "<名前>-config-map"
  namespace: default
data:
  <インテグレーション名>-config: |-
    ad_identifiers:
      <インテグレーションオートディスカバリー識別子>
    logs:
      <ログ_コンフィグ>

<INTEGRATION_AUTODISCOVERY_IDENTIFIER> の詳細については、オートディスカバリーコンテナ識別子のドキュメントを参照してください。

オートディスカバリーでは、Consul、Etcd、および Zookeeper をインテグレーションテンプレートソースとして使用できます。key-value ストアを使用するには、Agent の datadog.yaml 構成ファイルでストアを構成し、このファイルをコンテナ化 Agent 内にマウントします。あるいは、key-value ストアを環境変数としてコンテナ化 Agent に渡します。

datadog.yaml での構成

datadog.yaml ファイルで、key-value ストアの <KEY_VALUE_STORE_IP> アドレスと <KEY_VALUE_STORE_PORT> を以下のように設定します。

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:

次に、Agent を再起動して、構成の変更を適用します。

環境変数での構成

key-value ストアがテンプレートソースとして有効になっている場合、Agent はキー /datadog/check_configs の下でテンプレートを探します。オートディスカバリーは、以下のような key-value 階層を前提とします。

/datadog/
  check_configs/
    <コンテナ識別子>/
      - logs: ["<ログ_コンフィグ>"]
    ...

注: key-value ストアを使用している場合、オートディスカバリーは特定の構成を特定のコンテナに適用するために、<CONTAINER_IDENTIFIER> と .spec.containers[0].image の一致を試みることで、コンテナをイメージで識別します。

以下のポッドアノテーションは、カスタム password パラメーターを使用して redis コンテナのインテグレーションテンプレートを定義し、すべてのログに正しい source および service 属性でタグ付けします。

apiVersion: v1
kind: Pod
metadata:
  name: redis
  annotations:
    ad.datadoghq.com/redis.logs: '[{"source":"redis","service":"redis"}]'
  labels:
    name: redis
spec:
  containers:
    - name: redis
      image: redis:latest
      ports:
        - containerPort: 6379

次の ConfigMap は、ログを収集するための source 属性と service 属性を使用して、redis コンテナのインテグレーションテンプレートを定義しています。

kind: ConfigMap
apiVersion: v1
metadata:
  name: redis-config-map
  namespace: default
data:
  redisdb-config: |-
    ad_identifiers:
      - redis
      - redis-test
    logs:
      source: redis
      service: redis

マニフェストで volumeMounts と volumes を定義します。

# [...]
        volumeMounts:
        # [...]
          - name: redisdb-config-map
            mountPath: /conf.d/redisdb.d
        # [...]
      volumes:
      # [...]
        - name: redisdb-config-map
          configMap:
            name: redisdb-config-map
            items:
              - key: redisdb-config
                path: conf.yaml
# [...]

以下の etcd コマンドは、カスタム password パラメーターを使用して Redis インテグレーションテンプレートを作成し、すべてのログに正しい source および service 属性でタグ付けします。

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

3 つの値がそれぞれリストであることに注目してください。オートディスカバリーは、共有リストインデックスに基づいて、リスト項目をインテグレーション構成に集約します。この例の場合は、check_names[0]、init_configs[0]、および instances[0] から最初 (かつ唯一) のチェック構成が作成されます。

auto-conf ファイルとは異なり、key-value ストアの場合は、コンテナ識別子として短いイメージ名 (redis など) も長いイメージ名 (redis:latest など) も使用できます。