Isoler les charges de travail de lecture et d’écriture

Séparer les charges de travail d’ingestion et de requête de ClickStack grâce aux warehouses ClickHouse Cloud

Les charges de travail d’observability imposent deux exigences très différentes aux mêmes données. L’ingestion est continue et fortement orientée écriture, les fusions en arrière-plan consommant du CPU et de la mémoire longtemps après la fin d’une insertion. La charge de requêtes, elle, est irrégulière : les dashboards et les recherches atteignent leur pic pendant un incident, précisément au moment où une réponse lente est le moins acceptable.

Avec les warehouses de ClickHouse Cloud, les deux charges de travail peuvent être servies à partir des mêmes données par des ressources de compute distinctes, de sorte qu’aucune ne concurrence l’autre pour le CPU et la mémoire.

Les warehouses étant une fonctionnalité de ClickHouse Cloud, la configuration décrite ici s’applique à ClickStack fonctionnant avec ClickHouse Cloud, chaque côté de la séparation étant dimensionné, mis à l’échelle et mis en veille indépendamment, au-dessus d’une seule copie des données.

Quand l’isolation en vaut la peine

L’isolation s’adresse aux déploiements de grande taille avec une ingestion continue. En dessous d’environ 100 To/mois de données stockées, un seul service read-write absorbe normalement les deux charges de travail et un second service n’est sans doute pas nécessaire. Utilisez le modèle de dimensionnement pour estimer votre volume compressé mensuel.

​

Pourquoi isoler les lectures des écritures

• Les écritures cessent de dégrader les lectures. L’ingestion OpenTelemetry continue — les inserts eux-mêmes, ainsi que les fusions en arrière-plan qui les suivent — entre en concurrence avec les requêtes de tableaux de bord et de recherche pour le CPU et la mémoire. La latence de lecture peut se dégrader sensiblement pendant l’ingestion, puis revenir à la normale une fois celle-ci terminée.
• Les lectures cessent de perturber les écritures. La contention joue dans les deux sens : une requête ad hoc lourde ou un rendu de tableau de bord coûteux peut épuiser la mémoire du service et faire échouer purement et simplement les inserts, et pas seulement les ralentir.
• Le compute en lecture seule est entièrement dédié aux requêtes. Les services en lecture seule n’effectuent aucune fusion en arrière-plan en dehors des tables système. Ils passent également en veille sans délai, contrairement aux services en lecture-écriture, que les fusions peuvent maintenir actifs.
• Chaque côté est dimensionné indépendamment. Le modèle de dimensionnement estime séparément le compute d’ingestion et le compute de requêtes, et un warehouse vous permet de provisionner chacun comme un service distinct. Au-delà du seuil de référence de 1 QPS retenu par le modèle, c’est le compute de requêtes qui domine — son exemple détaillé à 5 QPS aboutit à 58 vCPU pour l’ingestion contre 290 pour les requêtes — de sorte qu’un petit service d’écriture peut alimenter un service de lecture bien plus important.
• La mise en veille et l’autoscaling se configurent par service. Chaque service dispose de son propre nombre de réplicas et de ses propres paramètres d’autoscaling et de mise en veille automatique : le service d’écriture peut ainsi rester toujours actif pour l’ingestion continue, tandis que le service de lecture se met en veille en dehors des heures de travail.
• Le stockage n’est pas dupliqué. Les services d’un warehouse partagent le même dossier de stockage objet et les mêmes tables, et le stockage n’est facturé qu’une seule fois.
• L’accès peut être restreint par endpoint. Les listes d’accès IP s’appliquent par service : l’endpoint d’écriture peut n’être joignable que depuis vos collectors et l’endpoint de lecture que depuis votre déploiement ClickStack. Consultez notre guide sur le contrôle d’accès réseau.

​

Architecture

La topologie recommandée est un warehouse contenant un service read-write pour l’ingestion et un service read-only pour ClickStack :

Service	Type	Responsabilités	Clients
Primary	Read-write	Ingestion, background merges, DDL (création de tables, TTL, vues matérialisées)	OpenTelemetry collector, ClickPipes, Vector, SQL console / client pour l’administration
Secondary	Read-only	Recherche, dashboards, notebooks, évaluation des alertes	ClickStack UI (HyperDX)

À garder à l’esprit lors de la planification de la topologie :

• Le premier service d’un warehouse est toujours read-write, et le type d’un service est fixé à la création — pour passer de read-only à read-write, créez un nouveau service dans le warehouse.
• Tous les services d’un warehouse partagent le même cloud provider, la même region, la même version de ClickHouse, le même Keeper ainsi que l’upgrade schedule du service primary.
• N’utilisez qu’un seul service read-write pour l’ingestion. Les fusions sont réparties entre tous les services read-write qui partagent le stockage : une fusion liée à un insert sur un service peut donc être exécutée par un autre. Si cet autre service traite par ailleurs des requêtes lourdes, celles-ci entrent en concurrence avec la fusion pour le CPU et la mémoire du service qui l’exécute, ce qui ralentit les fusions liées aux inserts du premier service, et avec elles la performance d’insertion. Conservez les charges de travail de requêtes sur le service read-only et n’ajoutez un second service read-write que si vous avez besoin de séparer les fusions de l’ingestion.

​

Mise en place d’un déploiement isolé

1. Préparez le service en lecture-écriture

   Utilisez votre service existant — ou le primary service d’un nouveau warehouse — pour l’ingestion, en le dimensionnant pour le compute d’ingestion d’après le sizing model.

   Créez la base de données et l’utilisateur d’ingestion dédié sur ce service. Tous les services d’un warehouse partageant les mêmes access controls, les utilisateurs que vous créez ici sont disponibles sur chaque service du warehouse :

   CREATE DATABASE otel;
   CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
   GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;
   

   Générez le mot de passe à l’aide d’un outil tel que openssl rand -base64 24 et conservez-le dans un gestionnaire de secrets plutôt que dans un manifeste ou dans l’historique du shell. Consultez notre guide sur la création d’un utilisateur d’ingestion pour plus de détails.

   Si ce service fait déjà partie d’un warehouse, notez que les DDL au niveau de la base de données peuvent rester bloquées lorsqu’un autre service du même warehouse est en état idled — voir Administration et DDL.

2. Ajoutez un service en lecture seule à l’entrepôt de données

   Dans la ClickHouse Cloud console, cliquez sur le signe plus du service que vous venez de préparer afin de créer un second service partageant ses données. Sélectionnez read-only comme service type, puis dimensionnez-le en fonction du compute de requêtes défini par le sizing model.

   Pour la procédure complète, consultez notre guide Comment configurer un warehouse.

3. Dirigez l’ingestion vers le service en lecture-écriture

   Configurez votre collector pour qu’il exporte vers le point de terminaison de service read-write, en s’authentifiant en tant qu’utilisateur d’ingestion :

   CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
   CLICKHOUSE_USER=hyperdx_ingest
   CLICKHOUSE_PASSWORD=<strong-password>
   HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel
   

   Consultez les options de configuration du collector pour plus de détails, ou les paramètres équivalents pour Vector et les autres méthodes d’ingestion.

   Les écritures envoyées à l’endpoint en lecture seule sont rejetées ; le collector doit donc toujours cibler le service en lecture-écriture.

4. Pointer ClickStack vers le service en lecture seule

   L’interface ClickStack se connecte toujours au ClickHouse service depuis lequel elle est lancée dans la ClickHouse Cloud console. Pour l’exécuter sur du read-only compute :

   1. Sélectionnez le read-only service dans la ClickHouse Cloud console.
   2. Sélectionnez ClickStack dans le menu de navigation de gauche.

   Chaque requête émise par l’UI s’exécute alors sur ce read-only compute. Aucune configuration n’est nécessaire au sein de ClickStack. Consultez notre guide Utiliser ClickStack avec du read-only compute.

   L’état de ClickStack est propre au service

   Les dashboards, recherches enregistrées, alerts et sources appartiennent au service depuis lequel ClickStack a été lancé et ne vous suivent pas sur un autre service du même warehouse — même si les deux services partagent les mêmes données. Les sources utilisant le schéma OpenTelemetry par défaut sont détectées automatiquement sur le nouveau service : la recherche sur ces données fonctionne donc immédiatement, mais les sources personnalisées ou configurées manuellement — ainsi que tout ce que vous avez enregistré — doivent être recréées.

   Choisissez le service depuis lequel vous souhaitez exécuter ClickStack avant de créer vos dashboards. Si vous faites basculer un déploiement déjà en place, notez que les alerts créées sur le service précédent continuent d’y être évaluées — sur le compute de ce service — jusqu’à ce que vous les supprimiez.

5. Vérifier la répartition

   Lancez une recherche ou ouvrez un dashboard dans ClickStack, puis vérifiez où les requêtes ont été exécutées. Les tables system sont écrites sur le nœud qui a exécuté la requête : un service comportant plus d’une réplique nécessite donc clusterAllReplicas avec le nom de cluster default pour toutes les couvrir. Sur le service read-only, vous devriez voir les requêtes ClickStack :

   SELECT 
       user, 
       query_kind, 
       http_user_agent,
       count()
   FROM clusterAllReplicas('default', system.query_log)
   WHERE event_time > now() - toIntervalMinute(10) 
     AND type = 'QueryFinish'
     AND is_initial_query = 1
   GROUP BY ALL
   ORDER BY count() DESC;
   

   Un résultat vide ne signifie pas à lui seul que les requêtes sont passées ailleurs : system.query_log est vidé périodiquement — toutes les 7,5 secondes par défaut — si bien qu’une requête exécutée immédiatement après une recherche peut ne pas encore y figurer. Patientez un instant et relancez-la, ou forcez le flush avec SYSTEM FLUSH LOGS si vous disposez du privilège correspondant.

   C’est le regroupement par user et http_user_agent qui permet d’attribuer le trafic : il distingue l’UI de la SQL Console et de tout autre client se connectant à l’endpoint, quelles que soient les tables visées par vos sources. Le filtre sur is_initial_query = 1 conserve une seule ligne par requête telle qu’elle a été soumise — les requêtes secondaires issues de l’exécution distribuée, ainsi que les requêtes internes qui évaluent les vues matérialisées, sont journalisées séparément avec is_initial_query = 0.

   Sur le service read-write, la même requête devrait faire apparaître les inserts de l’utilisateur d’ingestion et aucun trafic de requêtes ClickStack.

   Exécuter la requête sur chaque service à tour de rôle constitue la vérification la plus fiable, car le cluster default ne contient que les répliques du service auquel vous êtes connecté. Pour obtenir une vue agrégée à l’échelle du warehouse, utilisez plutôt le nom de cluster all_groups.default :

   SELECT 
       hostName() AS host, 
       query_kind, 
       count()
   FROM clusterAllReplicas('all_groups.default', system.query_log)
   WHERE event_time > now() - toIntervalMinute(10) 
     AND type = 'QueryFinish'
     AND is_initial_query = 1
   GROUP BY ALL;
   

   Deux points à garder en tête avec cette requête : les services mis en veille ne peuvent pas fournir de lignes, il faut donc les réveiller au préalable si vous avez besoin de résultats complets, et hostName() identifie une réplique et non un service — pour rattacher une activité à un service précis, interrogez directement ce service.

​

Séparer les fusions de l’ingestion

À des débits d’ingestion soutenus très élevés, ce sont les fusions — et non les insertions elles-mêmes — qui deviennent le principal coût du service d’ingestion. Comme les fusions sont réparties entre tous les services en lecture-écriture partageant le même stockage, elles peuvent aussi être attribuées à un service que vous destiniez à un autre usage.

Pour ces déploiements, les fusions peuvent être entièrement sorties du service d’ingestion, ce qui donne une topologie à trois services :

Service	Type	Responsabilités
Ingestion	Lecture-écriture, fusions désactivées	Accepte uniquement les insertions
Fusion	Lecture-écriture	Exécute toutes les fusions et mutations en arrière-plan du warehouse
Requête	Lecture seule	Sert ClickStack

Nécessite une demande auprès du support

La désactivation des fusions sur un service en lecture-écriture n’est pas configurable depuis la console Cloud. Contactez le support pour l’appliquer à un service.

Cette topologie mérite d’être envisagée lorsque l’ingestion suffit à saturer un service, ou lorsque vous avez besoin de deux services en lecture-écriture parce que tous deux doivent écrire. Si votre charge de travail de requêtes est entièrement assurée par ClickStack — qui ne fait que lire — la répartition plus simple entre lecture-écriture et lecture seule suffit à répondre au besoin et constitue l’approche la mieux prise en charge.

Lorsque vous exploitez cette topologie, gardez à l’esprit les points suivants :

• Ne comptez pas sur l’auto-idling pour l’un ou l’autre des services en lecture-écriture. Un service dont les fusions sont désactivées traite malgré tout les événements de téléchargement et de suppression de parts générés par des insertions ailleurs dans le warehouse, et un nombre élevé de parts non fusionnées peut à lui seul empêcher l’idling. Prévoyez que les deux services en lecture-écriture restent actifs en permanence.
• N’envoyez aucune requête vers les services en lecture-écriture. Des requêtes SELECT lourdes sur un service en lecture-écriture entrent en concurrence avec le travail de fusion pour le CPU et la mémoire, ce qui constitue précisément le mode de défaillance que cette topologie vise à éviter. Pointez ClickStack vers le service en lecture seule comme décrit ci-dessus.
• Les mutations, lorsque vous en avez, sont suivies sur le service qui les exécute. Les mutations sont rares en observability — le schéma de ClickStack définit ttl_only_drop_parts = 1, de sorte que la rétention ordinaire supprime des parts expirées entières lors des fusions TTL plutôt que de muter les lignes une à une. Si vous soumettez au service d’ingestion un ALTER produisant une mutation, celle-ci est exécutée par le service de fusion, et sa progression apparaît dans system.mutations sur ce service plutôt que sur le service d’ingestion.

​

Administration et DDL

Tous les changements de schéma doivent être exécutés sur le service read-write, notamment :

• La création de tables — effectuée automatiquement par le ClickStack collector lors de la première ingestion
• La modification du TTL pour ajuster la rétention
• La création de vues matérialisées pour accélérer les requêtes
• L’ajout d’index de saut, de projections et d’autres optimisations de performance

Les utilisateurs, rôles et grants ne sont pas des changements de schéma : ils sont partagés par tous les services du warehouse, il suffit donc de les créer une seule fois, depuis n’importe quel service. Les étapes de configuration ci-dessus créent l’utilisateur d’ingestion. Tout autre client que vous dirigez vers le service read-only doit s’authentifier avec un utilisateur de requête read-only distinct, disposant des permissions requises par l’UI ClickStack — et non avec les grants d’ingestion présentés ci-dessus.

Connectez-vous au service read-write via la SQL Console ou le clickhouse client. Comme le warehouse partage le stockage et les contrôles d’accès, les changements sont immédiatement visibles par le service read-only. Si vous avez séparé les fusions de l’ingestion, les statements peuvent être soumis à l’un ou l’autre des services read-write — notez toutefois que les mutations sont exécutées et suivies sur le service de fusion.

Le DDL de base de données peut rester bloqué lorsqu’un autre service est idled

Les statements CREATE, RENAME et DROP DATABASE peuvent être bloqués par des services idled ou arrêtés du warehouse, et rester ainsi en attente. Le cas se produit facilement dans cette topologie, car les services read-only passent en veille sans délai. Exécutez les statements au niveau de la base de données avec distributed_ddl_task_timeout=0, défini par requête ou pour la session :

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

Un service que vous avez arrêté manuellement doit être redémarré avant que des requêtes puissent y être exécutées.

Les vues matérialisées sont déclenchées par l’insertion : elles sont donc exécutées par le service read-write. Le service read-only interroge leurs target tables comme n’importe quelle autre table, y compris les vues enregistrées auprès d’une source ClickStack pour accélérer les requêtes.

​

Isoler les charges de travail agentiques

Les assistants IA connectés via le serveur MCP ClickStack génèrent du trafic de lecture comme n’importe quel dashboard, mais leur profil de charge diffère : un agent qui enquête sur un incident émet de nombreuses requêtes exploratoires en rafale, sur des plages que personne n’a choisies à l’avance. Partager un même service en lecture seule entre les agents et l’UI fait passer cette rafale devant les dashboards qu’un ingénieur consulte pendant ce même incident.

Le même modèle de warehouse s’applique : donnez aux agents leur propre compute en lecture seule.

1. Ajouter un deuxième service en lecture seule

   Créez un autre service en lecture seule dans le warehouse, exactement comme dans la configuration ci-dessus. Il lit les mêmes tables que le service qui alimente l’UI, sans aucune donnée à copier.

   Lancez ensuite ClickStack dessus une fois depuis la Cloud console, comme décrit dans pointer ClickStack vers un service en lecture seule. Cloud MCP nécessite un service sur lequel ClickStack est activé, ainsi que MCP lui-même : voir les prérequis MCP.

   Dimensionnez-le en fonction de la charge de requêtes attendue de la part des agents plutôt que du QPS des dashboards issu du sizing model, et laissez l’auto-idling activé : l’usage agentique est généralement intermittent, le service peut donc rester au repos entre deux investigations.

2. Activer MCP sur ce service

   Ouvrez le service en lecture seule dans la ClickHouse Cloud console, cliquez sur Connect, sélectionnez Connect with MCP et activez l’option. Voir activer le serveur MCP distant.

3. Pointer les clients MCP vers ce service

   Le endpoint Cloud MCP est identique pour tous les services : les requêtes sont routées par l’en-tête x-service-id et, en son absence, elles sont dirigées vers le premier service ClickStack utilisé par votre compte. Copiez votre configuration MCP existante et ajoutez l’en-tête avec l’ID du nouveau service en lecture seule :

   claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
     --header "x-service-id: <read-only-agent-service-id>"
   

   N’importe quel client MCP peut transmettre cet en-tête : voir cibler un service spécifique pour la configuration équivalente dans Cursor, VS Code et d’autres outils.

MCP écrit son état sur le service qu’il cible

Le serveur MCP peut créer des dashboards, des alertes et des recherches enregistrées en plus d’exécuter des requêtes, et cet état reste limité au service vers lequel la requête a été routée, comme tout l’état ClickStack. Un dashboard créé par un agent sur le service dédié aux agents n’apparaîtra pas dans l’UI ClickStack lancée depuis le service qui sert vos ingénieurs, et une alerte qu’il y crée est évaluée sur le compute de ce service — or un service agent au repos retardera ou manquera ces évaluations, comme décrit ci-dessous. Routez les agents censés créer des artefacts durables vers le service utilisé par votre équipe.

​

Alerts

ClickStack évalue une alert sur le service depuis lequel elle a été créée ; les alerts s’exécutent donc sur le même compute que l’UI, c’est-à-dire le read-only service dans cette topologie.

Managed ClickStack

Pour activer les alerts, au moins un utilisateur disposant des permissions Service Admin doit s’être connecté à ClickStack au moins une fois. Cette opération provisionne le database user dédié qui exécute les requêtes d’alert, utilisateur partagé par l’ensemble des services du warehouse. Consultez notre guide sur l’octroi de l’accès à Managed ClickStack.

L’évaluation des alerts constitue une charge de travail de requêtes récurrente. Prenez-la en compte dans le QPS retenu pour dimensionner le read-only service : le sizing model traite les requêtes de recherche, de dashboard et d’alerting comme une seule valeur agrégée.

​

Isoler l’évaluation des alertes

La charge liée aux alertes ne peut pas être routée de façon centralisée, car les alertes sont créées par les utilisateurs : quiconque ajoute une alerte dans ClickStack l’ajoute au service dans lequel il travaille, et elle est évaluée sur le compute de ce service. Aucun paramètre ne permet de déplacer ailleurs les alertes d’un service.

Ce que vous pouvez isoler, ce sont les alertes que vous gérez de manière centralisée — celles qu’une équipe plateforme maintient pour l’ensemble de l’organisation, qui sont généralement aussi celles évaluées le plus fréquemment. Attribuez-leur leur propre service en lecture seule dans le warehouse, et créez-les depuis une instance ClickStack lancée à cet endroit :

Service	Type	Dessert
Ingestion	Lecture-écriture	OpenTelemetry collector
Requêtage	Lecture seule	ClickStack UI, et les alertes que les utilisateurs créent pour eux-mêmes
Alerting	Lecture seule	Alertes communes maintenues par l’équipe plateforme

Désactivez l’auto-idling sur le service d’alerting

Configurer des alertes sur un service ne suffit pas à le maintenir éveillé. Les évaluations d’alertes qui arrivent sur un service idled sont retardées par le réveil, voire échouent purement et simplement : un service d’alerting sur lequel l’auto-idling reste enabled peut donc manquer des évaluations. Désactivez l’auto-idling sur ce service et prévoyez de le laisser toujours actif. Le même principe s’applique partout où vos alertes sont évaluées : si elles s’exécutent sur le service qui dessert l’UI, ce service ne peut pas non plus être laissé en idle.

Les compromis restants découlent du fait que l’état est propre à chaque service :

• Les alertes communes, ainsi que les dashboards qui les accompagnent, n’existent que sur le service d’alerting et ne sont pas visibles pour les utilisateurs travaillant sur le service de requêtage. Les notifications sont acheminées vers les mêmes destinations dans les deux cas : ce que les utilisateurs perdent, c’est la visibilité sur les définitions, et non l’alerting lui-même.
• Les sources du service d’alerting sont des objets distincts. Celles qui utilisent le schéma OpenTelemetry par défaut sont détectées automatiquement, mais les sources personnalisées doivent aussi y être configurées avant qu’une alerte puisse les référencer.

Si un unique ensemble d’alertes est suffisamment réduit pour que sa charge d’évaluation soit négligeable face au trafic des dashboards, conservez tout sur un seul service en lecture seule — le coût opérationnel de maintenir des définitions à deux endroits est le plus élevé des deux.

​

Considérations supplémentaires

Auto-idling. La première requête adressée à un service read-only mis en veille doit attendre le démarrage du service : un usage intermittent échange donc un peu de latence contre une dépense réduite. Ne comptez pas sur les alerts pour empêcher la mise en veille : désactivez l’auto-idling sur tout service dont vous dépendez pour les évaluer, comme décrit ci-dessus. L’ingestion continue maintient effectivement le service read-write éveillé, mais si votre ingestion est intermittente ou planifiée, le premier batch suivant une période de veille subit la même attente, ce qui se traduit par de la telemetry retardée.

Sauvegardes. Les sauvegardes ne sont réalisées que sur le service primary, ce qui couvre les données de l’ensemble du warehouse. Restaurer une sauvegarde crée un service entièrement nouveau, non rattaché au warehouse existant.

Limites de répliques. Le nombre cumulé de répliques sur l’ensemble des services d’un warehouse est plafonné par défaut — voir les limites d’utilisation.

Isoler ClickStack des autres charges de travail. Si vous ajoutez ClickStack à un service qui exécute déjà d’autres charges de travail, comme de l’analytics applicatif en temps réel, c’est cette même fonctionnalité de warehouse qui permet de dédier son propre compute à l’observability. Consultez notre guide sur l’isolation des charges de travail d’observability.

Pour connaître l’ensemble des comportements et limitations des warehouses, consultez notre guide sur les Warehouses.