Ce guide s’adresse aux utilisateurs existants de ClickHouse Cloud. Si vous découvrez ClickHouse Cloud, nous vous recommandons notre guide de prise en main pour Managed ClickStack.
Dans ce modèle de déploiement, ClickHouse et l’interface utilisateur de ClickStack (HyperDX) sont tous deux hébergés dans ClickHouse Cloud, ce qui réduit au minimum le nombre de composants que l’utilisateur doit auto-héberger.
En plus d’alléger la gestion de l’infrastructure, ce modèle de déploiement garantit que l’authentification est intégrée au SSO/SAML de ClickHouse Cloud. Contrairement aux déploiements auto-hébergés, il n’est pas non plus nécessaire de provisionner une instance MongoDB pour stocker l’état de l’application — comme les tableaux de bord, les recherches enregistrées, les paramètres utilisateur et les alertes. Les utilisateurs bénéficient également de :
- La mise à l’échelle automatique des ressources de calcul, indépendamment du stockage
- Une rétention à faible coût et pratiquement illimitée grâce au stockage objet
- La possibilité d’isoler indépendamment les charges de travail de lecture et d’écriture avec les Warehouses.
- Une authentification intégrée
- Des sauvegardes automatisées
- Des fonctionnalités de sécurité et de conformité
- Des mises à niveau transparentes
Dans ce mode, l’ingestion des données est entièrement à la charge de l’utilisateur. Vous pouvez ingérer des données dans Managed ClickStack à l’aide de votre propre OpenTelemetry Collector hébergé, par ingestion directe depuis des bibliothèques clientes, des moteurs de table natifs de ClickHouse (tels que Kafka ou S3), des pipelines ETL ou ClickPipes — le service d’ingestion géré de ClickHouse Cloud. Cette approche offre le moyen le plus simple et le plus performant d’exploiter ClickStack.
Ce modèle de déploiement est idéal dans les scénarios suivants :
- Vous disposez déjà de données d’observabilité dans ClickHouse Cloud et souhaitez les visualiser avec ClickStack.
- Vous exploitez déjà un déploiement d’observabilité à grande échelle et avez besoin des performances et de la scalabilité dédiées de ClickStack sur ClickHouse Cloud.
- Vous utilisez déjà ClickHouse Cloud pour l’analytique et souhaitez instrumenter votre application à l’aide des bibliothèques d’instrumentation de ClickStack, en envoyant les données vers le même cluster. Dans ce cas, nous recommandons d’utiliser les warehouses afin d’isoler les ressources de calcul des charges de travail d’observabilité.
Ce guide suppose que vous avez déjà créé un service ClickHouse Cloud. Si ce n’est pas encore fait, suivez le guide Prise en main pour Managed ClickStack. Vous obtiendrez ainsi un service dans le même état que celui décrit dans ce guide, c’est-à-dire prêt à recevoir des données d’observabilité avec ClickStack activé.
Créer un nouveau service
Sur la page d’accueil de ClickHouse Cloud, sélectionnez New service pour créer un nouveau service.Indiquez votre fournisseur, votre région et votre ressource
Scale vs EnterpriseNous recommandons ce niveau Scale pour la plupart des charges de travail ClickStack. Choisissez le niveau Enterprise si vous avez besoin de fonctionnalités de sécurité avancées comme SAML, CMEK ou la conformité HIPAA. Il propose également des profils matériels personnalisés pour les déploiements ClickStack de très grande envergure. Dans ce cas, nous vous recommandons de contacter le support. 
Lorsque vous indiquez les CPU et la mémoire, estimez-les en fonction de votre débit d’ingestion ClickStack attendu. Le tableau ci-dessous fournit des repères pour dimensionner ces ressources.| Volume d’ingestion mensuel | Capacité de calcul recommandée |
|---|
| < 10 TB / mois | 2 vCPU × 3 répliques |
| 10–50 TB / mois | 4 vCPU × 3 répliques |
| 50–100 TB / mois | 8 vCPU × 3 répliques |
| 100–500 TB / mois | 30 vCPU × 3 répliques |
| 1 PB+ / mois | 59 vCPU × 3 répliques |
- Le volume de données correspond au volume d’ingestion non compressé par mois et s’applique aussi bien aux logs qu’aux traces.
- Les modèles de requêtes sont typiques des cas d’usage d’observabilité, la plupart des requêtes portant sur des données récentes, généralement des 24 dernières heures.
- L’ingestion est relativement uniforme sur l’ensemble du mois. Si vous prévoyez un trafic irrégulier ou des pics, vous devez prévoir une marge de capacité supplémentaire.
- Le stockage est géré séparément via le stockage objet ClickHouse Cloud et ne constitue pas un facteur limitant pour la rétention. Nous partons du principe que les données conservées plus longtemps sont rarement consultées.
Des ressources de calcul supplémentaires peuvent être nécessaires pour des modes d’accès qui interrogent régulièrement des intervalles de temps plus longs, effectuent des agrégations lourdes ou prennent en charge un grand nombre d’utilisateurs simultanés.Bien que deux répliques puissent répondre aux exigences de CPU et de mémoire pour un débit d’ingestion donné, nous recommandons d’utiliser trois répliques lorsque cela est possible afin d’obtenir la même capacité totale et d’améliorer la redondance du service.Ces valeurs sont uniquement des estimations et doivent être utilisées comme point de départ. Les besoins réels dépendent de la complexité des requêtes, de la concurrence, des politiques de rétention et de la variabilité du débit d’ingestion. Surveillez toujours l’utilisation des ressources et adaptez le dimensionnement si nécessaire.
Une fois votre service provisionné, assurez-vous que ce service est sélectionné, puis cliquez sur “ClickStack” dans le menu de gauche.
Sélectionnez “Start Ingestion” et vous serez invité à choisir une source d’ingestion. Managed ClickStack prend en charge OpenTelemetry et Vector comme principales sources d’ingestion. Les utilisateurs peuvent toutefois aussi envoyer des données directement vers ClickHouse selon leur propre schéma, à l’aide de l’une des intégrations prises en charge par ClickHouse Cloud.
OpenTelemetry recommandéL’utilisation d’OpenTelemetry est fortement recommandée pour l’ingestion.
Il offre l’expérience la plus simple et la plus optimisée, avec des schémas prêts à l’emploi spécialement conçus pour fonctionner efficacement avec ClickStack.
Pour envoyer des données OpenTelemetry à Managed ClickStack, il est recommandé d’utiliser un OpenTelemetry Collector. Le collector agit comme une passerelle : il reçoit les données OpenTelemetry de vos applications (et d’autres collectors) et les transmet à ClickHouse Cloud.Si vous n’avez pas déjà un collector en cours d’exécution, démarrez-en un en suivant les étapes ci-dessous. Si vous disposez déjà de collectors, un exemple de configuration est également fourni.Démarrer un collector
La suite de cette procédure part du principe que vous utilisez l’option recommandée, à savoir la distribution ClickStack de l’OpenTelemetry Collector, qui inclut des traitements supplémentaires et est spécifiquement optimisée pour ClickHouse Cloud. Si vous souhaitez utiliser votre propre OpenTelemetry Collector, consultez « Configurer des collectors existants »Pour démarrer rapidement, copiez et exécutez la commande Docker affichée.
Cette commande doit déjà contenir vos identifiants de connexion préremplis.Déploiement en productionBien que cette commande utilise l’utilisateur default pour se connecter à Managed ClickStack, vous devriez créer un utilisateur dédié lors du passage en production et modifier votre configuration. Démarrer l’ingestion (facultatif)
Si vous avez des applications ou une infrastructure existantes à instrumenter avec OpenTelemetry, accédez aux guides correspondants depuis l’UI.Pour instrumenter vos applications afin de collecter des traces et des logs, utilisez les SDKs de langages pris en charge, qui envoient les données à votre OpenTelemetry Collector, lequel agit comme une passerelle pour l’ingestion dans Managed ClickStack.Les logs peuvent être collectés à l’aide d’OpenTelemetry Collectors exécutés en mode agent, qui transmettent les données au même collector. Pour le monitoring Kubernetes, suivez le guide dédié. Pour les autres intégrations, consultez nos guides de démarrage rapide.Données de démonstration
Sinon, si vous n’avez pas de données existantes, essayez l’un de nos jeux de données d’exemple.
- Jeu de données d’exemple - Chargez un jeu de données d’exemple depuis notre démo publique. Diagnostiquez un problème simple.
- Fichiers locaux et métriques - Chargez des fichiers locaux et surveillez le système sur OSX ou Linux à l’aide d’un collector OTel local.
Vector est un pipeline de données d’observabilité haute performance, indépendant des fournisseurs, particulièrement apprécié pour l’ingestion de logs grâce à sa flexibilité et à sa faible empreinte en ressources.Lorsque vous utilisez Vector avec ClickStack, vous devez définir vos propres schémas. Ces schémas peuvent suivre les conventions OpenTelemetry, mais ils peuvent aussi être entièrement personnalisés pour représenter des structures d’événements définies par l’utilisateur.Timestamp requisLa seule exigence stricte pour Managed ClickStack est que les données incluent une colonne timestamp (ou un champ temporel équivalent), qui peut être déclarée lors de la configuration de la source de données dans l’UI ClickStack.
Créer une base de données et une table
Vector exige qu’une table et un schéma soient définis avant l’ingestion des données.Créez d’abord une base de données. Vous pouvez le faire via la ClickHouse Cloud console.Par exemple, créez une base de données pour les logs :CREATE DATABASE IF NOT EXISTS logs
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);
Pour plus d’exemples sur l’ingestion de données avec Vector, consultez “Ingestion avec Vector” ou la documentation du sink ClickHouse de Vector pour les options avancées. Accéder à l’interface de ClickStack
Sélectionnez « Launch ClickStack » pour accéder à l’interface ClickStack (HyperDX). Vous serez automatiquement authentifié, puis redirigé.Des sources de données seront automatiquement créées pour toutes les données OpenTelemetry.
Si vous utilisez Vector, vous devrez créer vos propres sources de données. Il vous sera demandé d’en créer une lors de votre première connexion. Ci-dessous, nous montrons un exemple de configuration pour une source de données de logs.
Cette configuration suppose un schéma de type Nginx avec une colonne time_local utilisée comme horodatage. Idéalement, il doit s’agir de la colonne d’horodatage déclarée dans la clé primaire. Cette colonne est obligatoire.Nous vous recommandons également de mettre à jour Default SELECT afin de définir explicitement quelles colonnes sont renvoyées dans la vue des logs. Si des champs supplémentaires sont disponibles, comme le nom du service, le niveau de log ou une colonne body, ils peuvent aussi être configurés. La colonne d’affichage de l’horodatage peut également être redéfinie si elle diffère de la colonne utilisée dans la clé primaire de la table et configurée ci-dessus.Dans l’exemple ci-dessus, il n’existe pas de colonne Body dans les données. À la place, elle est définie à l’aide d’une expression SQL qui reconstitue une ligne de log Nginx à partir des champs disponibles.Pour connaître les autres options possibles, consultez la référence de configuration.Une fois la source créée, vous devriez être redirigé vers la vue de recherche, où vous pourrez immédiatement commencer à explorer vos données. Sélectionner un service
Depuis la page d’accueil de ClickHouse Cloud, sélectionnez le service pour lequel vous souhaitez activer Managed ClickStack.Estimation des ressourcesCe guide suppose que vous avez provisionné suffisamment de ressources pour prendre en charge le volume de données d’observability que vous prévoyez d’ingérer et d’interroger avec ClickStack. Pour estimer les ressources nécessaires, consultez le guide Estimating Resources.Si votre service ClickHouse héberge déjà d’autres charges de travail, comme de l’analytics applicatif en temps réel, nous vous recommandons de créer un service enfant à l’aide de la fonctionnalité warehouses de ClickHouse Cloud afin d’isoler la charge de travail d’observability. Cela garantit que vos applications existantes ne seront pas perturbées, tout en gardant les jeux de données accessibles depuis les deux services. Accédez à la ClickStack UI
Sélectionnez ‘ClickStack’ dans le menu de navigation de gauche. Vous serez redirigé vers la ClickStack UI et authentifié automatiquement selon vos permissions ClickHouse Cloud.Si des tables OpenTelemetry existent déjà dans votre service, elles seront détectées automatiquement et les sources de données correspondantes seront créées.Détection automatique des sources de donnéesLa détection automatique s’appuie sur le schéma de table OpenTelemetry standard fourni par la distribution ClickStack du collector OpenTelemetry. Des sources sont créées pour la base de données qui dispose de l’ensemble de tables le plus complet. Des tables supplémentaires peuvent être ajoutées comme sources de données distinctes si nécessaire. Si la détection automatique échoue ou si vous n’avez aucune table existante, vous serez invité à configurer l’ingestion.Sélectionnez “Start Ingestion” et vous serez invité à choisir une source d’ingestion. Managed ClickStack prend en charge OpenTelemetry et Vector comme principales sources d’ingestion. Les utilisateurs sont également libres d’envoyer des données directement à ClickHouse dans leur propre schéma en utilisant l’une des intégrations compatibles avec ClickHouse Cloud.OpenTelemetry recommandéL’utilisation d’OpenTelemetry comme format d’ingestion est fortement recommandée.
Il offre la solution la plus simple et la plus optimisée, avec des schémas prêts à l’emploi spécialement conçus pour fonctionner efficacement avec ClickStack.
Pour envoyer des données OpenTelemetry à Managed ClickStack, il est recommandé d’utiliser un OpenTelemetry Collector. Le collecteur agit comme une passerelle : il reçoit les données OpenTelemetry de vos applications (et d’autres collecteurs) et les transmet à ClickHouse Cloud.Si vous n’en avez pas déjà un en cours d’exécution, démarrez un collecteur en suivant les étapes ci-dessous. Si vous avez déjà des collecteurs en place, un exemple de configuration est également fourni.Démarrer un collecteur
La procédure ci-dessous suit l’approche recommandée, qui consiste à utiliser la distribution ClickStack de l’OpenTelemetry Collector, laquelle inclut un traitement supplémentaire et est optimisée spécifiquement pour ClickHouse Cloud. Si vous souhaitez utiliser votre propre OpenTelemetry Collector, consultez “Configurer des collecteurs existants.”Pour démarrer rapidement, copiez et exécutez la commande Docker affichée.Modifiez cette commande avec les identifiants de votre service, enregistrés lors de la création de celui-ci.Déploiement en productionBien que cette commande utilise l’utilisateur default pour se connecter à Managed ClickStack, vous devez créer un utilisateur dédié lors du passage en production et modifier votre configuration. receivers:
otlp/hyperdx:
protocols:
grpc:
include_metadata: true
endpoint: "0.0.0.0:4317"
http:
cors:
allowed_origins: ["*"]
allowed_headers: ["*"]
include_metadata: true
endpoint: "0.0.0.0:4318"
processors:
batch:
memory_limiter:
# 80% of maximum memory up to 2G, adjust for low memory environments
limit_mib: 1500
# 25% of limit up to 2G, adjust for low memory environments
spike_limit_mib: 512
check_interval: 5s
connectors:
routing/logs:
default_pipelines: [logs/out-default]
error_mode: ignore
table:
- context: log
statement: route() where IsMatch(attributes["rr-web.event"], ".*")
pipelines: [logs/out-rrweb]
exporters:
debug:
verbosity: detailed
sampling_initial: 5
sampling_thereafter: 200
clickhouse/rrweb:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
logs_table_name: hyperdx_sessions
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
clickhouse:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
service:
pipelines:
traces:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
metrics:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/in:
receivers: [otlp/hyperdx]
exporters: [routing/logs]
logs/out-default:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/out-rrweb:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse/rrweb]
Démarrer l’ingestion (facultatif)
Si vous avez déjà des applications ou une infrastructure à instrumenter avec OpenTelemetry, consultez les guides pertinents accessibles depuis “Connecter une application”.Pour instrumenter vos applications afin de collecter des traces et des logs, utilisez les SDKs de langage pris en charge, qui envoient les données à votre OpenTelemetry Collector, lequel agit comme une passerelle pour l’ingestion dans Managed ClickStack.Les logs peuvent être collectés à l’aide d’OpenTelemetry Collectors exécutés en mode agent et transmis au même collecteur. Pour le monitoring Kubernetes, suivez le guide dédié. Pour les autres intégrations, consultez nos guides de démarrage rapide. Vector est un pipeline de données d’observabilité haute performance, indépendant des fournisseurs, particulièrement apprécié pour l’ingestion de logs grâce à sa flexibilité et à sa faible empreinte sur les ressources.Lorsque vous utilisez Vector avec ClickStack, vous devez définir vos propres schémas. Ces schémas peuvent suivre les conventions OpenTelemetry, mais ils peuvent aussi être entièrement personnalisés et représenter des structures d’événements définies par l’utilisateur.Horodatage requisLa seule exigence stricte pour Managed ClickStack est que les données incluent une colonne d’horodatage (ou un champ temporel équivalent), qui peut être déclarée lors de la configuration de la source de données dans la ClickStack UI.
Créer une base de données et une table
Vector exige qu’une table et un schéma soient définis avant l’ingestion des données.Commencez par créer une base de données. Vous pouvez le faire via la ClickHouse Cloud console.Par exemple, créez une base de données pour les logs :CREATE DATABASE IF NOT EXISTS logs
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);
Accédez à l’interface ClickStack
Une fois la configuration de l’ingestion terminée et l’envoi des données démarré, sélectionnez “Next”.Si vous avez ingéré des données OpenTelemetry à l’aide de ce guide, les sources de données sont créées automatiquement et aucune configuration supplémentaire n’est nécessaire. Vous pouvez commencer à explorer ClickStack immédiatement. Vous serez redirigé vers la vue Search avec une source automatiquement sélectionnée, afin de pouvoir commencer à interroger les données immédiatement.C’est tout — tout est prêt 🎉.
Si vous avez ingéré des données via Vector ou une autre source, vous serez invité à configurer la source de données.La configuration ci-dessus suppose un schéma de type Nginx avec une colonne time_local utilisée comme horodatage. Il doit s’agir, dans la mesure du possible, de la colonne d’horodatage déclarée dans la clé primaire. Cette colonne est obligatoire.Nous vous recommandons également de mettre à jour Default SELECT pour définir explicitement les colonnes renvoyées dans la vue des logs. Si des champs supplémentaires sont disponibles, comme le nom du service, le niveau de log ou une colonne body, ils peuvent également être configurés. La colonne d’affichage de l’horodatage peut aussi être remplacée si elle diffère de celle utilisée dans la clé primaire de la table et configurée ci-dessus.Dans l’exemple ci-dessus, il n’existe pas de colonne Body dans les données. Elle est à la place définie à l’aide d’une expression SQL qui reconstitue une ligne de log Nginx à partir des champs disponibles.Pour connaître les autres options possibles, consultez la référence de configuration.Une fois la source configurée, cliquez sur “Save” et commencez à explorer vos données.
- Accédez à votre service dans la console ClickHouse Cloud
- Accédez à Settings → SQL Console Access
- Définissez le niveau d’autorisation approprié pour chaque utilisateur :
- Service Admin → Full Access - Requis pour activer les alerts
- Service Read Only → Read Only - Permet de consulter les données d’observabilité et de créer des dashboards
- No access - Ne permet pas d’accéder à HyperDX
Les alerts nécessitent des droits d’administrateurPour activer les alerts, au moins un utilisateur disposant des permissions Service Admin (associées à Full Access dans la liste déroulante SQL Console Access) doit se connecter à HyperDX au moins une fois. Cela crée dans la base de données un utilisateur dédié qui exécute les requêtes d’alerts.
Utiliser ClickStack avec des ressources de calcul en lecture seule
- Si vous ouvrez ClickStack depuis un service en lecture seule, toutes les requêtes émises par l’interface utilisateur de ClickStack s’exécuteront sur cette ressource de calcul en lecture seule.
- Si vous ouvrez ClickStack depuis un service en lecture-écriture, ClickStack utilisera cette ressource de calcul à la place.
Aucune configuration supplémentaire dans ClickStack n’est nécessaire pour garantir le mode lecture seule.
Configuration recommandée
- Créez ou repérez un service ClickHouse Cloud dans le warehouse configuré en lecture seule.
- Dans la console ClickHouse Cloud, sélectionnez le service en lecture seule.
- Lancez ClickStack depuis le menu de navigation de gauche.
Une fois lancé, ClickStack UI s’associera automatiquement à ce service en lecture seule.
Ajouter d’autres sources de données
Utiliser les schémas OpenTelemetry
Table avec la valeur otel_logs afin de créer une source de logs. Tous les autres paramètres devraient être détectés automatiquement, ce qui vous permettra de cliquer sur Enregistrer la nouvelle source.
Pour créer des sources pour les traces et les métriques OTel, vous pouvez sélectionner Créer une nouvelle source dans le menu supérieur.
Sélectionnez ensuite le type de source requis, puis la table appropriée ; par exemple, pour les traces, sélectionnez la table otel_traces. Tous les paramètres devraient être détectés automatiquement.
Sources corréléesNotez que différentes sources de données dans ClickStack — comme les logs et les traces — peuvent être corrélées entre elles. Pour activer cette fonctionnalité, une configuration supplémentaire est nécessaire pour chaque source. Par exemple, dans la source de logs, vous pouvez spécifier une source de traces correspondante, et inversement dans la source de traces. Voir « Sources corrélées » pour plus de détails. Utiliser des schémas personnalisés
Choix du schéma : Map vs JSON
Map(LowCardinality(String), String). Il s’agit du schéma recommandé pour les charges de travail d’observabilité. Associé à la sérialisation de map compartimentée et à des index textuels sur les clés et les valeurs de la map, il permet des recherches sélectives sans la surcharge d’ingestion par clé propre aux sous-colonnes JSON dynamiques.
Un schéma de type JSON est disponible en bêta pour évaluation sur des charges de travail avec un ensemble réduit et stable de clés d’attributs. Il n’est pas recommandé par défaut. Consultez Map vs JSON type pour la comparaison complète et les variables d’environnement requises pour activer la prise en charge de JSON. 
