GUIDE TECHNIQUE · DATADOG
Activer la collecte des logs Datadog sur Linux
Activer la collecte des logs Datadog Agent sur Linux, configurer un fichier de test, réduire le risque d'ingestion de secrets et vérifier le résultat dans Log Explorer. L'exemple utilise un service fictif sans données de production.
01 · CADRAGE
Ce que vous allez mettre en place
Activer la collecte des logs Datadog Agent sur Linux, configurer un fichier de test, réduire le risque d'ingestion de secrets et vérifier le résultat dans Log Explorer. L'exemple utilise un service fictif sans données de production.
Pour qui : Administrateurs, équipes observabilité et exploitation
Datadog Agent Linux récent : configuration datadog.yaml et intégration custom_logs.d/conf.yaml ; confirmer les droits et l'option mask_sequences dans la version déployée.
Vérifiez la compatibilité avec votre environnement réel. Les versions ne sont jamais présumées identiques d’un tenant à l’autre.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Agent Datadog opérationnel avec logs disponibles sur le compte cible.
- Droits sur /etc/datadog-agent, fichier /var/log/mon-service/application.log de recette et compte de service Agent.
- Événements sans données nominatives réelles ; une valeur factice pour tester le masquage.
- Quota et indexation de logs Datadog vérifiés avant tout import massif.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
Illustration éditoriale validée ADN Consulting, distincte d’une capture de console.
Source : ADN Consulting04 · TUTORIEL
Procédure complète, étape par étape
Chaque étape explique l’action, sa raison, le contrôle attendu et les erreurs habituelles. Adaptez les exemples aux paramètres de votre propre environnement.
ÉTAPE 1 / 5
Vérifier l’Agent et le périmètre
La configuration de logs ne répare pas un Agent non connecté ni les permissions d'accès au fichier.
- Vérifier datadog-agent status et l'état de la connexion au site Datadog.
- Contrôler le fichier ciblé et ses droits de lecture par l'utilisateur Agent.
- Limiter la recette à un journal synthétique.
sudo datadog-agent status
sudo ls -l /var/log/mon-service/application.log
# Vérifier le compte de service et son accès effectif, pas seulement les permissions root.À vérifier : L'Agent est connecté et le journal fictif est accessible en lecture.
Point de vigilance ADN : Éviter de déplacer des logs clients dans le laboratoire.
ÉTAPE 2 / 5
Activer la collecte dans l’Agent
La collecte doit être explicitement activée au niveau global de l'Agent.
- Sauvegarder /etc/datadog-agent/datadog.yaml.
- Définir logs_enabled: true en conservant les autres paramètres du tenant.
- Vérifier qu'il n'existe pas de seconde entrée YAML contradictoire.
logs_enabled: true
# Extrait à placer dans /etc/datadog-agent/datadog.yaml, pas un fichier complet.À vérifier : La collecte des logs est activée dans la configuration sauvegardée.
Point de vigilance ADN : La configuration prend effet après rechargement/redémarrage du service.
ÉTAPE 3 / 5
Déclarer la source et son service
Le fichier de conf de l'intégration peut également masquer des séquences sensibles avant ingestion.
- Créer conf.d/custom_logs.d/conf.yaml avec un fichier de recette.
- Appliquer une règle mask_sequences à une clé fictive token, sans valeur de jeton réel.
- Adapter le pattern à la structure réelle et vérifier l'absence de données personnelles dans tous les autres champs.
logs:
- type: file
path: /var/log/mon-service/application.log
service: mon-service
source: java
log_processing_rules:
- type: mask_sequences
name: masquer_token_de_test
pattern: '(token=)[^[:space:]]+'
replace_placeholder: '1[MASQUÉ]'
# Valeur de recette: token=EXEMPLE123 (jamais un vrai secret)À vérifier : Le journal est déclaré avec service/source et une règle de masquage à valider sur données factices.
Point de vigilance ADN : Les règles de regex/placeholder doivent être validées avec l'Agent exact ; ne jamais considérer une regex unique comme une protection exhaustive.
ÉTAPE 4 / 5
Redémarrer puis consulter Log Explorer
Le redémarrage seul ne démontre pas l'ingestion ; vérifier la séquence dans le backend.
- Redémarrer l'Agent pendant la fenêtre de recette et contrôler datadog-agent status.
- Émettre un journal fictif token=EXEMPLE123, puis filtrer service:mon-service dans Log Explorer.
- Vérifier que la valeur factice est masquée dans l'événement ingéré.
sudo systemctl restart datadog-agent
sudo datadog-agent status
# Journal de TEST uniquement :
echo 'INFO test-token token=EXEMPLE123' | sudo tee -a /var/log/mon-service/application.log
# Dans Log Explorer : service:mon-serviceÀ vérifier : Un événement récent du service est visible et ne contient plus la valeur EXEMPLE123.
Point de vigilance ADN : Ne pas diffuser l'événement brut avec un vrai token, même pour une recette.
ÉTAPE 5 / 5
Contrôler la sécurité et l’ingestion
La validité opérationnelle inclut parsing, coûts et absence de divulgation.
- Vérifier les timestamps, le service/source, le volume par minute et l'index de destination.
- Chercher l'absence de valeurs factices non masquées et évaluer les autres risques (email, ID, header).
- Consigner le rollback : restauration des fichiers puis redémarrage Agent.
sudo datadog-agent status
# Dans Log Explorer : service:mon-service ; vérifier date, parsing et champs.À vérifier : L'ingestion est contrôlée ; ses limites de confidentialité et de volumétrie sont documentées.
Point de vigilance ADN : Les règles de masquage au niveau Agent précèdent l'envoi ; les pipelines Datadog ne remplacent pas une politique de minimisation.
05 · RECETTE
Comment vérifier que tout fonctionne ?
Agent sain, fichier lisible sous son utilisateur d'exécution.
logs_enabled et conf.d activés après redémarrage.
Événement de recette vu dans Log Explorer avec bons service/source et timestamp.
Valeur token fictive masquée AVANT indexation ; contrôle des logs non masqués.
Volume/quotas/rollback explicités.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
Pas de journal
Cause probable : Mauvais chemin, ACL ou Agent sans droit
Que faire : Lire datadog-agent status et vérifier lecture du fichier sous le compte Agent.
Token de test encore visible
Cause probable : Règle regex mal interprétée ou non rechargée
Que faire : Revoir match, placeholder, version Agent et réexécuter sur une valeur factice.
Journaux dupliqués
Cause probable : Deux configs collectent le même fichier
Que faire : Lister les intégrations et chemins de fichiers.
Hausse de coûts
Cause probable : Volume et indexation non maîtrisés
Que faire : Configurer réduction à la source, exclusions et politique de rétention.
Le conseil de l’expert ADN
Avant de généraliser cette configuration, validez-la sur un périmètre représentatif, documentez les critères de réussite et conservez une procédure de retour arrière. Une instrumentation utile se juge sur les données effectivement exploitables, pas sur la seule installation de l’outil.
07 · QUESTIONS PRATIQUES
Questions fréquentes
mask_sequences supprime-t-il tous les secrets ?
Non : l'exemple ne cible qu'une forme de token fictif. Il faut analyser et tester toutes les catégories de données sensibles.
Pourquoi tester dans Log Explorer ?
Le fichier de configuration et le statut Agent ne garantissent pas seuls ingestion et parsing.