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, 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, certains attributs sont réservés et se comportent de façon spécifique dans Datadog. Consultez la section Attributs réservés pour en savoir plus.

Collecte de logs depuis une 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 des flux stdout/stderr du conteneur sans utiliser de pilote de log. Lorsque le check Docker de l’Agent est activé, les métadonnées du conteneur et de l’orchestrateur 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 via un DaemonSet.

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


Collecte de logs depuis un environnement sans serveur

Datadog peut recueillir des logs depuis AWS Lambda. Pour activer cette fonctionnalité, consultez la documentation sur l’intégration AWS Lambda.

Collecte de logs depuis un fournisseur 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é(e) capable 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 vos logs :

L’endpoint TCP sécurisé est intake.logs.datadoghq.com:10516 (utilisez le port 10514 pour les connexions non sécurisées).

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

<CLÉ_API_DATADOG> <CHARGEUTILE>

Remarque : <CHARGEUTILE> peut être au format brut, Syslog ou JSON.

Testez votre charge utile manuellement avec telnet. Exemple de <CHARGEUTILE> au format brut :

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

Vous obtenez alors le résultat suivant sur votre page Live Tail :

Si votre <CHARGEUTILE> est au format JSON, Datadog se charge de parser automatiquement ses attributs :

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 (utilisez le port 1883 pour les connexions non sécurisées).

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

<CLÉ_API_DATADOG> <CHARGEUTILE>

Remarque : <CHARGEUTILE> peut être au format brut, Syslog ou JSON.

Testez votre charge utile manuellement avec telnet. Exemple de <CHARGEUTILE> au format brut :

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

Vous obtenez alors le résultat suivant sur votre page Live Tail :

Si votre <CHARGEUTILE> est au format JSON, Datadog se charge de parser automatiquement ses attributs :

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 HTTPS vers le site européen ou américain de Datadog, consultez la documentation relative à l’API HTTP de log Datadog.

Endpoints de logs Datadog

Datadog fournit des endpoints de logs pour les connexions avec chiffrement SSL et les connexions non chiffrées. Utilisez l’endpoint chiffré si vous le pouvez. L’Agent Datadog utilise l’endpoint chiffré pour envoyer les logs à Datadog (pour en savoir plus, consultez la documentation sur la sécurité de Datadog).

Les endpoints suivants peuvent être utilisés pour l’envoi de logs à Datadog :

Endpoints pour connexions avec chiffrement SSLPortDescription
agent-intake.logs.datadoghq.com10516Utilisé par l’Agent pour envoyer des logs au format protobuf via une connexion TCP avec chiffrement SSL.
agent-http-intake.logs.datadoghq.com443Utilisé par l’Agent pour envoyer des logs au format protobuf via HTTPS. Consultez la section Envoyer des logs via HTTP.
http-intake.logs.datadoghq.com443Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la section Envoyer des logs via HTTP.
intake.logs.datadoghq.com10516Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL.
lambda-intake.logs.datadoghq.com10516Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL.
lambda-http-intake.logs.datadoghq.com443Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS.
functions-intake.logs.datadoghq.com10516Utilisé par les fonctions Azure pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL. Remarque : cet endpoint peut servir pour d’autres fournisseurs de cloud.
Endpoint pour connexions non chiffréesPortDescription
intake.logs.datadoghq.com10514Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP non chiffrée.
Endpoints pour connexions avec chiffrement SSLPortDescription
agent-intake.logs.datadoghq.eu443Utilisé par l’Agent pour envoyer des logs au format protobuf via une connexion TCP avec chiffrement SSL.
agent-http-intake.logs.datadoghq.eu443Utilisé par l’Agent pour envoyer des logs au format protobuf via HTTPS. Consultez la section Envoyer des logs via HTTP.
http-intake.logs.datadoghq.eu443Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la section Envoyer des logs via HTTP.
tcp-intake.logs.datadoghq.eu443Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL.
lambda-intake.logs.datadoghq.eu443Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL.
lambda-http-intake.logs.datadoghq.eu443Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS.
functions-intake.logs.datadoghq.eu443Utilisé par les fonctions Azure pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL. Remarque : cet endpoint peut servir pour d’autres fournisseurs de cloud.
Endpoint pour connexions non chiffréesPortDescription
tcp-intake.logs.datadoghq.eu1883Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP non chiffrée.

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

Attributs réservés

Voici quelques attributs clés auxquels vous devez prêter attention lors de la configuration de votre projet :

AttributDescription
hostLe nom du host d’origine, tel que défini dans les métriques. Les tags de host correspondants sont automatiquement récupérés à partir du host associé dans Datadog, et sont ensuite appliqués à 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.
statusIndique le niveau ou la sévérité d’un log. Cet attribut permet de définir des patterns. Il s’affiche de façon distincte dans l’interface utilisateur pour les logs Datadog.
serviceLe nom de l’application ou du service qui génère les événements de log. Il est utilisé pour passer des logs à l’APM. Assurez-vous donc 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 afin d’extraire automatiquement error.message et error.kind.

Envoyer vos logs d’application au format JSON

Pour les frameworks d’intégration, Datadog propose des instructions relatives à l’enregistrement de logs au format JSON dans un fichier. L’enregistrement au format JSON facilite la gestion des logs d’application multiligne, et les logs sont automatiquement parsés par Datadog.

Avantages de la collecte de logs au format JSON

Les logs au format JSON sont automatiquement parsés par Datadog. Si vous pouvez choisir le format de log envoyé à Datadog, nous vous conseillons donc d’opter pour ce format : de cette façon, vous n’aurez pas besoin de créer de règles de parsing personnalisées.

Pour aller plus loin