Pourquoi ClickHouse prend l’avantage dans la guerre de l’observability

• Les logs, contrairement à l’expérience grep sur un petit système, deviennent les données les plus difficiles à gérer en observability quand services et consommateurs se multiplient, car s’y combinent gros volumes, données non structurées et requêtes imprévisibles
• ClickHouse est né comme base de données pour l’analyse de clickstream, mais correspond bien aux patterns d’usage des logs : fort volume, écritures orientées ajout, ordre temporel, lectures agrégées
• Le stockage en colonnes permet de ne lire que les colonnes nécessaires et montre, sur des données réelles d’observability, des taux de compression de 10 à 14x, contre 2 à 3x pour Elasticsearch
• À l’échelle de 1 To/jour, plusieurs stacks restent viables, mais à 5 To/jour puis 10 To/jour, Elasticsearch, LGTM et Datadog exigent de gros changements d’architecture ou de coûts, tandis que ClickHouse monte surtout en charge en ajoutant des shards
• ClickHouse demande une conception de schéma initiale et une certaine complexité côté moteur de requêtes, mais son modèle opérationnel reste globalement stable même quand les volumes augmentent d’un ordre de grandeur ou plus

---

Pourquoi les logs sont difficiles en observability

• Les développeurs ont des attentes élevées pour la recherche dans les logs, car ils ont connu sur de petits systèmes une expérience rapide avec grep, jq et tail -f
• Cette approche fonctionne bien quand le système est petit, que le volume de logs est faible et que la personne qui interroge les logs est aussi celle qui a écrit directement les lignes de log
• Quand l’échelle augmente, on voit apparaître en même temps la dérive de schéma, l’explosion de cardinalité, des consommateurs répartis entre équipes et des besoins de tableaux de bord
• Les personnes qui utilisent les logs ne sont pas seulement les développeurs
  • Le support client doit pouvoir retrouver des événements comme l’échec d’un paiement pour un utilisateur précis
  • L’équipe data peut construire des tableaux de bord métier au-dessus de lignes de log que les ingénieurs backend peuvent modifier
  • La personne d’astreinte attend qu’une barre de recherche fonctionne immédiatement, sans devoir apprendre un nouveau langage de requête ou des patterns d’index
• Techniquement, le volume de données est important, la forme des données irrégulière et il est difficile de prévoir quelles requêtes vont arriver
• Les développeurs veulent de l’immédiateté, des opérations arbitraires et un schéma souple, tandis que les utilisateurs non techniques veulent des tableaux de bord stables et une UI tolérante

Pourquoi la structure de ClickHouse correspond bien aux logs

• ClickHouse a été créé chez Yandex pour exécuter des requêtes analytiques à grande échelle sur des données de clickstream
• Il n’a pas été conçu spécifiquement pour l’observability, mais les données de clickstream et d’observability ont beaucoup en commun
  • Données massives
  • Écritures majoritairement en ajout
  • Forte dimension temporelle
  • Lectures surtout orientées agrégation
  • Besoin occasionnel de retrouver un enregistrement précis
• Plusieurs modes d’exploitation sont possibles
  • Exécution directe via un chart Helm
  • Utilisation du plugin ClickHouse de Grafana, de sa propre interface web ou d’un frontend maison
  • Ingestion directe de données OTLP via l’exporter ClickHouse d’OpenTelemetry Collector, avec gestion initiale du schéma
• Il a été conçu pour scanner des milliards de lignes et ingérer des volumes de données très importants
• Son langage de requête n’est pas un langage spécialisé inédit, mais du SQL

La différence créée par le stockage en colonnes et la compression

• Par nature, les logs sont proches d’un modèle append-only
  • On ne met pas à jour une ligne de log
  • Les suppressions individuelles sont rares, et les suppressions se font en masse à la fin de la période de rétention
  • Les données arrivent en général dans l’ordre temporel, sans être parfaitement triées
• Les patterns de lecture changent brutalement lors d’un incident ou d’une analyse
  • Personne ne regarde les logs pendant plusieurs jours, puis pendant un incident on veut parcourir des milliards d’événements en quelques secondes
  • Il est fréquent d’examiner plusieurs champs sur une fenêtre de temps étroite, ou d’agréger sur une large plage temporelle avec quelques filtres
  • Le pattern consistant à retrouver une seule ligne par ID précis, comme dans une base transactionnelle, est rare
• Les bases orientées lignes comme Elasticsearch, Postgres ou MySQL stockent ensemble tous les champs d’une même ligne de log
  • Même si seulement 3 champs sur 40 sont nécessaires, le disque doit en lire 40
• ClickHouse stocke chaque colonne séparément
  • Une requête qui n’utilise que timestamp, service et status_code ne lira que ces colonnes
  • Dans les données d’observability, où une requête donnée n’utilise souvent que 3 ou 4 colonnes malgré des dizaines d’attributs, l’écart de volume lu devient important
• Les données en colonnes se compressent bien parce que les valeurs d’une même colonne se ressemblent
  • La colonne service_name peut n’avoir que quelques centaines de chaînes uniques sur des milliards de lignes
  • Sur des données réelles d’observability, on voit souvent des taux de compression de 10 à 14x
  • Cela contraste nettement avec les 2 à 3x d’Elasticsearch

À 1 To/jour, la plupart des stacks restent viables

• À l’échelle de 1 To/jour, les stacks modernes d’observability sont globalement utilisables ; il existe des différences, mais elles restent encore supportables

• Elasticsearch

  • Un cluster Elasticsearch relativement standard avec un buffer Logstash peut suffire
  • La recherche full-text est un point fort d’Elasticsearch, et elle fonctionne bien à cette échelle
  • Avec des données hétérogènes, le risque de mapping explosion existe ; il faut donc désactiver le dynamic mapping ou définir soigneusement les templates
  • Les politiques ILM hot → warm → delete sont déjà indispensables à cette échelle
  • Le coût se situe autour de 6 à 9 k$ par mois

• LGTM

  • Alloy unifie la collecte dans un daemon unique
  • Loki fonctionne bien à condition de former les développeurs à poser des labels utiles
  • Mimir et Tempo remplissent globalement le rôle attendu
  • Le coût se situe autour de 3,5 à 5 k$ par mois

• Datadog

  • À 1 To/jour, l’expérience est simple : on installe l’agent et on consulte les tableaux de bord
  • On commence à voir apparaître les questions de metered pipeline, de séparation entre indexed logs et ingested logs, ainsi que les coûts liés à la cardinalité des custom metrics, mais cela reste gérable à cette échelle
  • Le coût se situe autour de 45 à 75 k$ par mois, avec de fortes variations selon la négociation
  • La logique tarifaire de Datadog repose sur l’idée qu’il permet d’économiser un ingénieur dédié

• ClickHouse

  • À 1 To/jour, ClickHouse n’est pas moins complexe que les autres options
  • Il faut une conception de schéma dès le départ, et la clé ORDER BY est cruciale
  • Avec ZSTD et des codecs adaptés, on peut obtenir une compression de 10 à 14x
  • Altinity Operator gère la coordination keeper, et l’ensemble tourne avec environ 7 pods
  • Il n’y a pas de PromQL natif ; les workflows métriques passent par le plugin Grafana ou par chproxy avec un adapter
  • Le coût se situe autour de 1,5 à 2,5 k$ par mois

À 5 To/jour, les différences d’architecture deviennent visibles

• À 5 To/jour, la courbe de croissance devient plus raide pour la plupart des stacks, et l’écart avec ClickHouse apparaît plus clairement

• Elasticsearch

  • Kafka devient pratiquement indispensable
  • En écrivant directement dans Elasticsearch, des pics de trafic peuvent faire tomber le cluster à cause des bulk rejects et de la backpressure
  • Avec des shards cibles de 50 Go, on crée environ 200 shards par jour en comptant les replicas, et la taille même du cluster state devient un problème
  • Les searchable snapshots et le frozen tier rendent quasiment nécessaire une licence commerciale Elastic
  • Le coût se situe autour de 40 à 55 k$ par mois avant licence

• Stack LGTM

  • On passe à un mode microservices avec plus de 65 pods et trois systèmes séparés à exploiter
  • Chaque système a son pipeline de compaction, son hash ring et son tier memcached
  • Le ring gossip/memberlist devient un vrai sujet d’exploitation
  • Le rollout des ingesters demande des réglages de -ingester.autoforget-unhealthy, faute de quoi on risque pertes ou duplications de données
  • Le coût se situe autour de 22 à 32 k$ par mois

• Datadog

  • La complexité opérationnelle reste faible puisqu’on n’exploite pas les serveurs soi-même
  • En revanche, il devient nécessaire d’avoir une équipe pipeline dédiée à la réduction de la facture Datadog
  • Apparaissent alors exclusion filters, sampling rules, cardinality caps et tag allow-lists
  • Le coût se situe autour de 180 à 350 k$ par mois, selon l’agressivité de cette équipe pipeline
  • La relation avec le fournisseur SaaS consiste alors à réduire les coûts en épluchant les documents de facturation

• ClickHouse

  • Le principal changement est l’ajout de shards
  • L’operator, le moteur de requêtes, le langage de requête et le modèle mental restent les mêmes
  • Le rééquilibrage après ajout de shards reste manuel ; la plupart des équipes contournent cela par du pré-provisionnement ou par le weighting des tables Distributed
  • Les materialized views pour les rollups de dashboards passent du statut de nice-to-have à celui de quasi-indispensable
  • Le coût se situe autour de 7 à 11 k$ par mois

À 10 To/jour, les modèles opérationnels divergent

• À 10 To/jour, beaucoup de solutions atteignent une échelle où la charge opérationnelle devient difficile à supporter

• Elasticsearch

  • On finit par exploiter 3 clusters Elasticsearch séparés pour les logs, les métriques et l’APM, reliés via Cross-Cluster Search
  • Le coût du hot tier en NVMe domine la facture
  • C’est à cette échelle que les équipes commencent à évaluer sérieusement les alternatives, et beaucoup de migrations récentes vers ClickHouse viennent de là
  • Le coût se situe autour de 95 à 140 k$ par mois hors licence commerciale
  • Exploiter Elasticsearch à cette échelle exige de vrais experts

• LGTM

  • Il faut environ 180 pods ou plus, une configuration zone-aware, de la compaction split-and-merge, des limites par tenant et du shuffle sharding pour éviter les noisy neighbors
  • Une équipe platform observability dédiée de 3 à 5 personnes devient presque indispensable
  • Le coût se situe autour de 55 à 85 k$ par mois

• Datadog

  • Cela reste simple au sens où il n’y a toujours pas de serveurs à exploiter soi-même, mais la facture mensuelle peut atteindre 6 ou 7 chiffres
  • L’organisation est alors susceptible de créer une équipe de pipelines de prétraitement pour réduire la facture
  • À cette échelle, beaucoup d’entreprises utilisent une configuration hybride : Datadog pour l’APM et les métriques à forte valeur, et un hébergement self-hosted pour les logs
  • De plus en plus, cette cible self-hosted est ClickHouse
  • On se retrouve donc avec la simplicité de Datadog, la complexité des pipelines et une deuxième stack self-hosted en parallèle
  • Le coût est très variable et peut dépasser 1 M$ par mois

• ClickHouse

  • Le schéma général reste le même qu’à 1 To/jour ; la différence est simplement qu’il y a plus de shards
  • Les materialized views de rollup ne sont plus une option, mais une nécessité
  • Une erreur de conception de schéma faite deux ans plus tôt peut devenir très douloureuse à cette échelle
  • Le rééquilibrage après ajout de shards reste manuel
  • La plupart des équipes font du pré-provisionnement ou utilisent clickhouse-copier et des migrations en dual-write
  • Pour des ingestions très bursty, Kafka devient utile comme buffer, sans être strictement indispensable
  • Le coût se situe autour de 18 à 28 k$ par mois

Critères de choix

• À 1 To/jour, à peu près n’importe quelle stack peut fonctionner ; le bon choix est souvent celle que l’équipe connaît déjà
• La vraie question n’est pas de savoir si cela fonctionne aujourd’hui, mais si la même forme restera viable dans deux ans quand les données auront été multipliées par 5, l’équipe par 2, et que les concepteurs initiaux seront partis
• Elasticsearch et LGTM changent de structure quand l’échelle augmente
• Datadog reste simple à exploiter, mais évolue côté coûts vers un modèle qui exige une équipe dédiée à la comptabilité et aux pipelines
• ClickHouse s’élargit principalement en ajoutant des shards
• Le prix à payer est d’accepter dès le départ la conception du schéma et la complexité du moteur de requêtes
• En acceptant ce coût, l’expérience des développeurs et des opérateurs reste globalement stable même quand les volumes augmentent d’un ordre de grandeur ou plus

[GN⁺]

Avis sur Lobste.rs

• Une startup où j’ai travaillé brièvement en 2019 avait produit pas mal de choses assez impressionnantes, et on m’y a un peu montré ClickHouse : ça m’a vraiment marqué
  Jusque-là, je pensais qu’il serait rare d’avoir besoin d’autre chose que PostgreSQL, mais ClickHouse m’a donné envie de l’utiliser
  J’ai aussi essayé ElasticSearch, InfluxDB, etc., mais je les ai toujours trouvés décevants, probablement parce qu’ils ont chacun recréé leur langage de requête à partir de zéro. À l’inverse, ClickHouse reprend le SQL familier et l’étend juste là où c’est nécessaire
  Comme les produits qui réussissent, ClickHouse donne une impression de qualité d’implémentation et d’attention portée aux utilisateurs, avec même les petits détails correctement réglés par défaut
  Dans mon entreprise actuelle, nous utilisons HyperDX ; les graphes de métriques sont un peu pénibles, mais les traces fonctionnent plutôt bien. Je pensais que le tracing deviendrait vite un outil indispensable et ferait fortement gagner en productivité, mais vu qu’il n’est pas adopté autant que prévu, ce n’est sans doute pas aussi révolutionnaire que je l’imaginais. Cela dit, je suis content que ClickHouse devienne un acteur central dans ce domaine et nous évite d’avoir à gérer trop d’autres choses

  • Introduire le tracing dans une organisation qui s’en sortait jusque-là avec seulement des métriques et des logs est, d’après mon expérience, une pente assez raide
    Il faut beaucoup d’évangélisation, collecter des cas d’usage, et faire le travail difficile de montrer concrètement ce qu’on peut désormais faire alors qu’on ne le pouvait pas avant, ainsi que combien certaines choses autrefois difficiles deviennent simples
    Techniquement aussi, l’adoption doit être aussi fluide que possible ; selon la stack et le contexte, cela peut représenter un gros effort en soi, et cette charge retombe généralement sur la personne qui pousse l’adoption
    Ce n’est pas très différent d’une initiative organisationnelle transversale : avoir de la crédibilité personnelle et une ou deux personnes vraiment convaincues pour la diffuser dans l’entreprise aide beaucoup
  • Je me demande si tu parles du langage de requête JSON d’ElasticSearch. ElasticSearch prend en charge plusieurs langages de requête, dont un dialecte SQL
    Je ne sais pas ce que vaut cette prise en charge, mais je n’ai utilisé directement que le langage de requête JSON, et je viens seulement de découvrir les autres
    SQL n’est pas parfait comme langage de requête. Le fait de ne pas pouvoir dupliquer les clauses ni les écrire dans un ordre arbitraire est agaçant, mais SQL reste un très bon langage

• Mon expérience est similaire à celle de l’auteur. La scalabilité de ClickHouse est étonnamment bonne, et même quand on l’exploite soi-même, cela ressemble surtout à ajouter davantage de cœurs
  Le coût de configuration initial peut être un peu plus élevé, mais le schéma est en pratique largement défini par l’export OTel ; on peut donc commencer avec ça, puis extraire des colonnes et des vues matérialisées quand on a besoin de plus de performances de requête
  En contrepartie, on a moins à se soucier du passage à l’échelle, on peut exploiter toutes ses données pour l’analyse, et il devient aussi possible de dériver des métriques à partir des traces
  En revanche, l’autre pièce du puzzle, la visualisation, doit encore beaucoup s’améliorer. Grafana n’est pas optimal pour afficher et analyser des traces comparé à des outils comme Honeycomb. J’espère qu’un acteur existant réglera ça bientôt, peut-être HyperDX

• Cet article donnait d’abord l’impression de démarrer très fort, avec une introduction convaincante, mais lorsqu’il passe à l’analyse de plusieurs entreprises, il s’effondre en une liste au style LLM à faible effort très marqué
  En relisant l’introduction avec un œil plus critique, j’y ai aussi vu de plus en plus de traces de ce genre
  C’est un schéma que je vois de plus en plus souvent dans les articles sur Lobsters ces derniers temps ; plutôt que d’attaquer un texte en particulier, je voudrais laisser ici une courte réflexion sur une observation plus générale
  Personnellement, je n’ai pas une grande expérience des outils d’observabilité, donc certaines parties de l’article m’ont intéressé indépendamment de la manière dont il est écrit. Mais je ne veux pas tomber dans l’erreur consistant à faire confiance à un LLM sur les sujets que je connais mal, puis à dire que les textes de LLM sont flawed sur ceux que je connais bien
  Je ne sais donc pas vraiment dans quelle mesure on peut faire confiance factuellement à cet article, ou à la plupart des textes similaires. Il me paraît clair que l’auteur a délégué une grande partie de la réflexion à une machine, même si l’idée de départ semblait assez nette
  Quand je programme, même les idées claires dans ma tête doivent passer par l’écriture effective du programme, les échecs sur les tests de cas limites ou le typage, pour me convaincre qu’il manque quelque chose de fondamental
  Pour l’écriture, c’est pareil : si l’on ne construit pas soi-même son argumentation, qu’on n’assemble pas l’ensemble, puis qu’on ne considère pas soigneusement les objections, on ne transmet pas plus de valeur que l’idée claire initiale
  C’est probablement ce que veulent dire les gens qui proposent d’écrire du code en ne conservant que les prompts pour les futurs LLM
  Mais si toute la programmation ou toute l’écriture se fait ainsi, alors on renonce non seulement à la réflexion, mais aussi à la rigueur, au sérieux et au respect
  Je ne sais pas très bien ce que Lobsters devrait faire à ce sujet. Le tag vibecoding ressemble déjà à une solution surchargée. Mais un tag odeur de LLM pourrait peut-être aider à signaler un manque de rigueur

  • Je n’avais pas envie d’en faire un commentaire de premier niveau non plus, mais en ouvrant l’article, je suis tombé sur de simples clichés de LLM, et j’ai un peu regretté le temps passé à lire le début
  • Pour quelqu’un qui a un peu utilisé des outils d’observabilité, l’article m’a semblé assez clair et raisonnable
    L’idée centrale est que chaque produit passe à l’échelle différemment, et il montre avec des tableaux et des explications concrètes ce qui se passe à chaque ordre de grandeur
    Si tu as vu un passage où la réflexion est manifestement abandonnée, je serais curieux d’avoir un exemple
  • Matthew connaît au minimum assez bien l’observabilité. Il a été tech lead chez Braintree et il est maintenant Principal chez SYBO, connu pour Subway Surfers
    Les passages avec des grossièretés laissent aussi transparaître en partie sa propre voix
    En le passant dans GPTZero, on obtient tout de même 71 % de probabilité LLM et 28 % mixte. Cela dit, à cause de la limite de caractères, l’introduction, qui se lisait comme la partie la plus humaine, a été coupée
    Je comprends la réaction de rejet, mais cela ressemble plutôt à un texte effectivement relu et retravaillé, sans filtrage des tournures trop LLM ni optimisation du ton. Désormais, se contenter de ne pas utiliser d’em dash ne suffit plus à éviter l’odeur

• Pour les personnes qui ont de l’expérience avec Honeycomb, je serais curieux de savoir comment il s’insère dans ce contexte
  D’après ce que je sais, Honeycomb utilise aussi un format de stockage en colonnes et s’appuie beaucoup sur la compression et le bucketing pour sauter de gros volumes de données à la lecture. Je ne crois pas qu’il fonctionne avec des index inversés comme Elastic ou Datadog, et il me semble que Datadog fait tourner Elastic en interne

  • Je me souviens qu’il y a quelques années, Charity Majors, cofondatrice de Honeycomb, avait dit sur Twitter que si ClickHouse avait existé au moment où elle a lancé l’entreprise, ils l’auraient probablement simplement utilisé
    Je ne sais toutefois pas dans quelle mesure les deux systèmes se recoupent vraiment conceptuellement. Il serait intéressant de savoir si le domaine du problème menait naturellement à une approche similaire, et personnellement je m’attendrais à ce que ce soit le cas

• Cela mettra peut-être certaines personnes mal à l’aise, mais l’usage de certains mots m’a paru tellement distrayant que j’ai simplement fait un rechercher-remplacer pour les remplacer par des termes qui ne me dérangeaient pas, et le texte est devenu bien meilleur
  Je ne dirai pas de quels mots il s’agissait, mais ce sont des expressions de plus en plus utilisées de façon imprécise, et elles m’agacent. C’était agréable de pouvoir rendre l’article plus lisible avec une simple recherche-remplacement