Déployez Managed ClickStack sur ClickHouse Cloud, envoyez un événement de test via votre pipeline d’ingestion et vérifiez que l’événement est disponible dans la ClickStack UI.
ClickHouse Cloud exploite le backend ClickHouse tandis que vous conservez le contrôle du pipeline d’ingestion et du schéma. Managed ClickStack fournit :
- Mise à l’échelle automatique de la capacité de calcul, indépendante du stockage
- Rétention peu coûteuse et pratiquement illimitée, basée sur le stockage objet
- Isolation indépendante des charges de travail de lecture et d’écriture avec des warehouses
- Authentification intégrée
- Sauvegardes automatisées
- Fonctionnalités de sécurité et de conformité
- Mises à niveau transparentes
Avant de commencer
Vous pouvez également envoyer des données directement vers ClickHouse à l’aide d’une intégration prise en charge et de votre propre schéma.
Créer un service ClickHouse Cloud
Effectuez l’étape Créer un service ClickHouse du quickstart ClickHouse Cloud. Avant de poursuivre, vérifiez que le service est en cours d’exécution.
Préparez votre environnement d'ingestion
- Pour démarrer un nouvel OpenTelemetry Collector, installez Docker. Pour Kubernetes, déployez le collector avec Helm.
- Pour utiliser un collector existant, exécutez-le en tant que gateway et assurez-vous que sa distribution inclut l’exportateur ClickHouse. Vous ajouterez la configuration requise dans ce guide.
Configurer Managed ClickStack
Choisissez une source d’ingestion et configurez le collecteur
Depuis votre service ClickHouse Cloud, lancez ClickStack. Sur la page Premiers pas de ClickStack, sélectionnez Commencer l’ingestion.

Sur la page Choisir une source d’ingestion, sélectionnez OpenTelemetry.

ClickStack génère la commande du collecteur avec les identifiants administrateur default. Nous recommandons d’utiliser des identifiants d’ingestion dédiés afin de séparer l’accès à l’ingestion des tâches d’administration et d’éviter de dépendre du mot de passe administrateur.
Créer des identifiants d’ingestion dédiés (recommandé)
Dans ClickHouse Cloud, ouvrez la console SQL de votre service et exécutez :
CREATE USER `clickstack-ingest` IDENTIFIED WITH sha256_password BY '<password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON default.* TO `clickstack-ingest`;Dans la commande générée, remplacez CLICKHOUSE_USER="default" par CLICKHOUSE_USER="clickstack-ingest" et définissez CLICKHOUSE_PASSWORD sur le mot de passe de l’utilisateur dédié.
Pour continuer avec les identifiants administrateur default, copiez la commande depuis l’onglet Démarrer le collecteur. ClickStack préremplit le point de terminaison de service. Remplacez l’espace réservé du mot de passe par celui de votre service. Si vous ne l’avez plus, récupérez ou réinitialisez vos informations de connexion.
La commande se présente comme suit :
docker run -e CLICKHOUSE_ENDPOINT="https://<host>:8443" \
-e CLICKHOUSE_USER="default" \
-e CLICKHOUSE_PASSWORD="<your_password_here>" \
-p 4317:4317 -p 4318:4318 \
clickhouse/clickstack-otel-collector:latestRemplacez <host> et <your_password_here> par les valeurs correspondant à votre service ClickHouse Cloud, puis exécutez la commande.
Le collecteur s’exécute au premier plan. Laissez ce terminal ouvert et utilisez un second terminal pour les commandes restantes de ce guide.
Sélectionnez Configurer un collecteur existant, puis adaptez la configuration de votre collecteur.
Exécutez le collecteur comme passerelle entre vos applications et ClickHouse Cloud. La configuration ci-dessous ajoute les exporters ClickHouse et les pipelines de signaux requis.
L’exemple utilise les identifiants default générés par ClickStack. Pour utiliser des identifiants d’ingestion dédiés, suivez la procédure facultative de l’onglet Démarrer un nouveau collecteur. Dans les deux blocs d’exporter ClickHouse, remplacez username: default par username: clickstack-ingest et définissez password sur le mot de passe de l’utilisateur dédié.
Fusionnez les composants suivants avec votre configuration existante plutôt que de remplacer des receivers, processeurs, exporters ou extensions non concernés.
L’exemple ajoute des receivers OTLP, le traitement par lots et la limitation de mémoire, le routage de Session Replay et des exporters ClickHouse.
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]Réutilisez votre receiver OTLP existant et conservez ses paramètres d’authentification et TLS. Si votre configuration utilise déjà les ID de composants ou de pipelines de l’exemple, fusionnez-les ou renommez-les au lieu de créer des ID en double. L’exécution de deux receivers sur les ports 4317 et 4318 provoque un conflit de ports.
Après avoir fusionné la configuration, rechargez ou redémarrez le collecteur selon votre processus de déploiement habituel.
Pour plus de détails sur la configuration des collecteurs OpenTelemetry, consultez Ingestion avec OpenTelemetry.
Envoyer des données de test
Envoyez un log de test avec l’horodatage actuel :
NOW_NANO="$(date +%s)000000000"
curl -i "http://localhost:4318/v1/logs" \
-H "Content-Type: application/json" \
--data-binary @- <<EOF
{
"resourceLogs": [{
"resource": {
"attributes": [{
"key": "service.name",
"value": {"stringValue": "clickstack-docs-test"}
}]
},
"scopeLogs": [{
"scope": {"name": "clickstack-docs-test"},
"logRecords": [{
"timeUnixNano": "${NOW_NANO}",
"severityText": "INFO",
"body": {"stringValue": "ClickStack ingestion test"}
}]
}]
}]
}
EOFSi vous utilisez un collector existant, remplacez http://localhost:4318 par son endpoint HTTP OTLP. Si le receiver nécessite une authentification, ajoutez le header obligatoire à la commande curl.
Une requête réussie renvoie HTTP/1.1 200 OK.
Commencez à explorer et vérifiez l’ingestion
Une fois que ClickStack a détecté les sources de données OpenTelemetry, sélectionnez Start exploring pour ouvrir la vue Search. Recherchez ClickStack ingestion test.
Le résultat doit inclure l’événement de test dont le nom de service est clickstack-docs-test.

Préparer votre environnement d'ingestion
Partez d'un pipeline Vector existant capable d'envoyer des données vers ClickHouse.
Configurer Managed ClickStack
Choisissez Vector et configurez l’ingestion
Depuis votre service ClickHouse Cloud, lancez ClickStack. Sur la page Getting Started de ClickStack, sélectionnez Start ingestion.

Sur la page Choose an ingestion source, sélectionnez Vector.

Vector est un pipeline de données d'observabilité haute performance et indépendant de tout fournisseur, 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, c'est vous qui définissez le schéma. Celui-ci peut respecter les conventions OpenTelemetry ou utiliser des champs propres à vos événements.
Créer une database et une table
Créez une database et une table avant de configurer le sink Vector.
Dans ClickHouse Cloud, ouvrez la SQL Console de votre service et créez une database :
Par exemple, créez une database pour les logs :
CREATE DATABASE IF NOT EXISTS logsCréez ensuite une table dont le schema correspond à la structure de vos données de logs. L'exemple ci-dessous part du principe qu'il s'agit d'un log format d'accès Nginx classique :
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 schema de sortie produit par Vector. Adaptez le schema à vos données, en suivant les bonnes pratiques de schema recommandées.
Nous recommandons vivement de bien comprendre le fonctionnement des clés primaires dans ClickHouse et de choisir une clé de tri adaptée à vos modèles d'accès. Consultez les recommandations spécifiques à ClickStack sur le choix d'une clé primaire.
Configurer le sink ClickHouse
Une fois la table créée, ajoutez un sink ClickHouse à votre configuration Vector :
sinks:
clickhouse:
type: clickhouse
inputs:
- your_input
endpoint: "https://<host>:8443"
database: logs
table: nginx_logs
format: json_each_row
skip_unknown_fields: true
auth:
strategy: basic
user: default
password: "<your_password_here>"Remplacez your_input par l'entrée de votre pipeline existant. Remplacez <host> et <your_password_here> par les valeurs correspondant à votre service ClickHouse Cloud. Si nécessaire, modifiez la base de données ou la table cible.
Utiliser des identifiants dédiés à l’ingestion (recommandé)
En production, créez un utilisateur dédié et accordez-lui l’accès à la table cible de Vector. Dans ClickHouse Cloud, ouvrez la SQL Console de votre service et exécutez :
CREATE USER `clickstack-ingest` IDENTIFIED WITH sha256_password BY '<password>';
GRANT SELECT, INSERT ON logs.nginx_logs TO `clickstack-ingest`;Remplacez default par clickstack-ingest dans le sink Vector et définissez password sur le mot de passe de l’utilisateur dédié.
Enregistrez la configuration mise à jour, puis rechargez ou redémarrez Vector à l'aide de votre processus de déploiement existant.
Pour d'autres exemples d'ingestion de données avec Vector, consultez Ingestion avec Vector ou la documentation du sink ClickHouse de Vector pour les options avancées.
Créer une source de données ClickStack
Créez une data source pour la table alimentée par votre pipeline Vector. ClickStack vous invite à en créer une lors de votre première connexion.
Le formulaire préremplit les expressions correspondant au schéma OpenTelemetry par défaut. Pour la table Nginx créée dans ce guide, configurez la source avec les valeurs suivantes :
| Paramètre | Valeur |
|---|---|
| Nom | Nginx logs |
| Type de données source | Journal |
| Connexion au serveur | Default |
| Base de données | logs |
| Table | nginx_logs |
| Colonne d’horodatage | time_local |
| SELECT par défaut | time_local, remote_addr, status, request |
| Expression du nom du service | 'nginx' |
| Expression de niveau de journalisation | multiIf(status >= 500, 'ERROR', status >= 400, 'WARN', 'INFO') |
| Expression des attributs de journal | map('http.remote_addr', toString(remote_addr), 'http.status_code', toString(status), 'http.request', request) |
| Expression des attributs de ressource | map('service.name', 'nginx') |
| Colonne d’horodatage affichée | time_local |
| Expression d’ID de trace | '' |
| Expression d’ID de span | '' |
| Expression de colonne implicite | request |
La table Nginx ne contient pas de colonne Body. Définissez Body Expression sur :
concat(
remote_addr, ' ',
remote_user, ' ',
'[', formatDateTime(time_local, '%d/%b/%Y:%H:%i:%S %z'), '] ',
'"', request, '" ',
toString(status), ' ',
toString(body_bytes_sent), ' ',
'"', http_referer, '" ',
'"', http_user_agent, '" ',
'"', http_x_forwarded_for, '" ',
toString(request_time), ' ',
toString(upstream_response_time), ' ',
'"', http_host, '"'
)Pour les autres paramètres de source, consultez la référence de configuration ClickStack.
Envoyer des données de test
Envoyez un événement représentatif à l’entrée de votre pipeline Vector existant.
Pour d’autres exemples de sources et de transformations Vector, consultez Ingestion avec Vector.
Commencez à explorer et vérifiez l’ingestion
Après avoir créé la source de données, sélectionnez Start exploring pour ouvrir la vue Search. Sélectionnez la source de données associée à votre table et vérifiez qu’elle contient l’événement envoyé.

Vous disposez désormais d’un service Managed ClickStack, d’un pipeline d’ingestion fonctionnel et d’un événement de test que vous pouvez inspecter dans ClickStack.
Étapes suivantes
Si un autre guide nécessite votre endpoint ClickHouse Cloud ou votre mot de passe, récupérez ou réinitialisez vos informations de connexion avant de poursuivre.
Envoyer les données de vos applications et de votre infrastructure
Choisissez le guide correspondant aux données que vous souhaitez envoyer à ClickStack :
Instrumenter une application
Envoyez les traces et les logs de votre application à l’aide d’un SDK OpenTelemetry pris en charge.
Collecter les logs de l’hôte
Transférez les logs de l’hôte depuis un OpenTelemetry Collector exécuté en tant qu’agent.
Surveiller Kubernetes
Collectez les logs, les métriques et les traces d’un cluster Kubernetes.
Explorer d’autres intégrations
Consultez les guides dédiés à d’autres applications et sources de télémétrie.
Explorer des données d’exemple
Utilisez un jeu de données d’exemple pour explorer ClickStack avec des données de télémétrie plus riches :
Logs, traces et métriques d’exemple

Chargez les données de la démo publique et diagnostiquez un problème. Ce guide suppose que vous avez lancé un nouvel OpenTelemetry Collector local. Si vous avez configuré un collector existant, adaptez les paramètres d’endpoint et d’authentification à votre déploiement.
Logs et métriques locaux

Collectez des fichiers locaux et des métriques système sur macOS ou Linux.
Générer des données synthétiques
Utilisez un générateur pour tester l’ingestion sans disposer d’une application ou d’un jeu de données existant :
Générer des données avec otelgen
Envoyez une courte rafale de logs, traces et métriques OTLP synthétiques.
Générer des données avec telemetrygen
Générez des signaux OpenTelemetry configurables pour plusieurs services.
Consultez toutes les données d’exemple et démos ClickStack.
Préparer la mise en production
Consultez les recommandations relatives à la production et au dimensionnement avant d’utiliser ClickStack pour des charges de travail soutenues :
Passer en production
Consultez les recommandations relatives aux identifiants d’ingestion, à la sécurité, à la rétention et à l’exploitation.
Estimer les ressources
Dimensionnez les ressources de calcul en fonction du volume d’ingestion prévu.
Pour les tâches de déploiement, consultez le guide de déploiement de Managed ClickStack.