Log collection with Docker socket

문서 > 에이전트 > Agent FAQ > Log collection with Docker socket

이 페이지는 아직 한국어로 제공되지 않으며 번역 작업 중입니다. 번역에 관한 질문이나 의견이 있으시면 언제든지 저희에게 연락해 주십시오.

The Datadog Agent has two ways to collect logs: from Kubernetes log files, or from the Docker socket. Datadog recommends using Kubernetes log files when:

Docker is not the runtime, or
More than 10 containers are used on each node

The Docker API is optimized to get logs from one container at a time. When there are many containers in the same node, collecting logs through the Docker socket may consume more resources than collecting logs through Kubernetes log files.

This page discusses log collection with the Docker socket. To use Kubernetes log files, see Kubernetes log collection.

Configuration

Mount the Docker socket into the Datadog Agent:

  # (...)
    env:
      - {name: "DD_CRI_SOCKET_PATH", value: "/host/var/run/docker.sock"}
      - {name: "DOCKER_HOST", value: "unix:///host/var/run/docker.sock"}
  # (...)
    volumeMounts:
    #  (...)
      - name: dockersocketdir
        mountPath: /host/var/run
  # (...)
  volumes:
    # (...)
    - hostPath:
        path: /var/run
      name: dockersocketdir
  # (...)

Note: Mounting only the docker.sock socket instead of the whole directory containing it prevents the Agent from recovering after a Docker daemon restart.

Kubernetes

To use the Docker Socket for log collection in a Kubernetes environment, ensure Docker is the runtime and DD_LOGS_CONFIG_K8S_CONTAINER_USE_FILE has been set to false.

Short lived containers

For a Docker environment, the Agent receives container updates in real time through Docker events. The Agent extracts and updates the configuration from the container labels (Autodiscovery) once every second. Since Agent v6.14+, the Agent collects logs for all containers (running or stopped) which means that short lived containers logs that have started and stopped in the past second are still collected as long as they are not removed.

Autodiscovery

The Agent looks for Autodiscovery templates in the mounted /conf.d directory.

The advantage of storing templates as local files (and mounting them inside the containerized Agent) is that this does not require an external service or a specific orchestration platform.

The disadvantage is that you must restart your Agent containers each time you change, add, or remove templates.

Custom auto-configuration files

If you need a custom Datadog integration configuration to enable extra options, use different container identifiers—or use template variable indexing and write your own auto-configuration file:

Create a conf.d/<INTEGRATION_NAME>.d/conf.yaml file on your host and add your custom auto-configuration.
```
ad_identifiers:
  <INTEGRATION_AUTODISCOVERY_IDENTIFIER>

logs:
  <LOGS_CONFIG>
```
See the Autodiscovery Container Identifiers documentation for information about <INTEGRATION_AUTODISCOVERY_IDENTIFIER>.
Mount your host conf.d/ folder to the containerized Agent’s conf.d folder.

On Kubernetes, you can use ConfigMaps. Reference the template below and the Kubernetes Custom Integrations documentation.

apiVersion: v1
metadata:
  name: "<NAME>-config-map"
  namespace: default
data:
  <INTEGRATION_NAME>-config: |-
    ad_identifiers:
      <INTEGRATION_AUTODISCOVERY_IDENTIFIER>
    logs:
      <LOGS_CONFIG>

See the Autodiscovery Container Identifiers documentation for information on the <INTEGRATION_AUTODISCOVERY_IDENTIFIER>.

You can customize logs collection per integration within confd. This method mounts the desired configuration onto the Agent container.

confd:
  <INTEGRATION_NAME>.yaml: |-
    ad_identifiers:
      - <INTEGRATION_AUTODISCOVERY_IDENTIFIER>
    init_config:
    instances:
      (...)
    logs:
      <LOGS_CONFIG>