Cette page explique comment collecter des logs à partir des fichiers de logs Kubernetes.

Lorsque vos applications conteneurisées écrivent leurs logs dans la sortie standard et l’erreur standard (stdout/stderr), le container runtime et Kubernetes gèrent automatiquement les logs pour vous. Le modèle par défaut est que Kubernetes stocke ces flux de logs sous forme de fichiers sur le host dans le dossier /var/log/pods et les sous-dossiers pour chaque Pod et conteneur.

Le Datadog Agent peut collecter ces fichiers de logs Kubernetes pour ces conteneurs en suivant les instructions ci-dessous. Cette option s’adapte bien à la nature éphémère des Pods créés par Kubernetes et est plus efficace en termes de ressources que la collecte de logs à partir du socket Docker. Datadog recommande cette méthode pour la collecte de logs dans Kubernetes.

Alternativement, le Datadog Agent peut également collecter des logs en effectuant des requêtes répétées à l’API Docker via le socket Docker. Cependant, cela nécessite Docker comme conteneur runtime pour votre cluster Kubernetes. Cela est également plus gourmand en ressources que l’utilisation de fichiers de logs. Pour savoir comment collecter des logs à l’aide du socket Docker, consultez Collecte de logs avec le socket Docker. Si vos applications conteneurisées écrivent dans des fichiers de logs stockés dans le conteneur, cela peut compliquer la collecte de logs. Consultez collecte de logs à partir d’un fichier.

Configuration

Collecte de logs

Avant de commencer la collecte des logs d’application, assurez-vous que le Datadog Agent est en cours d’exécution dans votre cluster Kubernetes.

Pour configurer manuellement la collecte de logs dans le DaemonSet, consultez Collecte de logs avec DaemonSet. Sinon, suivez les instructions ci-dessous :

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

Sans privilèges

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>

Découverte de logs

Le Datadog Agent dans Kubernetes est déployé par un DaemonSet (géré par le Datadog Operator ou Helm). Ce DaemonSet planifie une réplique du Pod de l’Agent sur chaque nœud du cluster. Chaque Pod de l’Agent est ensuite responsable de rapporter les logs des autres Pods et conteneurs sur son nœud respectif. Lorsque la fonctionnalité « Container Collect All » est activée, l’Agent rapporte les logs de chaque conteneur découvert avec un ensemble par défaut de tags.

Filtrage

Lorsque « Container Collect All » est activé, vous pouvez configurer les conteneurs dont vous souhaitez collecter les logs. Cela peut être utile pour empêcher la collecte des logs du Datadog Agent, si vous le souhaitez. Vous pouvez le faire en transmettant des configurations au Datadog Agent pour contrôler ce qu’il récupère, ou en transmettant des configurations au Pod Kubernetes pour exclure certains logs de manière plus explicite.

Lors du filtrage des logs via des méthodes telles que DD_CONTAINER_EXCLUDE_LOGS ou ad.datadoghq.com/logs_exclude, l’Agent ignore la collecte de logs indépendamment des configurations de collecte de logs explicitement définies dans les annotations Autodiscovery, la DatadogInstrumentation CRD ou les fichiers de configuration Autodiscovery.

Lorsque « Container Collect All » est désactivé (par défaut), vous n’avez pas besoin d’ajouter de filtrage car tout est exclu par défaut. Pour inclure la collecte uniquement pour certains pods sélectionnés, vous pouvez activer la configuration des logs via les annotations Autodiscovery, la DatadogInstrumentation CRD ou les fichiers de configuration Autodiscovery pour les pods souhaités.

Consultez la section Gestion de la détection des conteneurs (en anglais) pour en savoir plus sur le filtrage.

Tagging

Le Datadog Agent tague les logs des conteneurs Kubernetes avec les tags Kubernetes par défaut, ainsi qu’avec tous les tags personnalisés extraits. Lorsque « Container Collect All » est activé, l’Agent rapporte les logs d’un conteneur avec un tag source et service correspondant au nom d’image court du conteneur. Par exemple, les logs d’un conteneur utilisant l’image gcr.io/owner/example-image:latest auraient example-image comme valeur de tag source, service et short_image.

Le tag service peut également être défini par le label de Pod tags.datadoghq.com/service: "<SERVICE>" de Unified Service Tagging. Pour plus d’informations sur les attributs source et service, consultez Attributs réservés.

Le tag source peut être important pour vos logs, car les pipelines de logs prêts à l’emploi sont filtrés à l’aide de ce tag. Cependant, ces pipelines peuvent être entièrement personnalisés selon vos besoins. Vous pouvez consulter les étapes dans la section Logs d’intégration ci-dessous pour personnaliser davantage les tags de vos logs.

Logs d’intégration

Autodiscovery vous permet d’utiliser des modèles pour configurer la collecte de logs et d’autres fonctionnalités sur les conteneurs. Utilisez l’une des méthodes suivantes pour configurer la collecte de logs :

• Annotations Autodiscovery (recommandé)
• DatadogInstrumentation CRD (nouveau)
• Fichiers de configuration d’Autodiscovery

Il est fortement recommandé de définir un tag source et service sur ces configurations de log. Faites correspondre le tag source à l’un des pipelines de logs prêts à l’emploi de Datadog afin que vos logs soient automatiquement enrichis ; vous pouvez également trouver une bibliothèque de pipelines dans Datadog. Le tag service alimente le Unified Service Tagging, reliant vos logs aux métriques et aux traces du même service. Si source et service sont omis, l’Agent revient au tag service du Unified Service Tagging (lorsqu’il est défini), et sinon au nom d’image court du conteneur.

Annotations d’Autodiscovery

Avec Autodiscovery, l’Agent recherche automatiquement les modèles d’intégration dans les annotations des pods.

Pour appliquer une configuration spécifique à un conteneur donné, ajoutez l’annotation ad.datadoghq.com/<CONTAINER_NAME>.logs à votre Pod avec la configuration de log au format JSON.

Remarque : Les annotations d’Autodiscovery identifient les conteneurs par leur nom, non par leur image. Il tente de faire correspondre <CONTAINER_NAME> au .spec.containers[i].name, et non au .spec.containers[i].image.

Configurer un seul conteneur

Pour configurer la collecte des logs pour un conteneur donné dans un pod, ajoutez les annotations suivantes à votre pod :

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

Exemple d’annotations d’Autodiscovery de logs

L’annotation de Pod suivante définit le modèle d’intégration pour un exemple de conteneur. Elle est définie dans les annotations du modèle de Pod, plutôt que sur le Deployment lui-même. Cette configuration de log définit tous les logs du conteneur app avec les tags source:java, service:example-app, et le tag supplémentaire 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

Configurez deux conteneurs différents

Pour appliquer deux modèles d’intégration différents à deux conteneurs différents au sein de votre Pod, <CONTAINER_NAME_1> et <CONTAINER_NAME_2>, ajoutez les annotations suivantes à votre 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>'
# (...)

CRD DatadogInstrumentation

Au lieu d’annoter vos pods ou déploiements, vous pouvez utiliser une DatadogInstrumentation ressource personnalisée pour configurer la collecte des logs. L’exemple suivant concerne la partie conteneur app du 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

Fichiers de configuration d’Autodiscovery

Vous pouvez fournir au Datadog Agent des fichiers de configuration pour que l’Agent exécute une intégration spécifiée lorsqu’il découvre un conteneur utilisant l’identifiant d’image correspondant. Cela vous permet de créer une configuration de log générique qui s’applique à un ensemble d’images de conteneur.

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>"]
    ...

Pour faire correspondre une configuration de log à un ensemble de conteneurs avec plus de granularité que le nom d’image court du conteneur, consultez Autodiscovery Container Identifiers.

Collecte de logs avancée

Utilisez les étiquettes de log Autodiscovery afin d’appliquer la logique de processing pour la collecte de logs avancée, par exemple :

• Filtrer les logs avant de les envoyer à Datadog.
• Nettoyez les données sensibles de vos logs.
• Passez à l’agrégation multiligne de journaux.

À partir d’un fichier de log local au conteneur

Datadog recommande d’utiliser les flux de sortie stdout et stderr pour les applications conteneurisées, afin de pouvoir configurer la collecte de logs plus automatiquement.

Cependant, l’Agent peut également collecter directement les logs à partir d’un fichier basé sur une annotation. Pour collecter ces logs, utilisez ad.datadoghq.com/<CONTAINER_NAME>.logs avec une configuration type: file et path. Les logs collectés à partir de fichiers avec une telle annotation sont automatiquement tagués avec le même ensemble de tags que les logs provenant du conteneur lui-même. Datadog recommande d’utiliser les flux de sortie stdout et stderr pour les applications conteneurisées, afin de pouvoir configurer automatiquement la collecte de logs. Pour plus d’informations, consultez les Configurations recommandées.

Ces chemins de fichiers sont relatifs au conteneur de l’Agent. Par conséquent, le répertoire contenant le fichier de log doit être monté à la fois dans le conteneur de l’application et dans celui de l’Agent afin que l’Agent puisse avoir une visibilité appropriée.

Par exemple, vous pouvez le faire avec un volume hostPath. Le Pod ci-dessous émet des logs dans le fichier /var/log/example/app.log. Cela est effectué dans le répertoire /var/log/example, où un volume et un volumeMount ont défini ceci comme un 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

Le même volume et le même chemin volumeMount doivent être définis dans le conteneur de l’Agent pour qu’il puisse lire ce fichier de log.

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

Configurations recommandées

• Cette stratégie peut fonctionner pour un pod donné, mais peut devenir fastidieuse avec plusieurs applications utilisant cette stratégie. Vous pouvez également rencontrer des problèmes si plusieurs réplicas utilisent le même chemin de log. Si possible, Datadog recommande de tirer parti de la variable de modèle Autodiscovery %%kube_pod_name%%. Par exemple, vous pouvez définir votre path pour référencer cette variable : "path": "/var/log/example/%%kube_pod_name%%/app.log". Votre pod d’application doit alors également écrire ses fichiers de log en respectant ce nouveau chemin. Vous pouvez utiliser l’API Downward pour aider votre application à déterminer son nom de Pod.

• Lorsque vous utilisez ce type d’annotation avec un conteneur, les logs stdout et stderr ne sont pas collectés automatiquement depuis le conteneur. Si la collecte à la fois depuis les flux de sortie du conteneur et depuis le fichier est nécessaire, activez-la explicitement dans l’annotation. Exemple :

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

• Lorsque vous utilisez ce type de combinaison, source et service n’ont pas de valeur par défaut pour les logs collectés à partir d’un fichier et doivent être explicitement définis dans l’annotation.

Dépannage

Pour les étapes de dépannage, consultez Dépannage de la collecte des logs de conteneur.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Surveillez les logs d'Amazon EKS sur Fargate avec DatadogBLOG Recueillir les traces de votre applicationDOCUMENTATION Recueillez vos métriques PrometheusDOCUMENTATION Recueillez automatiquement les métriques et les logs de vos applicationsDOCUMENTATION Limitez la collecte de données à un sous-ensemble de conteneursDOCUMENTATION Attribuez des tags à toutes les données envoyées par un conteneurDOCUMENTATION Dépannage de la collecte de logs de conteneursDOCUMENTATION Surveillance des applications de conteneurs - LogsCENTRE D'ARCHITECTURE