Collecte de logs de l'Agent de host

La collecte de logs nécessite la version 6.0+ de l’Agent. Les anciennes versions 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 relative aux pipelines dʼobservabilité 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 est désactivée par défaut dans l’Agent Datadog. Si vous exécutez l’Agent au sein d’un environnement Kubernetes ou Docker, consultez la section Collecte de logs Kubernetes ou Collecte de logs Docker.

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

datadog.yaml

## @param logs_enabled - boolean - optional - default: false
## @env DD_LOGS_ENABLED - boolean - optional - default: false
## Enable Datadog Agent log collection by setting logs_enabled to true.
logs_enabled: false

## @param logs_config - custom object - optional
## Enter specific configurations for your Log collection.
## Uncomment this parameter and the one below to enable them.
## See https://docs.datadoghq.com/agent/logs/
logs_config:

  ## @param container_collect_all - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL - boolean - optional - default: false
  ## Enable container log collection for all the containers (see ac_exclude to filter out containers)
  container_collect_all: false

  ## @param logs_dd_url - string - optional
  ## @env DD_LOGS_CONFIG_LOGS_DD_URL - string - optional
  ## Define the endpoint and port to hit when using a proxy for logs. The logs are forwarded in TCP
  ## therefore the proxy must be able to handle TCP connections.
  logs_dd_url: <ENDPOINT>:<PORT>

  ## @param logs_no_ssl - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_LOGS_NO_SSL - optional - default: false
  ## Disable the SSL encryption. This parameter should only be used when logs are
  ## forwarded locally to a proxy. It is highly recommended to then handle the SSL encryption
  ## on the proxy side.
  logs_no_ssl: false

  ## @param processing_rules - list of custom objects - optional
  ## @env DD_LOGS_CONFIG_PROCESSING_RULES - list of custom objects - optional
  ## Global processing rules that are applied to all logs. The available rules are
  ## "exclude_at_match", "include_at_match" and "mask_sequences". More information in Datadog documentation:
  ## https://docs.datadoghq.com/agent/logs/advanced_log_collection/#global-processing-rules
  processing_rules:
    - type: <RULE_TYPE>
      name: <RULE_NAME>
      pattern: <RULE_PATTERN>

  ## @param force_use_http - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_FORCE_USE_HTTP - boolean - optional - default: false
  ## By default, the Agent sends logs in HTTPS batches to port 443 if HTTPS connectivity can
  ## be established at Agent startup, and falls back to TCP otherwise. Set this parameter to `true` to
  ## always send logs with HTTPS (recommended).
  ## Warning: force_use_http means HTTP over TCP, not HTTP over HTTPS. Please use logs_no_ssl for HTTP over HTTPS.
  force_use_http: true

  ## @param force_use_tcp - boolean - optional - default: false
  ## @env DD_LOGS_CONFIG_FORCE_USE_TCP - boolean - optional - default: false
  ## By default, logs are sent through HTTPS if possible, set this parameter
  ## to `true` to always send logs via TCP. If `force_use_http` is set to `true`, this parameter
  ## is ignored.
  force_use_tcp: true

  ## @param use_compression - boolean - optional - default: true
  ## @env DD_LOGS_CONFIG_USE_COMPRESSION - boolean - optional - default: true
  ## This parameter is available when sending logs with HTTPS. If enabled, the Agent
  ## compresses logs before sending them.
  use_compression: true

  ## @param compression_level - integer - optional - default: 6
  ## @env DD_LOGS_CONFIG_COMPRESSION_LEVEL - boolean - optional - default: false
  ## The compression_level parameter accepts values from 0 (no compression)
  ## to 9 (maximum compression but higher resource usage). Only takes effect if
  ## `use_compression` is set to `true`.
  compression_level: 6

  ## @param batch_wait - integer - optional - default: 5
  ## @env DD_LOGS_CONFIG_BATCH_WAIT - integer - optional - default: 5
  ## The maximum time (in seconds) the Datadog Agent waits to fill each batch of logs before sending.
  batch_wait: 5

  ## @param open_files_limit - integer - optional - default: 500
  ## @env DD_LOGS_CONFIG_OPEN_FILES_LIMIT - integer - optional - default: 500
  ## The maximum number of files that can be tailed in parallel.
  ## Note: the default for Mac OS is 200. The default for
  ## all other systems is 500.
  open_files_limit: 500

  ## @param file_wildcard_selection_mode - string - optional - default: `by_name`
  ## @env DD_LOGS_CONFIG_FILE_WILDCARD_SELECTION_MODE - string - optional - default: `by_name`
  ## The strategy used to prioritize wildcard matches if they exceed the open file limit.
  ##
  ## Choices are `by_name` and `by_modification_time`.
  ##
  ## `by_name` means that each log source is considered and the matching files are ordered
  ## in reverse name order. While there are less than `logs_config.open_files_limit` files
  ## being tailed, this process repeats, collecting from each configured source.
  ##
  ## `by_modification_time` takes all log sources and first adds any log sources that
  ## point to a specific file. Next, it finds matches for all wildcard sources.
  ## This resulting list is ordered by which files have been most recently modified
  ## and the top `logs_config.open_files_limit` most recently modified files are
  ## chosen for tailing.
  ##
  ## WARNING: `by_modification_time` is less performant than `by_name` and will trigger
  ## more disk I/O at the configured wildcard log paths.
  file_wildcard_selection_mode: by_name

  ## @param max_message_size_bytes - integer - optional - default: 256000
  ## @env DD_LOGS_CONFIG_MAX_MESSAGE_SIZE_BYTES - integer - optional - default : 256000
  ## The maximum size of single log message in bytes. If maxMessageSizeBytes exceeds
  ## the documented API limit of 1MB - any payloads larger than 1MB will be dropped by the intake.
  https://docs.datadoghq.com/api/latest/logs/
  max_message_size_bytes: 256000

  ## @param integrations_logs_files_max_size - integer - optional - default: 10
  ## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_FILES_MAX_SIZE - integer - optional - default: 10
  ## The max size in MB that an integration logs file is allowed to use
  integrations_logs_files_max_size

  ## @param integrations_logs_total_usage - integer - optional - default: 100
  ## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_TOTAL_USAGE - integer - optional - default: 100
  ## The total combined usage all integrations logs files can use
  integrations_logs_total_usage

Depuis la version 6.19/7.19 de l’Agent, le transport HTTPS est utilisé par défaut. Pour découvrir comment imposer le transport HTTPS/TCP, consultez la section relative au transport de l’Agent.

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

  • DD_LOGS_ENABLED=true

Une fois la collecte de logs activée, l’Agent est prêt à envoyer ses logs à Datadog. Configurez ensuite l’Agent afin de définir les sources de collecte des logs.

Collecte de logs personnalisée

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

  1. Dans le répertoire conf.d/ à la racine du répertoire de configuration de votre Agent, créez un nouveau dossier <CUSTOM_LOG_SOURCE>.d/ auquel l’utilisateur Datadog peut accéder.
  2. Créez un fichier conf.yaml dans ce nouveau dossier.
  3. Ajoutez un groupe de configuration de collecte de logs personnalisée avec les paramètres ci-dessous.
  4. Redémarrez votre Agent pour appliquer cette nouvelle configuration.
  5. Lancez la sous-commande status de l’Agent et cherchez <SOURCE_LOGS_PERSONNALISÉE> dans la section Checks.

Si vous rencontrez des erreurs liées aux autorisations, consultez la rubrique Problèmes d’autorisation lors du suivi de fichiers de log pour les résoudre.

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

Pour recueillir les logs de votre application <NOM_APP> stockés dans <CHEMIN_FICHIER_LOG>/<NOM_FICHIER_LOG>.log, créez un fichier <NOM_APP>.d/conf.yaml à la racine du répertoire de configuration de votre Agent avec le contenu suivant :

logs:
  - type: file
    path: "<CHEMIN_FICHIER_LOG>/<NOM_FICHIER_LOG>.log"
    service: "<NOM_APP>"
    source: "<SOURCE>"

Sous Windows, utilisez le chemin <DRIVE_LETTER>:\\<PATH_LOG_FILE>\\<LOG_FILE_NAME>.log et vérifiez que l’utilisateur ddagentuser est autorisé à lire et modifier le fichier de log.

Remarque : une ligne de log doit se terminer par un caractère de retour à la ligne, \n ou \r\n. Autrement, lʼAgent attend indéfiniment et n’envoie pas la ligne de log.

Pour recueillir les logs de votre application <NOM_APP> qui transfert ses logs via TCP sur le port 10518, créez un fichier <NOM_APP>.d/conf.yaml à la racine du répertoire de configuration de votre Agent avec le contenu suivant :

logs:
  - type: tcp
    port: 10518
    service: "<NOM_APP>"
    source: "<SOURCE_PERSONNALISÉE>"

Si vous utilisez Serilog, vous disposez de l’option Serilog.Sinks.Network pour une 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 aux formats brut, JSON et Syslog. Si vous envoyez des logs en lot, séparez vos logs par des caractères de saut de ligne.
  • Une ligne de log doit se terminer par un caractère de retour à la ligne, \n ou \r\n. Autrement, lʼAgent attend indéfiniment et n’envoie pas la ligne de log.

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

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

Consultez la documentation relative à l’intégration journald pour obtenir des instructions de configuration spécifiques aux environnements conteneurisés et en savoir plus sur le filtrage des unités.

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

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

Get-WinEvent -ListLog *

Pour découvrir les canaux les plus actifs, exécutez la commande suivante dans PowerShell :

Get-WinEvent -ListLog * | sort RecordCount -Descending

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

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

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

Remplacez les paramètres <CANAL_X> par le nom du canal Windows pour lequel vous souhaitez recueillir des événements. Définissez le même nom de canal pour le paramètre source correspondant afin de bénéficier de la configuration de pipeline de traitement d’intégration automatique.

Pour terminer, redémarrez l’Agent.

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

ParamètreObligatoireRôle
typeOuiLe type de source d’entrée de log. Valeurs autorisées : tcp, udp, file, windows_event, docker ou journald.
portOuiSi type est défini sur tcp ou udp, configurez le port sur lequel l’écoute des logs est effectuée.
pathOuiSi type est défini sur file ou journald, configurez le chemin du fichier à partir duquel les logs sont recueillis.
channel_pathOuiSi type est défini sur windows_event, énumérez les canaux d’événements Windows à partir desquels les logs doivent être recueillis.
serviceOuiLe nom du service propriétaire du log. Si vous avez instrumenté votre service avec l’APM Datadog, ce paramètre doit correspondre au même nom de service. Consultez les instructions relatives au tagging de service unifié si vous configurez service pour plusieurs types de données.
sourceOuiUn attribut qui définit l’intégration qui envoie les logs. Si les logs ne viennent pas d’une intégration existante, vous pouvez spécifier le nom d’une source personnalisée. Toutefois, il est conseillé d’utiliser la valeur de l’espace de nommage des métriques custom recueillies. Exemple : myapp pour myapp.request.count.
include_unitsNonSi type est défini sur journald, il s’agit de la liste des unités journald spécifiques à inclure.
exclude_pathsNonSi type est défini sur file, et si path contient un caractère wildcard, permet de définir les fichiers qui doivent être exclus de la collecte de logs. Disponible depuis la version 6.18 de l’Agent.
exclude_unitsNonSi type est défini sur journald, il s’agit de la liste des unités journald spécifiques à exclure.
sourcecategoryNonL’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_positionNonRéférez-vous à la section relative à la position de départ pour en savoir plus.
encodingNonSi type est défini sur file, ce paramètre permet de définir le format d’encodage que l’Agent doit utiliser pour lire le fichier. Définissez sa valeur sur utf-16-le pour UTF-16 Little Endian et sur utf-16-be pour UTF-16 Big Endian, ou sur shift-jis pour Shift JIS. Si vous définissez une autre valeur, l’Agent lit le fichier au format UTF-8. Les valeurs utf-16-le et utf-16be sont disponibles depuis les versions v6.23/v7.23 de l’Agent, et la valeur shift-jis est disponible depuis les versions v6.34/v7.34 de l’Agent.
tagsNonLa liste des tags à ajouter à chaque log recueilli (en savoir plus sur le tagging).

Position de départ

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

Compatibilité :

  • File : Agent version 6.19/7.19 ou ultérieur
  • Journald : Agent version 6.38/7.38 ou ultérieur

Si type est file :

  • Définissez la position à laquelle lʼAgent doit commencer à lire le fichier.
  • Les valeurs valables sont beginning, end, forceBeginning et forceEnd (valeur par défaut : end).
  • La position beginning ne prend pas en charge les chemins d’accès contenant des caractères génériques.

Si type est journald :

  • Définissez la position à laquelle lʼAgent doit commencer à lire le journal.
  • Les valeurs valables sont beginning, end, forceBeginning et forceEnd (valeur par défaut : end).

Priorité

Pour les types de tailer file et journald, si une position end ou beginning est spécifiée, mais qu’un décalage est stocké, ce dernier est prioritaire. L’utilisation de forceBeginning ou de forceEnd oblige lʼAgent à utiliser la valeur spécifiée, même si un décalage est stocké.

Pour aller plus loin