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

• LogHouse, la plateforme interne de ClickHouse, est passée en un an de 19 PiB et environ 40 000 milliards de lignes à plus de 100 Po de logs non compressés et près de 500 000 milliards de lignes
• Le pipeline de collecte existant centré sur OpenTelemetry passait par JSON, le format OTel et le format ClickHouse Native, ce qui augmentait le coût CPU et le risque de perte de logs
• Avec SysEx (System Tables Exporter), ClickHouse copie les tables système vers LogHouse octet par octet et traite 37M logs/s avec 70 cœurs CPU
• OTel reste utile pour les logs d’incident basés sur stdout/stderr et comme format standard neutre vis-à-vis des fournisseurs, mais la télémétrie ClickHouse essentielle bascule vers SysEx et les wide events
• Depuis l’adoption d’HyperDX, ClickHouse combine une UI native ClickHouse, la recherche en syntaxe Lucene, l’analyse SQL et l’exploration indépendante du schéma, remplaçant une partie du rôle de l’UI custom basée sur Grafana

---

LogHouse atteint 100 Po et 500 000 milliards de lignes

• LogHouse est la plateforme interne de logging créée pour superviser ClickHouse Cloud, et servait auparavant aussi à remplacer des coûts Datadog en forte hausse
• Il y a un an, elle traitait 19 PiB de données non compressées et 37 000 milliards de lignes ; elle stocke aujourd’hui plus de 100 Po de données non compressées et près de 500 000 milliards de lignes
• Les principales composantes des données stockées aujourd’hui sont les suivantes
  • SysEx : 93,6 Po, 431 000 milliards de lignes
  • OTel : 14,5 Po, 16,7 000 milliards de lignes
• Auparavant, toute la télémétrie passait par OpenTelemetry ; aujourd’hui, la plupart des données proviennent de SysEx, un exporter spécialisé créé par ClickHouse

Les limites du pipeline OpenTelemetry

• OpenTelemetry convenait comme pipeline standard initial pour envoyer vers ClickHouse tous les logs des pods dans un environnement Kubernetes
• Les seuls logs texte stdout de ClickHouse ne suffisaient pas pour l’analyse opérationnelle ; l’analyse réelle nécessitait les logs structurés, les métriques, les détails d’exécution, les E/S disque et l’état des tâches en arrière-plan présents dans les tables system
• Le chemin de logs OTel existant passait par plusieurs étapes de transformation
  • L’instance ClickHouse du client écrit les logs en JSON sur stdout
  • kubelet stocke les logs dans /var/log/…
  • Le collector OTel lit les logs sur disque, parse le JSON et le convertit en représentation mémoire
  • Le collector les reconvertit au format de logs OTel
  • Le client Go ClickHouse les reconvertit au format ClickHouse Native et les insère dans LogHouse
• Le pipeline OTel réel inclut aussi un edge collector, un transport OTLP, un gateway collector et des traitements supplémentaires, chaque étape augmentant l’overhead, la latence et la complexité
• Avec la montée en charge, deux problèmes sont devenus marquants
  • Les types ClickHouse Native passent par JSON et le format OTel, ce qui gaspille du CPU et réduit la fidélité des données
  • L’agent OTel des nœuds Kubernetes atteint ses limites de CPU et de mémoire et drop des lignes de logs lors des pics de trafic
• Pour traiter 20M rows/s sans perte avec OTel, il faudrait environ 8 000 cœurs CPU sur l’ensemble des agents et collectors

SysEx : un collecteur spécialisé pour le transfert ClickHouse-to-ClickHouse

• ClickHouse a créé System Tables Exporter (SysEx) pour transférer directement les données des tables système ClickHouse des pods clients vers les tables LogHouse
• SysEx effectue une copie octet par octet entre la source et la destination, préserve les types ClickHouse Native et élimine les transformations intermédiaires
• Grâce à cette architecture, les requêtes que les ingénieurs utilisaient pour déboguer une live instance peuvent facilement devenir des requêtes sur l’historique de l’ensemble de la flotte dans LogHouse
  • Les schémas de tables sont identiques, seuls des colonnes d’enrichissement comme le nom du pod et la version de ClickHouse sont ajoutées
• L’architecture repose sur un pool de scrapers SysEx et un hash ring
  • Le hash ring assigne les pods clients à une réplique de scraper donnée pour répartir la charge
  • Le scraper exécute des SELECT sur les system tables du pod source et streame les données vers LogHouse
  • Le scraper orchestre le transfert des octets entre source et destination, sans désérialisation
• Pour éviter de manquer les flushs de buffers des tables système, SysEx utilise une fenêtre temporelle glissante et interroge généralement avec 5 minutes de retard par rapport au temps réel
• Comme le comportement par défaut du client Go ClickHouse convertit les données en types natifs Go, ClickHouse a contribué à clickhouse-go une fonctionnalité permettant de contourner le marshalling interne
• SysEx étant basé sur un modèle pull, il n’a pas besoin d’un buffering lourd comme OTel ; si LogHouse est temporairement indisponible ou si la télémétrie source augmente fortement, il peut rescraper des fenêtres passées pour backfiller les données

Schéma dynamique et snapshots d’état

• SysEx exige que les schémas source et cible correspondent, mais les schémas des system tables ClickHouse changent fréquemment avec l’ajout de nouvelles métriques et colonnes
• Pour gérer cela, quand SysEx rencontre une system table, il inspecte son schéma, le hashe, puis vérifie s’il existe dans LogHouse une table avec le même schéma
  • Si oui, il insère dans la table existante
  • Sinon, il crée une nouvelle version de schéma, comme text_log_6
• Au moment des requêtes, le Merge table engine de ClickHouse sert à regrouper plusieurs itérations de schéma en une vue logique unique
• Le Merge table engine permet de sélectionner uniquement les colonnes compatibles ou de limiter les requêtes aux tables possédant les colonnes demandées, ce qui rend les changements de schéma interrogeables sans gestion manuelle
• ClickHouse capture aussi périodiquement sous forme de snapshots les system tables en mémoire, comme system.processes, et les stocke dans LogHouse
• Ces snapshots servent à analyser rétrospectivement l’état d’un cluster, les schémas de tables et la configuration du cluster à un instant donné

Analyse de toute la flotte et chiffres d’efficacité

• Grâce à SysEx, les requêtes Advanced Dashboard que les clients utilisent pour superviser des instances ClickHouse individuelles peuvent être exécutées simultanément sur l’ensemble de la flotte d’instances clientes
• Pour l’analyse des releases, des requêtes de diagnostic sont exécutées avant et après le déploiement afin d’observer en temps réel, à l’échelle de la flotte, les patterns de performance des requêtes, les tendances d’utilisation des ressources et les variations du taux d’erreur
• Les dashboards de support corrèlent, dans la même interface, les requêtes Advanced Dashboard avec les logs réseau, les événements Kubernetes et les événements du data plane et du control plane
• La comparaison d’efficacité dans LogHouse est la suivante
  • OTel Collectors : plus de 800 cœurs CPU pour transférer 2M logs/s
  • LogHouse Scrapers (SysEx) : 70 cœurs CPU pour transférer 37M logs/s
• SysEx a multiplié par 20 le volume d’événements sur la source de données la plus importante, tout en réduisant l’empreinte CPU à moins de 10 % de l’existant et en évitant de dropper des événements à l’edge

Les domaines où OpenTelemetry reste nécessaire

• OpenTelemetry reste le choix par défaut de ClickStack, car il fournit un format standard neutre vis-à-vis des fournisseurs et une expérience d’onboarding adaptée aux nouveaux utilisateurs
• SysEx est fortement couplé aux internes de ClickHouse et repose sur un modèle pull qui interroge les live system tables ; si un service est en crash loop ou down, il ne peut pas scraper les données
• OpenTelemetry capture passivement les logs émis sur stdout et stderr, ce qui lui permet de collecter des logs pendant un incident même si le service n’est pas complètement healthy
• ClickHouse continue d’exécuter OpenTelemetry sur tous les services ClickHouse, mais avec un périmètre de collecte modifié
  • Auparavant, tous les logs jusqu’au niveau trace étaient ingérés
  • Aujourd’hui, seuls les logs de niveau info et supérieur sont collectés
• Depuis ce changement, le collector et le gateway OTel fonctionnent avec beaucoup moins de ressources, et le pipeline plus réduit évoqué plus haut, à 2M log lines/s, est maintenu

HyperDX et l’expérience d’exploration native ClickHouse

• La première UI de LogHouse était une expérience d’observabilité custom construite sur Grafana, mais avec l’augmentation de SysEx et de la télémétrie wide-column, une UI plus profondément intégrée à ClickHouse est devenue nécessaire
• HyperDX est une UI native ClickHouse qui prend en charge l’exploration des logs et des traces, la corrélation et l’analyse à grande échelle
• La possibilité d’interroger avec la syntaxe Lucene simplifie l’exploration des données, tandis que SQL reste utilisable pour les analyses d’événements complexes
• L’approche indépendante du schéma d’HyperDX v2.0 n’impose pas une structure de table de logs unique et fixe
  • Elle traite les formats de données standardisés mais évolutifs du pipeline OpenTelemetry
  • Elle traite aussi les tables wide-column spécialisées de SysEx et d’autres custom exporters, sans connaissance préalable du schéma ni patterns grok complexes
• Grafana conserve aussi un rôle dans LogHouse
  • L’application interne basée sur Grafana permet de spécifier un namespace afin de connaître l’emplacement des données par service et de router la requête vers la bonne instance ClickHouse
  • Les dashboards et alertes existants basés sur les métriques Prometheus restent dans Grafana
  • Les métriques de haut niveau comme kube_state_metrics ne sont pas adaptées aux investigations approfondies, mais conviennent à l’alerting

Wide events et observabilité à forte cardinalité

• L’adoption de SysEx a entraîné le passage d’une collecte centrée sur les logs stdout à un modèle centré sur les wide events basés sur les system tables et les données à forte cardinalité
• ClickHouse appelle cela l’association de LogHouse et ClickStack, plutôt qu’Observability 2.0
• Ce modèle stocke dans un warehouse central de la télémétrie à forte cardinalité provenant de plusieurs sources, au lieu du modèle traditionnel des trois piliers
• Chaque ligne inclut un contexte riche comme un query identifier, le nom du pod, les métadonnées de version et des détails réseau ; les dimensions ne sont pas préagrégées ni abandonnées pour s’adapter aux limites d’un metric store
• Les données sont stockées brutes à l’ingestion, sans résumé, et les agrégations sont repoussées au moment des requêtes
• La différence avec Prometheus est que tous les data points sont stockés
  • Les champs comme insertDuration ne sont pas préagrégés ; chaque valeur est conservée avec ses dimensions associées
  • Stocker dans Prometheus les timeseries de toutes les combinaisons de labels provoque une explosion de cardinalité
  • La préagrégation en histogrammes contrôle l’usage des ressources, mais rend difficile de demander à quelle instance, table ou fenêtre temporelle correspond un spike précis d’insert
• Elasticsearch a aussi encouragé les wide events et les structures de documents flexibles, mais le design columnar de ClickHouse permet de stocker et d’interroger efficacement à grande échelle des données d’événements à forte cardinalité et fort volume

Outils de data science et analyse SQL

• Plusieurs caractéristiques peuvent être visualisées à partir d’un seul wide event, et il est possible de revenir au raw log depuis un point précis d’un graphique
• ClickHouse fournit des intégrations de visualisation de données et des clients langage, ce qui permet d’utiliser des outils basés sur SQL comme Plotly, Jupyter notebook, Hex, Bokeh ou Evidence
• La recherche en syntaxe Lucene d’HyperDX convient aux consultations et filtrages rapides, mais les questions complexes nécessitent SQL
• ClickHouse SQL peut exprimer des joins, des opérations temporelles et des transformations
  • L’exemple associe, dans le stream d’événements Kubernetes, les événements Killing et Created d’un même conteneur avec un ASOF JOIN afin de calculer le temps entre l’arrêt et le redémarrage
  • La requête d’exemple a traité 17,78M rows et 581,49 Mo en 0,099 seconde, avec un pic mémoire de 272,88 MiB
• Les métriques nécessaires peuvent être dérivées au query time dans le warehouse de wide events, sans avoir à créer et déployer à l’avance des composants dédiés

Sources de données ajoutées à LogHouse

• LogHouse a ajouté davantage de data sinks basés sur les wide events à la demande des équipes engineering et support
• kubenetmon : outil open source de monitoring réseau Kubernetes qui utilise Linux conntrack pour capturer les données de connexion L3/L4 ainsi que les compteurs d’octets et de paquets
  • Il fournit de la forensics, de l’attribution par workload et par pod, ainsi que du metering de coûts comme l’egress inter-régions
  • Projet : https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter : fork d’un exporter populaire, avec ajout d’un sink natif ClickHouse pour analyser les événements de l’API Kubernetes à grande échelle
  • Fork : ClickHouse/kubernetes-event-exporter
  • Il est prévu d’ingérer dans LogHouse non seulement les événements, mais aussi tout le modèle d’objets Kubernetes, et de stocker un snapshot à chaque changement
• Control Plane Data : collecte de données opérationnelles du département Control Plane qui n’avaient pas encore été onboardées dans LogHouse
• Real User Monitoring (RUM) : projet en cours qui envoie les métriques de performance frontend du navigateur utilisateur au pipeline OTel via une gateway publique
• Istio Access Log : ingestion des données de trafic HTTP-level du service mesh Istio pour capturer les patterns de requêtes et réponses, la latence et les décisions de routage
  • En les combinant avec system.query_log et les flux réseau de kubenetmon, il devient possible de croiser requêtes SQL, requêtes HTTP et packet flows

Prochaines étapes : zero-impact scraping et JSON

• Les requêtes de scrape SysEx sont limitées par un strict memory limit, mais les clients peuvent s’en inquiéter lorsqu’ils les voient dans leurs logs et métriques
• ClickHouse explore le zero-impact scraping, qui n’exécute pas de requêtes sur le système live
  • Une piste prometteuse consiste à exploiter le plain rewritable disk S3 sur lequel ClickHouse écrit déjà les service logs
  • Si un pool de workers SysEx monte directement une table de logs basée sur disque, il peut contourner les requêtes sur l’instance ClickHouse en cours d’exécution
• Si cette approche réussit, elle préservera les avantages actuels — format native, haute fidélité, transformations minimales — tout en réduisant aussi la perception d’un impact opérationnel
• Le type JSON de ClickHouse a atteint la GA en 25.3 ; il crée dynamiquement des colonnes avec le bon type lorsque de nouveaux champs apparaissent, et gère aussi les champs à types multiples ainsi que la schema explosion
• LogHouse évalue dans quelle mesure JSON correspond aux patterns d’accès d’observabilité à grande échelle
  • Rechercher une chaîne dans tout un blob JSON peut scanner des milliers de colonnes
  • Il existe une solution de contournement consistant à stocker une chaîne JSON brute avec les données structurées
  • La plupart des attributs de logs et de resources sont petits et stables, donc le type Map reste aussi adapté
  • HyperDX convertit automatiquement les accès aux maps en fonctions JSONExtract