Échantillonnage des journaux pour les événements à fort volume : conserver toutes les erreurs, échantillonner les lignes répétitives

Ce que c'est

L'échantillonnage des journaux consiste à n'enregistrer qu'une fraction choisie des événements qui, sans cela, se répéteraient des milliers de fois avec peu de variation : lignes de débogage par requête, hits de cache, requêtes de contrôle de santé (health-check), tentatives répétées dans une boucle. Le README de zerolog présente les formes courantes côté producteur : un échantillonneur basique qui conserve un événement sur N, un échantillonneur de rafale (burst) qui laisse passer un certain nombre d'événements par période avant de confier le reste à un échantillonneur un-sur-N, et un échantillonneur par niveau qui n'applique ces règles qu'aux événements de débogage, les autres niveaux n'étant pas échantillonnés. Les outils côté pipeline font la même chose après coup ; la transformation sample de Vector conserve un taux configurable (un sur N) ou un ratio, peut hacher un key_field afin que tous les événements partageant une valeur soient conservés ou rejetés ensemble, inscrit le taux appliqué dans un champ, et accepte une condition d'exclusion pour les événements qui ne doivent jamais être échantillonnés. La page d'OpenTelemetry sur l'échantillonnage décrit l'équivalent côté traces : l'échantillonnage en tête (head sampling) décide tôt et à faible coût, l'échantillonnage en queue (tail sampling) décide après avoir vu la trace entière et peut donc garantir la conservation de chaque trace comportant une erreur, ce que l'échantillonnage en tête seul ne peut pas assurer.

Pourquoi c'est important

Le volume de journaux se paie trois fois : CPU et E/S côté producteur, bande passante et indexation dans le pipeline, et stockage pendant la durée de rétention. L'échantillonnage réduit les trois, mais seulement si ce qui subsiste répond encore aux questions posées lors d'un incident.

Comment l'appliquer

• Ne jamais échantillonner les alertes, les erreurs, les événements d'audit ou les événements de sécurité ; réserver l'échantillonnage aux niveaux informatif et débogage.
• Indexer l'échantillonnage sur l'identifiant de requête ou de trace afin qu'une requête conservée soit complète et qu'une requête rejetée soit absente, plutôt que d'avoir chaque requête à moitié journalisée.
• Inscrire le taux d'échantillonnage dans les événements conservés (sample_rate: 100) afin que les comptages puissent être remis à l'échelle et que les lecteurs sachent ce qu'ils regardent.
• Déplacer d'abord le comptage vers les métriques ; un compteur ne coûte qu'un échantillon par scrape quel que soit le nombre d'événements comptés, tandis que la journalisation coûte une ligne par événement.
• Préférer la rafale-puis-taux au simple un-sur-N pour les événements qui comptent dès qu'ils commencent à se produire : les premières occurrences d'un nouveau mode de défaillance arrivent non échantillonnées.
• Conserver un interrupteur pour désactiver l'échantillonnage sur un service pendant une investigation, et penser à le réactiver ensuite.

Pièges

Le hachage sur une clé dont les valeurs sont réparties de manière inégale modifie le taux effectif, comme le note la documentation de Vector. Les alertes ou tableaux de bord qui comptent des lignes de journal se dérèglent silencieusement dès que l'échantillonnage démarre. Échantillonner à la fois chez le producteur et dans le pipeline compose les taux. Les journaux de conformité qui doivent être complets ne sont pas un problème de coût à résoudre par l'échantillonnage.