Collecte de logs et intégrations
Présentation
Choisissez une option de configuration ci-dessous pour commencer à ingérer vos logs. Si vous utilisez déjà un daemon log shipper, consultez la documentation dédiée pour Rsyslog, Syslog-ng, NXlog, FluentD ou Logstash.
Consultez la liste des endpoints de collecte de logs Datadog 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 sur les attributs réservés pour en savoir plus.
Implémentation
- Installez l’Agent Datadog.
- Pour activer la collecte de logs, remplacez
logs_enabled: false
par logs_enabled: true
dans le fichier de configuration principal de votre Agent (datadog.yaml
). Consultez la section Collecte de logs de l’Agent de host pour obtenir plus de détails et d’exemples. - Suivez les instructions d’installation correspondant au langage de votre application pour configurer un logger et commencer à générer des logs :
Choisissez un fournisseur de conteneurs ou d’orchestrateurs et suivez les instructions relatives à la collecte de logs :
Remarques :
Utilisez le Forwarder Datadog, une fonction AWS Lambda qui transmet des logs à Datadog depuis votre environnement. Pour activer la collecte de logs dans votre environnement AWS sans serveur, consultez la section Forwarder Datadog.
Sélectionnez votre fournisseur de Cloud ci-dessous pour savoir comment recueillir automatiquement vos logs et les transférer à Datadog :
Les intégrations Datadog et la collecte de logs sont liées. Vous pouvez utiliser un fichier de configuration d’intégration par défaut pour activer les processeurs, le parsing et les facettes dans Datadog. Pour commencer à recueillir des logs avec une intégration, procédez comme suit :
- Sélectionnez une intégration depuis la page Integrations et suivez les instructions de configuration.
- Suivez les instructions de l’intégration concernant la collecte de logs. Cette section décrit comment supprimer la mise en commentaire de la section logs du fichier
conf.yaml
de l’intégration en question et comment la configurer pour votre environnement.
Options de configuration supplémentaires
Endpoints de journalisation
Datadog fournit des endpoints de journalisation pour les connexions avec chiffrement SSL et les connexions non chiffrées. Utilisez l’endpoint chiffré tant que vous le pouvez. L’Agent Datadog utilise l’endpoint chiffré pour envoyer des logs à Datadog. Pour en savoir plus, consultez la documentation sur la sécurité de Datadog.
Endpoints pris en charge
Utilisez le menu déroulant situé à droite de la page pour sélectionner votre site Datadog et afficher les endpoints qu’il prend en charge.
Site | Type | Endpoint | Port | Description |
---|
US | HTTPS | http-intake.logs.datadoghq.com | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la documentation relative à l’API Logs HTTP. |
US | HTTPS | agent-http-intake-pci.logs.datadoghq.com | 443 | Utilisé par l’Agent pour envoyer des logs via HTTPS à une organisation pour laquelle la conformité PCI DSS est activée. Consultez la section Conformité PCI DSS pour Log Management pour en savoir plus. |
US | HTTPS | agent-http-intake.logs.datadoghq.com | 443 | Utilisé par l’Agent pour envoyer des logs au format JSON via HTTPS. Consultez la section Collecte de logs de l’Agent de host. |
US | HTTPS | lambda-http-intake.logs.datadoghq.com | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. |
US | HTTPS | logs.
| 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. |
US | TCP | agent-intake.logs.datadoghq.com | 10514 | Utilisé par l’Agent pour envoyer les logs sans TLS. |
US | TCP et TLS | agent-intake.logs.datadoghq.com | 10516 | Utilisé par l’Agent pour envoyer les logs via TLS. |
US | TCP et TLS | intake.logs.datadoghq.com | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL. |
US | TCP et TLS | functions-intake.logs.datadoghq.com | 443 | Utilisé 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. |
US | TCP et TLS | lambda-intake.logs.datadoghq.com | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL. |
Site | Type | Endpoint | Port | Description |
---|
Union européenne | HTTPS | http-intake.logs.datadoghq.eu | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la documentation relative à l’API Logs HTTP. |
Union européenne | HTTPS | agent-http-intake.logs.datadoghq.eu | 443 | Utilisé par l’Agent pour envoyer des logs au format JSON via HTTPS. Consultez la section Collecte de logs de l’Agent de host. |
Union européenne | HTTPS | lambda-http-intake.logs.datadoghq.eu | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. |
Union européenne | HTTPS | logs.
| 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. |
Union européenne | TCP et TLS | agent-intake.logs.datadoghq.eu | 443 | Utilisé par l’Agent pour envoyer des logs au format protobuf via une connexion TCP avec chiffrement SSL. |
Union européenne | TCP et TLS | functions-intake.logs.datadoghq.eu | 443 | Utilisé 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. |
Union européenne | TCP et TLS | lambda-intake.logs.datadoghq.eu | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via une connexion TCP avec chiffrement SSL. |
Site | Type | Endpoint | Port | Description |
---|
US3 | HTTPS | http-intake.logs.us3.datadoghq.com | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la documentation relative à l’API Logs HTTP. |
US3 | HTTPS | lambda-http-intake.logs.us3.datadoghq.com | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. |
US3 | HTTPS | agent-http-intake.logs.us3.datadoghq.com | 443 | Utilisé par l’Agent pour envoyer des logs au format JSON via HTTPS. Consultez la section Collecte de logs de l’Agent de host. |
US3 | HTTPS | logs.
| 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. |
Site | Type | Endpoint | Port | Description |
---|
US5 | HTTPS | http-intake.logs.us5.datadoghq.com | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la documentation relative à l’API Logs HTTP. |
US5 | HTTPS | lambda-http-intake.logs.us5.datadoghq.com | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. |
US5 | HTTPS | agent-http-intake.logs.us5.datadoghq.com | 443 | Utilisé par l’Agent pour envoyer des logs au format JSON via HTTPS. Consultez la section Collecte de logs de l’Agent de host. |
US5 | HTTPS | logs.
| 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. |
Site | Type | Endpoint | Port | Description |
---|
US5 | HTTPS | http-intake.logs.ap1.datadoghq.com | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la documentation relative à l’API Logs HTTP. |
US5 | HTTPS | lambda-http-intake.logs.ap1.datadoghq.com | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. |
US5 | HTTPS | agent-http-intake.logs.ap1.datadoghq.com | 443 | Utilisé par l’Agent pour envoyer des logs au format JSON via HTTPS. Consultez la section Collecte de logs de l’Agent de host. |
US5 | HTTPS | logs.
| 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. |
Site | Type | Endpoint | Port | Description |
---|
US1-FED | HTTPS | http-intake.logs.ddog-gov.com | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la documentation relative à l’API Logs HTTP. |
US1-FED | HTTPS | lambda-http-intake.logs.ddog-gov.datadoghq.com | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. |
US1-FED | HTTPS | agent-http-intake.logs.ddog-gov.datadoghq.com | 443 | Utilisé par l’Agent pour envoyer des logs au format JSON via HTTPS. Consultez la section Collecte de logs de l’Agent de host. |
US1-FED | HTTPS | logs.
| 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. |
Transmission personnalisée de logs
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.
Vous pouvez tester manuellement votre connexion avec OpenSSL, GnuTLS ou un autre client SSL/TLS. Pour GnuTLS, exécutez la commande suivante :
gnutls-cli intake.logs.datadoghq.com:10516
Pour OpenSSL, exécutez la commande suivante :
openssl s_client -connect intake.logs.datadoghq.com:10516
Vous devez ajouter un préfixe correspondant à votre [clé d’API Datadog][1] à l’entrée de log, puis ajouter une charge utile.
<CLÉ_API_DATADOG> Log sent directly using TLS
Votre charge utile, Log sent directly using TLS
dans cet exemple, peut être au format brut, Syslog ou JSON. Si votre charge utile est au format JSON, Datadog parse automatiquement ses attributs.
<CLÉ_API_DATADOG> {"message":"json formatted log", "ddtags":"env:my-env,user:my-user", "ddsource":"my-integration", "hostname":"my-hostname", "service":"my-service"}
[1]: /fr/account_management/api-app-keys/#api-keys
Vous pouvez tester manuellement votre connexion avec OpenSSL, GnuTLS ou un autre client SSL/TLS. Pour GnuTLS, exécutez la commande suivante :
gnutls-cli tcp-intake.logs.datadoghq.eu:443
Pour OpenSSL, exécutez la commande suivante :
openssl s_client -connect tcp-intake.logs.datadoghq.eu:443
Vous devez ajouter un préfixe correspondant à votre clé d’API Datadog à l’entrée de log, puis ajouter une charge utile.
<CLÉ_API_DATADOG> Log sent directly using TLS
Votre charge utile, Log sent directly using TLS
dans cet exemple, peut être au format brut, Syslog ou JSON. Si votre charge utile est au format JSON, Datadog parse automatiquement ses attributs.
<CLÉ_API_DATADOG> {"message":"json formatted log", "ddtags":"env:my-env,user:my-user", "ddsource":"my-integration", "hostname":"my-hostname", "service":"my-service"}
Il n’est pas recommandé d’utiliser l’endpoint TCP pour ce site. Contactez l’assistance pour en savoir plus.
L’endpoint TCP n’est pas pris en charge par ce site.
Remarques :
- L’API HTTPS prend en charge les logs d’une taille maximale de 1 Mo. Toutefois, pour obtenir des performances optimales, il est recommandé que chaque log ne dépasse pas 25 Ko. Si vous utilisez l’Agent Datadog pour générer des logs, il est configuré pour créer un nouveau log dès que le précédent atteint 256 Ko (256 000 octets).
- Un événement de log ne doit pas comporter 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 convertis au format JSON doivent contenir moins de 256 attributs. Les clés de chacun de ces attributs doivent être inférieures à 50 caractères, être imbriquées 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.
- Les événements de log peuvent être envoyés avec un timestamp jusqu’à 18 h dans le passé.
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.
Les attributs déterminent les facettes des logs qui servent à filtrer le Log Explorer et à y effectuer des recherches. Pour obtenir la liste des attributs standard et réservés et pour en savoir plus sur la mise en place d’une convention de nommage avec les attributs et les alias de log, consultez la documentation relative aux attributs et aux alias.
Attributs pour les stack traces
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 stack trace.
Pour activer ces fonctionnalités, utilisez les noms d’attribut suivants :
Attribut | Description |
---|
logger.name | Le nom du logger |
logger.thread_name | Le nom du thread actuel |
error.stack | La stack trace réelle |
error.message | Le message d’erreur contenu dans la stack trace |
error.kind | Le type d’erreur (par exemple, « Exception » ou « OSError ») |
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 parsent les stack traces ou tracebacks afin d’extraire automatiquement error.message
et error.kind
.
Pour en savoir plus, consultez la documentation relative aux attributs de code source.
Étapes suivantes
Une fois les logs recueillis et ingérés, ils sont disponibles dans le Log Explorer. Depuis cette vue, vous pouvez rechercher, enrichir et visualiser des alertes sur vos logs. Référez-vous à la documentation relative au Log Explorer pour commencer à analyser vos données de log, ou consultez les sections supplémentaires ci-dessous sur la gestion des logs.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
*Logging without Limits est une marque déposée de Datadog, Inc.