ClickStack – une alternative open source à Datadog construite avec ClickHouse et HyperDX

• ClickStack est une plateforme d’observabilité open source basée sur ClickHouse et HyperDX, qui unifie en un seul endroit les logs, métriques, traces et session replay
• La recherche et la visualisation des logs et des traces sont prises en charge facilement et rapidement sur un cluster ClickHouse, avec prise en charge de n’importe quel schéma sans travail supplémentaire
• Elle propose une recherche intuitive, des alertes basées sur les événements et des tableaux de bord pour permettre aux ingénieurs d’identifier et de traiter rapidement les problèmes
• Prise en charge native du standard OpenTelemetry, avec intégration SDK pour de nombreux langages et plateformes
• Par rapport aux solutions commerciales existantes, elle est moins coûteuse et plus simple à configurer, et permet d’effectuer tout le workflow sur une seule plateforme sans avoir à naviguer entre plusieurs outils d’observabilité

Fonctionnalités principales

• Possibilité d’effectuer en un seul endroit l’analyse de corrélation et la recherche sur les logs, métriques, session replay et traces
• Réutilise tel quel le schéma existant de ClickHouse, avec une architecture indépendante du schéma
• Adaptée aux grands volumes de données grâce à une recherche rapide et à une visualisation optimisée
• Prise en charge à la fois de la recherche plein texte et par attributs, avec utilisation de SQL en option
• Analyse des évolutions d’événements, configuration simple des alertes et création de tableaux de bord
• Prise en charge des requêtes en chaînes JSON natives
• Possibilité de consulter les événements les plus récents grâce aux fonctions de tail en temps réel des logs et des traces
• Intégration OpenTelemetry et prise en charge d’un environnement APM (monitoring des performances)

Déploiement et prise en main

• Le package ClickStack permet un déploiement unifié incluant ClickHouse, HyperDX, OpenTelemetry Collector et MongoDB
• L’interface HyperDX est accessible depuis le navigateur
• Il peut aussi s’intégrer à un environnement ClickHouse Cloud et se déployer facilement dans différents contextes

Instrumentation et intégration des applications

Pour collecter avec HyperDX les données de logs, métriques, traces et session replay, l’application doit envoyer ses données de télémétrie à HyperDX

• SDK et options d’intégration disponibles : des SDK pour navigateur, Node.js, Python et d’autres langages/environnements permettent une intégration facile
• Prise en charge du standard OpenTelemetry : compatibilité avec Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust et divers runtimes
• Le collecteur OpenTelemetry est accessible par défaut à l’adresse http://localhost:4318

Comment contribuer

• Les contributions de la communauté sont bienvenues sous diverses formes : soumission de PR, ouverture d’issues, amélioration de la documentation, vote sur les issues ouvertes, proposition de nouveaux cas d’usage, etc.

Motivation et philosophie du projet

L’objectif de l’équipe HyperDX est de permettre à tous les ingénieurs de résoudre rapidement les problèmes en exploitant la télémétrie des environnements de production

Principaux problèmes existants :

• Les outils d’observabilité en production sont coûteux, avec des dépenses qui augmentent à mesure que les volumes de données s’étendent
• La configuration et l’utilisation sont complexes, ce qui nécessite des SRE et des spécialistes
• Les différentes fonctions comme les logs, le session replay ou l’APM sont séparées, ce qui complique le rapprochement des informations

Pour surmonter ces limites, ClickStack et HyperDX sont proposés en open source

• HyperDX a été acquis par ClickHouse

[GN⁺]

Réactions sur Hacker News

• Interrogation sur le choix de créer un frontend sur mesure au lieu d’utiliser Grafana, qui existe déjà

• Partage du fait que les prix de DataDog sont élevés, ce qui rend HyperDX vraiment attractif ; LogLayer (https://loglayer.dev), qu’il exploite, est un logger structuré pour TypeScript capable d’envoyer des logs vers plusieurs types de loggers et services cloud (dont DataDog). Il indique développer une intégration pour HyperDX, avec une sortie prévue prochainement, souhaite ajouter sur son site un lien vers la documentation d’intégration HyperDX dans la section « integrations », et partage la PR associée (https://github.com/hyperdxio/hyperdx-js/pull/184)

  • Demande d’ajouter aussi la possibilité d’envoyer les logs vers VictoriaLogs, avec en suggestion le lien vers la documentation des différents protocoles d’ingestion de données (https://docs.victoriametrics.com/victorialogs/data-ingestion/)
  • Retour positif indiquant que l’intégration entre LogLayer et HyperDX a l’air très réussie et qu’elle sera testée directement

• Utilisation réelle de HyperDX en production, avec une forte satisfaction concernant l’intégration avec ClickHouse et l’efficacité en termes de coûts ; question sur la nécessité de préparer une migration de HyperDX vers ClickStack

  • Réponse chaleureuse indiquant que les retours d’utilisateurs en production sont toujours très attendus ; explication que HyperDX ne disparaîtra absolument pas et qu’il reste présenté comme un composant central de la stack sur la page marketing. À l’avenir, l’équipe prévoit de se concentrer davantage sur HyperDX v2 et le modèle ClickStack, mais HyperDX continuera à mettre l’accent sur l’expérience utilisateur finale. Objectif supplémentaire : exploiter plus largement la flexibilité et les performances du cœur basé sur ClickHouse. Partage aussi du fait que l’ingénierie se concentre sur une transition fluide, à la fois en open source et dans le cloud, avec en aparté une mention d’une réponse tardive due à un Wi‑Fi récemment instable

• Partage du sentiment que les traces et logs d’OTel sont corrects, mais que la fonctionnalité de métriques OTel semble conçue de manière trop complexe ; questions sur la capacité de ClickStack à ingérer des données statsd (notamment avec les extensions de tags de Datadog), sur la corrélation et le lien de tags de service entre traces/logs/métriques, sur l’existence de liens de données associées dans l’UI, sur la raison pour laquelle le SDK Elixir utilise la bibliothèque hyperdx, et sur la présence de la fonctionnalité Notebooks dans la roadmap

  • Réponse saluant la qualité des questions et partageant le constat que la norme des métriques OTel est devenue très vaste, avec les frustrations que cela implique ; précision que le collector OTel peut recevoir de nombreux formats comme statsd et écrire directement dans ClickHouse, ce qui permet donc d’utiliser statsd (lien vers la documentation statsdreceiver). Les logs et traces peuvent être reliés via les trace/span id et les resource attributes, et dans les workloads k8s, une corrélation avec les métriques est également fournie. La corrélation de métriques via la fonctionnalité exemplars n’est pas encore prise en charge, mais c’est prévu. Le SDK Elixir a été choisi dans une logique de support adapté à l’environnement des utilisateurs ; la bibliothèque a évolué de façon indépendante, et une transition future vers le SDK OTel officiel est à l’étude. Un exemple est aussi donné d’intégration OTel rapidement mise en place directement pour Deno. Notebooks devrait être publié prochainement à l’état expérimental afin d’activer différents workflows, et l’équipe dit être intéressée par davantage de retours utilisateurs
  • Question en retour sur les raisons qui font percevoir les métriques OTel comme complexes, avec la précision qu’un avantage est justement de ne pas avoir à remplacer facilement des pipelines de métriques existants comme statsd ou l’agent DD

• Avis selon lequel HyperDX ressemble à Signoz, notamment parce qu’il est lui aussi basé sur ClickHouse et propose des versions open source et cloud, avec une curiosité sur les différences ; observation également que l’UI semble similaire

  • Curiosité supplémentaire : envie d’entendre une comparaison plus directe avec Signoz

• Recherche d’une nouvelle solution de logging pour remplacer Kibana, avec un intérêt pour l’UI de HyperDX en raison d’une bonne expérience avec ClickHouse ; partage d’un pipeline de logs actuel basé sur Vector sur Kubernetes, Vector prenant en charge un sink OTel (bêta), et réflexion sur la meilleure manière d’envoyer les logs lorsque les données sont en JSON ; insistance sur un environnement à très gros volume, de l’ordre du téraoctet, et à hautes performances

  • Réponse indiquant que ClickHouse est particulièrement adapté aux gros volumes et aux débits élevés, avec mention de cas d’usage où Vector écrit directement dans ClickHouse (par exemple une présentation d’Anthropic), et proposition d’essayer puis de laisser un retour pour obtenir de l’aide
  • Avis selon lequel standardiser le format de transport des données sur otel est un bon choix stratégique pour l’avenir, avec le sentiment que cela réduit deux préoccupations d’un coup

• Question sur les différences entre Signoz et HyperDX (ou ClickHouse), avec observation que les deux viennent de YC et utilisent ClickHouse

  • Réponse expliquant que, comme mentionné plus bas, le plus grand facteur de différenciation est qu’il s’agit d’un produit 1st-party officiellement développé par l’équipe ClickHouse, capable de fonctionner avec souplesse sur presque toutes les instances ClickHouse et de prendre en charge des schémas personnalisés. C’est important pour les optimisations hautes performances ou certains environnements très grande échelle (par exemple Anthropic). Si l’on possède déjà des données dans ClickHouse, l’adoption est très simple. OTel n’est pas imposé à tout prix, et Vector, Cribl, S3, des scripts personnalisés, etc. sont aussi pris en charge nativement. Il existe aussi des fonctions de telemetry wrangling (deltas d’événements à haute cardinalité, clustering automatique de logs/spans basé sur le ML, etc.) qui facilitent l’exploration des données. La fonctionnalité session replay permet une intégration globale, des clics utilisateur jusqu’aux métriques d’infrastructure. Le système est exploité à une échelle de 100PB+ pour la supervision interne de ClickHouse Cloud, avec la flexibilité nécessaire pour analyser de bout en bout jusqu’aux problèmes d’utilisateurs spécifiques. Sur le plan philosophique, l’idée partagée est qu’au lieu de séparer les « 3 piliers » classiques (logs/métriques/traces), il est plus adapté au débogage réel de construire un outil unifié et centralisé pour l’exploration des indices
  • Précision que « You » désigne ClickHouse

• Après inscription, partage d’une expérience UX jugée déroutante : le widget « Was this search result helpful? » s’affichait dans l’UI avant même toute recherche ; découverte d’un bug où cliquer sur Hide fait apparaître le bouton de feedback, puis cliquer de nouveau sur ce feedback rétablit l’état initial ; critique générale sur une police globalement monospace et trop petite, ainsi que sur l’association de blanc gras et de vert clair avec le fond sombre, jugée peu harmonieuse ; constat que même le passage à une police système n’améliore pas beaucoup la situation, avec recommandation d’un style d’UI plus traditionnel ; retour indiquant que ce design difficile à lire donne hésitation à utiliser le produit

• Question sur le fait de savoir si ClickHouse est l’unique composant stateful de cette stack ; intérêt pour la compatibilité avec Rotel, un collector OTEL en Rust (https://github.com/streamfold/rotel) ; mention que Datadog dispose de son propre remplaçant du collector OTEL, développé en interne et plus performant

  • Réponse indiquant que Rotel semble bien adapté à l’intégration OTel dans des environnements légers comme lambda ; comme le point d’ingestion OTel de HyperDX est déjà standard, la compatibilité devrait être immédiate. Il est aussi indiqué que des échanges ont eu lieu avec les développeurs de Rotel, et que l’ajout récent du support ClickHouse rend l’ensemble de l’histoire encore plus cohérent