Le projet opendatahub-io propose un opérateur Kubernetes qui injecte un sidecar pour normaliser les logs. Ce composant répond à un problème récurrent en ingénierie : la diversité des formats émis par les applications modernes. Que ce soit du JSON, du klog, du Zap console ou du texte brut, l’outil vise à produire un enregistrement unique et structuré compatible OpenTelemetry (OTel) sans que les développeurs aient à modifier leur code.

Dans un environnement de microservices, chaque composant peut utiliser ses propres bibliothèques de log ou ses propres conventions. Les outils de collecte existants, comme Vector ou l’OTel Collector, exigent alors des règles de parsing complexes, souvent basées sur des expressions régulières (regex) sur mesure. Si une dépendance change son format de sortie, ces règles se cassent, et l’information critique se perd.

L’opérateur résout ce goulot d’étranglement en déplaçant la logique de normalisation au niveau de la frontière du pod. Grâce à un webhook d’admission mutante, il injecte le sidecar normalisateur dans les namespaces désignés. Ce conteneur intermédiaire intercepte les flux standards (stdout et stderr) de l’application. Il analyse le contenu au lieu de simplement le transmettre.

Le cœur de cette solution est l’algorithme Drain Template Mining. Au lieu de se fier à des patterns pré-définis, le sidecar examine les lignes pour identifier des structures similaires. Il remplace ensuite les éléments variables – comme les horodatages ou les identifiants – par des jokers. Cela permet une classification basée sur des modèles découverts, offrant une robustesse supérieure face à la variation.

Ce système ne se contente pas de nettoyer. Il gère aussi les entrées multi-lignes, essentielles pour capturer des traces de pile ou des sorties JSON formatées. Le normaliseur consolide ces fragments en un unique enregistrement log. Il exporte ensuite ces données vers deux destinations : le stdout du conteneur (pour rester visible via kubectl logs) et via gRPC OTLP vers un OTel Collector, si l’endpoint est spécifié dans la configuration.

Un contrat de log unique pour tous les composants

Cette approche est particulièrement utile lorsque l’on intègre des images tierces ou des composants écrits dans des langages différents. Red Hat Developer souligne que cette uniformisation permet aux outils de corrélation de naviguer entre les signaux d’observabilité en se fiant à des champs stables, même si chaque composant utilisait initialement des noms de champs différents. L’opérateur garantit que les métadonnées Kubernetes, comme le nom du pod ou du namespace, sont injectées dans chaque enregistrement, facilitant le traçage.

Le déploiement passe par l’installation de l’opérateur via make deploy et le labellisation des namespaces concernés avec lognormalizer.opendatahub.io/inject=enabled. Le webhook est configuré pour ne pas modifier rétroactivement les pods existants, bien qu’un pod spécifique puisse être exclu via une annotation.

L’injection automatique et les mécanismes de détection

Pour que le sidecar puisse intercepter tout le flux, le webhook est capable de remonter les ENTRYPOINT et CMD des conteneurs depuis les registries. Cela permet d’envelopper quasiment n’importe quel conteneur sans configuration manuelle lourde, en utilisant les secrets d’authentification du cluster.

Les mécanismes de détection sont variés : le système reconnaît nativement les structures JSON, les formats klog, les sorties Zap console tabulées et les structures logfmt (qui contiennent deux paires clé=valeur ou plus). Des consolidateurs linguistiques sont également présents pour gérer spécifiquement les paniques Go, les tracebacks Python ou les exceptions Java.

Cette architecture repose sur des versions récentes de Kubernetes, spécifiquement K8s 1.33+ ou OpenShift 4.18+, pour supporter le modèle de sidecar natif. Surveiller ces mécanismes d’injection automatique, c’est observer un pas vers la standardisation de l’observabilité au cœur de l’infrastructure conteneurisée.

Sources

• GitHub – opendatahub-io/odh-log-normalization-operator, github.com
• Make Kubernetes logs easier to correlate with traces using the log normalizer operator, Red Hat Developer, 6 novembre 2026