> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 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
export const ScalePlanFeatureBadge = ({feature = 'Cette fonctionnalité', linking_verb_are = false}) => {
return
Fonctionnalité de l’offre Scale
{feature} {linking_verb_are ? 'sont' : 'est'} disponible{linking_verb_are ? 's' : ''} avec les offres Scale et Enterprise. Pour passer à une offre supérieure, consultez la page des offres dans la console 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](/docs/fr/products/cloud/features/infrastructure/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](/docs/fr/clickstack/managing/estimating-resources) 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](/docs/fr/clickstack/managing/estimating-resources) 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é](/docs/fr/clickstack/managing/estimating-resources#worked-example) à 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](/docs/fr/products/cloud/features/infrastructure/warehouses#pricing).
* **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](/docs/fr/products/cloud/features/infrastructure/warehouses#network-access-control).
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](#separating-merges).
Mise en place d'un déploiement isolé
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](/docs/fr/clickstack/managing/estimating-resources).
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 :
```sql theme={null}
CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '';
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](/docs/fr/clickstack/ingesting-data/collector#creating-an-ingestion-user) 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](#administration).
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](/docs/fr/products/cloud/features/infrastructure/warehouses#setup-warehouses).
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 :
```shell theme={null}
CLICKHOUSE_ENDPOINT=https://.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel
```
Consultez les [options de configuration du collector](/docs/fr/clickstack/managing/config#otel-collector) pour plus de détails, ou les paramètres équivalents pour [Vector](/docs/fr/clickstack/ingesting-data/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.
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](/docs/fr/clickstack/deployment/managed#clickstack-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](/docs/fr/clickstack/deployment/managed#adding-data-sources) 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.
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`](/docs/fr/reference/system-tables/overview#querying-across-nodes) avec le nom de cluster `default` pour toutes les couvrir. Sur le service **read-only**, vous devriez voir les requêtes ClickStack :
```sql theme={null}
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`](/docs/fr/reference/statements/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](/docs/fr/reference/system-tables/query_views_log), 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` :
```sql theme={null}
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](https://clickhouse.com/support/program) 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](#architecture) 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](#point-clickstack).
* **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`](/docs/fr/clickstack/managing/ttl), 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`](/docs/fr/reference/system-tables/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](/docs/fr/clickstack/managing/ttl#modifying-ttl) pour ajuster la rétention
* La création de [vues matérialisées](/docs/fr/clickstack/managing/materialized-views) pour accélérer les requêtes
* L'ajout d'[index de saut, de projections et d'autres optimisations de performance](/docs/fr/clickstack/managing/performance-tuning)
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](#prepare-read-write-service) 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](/docs/fr/clickstack/managing/production#user-permissions) — 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](/docs/fr/clickstack/managing/admin). 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](#separating-merges), 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`](/docs/fr/reference/settings/session-settings/distributed-ddl#distributed_ddl_task_timeout), défini par requête ou pour la session :
```sql theme={null}
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](/docs/fr/clickstack/managing/config#materialized-views-settings) pour accélérer les requêtes.
Isoler les charges de travail agentiques
Les assistants IA connectés via le [serveur MCP ClickStack](/docs/fr/clickstack/mcp) 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.
Créez un autre service en lecture seule dans le warehouse, exactement comme dans [la configuration ci-dessus](#add-read-only-service). 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](#point-clickstack). Cloud MCP nécessite un service sur lequel ClickStack est activé, ainsi que MCP lui-même : voir les [prérequis MCP](/docs/fr/clickstack/mcp#managed-prerequisites).
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.
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](/docs/fr/products/cloud/features/ai-ml/mcp/remote-mcp#enable-remote-mcp-server).
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 :
```shell theme={null}
claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
--header "x-service-id: "
```
N'importe quel client MCP peut transmettre cet en-tête : voir [cibler un service spécifique](/docs/fr/clickstack/mcp#managed-service-override) 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](#point-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](#isolating-alerts). 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](/docs/fr/clickstack/deployment/managed#configure-access).
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](/docs/fr/clickstack/managing/estimating-resources#refining-sizing-assumptions) 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](/docs/fr/clickstack/features/alerts) 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](/docs/fr/clickstack/deployment/managed#adding-data-sources) 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](#isolating-alerts). 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](/docs/fr/products/cloud/guides/best-practices/usagelimits).
**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](/docs/fr/clickstack/managing/estimating-resources#isolating-workloads).
Pour connaître l'ensemble des comportements et limitations des warehouses, consultez notre guide sur les [Warehouses](/docs/fr/products/cloud/features/infrastructure/warehouses).