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 et intégrations

Suivez les instructions d’installation de l’Agent Datadog pour commencer à transférer des logs avec vos métriques et vos traces. L’Agent peut suivre des fichiers de log ou effecuter une écoute afin d’identifier des logs envoyés via UDP/TCP. Vous pouvez également le configurer de façon à exclure des logs, nettoyer les données sensibles ou agréger des logs multilignes. Enfin, choisissez le langage de votre application ci-dessous afin d’obtenir les meilleures pratiques dédiées à la journalisation. Si vous utilisez déjà un daemon log-shipper, consultez la documentation relative à Rsyslog, Syslog-ng, NXlog, FluentD, et Logstash.

La gestion de logs Datadog contient également un ensemble de solutions intégré pour recueillir vos logs et les envoyer vers Datadog :

Les intégrations Datadog et la collecte de logs sont liées. Utilisez un fichier de configuration d’intégration par défaut pour activer son processing dédié, son parsing et ses facettes dans Datadog.

Vous trouverez en bas de cette page la liste des endpoints de collecte de logs Datadog disponibles si vous souhaitez envoyer vos logs directement à Datadog.

Remarque : lorsque vous envoyez des logs au format JSON à Datadog, un ensemble d’attributs est spécifiquement réservé à Datadog. Consultez la section Attributs réservés pour en savoir plus.

Collecte de logs depuis l’application

Après avoir activé la collecte de logs, configurez le langage de votre application pour générer des logs :


Collecte de logs depuis un conteneur

L’Agent Datadog peut recueillir des logs directement à partir du conteneur stdout/stderr sans utiliser de pilote de log. Lorsque le check du Docker de l’Agent est activé, les métadonnées du conteneur et du gestionnaire d’orchestration sont automatiquement ajoutées à vos logs en tant que tags. Il est possible de recueillir les logs de tous vos conteneurs ou d’un sous-ensemble filtré selon une image de conteneur, une étiquette ou un nom. Autodiscovery peut également être utilisé pour configurer la collecte de logs directement dans les étiquettes de conteneur. Dans les environnements Kubernetes, vous pouvez également tirer parti de l’installation de Daemonset.

Choisissez votre environnement ci-dessous pour obtenir des instructions sur la collecte de logs :


Collecte de logs depuis des fournisseurs de Cloud

Sélectionnez votre fournisseur de Cloud ci-dessous pour savoir comment recueillir automatiquement vos logs et les transférer à Datadog :


Redirecteur de logs personnalisé

Vous pouvez utiliser un processus ou une bibliothèque de journalisation personnalisés capables de transmettre des logs via TCP ou HTTP pour gérer vos logs Datadog. Choisissez ci-dessous le site Datadog vers lequel vous souhaitez transférer des logs :

L’endpoint TCP sécurisé est intake.logs.datadoghq.com:10516 (ou avec le port 10514 pour les connexions instables).

Vous devez ajouter un préfixe correspondant à votre clé d’API Datadog à l’entrée de log. Par exemple :

<CLÉ_API_DATADOG> Ceci est mon log

Testez-la manuellement avec telnet :

telnet intake.logs.datadoghq.com 10514
<CLÉ_API_DATADOG> Log envoyé directement via TCP

Cela génère le résultat suivant dans votre page Live Tail :

Datadog analyse automatiquement les attributs des messages au format JSON.

telnet intake.logs.datadoghq.com 10514 
<CLÉ_API_DATADOG> {"message":"log au format json", "ddtags":"env:mon-env,user:mon-utilisateur", "ddsource":"mon-intégration", "hostname":"mon-hostname", "service":"mon-service"}

L’endpoint TCP sécurisé est tcp-intake.logs.datadoghq.eu:443 (ou avec le port 1883 pour les connexions instables).

Vous devez ajouter un préfixe correspondant à votre clé d’API Datadog à l’entrée de log. Par exemple :

<CLÉ_API_DATADOG> Ceci est mon log

Testez-la manuellement avec telnet :

telnet tcp-intake.logs.datadoghq.eu 1883
<CLÉ_API_DATADOG> Log envoyé directement via TCP

Cela génère le résultat suivant dans votre page Live Tail :

Datadog analyse automatiquement les attributs des messages au format JSON.

telnet tcp-intake.logs.datadoghq.eu 1883
<CLÉ_API_DATADOG> {"message":"log au format json", "ddtags":"env:mon-env,user:mon-utilisateur", "ddsource":"mon-intégration", "hostname":"mon-hostname", "service":"mon-service"}

Pour envoyer des logs via HTTP pour le site EU ou US, consultez la documentation relative à l’API HTTP de log Datadog.

Endpoints des logs Datadog

Datadog fournit des endpoints de logs pour les connexions avec un chiffrement SSL et les connexions non chiffrées. Nous vous conseillons d’utiliser le endpoint chiffré dès que possible. L’Agent Datadog utilise le endpoint chiffré pour envoyer les logs à Datadog (pour en savoir plus, consultez la documentation sur la sécurité de Datadog).

Endpoints pour l’envoi de logs à Datadog :

Endpoints pour les connexions avec un chiffrement SSLPortDescription
agent-intake.logs.datadoghq.com10516Utilisé par l’Agent pour envoyer des logs au format protobuf avec une connexion TCP chiffrée en SSL.
intake.logs.datadoghq.com10516Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP chiffrée en SSL.
lambda-intake.logs.datadoghq.com10516Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP chiffrée en SSL.
lambda-http-intake.logs.datadoghq.com443Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON avec HTTPS.
functions-intake.logs.datadoghq.com10516Utilisé par les fonctions Azure pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP chiffrée en SSL. Remarque : ce endpoint peut être utile avec les autres fournisseurs de Cloud.
Endpoint pour les connexions non chiffréesPortDescription
intake.logs.datadoghq.com10514Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP non chiffrée.
Endpoints pour les connexions avec un chiffrement SSLPortDescription
agent-intake.logs.datadoghq.eu443Utilisé par l’Agent pour envoyer des logs au format protobuf avec une connexion TCP chiffrée en SSL.
tcp-intake.logs.datadoghq.eu443Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP chiffrée en SSL.
lambda-intake.logs.datadoghq.eu443Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP chiffrée en SSL.
lambda-http-intake.logs.datadoghq.eu443Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON avec HTTPS.
functions-intake.logs.datadoghq.eu443Utilisé par les fonctions Azure pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP chiffrée en SSL. Remarque : ce endpoint peut être utile avec les autres fournisseurs de Cloud.
Endpoint pour les connexions non chiffréesPortDescription
tcp-intake.logs.datadoghq.eu1883Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON avec une connexion TCP non chiffrée.

Pour envoyer des logs via HTTP, consultez la documentation relative à l’API HTTP de log Datadog.

Attributs réservés

Voici quelques attributs clés auxquels vous devriez faire attention lors de la configuration de votre projet :

AttributDescription
hostLe nom du host d’origine, tel que défini dans les métriques. Nous récupérons automatiquement les tags de host correspondants à partir du host associé dans Datadog. Nous les appliquons ensuite à vos logs. L’Agent définit automatiquement cette valeur.
sourceCet attribut correspond au nom de l’intégration, à savoir la technologie à l’origine du log. Lorsqu’il a pour valeur le nom d’une intégration, Datadog installe automatiquement les parsers et les facettes correspondants. Par exemple : nginx, postgresql, etc.
statusCet attribut correspond au niveau ou à la sévérité d’un log. Il permet de définir des patterns. L’interface utilisateur pour les logs Datadog comporte une disposition distincte pour cet attribut.
serviceLe nom de l’application ou du service génère les événements de log. Il est utilisé pour passer des logs à l’APM, alors assurez-vous de définir la même valeur lorsque vous utilisez les deux produits.
messagePar défaut, Datadog ingère la valeur de l’attribut message comme corps de l’entrée du log. Cette valeur est alors mise en évidence et affichée dans le flux de logs, où elle est indexée pour d’éventuelles recherches plein texte.

Vos logs sont recueillis et rassemblés dans la vue Log Explorer. Vous pouvez également rechercher et enrichir vos logs, et recevoir des alertes les concernant.

Comment tirer le meilleur parti de vos logs d’application

Lorsque vous enregistrez des traces de pile, des attributs spécifiques disposent d’un affichage de l’interface utilisateur dédié au sein de votre application Datadog, comme le nom du logger, le thread actuel, le type d’erreur et la trace de pile.

Pour activer ces fonctionnalités, utilisez les noms d’attribut suivants :

AttributDescription
logger.nameLe nom du logger
logger.thread_nameLe nom du thread actuel
error.stackLa trace de pile actuelle
error.messageLe message d’erreur contenu dans la trace de pile
error.kindLe type d’erreur (comme « Exception », « OSError », etc.)

Remarque : par défaut, les pipelines des intégrations tentent de remapper les paramètres par défaut de la bibliothèque de création de logs sur ces attributs spécifiques et analysent les traces ou tracebacks de pile pour extraire automatiquement error.message et error.kind.

Envoyer vos logs d’application au format JSON

Pour les frameworks d’intégration, Datadog apporte des recommandations sur l’enregistrement de logs au format JSON dans un fichier. L’enregistrement au format JSON permet de gérer les logs d’application multilignes et est automatiquement analysé par Datadog.

Les avantages de la collecte de logs au format JSON

Datadog analyse automatiquement les logs au format JSON. C’est pour cela que si vous pouvez choisir le format de log envoyé à Datadog, nous vous recommandons d’opter pour le format JSON afin d’éviter de créer des règles de parsing personnalisées.

Pour aller plus loin