Remplacer OTel et étendre une plateforme d’observabilité avec les wide events

• LogHouse est passé en un an de 19 PiB à plus de 100 PB de données de logs traitées, atteignant près de 500 mille milliards de lignes
• En raison des limites de traitement et des inefficacités d’OpenTelemetry (OTel), la plateforme a basculé vers un pipeline sur mesure (SysEx) adapté à ses systèmes centraux
• Cette transition a permis de multiplier par 20 le débit d’événements tout en maintenant l’utilisation CPU sous les 10 %
• L’adoption de HyperDX et ClickStack de ClickHouse a permis d’unifier l’UI et les données, d’assouplir la gestion des schémas et de construire un environnement puissant d’exploration des données
• Avec l’adoption d’un modèle wide events et à haute cardinalité, il est devenu possible de stocker et d’analyser tous les événements sans pré-agrégation

---

Contexte et évolution

• LogHouse, la plateforme interne de journalisation de ClickHouse Cloud, est devenue en un an un système de grande ampleur, passant de 19 PiB à plus de 100 PB de données, et de 37 mille milliards à près de 500 mille milliards de lignes
• Au départ, toute la télémétrie était collectée via OpenTelemetry (OTel), mais dans un environnement à très grand volume, les problèmes de performances, de limites de ressources, ainsi que de gaspillage CPU et de perte de données lors des transformations sont devenus évidents

Limites d’OTel et raisons de l’adoption d’un pipeline sur mesure

• Dans le pipeline OTel, les logs étaient convertis en JSON puis remappés au format OTel, avec plusieurs cycles de transformation et de marshalling, ce qui rendait l’ensemble extrêmement inefficace
• En pratique, traiter 20 millions de lignes par seconde avec une architecture basée sur OTel nécessitait environ 8 000 cœurs CPU
• Lors des pics de trafic, le Collector se retrouvait surchargé et provoquait des pertes de logs, laissant une partie des données non collectée

Adoption de SysEx et architecture

• SysEx (System Tables Exporter) transfère directement vers LogHouse les données issues des system tables de ClickHouse, dans leur type d’origine et sans transformation
• La collecte distribuée via une structure en anneau de hachage, ainsi qu’un buffer à délai temporel et une fenêtre glissante, permettent d’éviter les pertes de données et de respecter les SLA internes
• Grâce à Go et à des fonctionnalités personnalisées du client ClickHouse, un transfert byte-to-byte est possible sans marshalling des données
• Pour gérer la variabilité des schémas, la plateforme utilise un hash de schéma et une gestion dynamique des schémas, puis agrège plusieurs versions de schéma dans une seule vue logique via le Merge table engine
• La collecte de tables mémoire basée sur des snapshots permet aussi de prendre en charge des diagnostics et analyses avancés

Améliorations de performance et d’efficacité

• Avec SysEx, là où OTel Collector traite 2 millions de logs par seconde avec 800 CPU, SysEx peut traiter 37 millions de logs avec 70 CPU
• Ce gain d’efficacité réduit fortement la consommation de ressources, évite les pertes d’événements et permet un fonctionnement en temps réel

Le rôle toujours actif d’OTel

• OTel reste essentiel comme standard et plateforme neutre vis-à-vis des fournisseurs, notamment en cas de panne de service ou d’état anormal
• Il permet toujours de capturer les logs dans les situations de crash ou d’anomalie que SysEx ne peut pas traiter
• Actuellement, seuls les logs au-dessus du niveau trace sont supprimés, et seuls ceux au niveau info et au-dessus sont collectés afin d’optimiser les ressources

Intégration UI avec HyperDX et ClickStack

• L’ancienne UI personnalisée sur Grafana est progressivement remplacée par une UI native ClickHouse basée sur HyperDX
• HyperDX est indépendant du schéma, prend en charge les requêtes Lucene ainsi que SQL, et offre une compatibilité complète avec la grande variété de types de données de ClickHouse
• Des structures de tables variées ainsi que des données issues d’exporters personnalisés peuvent être intégrées sans modification de l’UI
• Grafana continue de prendre en charge les métriques basées sur Prometheus et les tableaux de bord fixes, les deux solutions étant utilisées de manière complémentaire

Adoption du modèle wide events et haute cardinalité

• Les wide events incluent dans chaque ligne divers éléments de contexte comme l’ID de requête, le nom du Pod ou les informations de version, ce qui permet de stocker toutes les données sans agrégation
• Contrairement à Prometheus et à d’autres approches, ce modèle permet des analyses approfondies et des requêtes flexibles sans pré-agrégation, sans limites sur les labels et sans crainte d’explosion de cardinalité
• En effectuant les agrégations au moment de l’analyse, il devient possible de préserver à la fois les performances et les coûts même à grande échelle

Visualisation des données et flexibilité des requêtes

• ClickHouse s’intègre très bien avec Plotly, Jupyter notebook et d’autres outils de visualisation, ce qui permet d’exploiter librement plusieurs interfaces
• Au-delà de l’exploration rapide offerte par HyperDX sur base Lucene, des analyses causales avancées via des requêtes complexes et relationnelles (SQL, JOIN, etc.) peuvent être réalisées directement dans ClickHouse

Multiplication des sources de données basées sur les wide events

• kubenetmon : outil open source de supervision réseau Kubernetes, pour l’analyse du trafic L3/L4, des connexions et des coûts
• Kubernetes Event Exporter : utilisation d’un fork avec ajout d’un sink ClickHouse, pour suivre les changements d’état dans de grands clusters, avec expérimentation en cours sur des snapshots complets d’objets
• Control Plane Data, RUM (Real User Monitoring), Istio Access Log et d’autres couches de données renforcent fortement le périmètre d’interprétation et les capacités de corrélation

Considérations d’exploitation et orientations futures

• SysEx peut apparaître dans les logs et métriques pendant les requêtes, mais son architecture est conçue pour minimiser l’impact grâce à des limites mémoire et à une isolation des erreurs
• Zero-impact scraping : des recherches sont en cours sur une architecture totalement découplée, par exemple via un plain rewritable disk basé sur S3, afin d’éliminer à la racine tout impact sur le cluster
• OTel reste important pour récupérer les logs au démarrage des services et dans les états anormaux, mais sa dépendance devrait encore diminuer si l’approche zero-impact se stabilise

Évolution et usage du type JSON de ClickHouse

• Le type JSON est désormais disponible en GA, avec génération dynamique de colonnes par champ, prise en charge de plusieurs types et bonne souplesse face à l’explosion des schémas
• Les performances ne sont pas encore parfaitement optimisées pour les requêtes JSON comportant un grand nombre de colonnes ; la plateforme affine donc son approche avec du stockage parallèle selon les formes de données et une réévaluation de l’utilité pratique du type Map
• L’intégration avec HyperDX permet l’extraction et l’analyse automatiques des champs Map et JSON, avec un recours plus large au JSON prévu à l’avenir

Conclusion et changement culturel

• LogHouse s’est désormais imposé comme la plateforme centrale d’observabilité des opérations de ClickHouse Cloud, de l’analyse de performance au débogage en temps réel
• La réduction des coûts a été le point de départ, mais avec des outils sur mesure comme SysEx, une articulation avec OTel, et l’extension d’une UI flexible fondée sur HyperDX, l’entreprise vit une transition à la fois technique et culturelle
• Ce modèle de données basé sur des wide events à grande échelle et haute précision apporte de nouvelles sources de valeur et d’efficacité à l’ingénierie, au support et à l’analyse de données
• À l’avenir, l’objectif est de continuer à faire progresser l’observabilité en s’appuyant sur l’expérience acquise à l’échelle de 100 PB et de 500 mille milliards de lignes

[GN⁺]

Commentaires Hacker News

• Franchement, je ne pense pas que ce soit vraiment quelque chose dont on puisse se vanter. Stocker 100 PB de logs, c’est surtout la preuve qu’on n’a pas encore déterminé ce qu’il faut réellement conserver. L’essentiel des informations importantes peut généralement être compris avec des métriques et des événements structurés. Le reste ? Des logs de traces détaillés que personne ne lit, sauf quand il y a une vraie panne. Une meilleure approche ? Mettre en place une « politique de rétention basée sur l’intérêt », par exemple en supprimant automatiquement les logs qui n’ont jamais servi à une alerte, ou qui n’ont pas été recherchés pendant trois mois. Sans aller dans cette direction, ce n’est au fond qu’un énorme tas de déchets numériques très haut de gamme, un peu mieux compressé
  • Moi, je préfère l’approche inverse : tout collecter, puis filtrer quand ce n’est pas nécessaire. Les logs de debug ne servent pas au quotidien, mais quand on en a besoin, ils sont absolument indispensables. Si un événement est si rare qu’il n’est même pas reproductible, on ne peut pas se mettre à recollecter les données après coup. Si tout est déjà stocké, il suffit de chercher, et c’est bien mieux à mon avis
  • Après avoir utilisé Datadog dans plusieurs entreprises, j’ai souvent vu une forte pression pour réduire les logs et ne garder que les métriques et quelques événements limités quand la facture de renouvellement explosait. Le problème, c’est que si on savait d’avance ce qui allait casser, on l’aurait déjà corrigé. Quand quelque chose semble anormal et qu’on cherche ce qui s’est réellement passé, les logs détaillés sont extrêmement utiles. Mais dans la réalité, hors des cas qui se répètent, il n’y a aucun moyen de savoir à l’avance quels logs seront importants
  • La « politique de rétention basée sur l’intérêt », c’est vraiment une excellente idée. Rien qu’en comptant le nombre d’accès via requêtes/alertes par motif de log, on peut définir une politique de TTL (durée de conservation). Notre équipe a d’ailleurs adopté cette approche : on a réduit les coûts de stockage de 70 % tout en conservant toutes les données importantes
  • Le coût d’envoi des logs n’est pas gratuit non plus. En particulier, plus un langage écrit rapidement les logs sur disque pour identifier au plus vite la cause d’un crash, plus cela coûte cher. Quand il y a trop d’informations, il devient aussi plus difficile de trouver les vraies corrélations importantes, et les logs de bugs déjà résolus perdent vite leur valeur. Moi, je préfère les données statistiques. Elles sont plus efficaces à agréger, et dans les langages basés sur le GIL en particulier, l’overhead lié à l’usage d’OTEL peut parfois être excessif
  • Si les données sont déjà stockées, le filtrage ou le nettoyage peuvent toujours se faire après coup. Je pense qu’il vaut mieux tout conserver et l’utiliser au besoin, plutôt que de souffrir parce que les données nécessaires ne sont pas là au bon moment. Évidemment, cela suppose d’avoir les ressources pour exploiter ce type d’infrastructure à grande échelle
• En réalité, cela ne s’applique qu’aux logs ClickHouse. Ce n’est pas très pertinent pour d’autres types de logs. Cela dit, j’aime beaucoup ClickHouse comme solution
  • Tu dois être très drôle en soirée
• Un point d’attention à mentionner. Quand un service entre dans une boucle de crash ou tombe à cause d’un incident, SysEx ne permet pas d’accéder aux tables système nécessaires, donc il est impossible de collecter les logs. OpenTelemetry (OTel), en revanche, est passif, donc même si le service n’est pas totalement rétabli, il peut toujours récupérer les logs sortant sur stdout et stderr. Cela permet de collecter des logs même en situation de panne et d’analyser la cause racine
  • Tous les projets OTel sur lesquels j’ai travaillé étaient actifs. Donc ce point ne me semble pas être une information nouvelle ; cela paraît plutôt faux ou incomplet comme explication
• Je me demande si les « wide events » doivent vraiment occuper autant d’espace de stockage. L’observability est fondamentalement un problème d’échantillonnage. Il suffit de pouvoir reconstruire le mieux possible l’état à un instant donné avec un minimum de stockage. On peut réduire le nombre d’échantillons ou améliorer l’efficacité de la compression. Et je ne pense pas non plus que les technologies de compression aient déjà atteint leur limite. Dans des données bourrées de redondance, il doit forcément y avoir une énorme structure de faible rang. Bien sûr, on utilise déjà des index inversés et toutes sortes d’arbres, mais j’ai l’impression qu’il y a aussi de l’espoir dans des approches de recherche plus expérimentales comme la décomposition tensorielle de faible rang. Je ne suis pas du secteur, donc il me manque peut-être quelque chose
• Je n’ai jamais travaillé à l’échelle de ClickHouse. Des logs de ce volume sont-ils vraiment interrogeables ? Je sais qu’ElasticSearch répond bien aux requêtes à petite échelle. Pourquoi utiliser ClickHouse plutôt que de stocker des fichiers json pour les logs historiques ?
  • Je travaille à cette échelle. Pour répondre directement : oui, c’est possible. Mais le coût de traitement peut dépasser l’entendement. Si les stratégies d’indexation, de tri et de clustering sont mauvaises, une simple recherche du type « enregistrements contenant cette chaîne » peut coûter entre 1 et 10 dollars. D’après mon expérience, sur les très gros volumes, les principes essentiels sont toujours « toucher le moins de données possible, le moins souvent possible » et « déplacer le moins possible ». Dès qu’on ajoute une seule opération de sérialisation/désérialisation ou un accès disque/réseau, les coûts explosent. Dans ce contexte, pour OTel, faire passer les données par un collector supplémentaire peut aller totalement à l’encontre de l’efficacité. Mais à l’échelle du pétaoctet, les économies faites grâce à ce genre de petites optimisations dépassent largement le salaire d’un ingénieur chargé d’écrire un code de sérialisation complexe
  • Pourquoi utiliser ClickHouse plutôt que des fichiers json pour des logs historiques ? Pour plusieurs raisons. (1) Une base de logs comme ClickHouse compresse par colonne, donc chaque champ est compressé séparément, ce qui réduit bien davantage l’espace de stockage que des fichiers json classiques, même compressés. (2) Une base de logs interroge beaucoup plus vite. Il est possible d’être plus de 1000 fois plus rapide, parce qu’elle ne lit tout simplement pas les données inutiles. Lien connexe. (3) Chercher avec grep dans 100 PB de fichiers json est irréaliste. Une base de logs peut monter en charge horizontalement en ajoutant simplement des nœuds et du stockage
  • C’est une question d’échelle et de coût. Notre entreprise s’est elle aussi heurtée à un problème de volume de logs. Si on injecte simplement du json dans Splunk, cela coûte plus de 6 millions de dollars par an. Or le budget approuvé ne représente que 5 à 10 % de cette somme. Le texte dit qu’il fallait 8 000 CPU pour traiter les logs json, mais qu’après optimisation, 90 CPU suffisent
  • Il y a 2 ou 3 ans, ClickHouse laissait à désirer sur les performances de recherche full text. C’était rapide et capable de traiter de gros volumes au niveau d’ElasticSearch, mais selon l’usage, sans indexation préalable, j’avais l’impression qu’ES était bien plus rapide pour les lots, le groupement et la FTS
• L’extrémisme de l’observability ressemble vraiment à une nouvelle religion. Et c’est aussi bourré d’argent
  • Pour creuser jusqu’aux anomalies encore inconnues, il n’y a pas vraiment d’alternative évidente
  • Ce qui est amusant, c’est l’ironie de la situation : on crée des outils qui te font souffrir avec ce genre de problèmes, puis on te vend la stratégie du « paye un abonnement mensuel et tout sera résolu »
• Le texte ne disait rien sur la durée de rétention des logs. Passé un certain délai, je me demande s’il est vraiment nécessaire de garder les données brutes, plutôt que seulement des données résumées ou agrégées
• Chaque fois que je reviens à Postgres après avoir utilisé ClickHouse, j’ai l’impression d’un choc culturel. J’ai du mal à accepter qu’importer un dump de 20 Go prenne plusieurs minutes. Ça ne devrait pas se faire en quelques secondes ?
  • Chaque fois que j’utilise ClickHouse, j’en bave. Bien sûr, il a des cas d’usage où il est nécessaire, et Postgres ne peut pas tout remplacer, mais j’ai toujours l’impression que ClickHouse comporte beaucoup de « facteurs de risque » et que, sauf objectif très spécifique et limité, Postgres est meilleur dans presque tous les domaines
• Ceux qui poussent à utiliser les wide events ne parlent pas du tout de l’explosion des coûts de données pour les logs. Comparé à l’approche classique (métriques + traces + logs échantillonnés), cela coûte clairement beaucoup plus cher. Il y a évidemment des avantages, mais la question du coût est toujours absente
  • Une structure de wide events bien conçue peut au contraire réduire les coûts de stockage par rapport aux logs traditionnels. Une requête externe unique est enregistrée sous la forme d’un seul wide event, ce qui contient ensuite toutes les informations nécessaires pour le debug ou l’analyse. Voir l’article connexe : A practitioner's guide to wide events
• Je suis curieux de connaître l’astuce centrale derrière des systèmes comme ClickHouse ou Dynamo. En gros, est-ce essentiellement une gigantesque table de hachage ?
  • Il y a deux astuces communes aux grandes bases de données comme ClickHouse. Premièrement, disposer intelligemment les données sur disque afin d’ignorer la majorité des données et de ne lire que les blocs nécessaires (stockage en colonnes, variantes de LSM tree, etc.). Et compresser toutes les données stockées pour minimiser aussi les E/S disque. Deuxièmement, un tuning extrême pour exploiter au maximum toutes les ressources (CPU, RAM, disque, réseau). Par exemple, ClickHouse peut traiter plus d’un milliard de lignes par seconde et par cœur CPU, avec une montée en charge linéaire selon le nombre de cœurs