1. Exploiter ClickHouse #
Les points d'attention.
Production #
| Sujet | Recommandation |
|---|---|
| Réplication | ReplicatedMergeTree sur au moins deux réplicas, ClickHouse Keeper pour la coordination |
| Disques | SSD pour les données récentes, stockage objet (S3) pour l'ancien via les politiques de stockage |
| Insertion | Par lots (processeur batch du Collector, ou insertions asynchrones) : éviter les milliers de petites insertions |
| Fusions | Surveiller le nombre de parties actives : trop de parties ralentit tout |
| Rétention | TTL par table, différente selon le signal (logs 14 j, traces 7 j, métriques 13 mois) |
-- Santé : parties actives par table et requêtes lentes
SELECT table, count() AS parties FROM system.parts WHERE active GROUP BY table ORDER BY parties DESC LIMIT 5;
SELECT query_duration_ms, substring(query, 1, 80) FROM system.query_log
WHERE type = 'QueryFinish' ORDER BY query_duration_ms DESC LIMIT 5;2. Choisir #
Selon l'équipe et l'existant.
Comparatif #
| Critère | SigNoz | ClickStack | Stack Grafana (LGTM) | Elastic |
|---|---|---|---|---|
| Stockage | ClickHouse | ClickHouse | Objet (Loki, Tempo, Mimir) | Elasticsearch |
| Expérience APM intégrée | Forte | Bonne | Bonne (Grafana) | Forte |
| Haute cardinalité | Très bonne | Très bonne | Limitée dans les labels | Bonne |
| Langage | Query builder, SQL, PromQL | Lucene, SQL | PromQL, LogQL, TraceQL | KQL, ES|QL |
| Composants à exploiter | Peu (ClickHouse est le cœur) | Peu | Plusieurs bases | Un cluster Elasticsearch |
Bonne Pratique : Si vos équipes connaissent SQL et ont besoin d'analyses à haute cardinalité (par client, par utilisateur), une plateforme ClickHouse est très pertinente. Si vous êtes déjà sur Grafana, ses bases spécialisées restent souvent le chemin le plus simple.
