Collecte de logs et intégrations
Rapport de recherche Datadog : Bilan sur l'adoption de l'informatique sans serveur Rapport : Bilan sur l'adoption de l'informatique sans serveur

Collecte de logs et intégrations

Suivez les instructions d’installation de l’Agent Datadog pour commencer à transmettre des logs avec vos métriques et vos traces. L’Agent peut suivre des fichiers de log ou effectuer 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 multiligne. Enfin, choisissez le langage de votre application ci-dessous afin d’obtenir les meilleures pratiques en matière de 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 possèdent une signification particulière 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 de 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 :


Forwarder 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.

L’endpoint public est http-intake.logs.datadoghq.com. La clé d’API doit être ajoutée dans le chemin ou en tant qu’étiquette. Exemple :

curl -X POST https://http-intake.logs.datadoghq.com/v1/input \
     -H "Content-Type: text/plain" \
     -H "DD-API-KEY: <CLÉ_API>" \
     -d 'hello world'

Pour obtenir davantage d’exemples au format JSON, avec plusieurs logs par requête ou avec des paramètres de requête, consultez la documentation relative à l’API HTTP de log Datadog.

L’endpoint public est http-intake.logs.datadoghq.eu. La clé d’API doit être ajoutée dans le chemin ou en tant qu’étiquette. Exemple :

curl -X POST https://http-intake.logs.datadoghq.eu/v1/input \
     -H "Content-Type: text/plain" \
     -H "DD-API-KEY: <CLÉ_API>" \
     -d 'hello world'

Pour obtenir davantage d’exemples au format JSON, avec plusieurs logs par requête ou avec des paramètres de requête, consultez la documentation relative à l’API HTTP de log Datadog.

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"}

Endpoints de logs Datadog

Datadog fournit des endpoints de log 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 au site américain de 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 JSON 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.

Les endpoints suivants peuvent être utilisés pour l’envoi de logs au site européen de Datadog :

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 JSON 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.

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.
statusCet attribut indique le niveau ou la sévérité d’un log. Il permet de définir des patterns. Il s’affiche de façon distincte dans l’interface utilisateur des 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.

Tagging de service unifié

Pour la collecte de logs, Datadog vous conseille de configurer le tagging de service unifié afin de lier les données de télémétrie Datadog entre elles via trois tags standard : env, service et version. Reportez-vous à la documentation relative au tagging de service unifié pour en effectuer la configuration.

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.

Limites appliquées aux événements de log ingérés

  • Pour des performances optimales, Datadog vous conseille de limiter la taille d’un événement de log à 25 000 octets. Lorsque l’Agent Datadog est utilisé, les événements de log de plus de 256 Ko sont divisés en plusieurs entrées. Si vous utilisez directement l’API TCP ou HTTP de Datadog, la taille maximale d’un événement de log est de 1 Mo.
  • Les événements de log peuvent être envoyés jusqu’à 18 h avant ou 2 h après la réalisation de l’événement.
  • Les événements de log convertis au format JSON doivent contenir moins de 256 attributs. Les clés de chacun de ces attributs doit être inférieure à 50 caractères, être imbriquée dans moins de 10 niveaux successifs, et leur valeur respective doit être inférieure à 1 024 caractères si elle est présentée en tant que facette.
  • Un événement de log ne doit pas avoir plus de 100 tags, et chaque tag ne doit pas dépasser 256 caractères pour un maximum de 10 millions de tags uniques par jour.

Les événements de log qui ne respectent pas ces limitations sont susceptibles d’être modifiés ou tronqués par le système. Ils peuvent aussi ne pas être indexés s’ils sont envoyés en dehors de l’intervalle de temps spécifié. Toutefois, Datadog s’efforce de préserver autant de données utilisateur que possible.

Pour aller plus loin

*Logging without Limits est une marque déposée de Datadog, Inc.