Collecte de logs de l'Agent de host

Documentation > Agent > Collecte de logs de l'Agent de host

La collecte de logs nécessite le Datadog Agent v6.0+. Les versions antérieures de l’Agent n’incluent pas l’interface log collection. Si vous n’utilisez pas encore l’Agent, suivez les instructions d’installation de l’Agent.

Consultez la section Observability Pipelines si vous souhaitez envoyer des logs en utilisant Collector ou Forwarder d’un autre fournisseur, ou si vous souhaitez prétraiter les données de vos logs dans votre environnement avant de les envoyer.

Activer la collecte de logs

La collecte de logs n’est pas activée par défaut dans le Datadog Agent. Si vous exécutez l’Agent dans un environnement Kubernetes ou Docker, consultez la documentation dédiée Collecte de logs Kubernetes ou Collecte de logs Docker.

Pour activer la collecte de logs avec un Agent exécuté sur votre host, remplacez logs_enabled: false par logs_enabled: true dans le fichier de configuration principal de l’Agent (datadog.yaml).

datadog.yaml

logs_enabled: true
logs_config:
    auto_multi_line_detection: true
    force_use_http: true

Pour toutes les options de configuration disponibles, consultez les exemples de fichiers de configuration de l’Agent pour votre système d’exploitation.

À partir de l'Agent v6.19+/v7.19+, le transport HTTPS est le transport par défaut utilisé. Pour plus de détails, consultez le transport de l'Agent.

Pour envoyer des logs avec des variables d’environnement, configurez ce qui suit :

DD_LOGS_ENABLED=true

Après avoir activé la collecte de logs, l’Agent est prêt à transférer les logs vers Datadog. Ensuite, configurez l’Agent pour définir l’emplacement de collecte des logs.

Collecte de logs personnalisée

Le Datadog Agent v6 peut recueillir des logs et les transférer à Datadog à partir des fichiers, du réseau (TCP ou UDP), de journald et des canaux Windows :

Dans le répertoire conf.d/ à la racine de votre répertoire de configuration de l’Agent, créez un nouveau dossier <CUSTOM_LOG_SOURCE>.d/ accessible par l’utilisateur Datadog.
Créez un nouveau fichier conf.yaml dans ce nouveau dossier.
Ajoutez un groupe de configuration de collecte de logs personnalisée avec les paramètres ci-dessous.
Redémarrez votre Agent pour prendre en compte cette nouvelle configuration.
Exécutez la sous-commande de statut de l’Agent et recherchez <CUSTOM_LOG_SOURCE> dans la section Checks.

En cas d’erreurs de permission, consultez Problèmes de permission lors du suivi des fichiers de log pour résoudre le problème.

Pour déployer une configuration de collecte de logs personnalisée sur plusieurs Agents à la fois sans modifier les fichiers sur chaque host, consultez Configure Custom Logs avec Fleet Automation.

Voici des exemples de configuration de collecte de logs personnalisée ci-dessous :

Pour collecter des logs depuis votre application <APP_NAME> stockée dans <PATH_LOG_FILE>/<LOG_FILE_NAME>.log, créez un fichier <APP_NAME>.d/conf.yaml à la racine de votre répertoire de configuration de l’Agent avec le contenu suivant :

logs:
  - type: file
    path: "<PATH_LOG_FILE>/<LOG_FILE_NAME>.log"
    service: "<APP_NAME>"
    source: "<SOURCE>"

Sur Windows, utilisez le chemin <DRIVE_LETTER>:\\<PATH_LOG_FILE>\\<LOG_FILE_NAME>.log et vérifiez que l’utilisateur ddagentuser dispose d’un accès en lecture au fichier de log.

Remarque : Une ligne de log doit se terminer par un caractère de saut de ligne, \n ou \r\n, sinon l’Agent attend indéfiniment et n’envoie pas la ligne de log.

Pour capturer l’adresse IP de l’expéditeur et l’inclure dans la charge utile du message de log, ajoutez la configuration suivante à votre fichier datadog.yaml :

 logs_config:
   use_sourcehost_tag: true

Pour collecter des logs depuis votre application <APP_NAME> qui transfère ses logs vers le port TCP 10518, créez un fichier <APP_NAME>.d/conf.yaml à la racine de votre répertoire de configuration de l’Agent avec le contenu suivant :

logs:
  - type: tcp
    port: 10518
    service: "<APP_NAME>"
    source: "<CUSTOM_SOURCE>"

Si vous utilisez Serilog, Serilog.Sinks.Network est une option pour la connexion via UDP.

Depuis la version 7.31.0 de l’Agent, la connexion TCP reste ouverte indéfiniment même en cas d’inactivité.

Remarques :

L’Agent prend en charge les logs au format chaîne brute, JSON et Syslog. Si vous envoyez des logs par lots, utilisez des caractères de saut de ligne pour séparer vos logs.
Une ligne de log doit se terminer par un caractère de saut de ligne, \n ou \r\n, sinon l’Agent attend indéfiniment et n’envoie pas la ligne de log.

Pour collecter des logs depuis journald, créez un fichier journald.d/conf.yaml à la racine de votre répertoire de configuration de l’Agent avec le contenu suivant :

logs:
  - type: journald
    path: /var/log/journal/

Consultez la documentation relative à l’intégration journald pour en savoir plus sur la configuration des environnements conteneurisés et du filtrage des unités.

Pour envoyer des événements Windows en tant que logs à Datadog, ajoutez manuellement les canaux à conf.d/win32_event_log.d/conf.yaml ou utilisez le Datadog Agent Manager.

Pour consulter votre liste de canaux, exécutez la commande suivante dans PowerShell :

Get-WinEvent -ListLog *

Pour connaître les canaux les plus actifs, exécutez la commande suivante dans PowerShell :

Get-WinEvent -ListLog * | sort RecordCount -Descending

Ajoutez ensuite les canaux à votre fichier de configuration win32_event_log.d/conf.yaml :

logs:
  - type: windows_event
    channel_path: "<CHANNEL_1>"
    source: "<CHANNEL_1>"
    service: "<SERVICE>"
    sourcecategory: windowsevent

  - type: windows_event
    channel_path: "<CHANNEL_2>"
    source: "<CHANNEL_2>"
    service: "<SERVICE>"
    sourcecategory: windowsevent

Modifiez les paramètres <CHANNEL_X> avec le nom du canal Windows dont vous souhaitez collecter les événements. Définissez le paramètre source correspondant sur le même nom de canal pour bénéficier de la configuration automatique du pipeline de traitement de l’intégration.

Pour terminer, redémarrez l’Agent.

Suivez les étapes de ces sections pour envoyer les logs de l’emplacement privé Windows à Datadog :

Configurez l’Agent

Activez la collecte des logs de l’Agent en définissant logs_enabled: true dans le fichier de configuration de l’Agent.
Accédez à C:\ProgramData\Datadog\conf.d et créez un dossier nommé synthetics_worker.d.
Dans le dossier synthetics_worker.d, créez un fichier nommé conf.yaml en utilisant l’exemple suivant comme modèle :

logs:
  - type: file
    path: "C:\\Program Files\\Datadog-Synthetics\\Synthetics\\private-location-service.out.log"
    service: <YOUR_SERVICE>
    source: synthetics
    tags: # Defined per user preference
      - env:<YOUR_ENV>
      - private_location:<YOUR_PRIVATE_LOCATION>

Vérifiez l’utilisateur exécutant l’Agent

Comme le dossier d’installation de l’emplacement privé est restreint à l’accès administrateur, le Datadog Agent a besoin d’une autorisation pour accéder au fichier de log. Suivez ces étapes pour vérifier l’utilisateur exécutant le Datadog Agent :

Appuyez sur la touche Windows et R, puis recherchez Run.
Recherchez le Datadog Agent, faites un clic droit dessus et sélectionnez Properties.
Dans l’onglet Log On, vérifiez le compte (la valeur par défaut est ddagentuser).
Fermez la fenêtre.

Accordez l’autorisation à l’utilisateur exécutant l’Agent

Accédez à C:\Program Files et recherchez le dossier synthetics_worker.d.
Faites un clic droit sur le dossier synthetics_worker.d et sélectionnez Properties.
Accédez à l’onglet Security.
Cliquez sur Edit et ajoutez ddagentuser.
Accordez les autorisations nécessaires.
Redémarrez le Datadog Agent via l’écran Services ou la ligne de commande pour appliquer les modifications et commencer à envoyer des logs à Datadog.

Liste complète des paramètres disponibles pour la collection de logs :

Paramètre	Requis	Description
`type`	Oui	Le type de source d’entrée de log. Les valeurs valides sont : `tcp`, `udp`, `file`, `windows_event`, `docker` ou `journald`.
`port`	Oui	Si `type` est tcp ou udp, définissez le port d’écoute des logs.
`path`	Oui	Si `type` est file ou journald, définissez le chemin du fichier pour la collecte des logs.
`channel_path`	Oui	Si `type` est windows_event, listez les canaux d’événements Windows pour la collecte des logs.
`service`	Oui	Le nom du service propriétaire du log. Si vous avez instrumenté votre service avec Datadog APM, il doit s’agir du même nom de service. Vérifiez les instructions de unified service tagging lors de la configuration de `service` pour plusieurs types de données.
`source`	Oui	L’attribut qui définit quelle intégration envoie les logs. Si les logs ne proviennent pas d’une intégration existante, ce champ peut inclure un nom de source personnalisé. Cependant, il est recommandé de faire correspondre cette valeur à l’espace de nommage de toutes les métriques personnalisées associées que vous collectez, par exemple : `myapp` depuis `myapp.request.count`.
`include_units`	Non	Si `type` est journald, liste des unités journald spécifiques à inclure.
`exclude_paths`	Non	Si `type` est file et que `path` contient un caractère générique, listez le ou les fichiers correspondants à exclure de la collecte de logs. Ceci est disponible pour la version de l’Agent >= 6.18.
`exclude_units`	Non	Si `type` est journald, liste des unités journald spécifiques à exclure.
`sourcecategory`	Non	L’attribut utilisé pour définir la catégorie à laquelle appartient un attribut source, par exemple : `source:postgres, sourcecategory:database` ou `source: apache, sourcecategory: http_web_access`.
`start_position`	Non	Consultez Position de départ pour plus d’informations.
`encoding`	Non	Si `type` est file, définissez l’encodage pour que l’Agent puisse lire le fichier. Définissez-le sur `utf-16-le` pour UTF-16 little-endian, `utf-16-be` pour UTF-16 big-endian ou `shift-jis` pour Shift JIS. Si une autre valeur est définie, l’Agent lit le fichier en tant qu’UTF-8. Ajout de `utf-16-le` et `utf-16be` dans l’Agent v6.23/v7.23, `shift-jis` dans l’Agent v6.34/v7.34
`tags`	Non	Une liste de tags ajoutés à chaque log collecté (en savoir plus sur le tagging).

Position de départ

Le paramètre start_position est pris en charge par les types de suivi file et journald. Le start_position est toujours beginning lors du suivi d’un conteneur.

Compatibilité :

File : Agent 6.19+/7.19+
Journald : Agent 6.38+/7.38+

Si type est file :

Définissez la position à partir de laquelle l’Agent commence à lire le fichier.
Les valeurs valides sont beginning, end, forceBeginning et forceEnd (par défaut : end).
La position beginning ne prend pas en charge les chemins avec des caractères génériques.

Si type est journald :

Définissez la position à partir de laquelle l’Agent commence à lire le journal.
Les valeurs valides sont beginning, end, forceBeginning et forceEnd (par défaut : end).

Priorité

Pour les types de suivi file et journald, si une position end ou beginning est spécifiée, mais qu’un décalage est enregistré, le décalage est prioritaire. L’utilisation de forceBeginning ou forceEnd force l’Agent à utiliser la valeur spécifiée même s’il existe un décalage enregistré.