Surveiller une infrastructure en production exige de disposer de données fiables, actualisées et faciles à interpréter. L’association de ClickHouse et Grafana permet de construire un système de monitoring capable d’exploiter d’importants volumes de métriques.
Accéder à un dashboard temps réel est plus facile avec la combinaison de ClickHouse et Grafana. Les données techniques fournies par une infrastructure seront transformées en indicateurs exploitables par les équipes DevOps, SRE et les administrateurs système. Lorsqu’une application traite des millions d’événements, suivre les temps de réponse, les erreurs HTTP ou la consommation CPU devient rapidement compliqué.
ClickHouse répond à ce problème grâce à son architecture analytique en colonnes. L’outil est optimisé pour les agrégations rapides sur de grands volumes de données. De son côté, Grafana apporte une interface de visualisation capable de présenter ces métriques sous forme de courbes. Vous pouvez aussi apercevoir des jauges et des tableaux interactifs.
Dashboard temps réel ClickHouse et Grafana : pourquoi cette combinaison s’impose ?
ClickHouse est un système de gestion de bases de données orienté colonnes. En principe, il stocke les valeurs d’une même colonne de manière rapprochée. Avec cette organisation, une requête qui calcule la latence moyenne d’un service n’a pas besoin de lire toutes les informations.
Notez comme exemple une table avec de nombreux logs applicatifs. Elle peut stocker un horodatage, un identifiant de service, un code HTTP, une durée d’exécution et une adresse IP. Pour calculer le nombre d’erreurs 5xx par minute, ClickHouse peut se concentrer sur les colonnes temporelles et les codes de réponse. Ainsi, les autres champs ne sont pas nécessairement chargés pendant cette opération.
D’un autre côté, Grafana intervient ensuite pour exploiter ces résultats. Le logiciel se connecte à ClickHouse par l’intermédiaire de son plugin dédié. Il exécute aussi des requêtes SQL pour alimenter les panneaux du dashboard. Les résultats peuvent représenter les points suivants :
- Le taux d’erreurs HTTP 4xx et 5xx par service et par période.
- Les latences p50, p95 et p99 des requêtes applicatives.
- La consommation CPU, mémoire et espace disque des serveurs.
- Le nombre de requêtes traitées, de connexions actives et d’événements ingérés.
L’intérêt de cette association ne se limite pas à l’affichage des métriques. Elle facilite la corrélation entre plusieurs indicateurs. Une augmentation de la latence p95 peut être rapprochée d’une hausse de la consommation CPU ou d’un pic d’erreurs SQL. Les équipes disposent alors d’une vision plus précise du comportement de leur infrastructure. Elles peuvent identifier les services concernés, comparer les périodes et orienter leurs investigations sans parcourir manuellement des milliers de lignes de journaux.
Quelle architecture pour un dashboard temps réel avec ClickHouse et Grafana ?
Une architecture de monitoring performante doit séparer la collecte des événements, leur stockage, leur traitement et leur visualisation. Cette organisation évite de faire porter toutes les opérations à ClickHouse et limite les interactions inutiles entre les composants. Dans un environnement de production, le flux peut commencer avec les applications, les serveurs ainsi que les différents services distribués.
Les composants génèrent des métriques, des logs et des événements techniques. Des agents de collecte comme Vector récupèrent les informations, les normalisent et les transmettent vers une couche d’ingestion. Kafka peut compléter ce dispositif lorsque les volumes deviennent importants ou que plusieurs consommateurs doivent exploiter les mêmes événements. Il joue le rôle de tampon entre les producteurs et ClickHouse. Si la base rencontre une indisponibilité temporaire, les événements peuvent rester dans le système de messagerie.
Le parcours des données suit généralement la logique suivante :
- Collecte : Vector récupère les logs et les métriques depuis les différentes sources. Il peut enrichir les événements avec des métadonnées comme le nom du service, l’environnement ou la région.
- Transport : Kafka répartit les messages entre les partitions et absorbe les variations de débit. Cette étape découple les applications productrices de la base analytique.
- Ingestion : ClickHouse reçoit les événements dans une table d’entrée. Une table utilisant le moteur Null peut servir de point de réception lorsqu’elle est associée à une vue matérialisée.
- Agrégation : les vues matérialisées alimentent des tables de destination adaptées aux indicateurs recherchés.
- Visualisation : Grafana interroge les tables agrégées et présente les résultats dans des panneaux actualisés périodiquement.
Comment connecter ClickHouse à Grafana proprement ?
La première étape consiste à installer une version du plugin compatible avec l’environnement Grafana utilisé. Dans une installation Docker, cette opération peut être intégrée au processus de construction ou au démarrage du conteneur. Il faut ensuite déclarer une nouvelle source de données dans la configuration de Grafana. Le choix du protocole dépend de l’architecture réseau. ClickHouse expose les interfaces suivants :
| Protocole | Port courant | Utilisation |
| HTTP | 8123 | Requêtes HTTP, intégration et échanges avec des outils externes |
| HTTPS | 8443 | Requêtes HTTP chiffrées |
| Native | 9000 | Communication native avec ClickHouse |
| Native sécurisé | 9440 | Communication native chiffrée |
Le mode HTTP ou HTTPS est adapté à une connexion Grafana qui passe par un proxy inverse ou un répartiteur de charge. Le protocole Native peut être intéressant lorsque le plugin et l’infrastructure utilisent explicitement cette méthode de communication.
Il faut ensuite renseigner les paramètres de connexion comme l’adresse du serveur, le port… Pour un environnement de production, il est préférable de ne pas utiliser le compte administrateur de ClickHouse. Un compte dédié en lecture seule peut accéder aux bases et aux tables nécessaires aux visualisations. Cette restriction réduit les risques de suppression accidentelle ou de modification des données pendant une opération de monitoring.
Le provisioning YAML permet d’automatiser la déclaration de la source de données. Au lieu de configurer chaque connexion depuis l’interface graphique, l’administrateur versione les paramètres dans un fichier chargé par Grafana. Une fois les paramètres renseignés, le test de connexion permet de vérifier que Grafana communique correctement avec ClickHouse. Un échec peut provenir d’un port inaccessible, d’un certificat TLS invalide ou d’un mauvais identifiant.
Comment concevoir des requêtes ClickHouse rapides pour Grafana ?
La qualité d’un dashboard dépend des requêtes SQL qui alimentent ses panneaux. Une mauvaise sélection des colonnes ou une absence de filtre temporel peut provoquer des lectures massives et ralentir l’ensemble du dispositif. Le premier élément à travailler est la clé ORDER BY des tables MergeTree. Elle détermine l’organisation physique des données et influence les possibilités de filtrage. Pour une table de monitoring, une clé composée de l’identifiant du service et de l’horodatage peut être pertinente.
Toutefois, il ne faut pas choisir cette clé au hasard. Elle doit refléter les requêtes réellement exécutées par Grafana. Une clé inadaptée peut obliger ClickHouse à parcourir davantage de marques de données avant de trouver les lignes recherchées. La clause WHERE constitue un autre levier essentiel. Chaque requête destinée à un dashboard devrait limiter son périmètre temporel lorsque cela est possible. Une sélection sur les quinze dernières minutes sera généralement moins coûteuse qu’une agrégation sur plusieurs mois.
Les macros temporelles du plugin ClickHouse pour Grafana facilitent cette opération. Elles permettent de transmettre automatiquement les bornes correspondant à la période sélectionnée par l’utilisateur. Il faut notamment vérifier la syntaxe prise en charge par la version du plugin installée. Pour aller plus loin, il est possible de calculer les centiles de latence. Les fonctions d’agrégation de ClickHouse permettent notamment d’obtenir des indicateurs p50, p95 ou p99. Ces mesures sont souvent plus pertinentes qu’une moyenne lorsque certaines requêtes connaissent des ralentissements importants.
Quels panels Grafana choisir pour un monitoring temps réel efficace ?
Un dashboard efficace ne doit pas afficher toutes les métriques disponibles sur un seul écran. ll doit sélectionner les indicateurs qui permettent de comprendre rapidement l’état du système et repérer les anomalies qui nécessitent une intervention. Le panneau Stat convient aux valeurs synthétiques. Il peut afficher la disponibilité d’un service, le nombre d’erreurs sur une période ou le nombre de requêtes actives. Les seuils permettent d’associer une couleur à chaque niveau de risque. Une disponibilité de 99,9 % peut être présentée comme un objectif de service, sans être considérée comme une valeur universelle.
Le panneau Gauge est particulièrement adapté aux mesures exprimées sous forme de progression ou de capacité utilisée. Il permet de visualiser la consommation CPU, l’utilisation mémoire ou le remplissage d’un espace disque. Ainsi, les seuils doivent être définis en fonction des caractéristiques de l’infrastructure.
Le panneau Time Series reste incontournable pour analyser les évolutions temporelles. Il permet de comparer plusieurs courbes sur un même axe comme la latence p95 et le nombre de requêtes. Cette représentation facilite l’identification des corrélations entre les événements. Pour les équipes chargées des performances applicatives, trois indicateurs méritent une attention particulière :
- La latence p50 : elle représente le temps de réponse médian et donne une idée du comportement habituel de l’application.
- La latence p95 : elle indique le seuil sous lequel se situent 95 % des requêtes et permet de repérer les ralentissements qui touchent une partie des utilisateurs.
- La latence p99 : elle met en évidence les requêtes les plus lentes et aide à identifier les problèmes intermittents.
Comment rendre le dashboard réellement exploitable par les équipes ?
Un dashboard techniquement performant n’est pas toujours un dashboard facile à utiliser. Pour qu’il devienne un outil quotidien, sa présentation doit correspondre aux besoins des personnes qui l’utilisent. Cela concerne par exemple la direction technique, l’administrateur système ou les ingénieurs d’astreinte.
La première règle consiste à organiser les informations selon leur niveau de détail. Une vue générale doit permettre de savoir immédiatement si l’infrastructure fonctionne normalement. Les informations plus techniques doivent rester accessibles sans encombrer l’écran principal. Une organisation en trois niveaux peut répondre à cette exigence.
La supervision globale rassemble les indicateurs les plus importants, y compris les disponibilités. Elle intègre également la disponibilité des applications et l’état des principaux services. Elle s’adresse notamment aux responsables techniques qui souhaitent évaluer rapidement la santé de la plateforme.
La deuxième vue concerne le diagnostic opérationnel. Elle présente les latences p95 et p99, les services les plus sollicités. Prenez aussi en compte les erreurs par environnement et les consommations de ressources. Les ingénieurs peuvent l’utiliser pour localiser l’origine d’une anomalie. En outre, la troisième vue approfondit l’analyse technique. Elle rassemble les journaux, les traces distribuées, les requêtes lentes et les informations détaillées sur les composants concernés.
- Partager l'article :
