Set up docs MCPCe 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.
Convient à
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é.
Étapes de configuration
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
Sélectionnez le fournisseur Cloud et la région.
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 |
Ces recommandations reposent sur les hypothèses suivantes :
- 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.
Une fois vos besoins définis, le provisionnement de votre service Managed ClickStack prendra რამდენიმე minutes. N’hésitez pas à explorer le reste de la console ClickHouse Cloud pendant le provisionnement.
Une fois le provisionnement terminé, l’option 'ClickStack' dans le menu de gauche sera activée.
Configurer l’ingestion
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.
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.
L’exécution de cette seule commande démarre le ClickStack collector avec des endpoints OTLP exposés sur les ports 4317 (gRPC) et 4318 (HTTP). Si vous disposez déjà d’une instrumentation OpenTelemetry et d’agents, vous pouvez immédiatement commencer à envoyer des données de télémétrie vers ces endpoints.
Configurer des collectors existants
Vous pouvez également configurer vos propres OpenTelemetry Collectors existants ou utiliser votre propre distribution du collector.
À cette fin, un exemple de configuration d’OpenTelemetry Collector vous est fourni. Il utilise le ClickHouse exporter avec les paramètres appropriés et expose des receivers OTLP. Cette configuration correspond aux interfaces et au comportement attendus par la distribution ClickStack.
Remplacez les placeholders endpoint et password par les identifiants générés par ClickStack :
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:
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]Pour plus de détails sur la configuration des collectors OpenTelemetry, consultez « Ingestion avec OpenTelemetry »
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.
La suite suppose que vous disposez d’une instance de Vector en cours d’exécution, préconfigurée avec des pipelines d’ingestion, qui transmet des données.
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 logsCréez ensuite une table dont le schéma correspond à la structure de vos données de logs. L’exemple ci-dessous suppose un format classique de logs d’accès Nginx :
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);Votre table doit correspondre au schéma de sortie généré par Vector. Ajustez le schéma en fonction de vos données, en suivant les bonnes pratiques recommandées pour les schémas.
Nous vous recommandons vivement de bien comprendre le fonctionnement des clés primaires dans ClickHouse et de choisir une clé de tri en fonction de vos schémas d’accès. Consultez les recommandations spécifiques à ClickStack pour choisir une clé primaire.
Une fois la table créée, copiez l’extrait de configuration affiché. Ajustez l’entrée afin de consommer vos pipelines existants, ainsi que la table cible et la base de données si nécessaire. Les informations d’identification devraient être préremplies.
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.
Et c’est tout — vous êtes prêt. 🎉
Vous pouvez maintenant explorer ClickStack : commencez à rechercher dans les logs et les traces, observez comment les logs, les traces et les métriques se corrèlent en temps réel, créez des tableaux de bord, explorez les Service maps, découvrez Event deltas et Patterns, et configurez des alertes pour garder une longueur d’avance sur les problèmes.
Sélectionner un service
Depuis la page d’accueil de ClickHouse Cloud, sélectionnez le service pour lequel vous souhaitez activer Managed ClickStack.
Accéder à l’interface de ClickStack
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.
Si la détection automatique réussit, vous devriez être redirigé vers la vue de recherche, où vous pourrez immédiatement commencer à explorer vos données.
Si cette étape réussit, c’est terminé : tout est prêt 🎉. Sinon, passez à la configuration de l’ingestion.
Configurer l’ingestion
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 peuvent également envoyer des données directement à ClickHouse avec leur propre schéma en utilisant l'une des intégrations compatibles avec ClickHouse Cloud.
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.
L’exécution de cette seule commande démarre le collecteur ClickStack avec des endpoints OTLP exposés sur les ports 4317 (gRPC) et 4318 (HTTP). Si vous disposez déjà d’une instrumentation OpenTelemetry et d’agents, vous pouvez immédiatement commencer à envoyer des données de télémétrie vers ces endpoints.
Configurer des collecteurs existants
Vous pouvez également configurer vos propres OpenTelemetry Collectors existants ou utiliser votre propre distribution du collector.
À cet effet, un exemple de configuration OpenTelemetry Collector est fourni. Il utilise le ClickHouse exporter avec les paramètres appropriés et expose des receivers OTLP. Cette configuration correspond aux interfaces et au comportement attendus par la distribution ClickStack.
Remplacez les placeholders endpoint et password par les identifiants générés par ClickStack :
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:
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]
Pour plus de détails sur la configuration des collecteurs OpenTelemetry, consultez "Ingestion avec OpenTelemetry."
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.
La suite suppose qu’une instance de Vector est en cours d’exécution, préconfigurée avec des pipelines d’ingestion et qu’elle achemine les données.
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 logsCréez ensuite une table dont le schéma correspond à la structure de vos données de logs. L’exemple ci-dessous se base sur un format classique de journal d’accès Nginx :
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);Votre table doit correspondre au schéma de sortie généré par Vector. Ajustez le schéma en fonction de vos données, en suivant les bonnes pratiques recommandées pour les schémas.
Nous vous recommandons vivement de bien comprendre le fonctionnement des clés primaires dans ClickHouse et de choisir une clé de tri en fonction de vos modes d’accès. Consultez les recommandations spécifiques à ClickStack pour choisir une clé primaire.
Une fois la table créée, copiez l’extrait de configuration affiché. Ajustez l’entrée pour utiliser vos pipelines existants, ainsi que la table cible et la base de données si nécessaire. Les identifiants devraient déjà être préremplis.
Pour plus d’exemples d’ingestion de données avec Vector, consultez "Ingestion avec Vector" ou la documentation du sink ClickHouse de Vector pour accéder aux options avancées.
Accéder à l’interface de 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.
Tâches supplémentaires
Accorder l’accès à Managed ClickStack
- 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 alertes
- Service Read Only → Read Only - Permet de consulter les données d’observabilité et de créer des tableaux de bord
- No access - Ne permet pas d’accéder à HyperDX
Utiliser ClickStack avec des ressources de calcul en lecture seule
L'interface utilisateur de ClickStack peut fonctionner entièrement sur un service ClickHouse Cloud en lecture seule. Il s'agit de la configuration recommandée si vous souhaitez isoler les charges de travail d'ingestion et de requête.
Comment ClickStack sélectionne la ressource de calcul
L’interface utilisateur de ClickStack se connecte toujours au service ClickHouse depuis lequel il est lancé dans la ClickHouse Cloud Console.
Cela signifie :
- 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
Pour exécuter ClickStack sur des ressources de calcul en lecture seule :
- 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
ClickStack est nativement compatible avec OpenTelemetry, sans lui être exclusif : vous pouvez utiliser vos propres schémas de table si vous le souhaitez.
La section suivante explique comment ajouter des sources de données supplémentaires en plus de celles configurées automatiquement.
Utiliser les schémas OpenTelemetry
Si vous utilisez un OTel collector pour créer la base de données et les tables dans ClickHouse, conservez toutes les valeurs par défaut dans le formulaire de création de source et renseignez le champ 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.
Utiliser des schémas personnalisés
Les utilisateurs qui souhaitent connecter ClickStack à un service existant contenant déjà des données peuvent renseigner les paramètres de base de données et de table nécessaires. Les paramètres seront détectés automatiquement si les tables respectent les schémas OpenTelemetry pour ClickHouse.
Si vous utilisez votre propre schéma, nous vous recommandons de créer une source de logs en veillant à ce que les champs requis soient bien définis ; voir "Paramètres de la source de logs" pour plus de détails.
Choix du schéma : Map vs JSON
Par défaut, ClickStack stocke les attributs dans des colonnes 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.