Utilisez la fonction Datadog Log Management, également appelée logs, pour recueillir les logs issus de plusieurs sources de journalisation, comme votre serveur, votre conteneur, votre environnement Cloud, votre application ou vos processeurs et forwarders de logs existants. Avec un système de journalisation conventionnel, vous devez choisir les logs à analyser et à conserver afin de limiter les coûts. La fonctionnalité Logging without Limits* de Datadog vous permet de recueillir, traiter, archiver, explorer et surveiller vos logs sans limites de journalisation.
Cette page vous montre comment débuter avec la solution Log Management dans Datadog. Si vous ne l’avez pas encore fait, créez un compte Datadog.
Configurer une source de journalisation
Avec la solution Log Management, vous pouvez analyser et explorer vos données dans le Log Explorer, associer vos traces à vos métriques pour mettre en corrélation des données importantes sur toute la plateforme Datadog, et utiliser les logs ingérés pour la solution Cloud SIEM de Datadog. Le cycle de vie d’un log dans Datadog commence lorsqu’il est ingéré à partir d’une source de journalisation.
Serveur
Plusieurs intégrations peuvent être utilisées pour transmettre les logs de votre serveur à Datadog. Ces intégrations utilisent un bloc de configuration des logs dans leur fichier conf.yaml, qui est disponible dans le dossier conf.d/ à la racine du répertoire de configuration de votre Agent, pour transmettre les logs à Datadog depuis votre serveur.
Pour commencer à recueillir des logs à partir d’un serveur :
Si vous ne l’avez pas déjà fait, installez l’Agent Datadog en fonction de votre plateforme.
Remarque : la collecte de logs nécessite l’Agent Datadog v6+.
La collecte de logs n’est pas activée par défaut dans l’Agent Datadog. Pour activer la collecte de logs, définissez logs_enabled sur true dans votre fichier datadog.yaml.
datadog.yaml
## @param logs_enabled - boolean - optional - default: false## @env DD_LOGS_ENABLED - boolean - optional - default: false## Enable Datadog Agent log collection by setting logs_enabled to true.logs_enabled:false## @param logs_config - custom object - optional## Enter specific configurations for your Log collection.## Uncomment this parameter and the one below to enable them.## See https://docs.datadoghq.com/agent/logs/logs_config:## @param container_collect_all - boolean - optional - default: false## @env DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL - boolean - optional - default: false## Enable container log collection for all the containers (see ac_exclude to filter out containers)container_collect_all:false## @param logs_dd_url - string - optional## @env DD_LOGS_CONFIG_LOGS_DD_URL - string - optional## Define the endpoint and port to hit when using a proxy for logs. The logs are forwarded in TCP## therefore the proxy must be able to handle TCP connections.logs_dd_url:<ENDPOINT>:<PORT>## @param logs_no_ssl - boolean - optional - default: false## @env DD_LOGS_CONFIG_LOGS_NO_SSL - optional - default: false## Disable the SSL encryption. This parameter should only be used when logs are## forwarded locally to a proxy. It is highly recommended to then handle the SSL encryption## on the proxy side.logs_no_ssl:false## @param processing_rules - list of custom objects - optional## @env DD_LOGS_CONFIG_PROCESSING_RULES - list of custom objects - optional## Global processing rules that are applied to all logs. The available rules are## "exclude_at_match", "include_at_match" and "mask_sequences". More information in Datadog documentation:## https://docs.datadoghq.com/agent/logs/advanced_log_collection/#global-processing-rulesprocessing_rules:- type:<RULE_TYPE>name:<RULE_NAME>pattern:<RULE_PATTERN>## @param force_use_http - boolean - optional - default: false## @env DD_LOGS_CONFIG_FORCE_USE_HTTP - boolean - optional - default: false## By default, the Agent sends logs in HTTPS batches to port 443 if HTTPS connectivity can## be established at Agent startup, and falls back to TCP otherwise. Set this parameter to `true` to## always send logs with HTTPS (recommended).## Warning: force_use_http means HTTP over TCP, not HTTP over HTTPS. Please use logs_no_ssl for HTTP over HTTPS.force_use_http:true## @param force_use_tcp - boolean - optional - default: false## @env DD_LOGS_CONFIG_FORCE_USE_TCP - boolean - optional - default: false## By default, logs are sent through HTTPS if possible, set this parameter## to `true` to always send logs via TCP. If `force_use_http` is set to `true`, this parameter## is ignored.force_use_tcp:true## @param use_compression - boolean - optional - default: true## @env DD_LOGS_CONFIG_USE_COMPRESSION - boolean - optional - default: true## This parameter is available when sending logs with HTTPS. If enabled, the Agent## compresses logs before sending them.use_compression:true## @param compression_level - integer - optional - default: 6## @env DD_LOGS_CONFIG_COMPRESSION_LEVEL - boolean - optional - default: false## The compression_level parameter accepts values from 0 (no compression)## to 9 (maximum compression but higher resource usage). Only takes effect if## `use_compression` is set to `true`.compression_level:6## @param batch_wait - integer - optional - default: 5## @env DD_LOGS_CONFIG_BATCH_WAIT - integer - optional - default: 5## The maximum time (in seconds) the Datadog Agent waits to fill each batch of logs before sending.batch_wait:5## @param open_files_limit - integer - optional - default: 500## @env DD_LOGS_CONFIG_OPEN_FILES_LIMIT - integer - optional - default: 500## The maximum number of files that can be tailed in parallel.## Note: the default for Mac OS is 200. The default for## all other systems is 500.open_files_limit:500## @param file_wildcard_selection_mode - string - optional - default: `by_name`## @env DD_LOGS_CONFIG_FILE_WILDCARD_SELECTION_MODE - string - optional - default: `by_name`## The strategy used to prioritize wildcard matches if they exceed the open file limit.#### Choices are `by_name` and `by_modification_time`.#### `by_name` means that each log source is considered and the matching files are ordered## in reverse name order. While there are less than `logs_config.open_files_limit` files## being tailed, this process repeats, collecting from each configured source.#### `by_modification_time` takes all log sources and first adds any log sources that## point to a specific file. Next, it finds matches for all wildcard sources.## This resulting list is ordered by which files have been most recently modified## and the top `logs_config.open_files_limit` most recently modified files are## chosen for tailing.#### WARNING: `by_modification_time` is less performant than `by_name` and will trigger## more disk I/O at the configured wildcard log paths.file_wildcard_selection_mode:by_name## @param max_message_size_bytes - integer - optional - default: 256000## @env DD_LOGS_CONFIG_MAX_MESSAGE_SIZE_BYTES - integer - optional - default : 256000## The maximum size of single log message in bytes. If maxMessageSizeBytes exceeds## the documented API limit of 1MB - any payloads larger than 1MB will be dropped by the intake.https://docs.datadoghq.com/api/latest/logs/max_message_size_bytes:256000## @param integrations_logs_files_max_size - integer - optional - default: 10## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_FILES_MAX_SIZE - integer - optional - default: 10## The max size in MB that an integration logs file is allowed to useintegrations_logs_files_max_size## @param integrations_logs_total_usage - integer - optional - default: 100## @env DD_LOGS_CONFIG_INTEGRATIONS_LOGS_TOTAL_USAGE - integer - optional - default: 100## The total combined usage all integrations logs files can useintegrations_logs_total_usage
Suivez les étapes d’activation de l’intégration ou les étapes de collecte de logs de fichiers personnalisés sur le site Datadog.
Remarque : si vous recueillez des logs à partir de fichiers personnalisés et avez besoin d’exemples pour les fichiers suivis, TCP/UDP, journald ou événements Windows, consultez la section Collecte de logs personnalisés.
Container
À partir de l’Agent Datadog v6, l’Agent peut recueillir des logs à partir de conteneurs. Chaque service de conteneurisation dispose d’instructions de configuration spécifiques en fonction de l’emplacement où l’Agent est déployé ou exécuté, ou encore de l’acheminement des logs.
Par exemple, pour Docker, l’Agent peut être installé de deux façons : sur votre host, où l’Agent est externe à l’environnement Docker, ou via le déploiement d’une version conteneurisée de l’Agent dans votre environnement Docker.
Kubernetes nécessite que l’Agent Datadog s’exécute dans votre cluster Kubernetes, et la collecte de logs peut être configurée en utilisant une spécification DaemonSet, un chart Helm ou avec l’Operator Datadog.
Vous pouvez transmettre à Datadog les logs provenant de divers fournisseurs cloud, comme AWS, Azure, et Google Cloud. Chaque fournisseur cloud dispose d’instructions de configuration différentes.
Par exemple, les logs du service AWS sont généralement stockés dans des compartiments S3 ou des groupes de logs CloudWatch. Vous pouvez vous abonner à ces logs et les transmettre à un flux Amazon Kinesis pour les transmettre à nouveau à une ou plusieurs destinations. Datadog est l’une des destinations par défaut pour les flux de diffusion Amazon Kinesis.
Datadog vous permet de recueillir des logs à partir de clients via des SDK ou bibliothèques. Par exemple, utilisez le SDK datadog-logs pour envoyer des logs à partir de clients JavaScript à Datadog.
Si vous utilisez des utilitaires ou services de journalisation existants, comme rsyslog, Fluentd ou Logstash, Datadog offre des plug-ins et options de transmission de logs.
Si vous ne voyez pas votre intégration, vous pouvez la saisir dans la zone other integrations afin de recevoir une notification lorsque l’intégration sera disponible.
Une fois qu’une source de journalisation est configurée, vos logs sont disponibles dans le Log Explorer. Cet explorateur vous permet de filtrer, d’agréger et de consulter vos logs.
Par exemple, si vous souhaitez analyser en détail les logs d’un service donné, filtrez vos logs en fonction de service. Vous pouvez ensuite les filtrer en fonction de status, comme ERROR, puis sélectionner Aggregate by Patterns pour voir la partie de votre service qui génère le plus d’erreurs.
Agrégez vos logs en fonction du paramètre Field de Source et passez à l’option de visualisation Top List pour voir vos services qui génèrent le plus de logs. Sélectionnez une source, comme error, et sélectionnez View Logs dans le menu déroulant. Le volet latéral affiche des logs en fonction des erreurs, ce qui vous permet d’identifier rapidement les hosts et services qui nécessitent votre attention.
Et ensuite ?
Une fois qu’une source de journalisation est configurée et que vos logs sont disponibles dans le Log Explorer, vous pouvez commencer à explorer d’autres aspects de la gestion des logs.
Configuration des logs
Définissez des attributs et alias afin d’unifier votre environnement de logs.
Étant donné que la fonctionnalité Logging without Limits* dissocie l’ingestion et l’indexation de logs, vous pouvez configurer vos logs de façon à choisir ceux que vous souhaitez indexer, conserver ou archiver.
