Nouvelles annonces sur les technologies sans serveur et réseau ainsi que sur le RUM (Real-User Monitoring) dévoilées à la conférence Dash ! Nouvelles annonces dévoilées à la conférence Dash !

Collecte de logs de l'Agent

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.

La collecte de logs est désactivée par défaut dans l’Agent Datadog. Vous devez l’activer dans le fichier de configuration principal de l’Agent (datadog.yaml) :

logs_enabled: true

Par défaut, l’Agent Datadog envoie ses logs à Datadog via le protocole TCP chiffré par TLS. Cela nécessite une communication sortante sur le port 10516.

Voir ci-dessous pour envoyer les logs via HTTPS.

Remarque : si vous utilisez Kubernetes, assurez-vous d’activer la collecte de logs dans votre configuration DaemonSet. Si vous utilisez Docker, activez la collecte de logs pour l’Agent conteneurisé.

Activer la collecte de logs à partir d’intégrations

Pour recueillir des logs pour une intégration donnée, supprimez la mise en commentaire de la section logs du fichier conf.yaml de cette intégration et configurez-la pour votre environnement.

Consultez la liste des intégrations prises en charge qui intègrent une configuration de log par défaut.

Si une intégration ne prend pas en charge les logs par défaut, utilisez la collecte de logs personnalisée.

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. Créez un dossier <SOURCE_LOGS_PERSONNALISÉE>.d/ dans le répertoire conf.d/ à la racine du répertoire de configuration de votre Agent.
  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 prendre en compte cette nouvelle configuration.
  5. Lancez la sous-commande status de l’Agent et cherchez <SOURCE_LOGS_PERSONNALISÉE> dans la section Checks.

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>

Remarque : si vous lisez les logs d’un fichier avec l’Agent v6 sous Windows, vérifiez que ces fichiers sont encodés au format UTF8.

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_PERSONNALISEE>

Si vous utilisez Serilog, vous disposez de l’option Serilog.Sinks.Network pour une connexion via UDP.

Remarque : 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.

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 en savoir plus sur la configuration des environnements conteneurisés et du 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 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 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ètreObligatoireDescription
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.
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, nous vous conseillons d’utiliser la valeur de l’espace de nommage des métriques custom recueillies, par 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_unitsNonSi type est défini sur journald, il s’agit de la liste des unités journald spécifiques à exclure.
sourcecategoryNonUn attribut à valeur multiple utilisé pour préciser l’attribut source, par exemple : source:mongodb, sourcecategory:db_slow_logs.
tagsNonLa liste des tags à ajouter à chaque log recueilli (en savoir plus sur le tagging).

Envoyer des logs via HTTPS

Pour envoyer des logs via HTTPS avec l’Agent Datadog > 6.14, ajoutez la ligne suivante dans le fichier de configuration principal de l’Agent (datadog.yaml) :

logs_config:
  use_http: true

Vous pouvez également définir la variable d’environnement DD_LOGS_CONFIG_USE_HTTP sur true. Redémarrez ensuite l’Agent pour activer l’envoi des logs via HTTPS vers agent-http-intake.logs.datadoghq.com (site américain) ou agent-http-intake.logs.datadoghq.eu (site européen) sur le port 443.

L’Agent envoie les logs par lots en appliquant les limites suivantes :

  • Taille maximale du contenu par charge utile : 1 Mo
  • Taille maximale d’un log : 256 Ko
  • Taille maximale d’un tableau en cas d’envoi de plusieurs logs dans un tableau : 200 entrées de log

L’Agent patiente jusqu’à 5 secondes afin de satisfaire l’une de ces limites (la taille du contenu ou le nombre de logs). Par conséquent, dans le pire des cas (lorsque le nombre de logs générés est très faible), le passage au HTTPS entraîne une latence accrue de 5 secondes par rapport au TCP, qui envoie l’ensemble des logs en temps réel.

Lorsque les logs sont envoyés via HTTPS et doivent transiter par un proxy, utilisez les mêmes paramètres de proxy que ceux utilisés pour l’envoi d’autres types de données.

Pour aller plus loin