> ## 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.
# Aislar los workloads de lectura y escritura
> Separar los workloads de ingestión y de consulta de ClickStack con warehouses de ClickHouse Cloud
export const ScalePlanFeatureBadge = ({feature = 'Esta característica', linking_verb_are = false}) => {
return
Característica del plan Scale
{feature} {linking_verb_are ? 'están disponibles' : 'está disponible'} en los planes Scale y Enterprise. Para actualizar el plan, visita la página de planes en Cloud Console.
;
};
Las cargas de trabajo de observabilidad imponen dos demandas muy distintas sobre los mismos datos. La ingestión es continua e intensiva en escritura, con fusiones en segundo plano que consumen CPU y memoria mucho después de que finalice un insert. La carga de consultas es irregular: los dashboards y las búsquedas alcanzan su punto máximo durante un incidente, justo cuando una respuesta lenta resulta menos aceptable.
Con los [warehouses](/docs/es/products/cloud/features/infrastructure/warehouses) de ClickHouse Cloud, ambas cargas de trabajo pueden atenderse a partir de los mismos datos mediante cómputo independiente, de modo que ninguna compita con la otra por CPU y memoria.
Los warehouses son una característica de ClickHouse Cloud, por lo que la configuración descrita aquí se aplica a ClickStack ejecutándose sobre ClickHouse Cloud, donde cada lado del split se dimensiona, escala y pasa a estado idle de forma independiente sobre una única copia de los datos.
**Cuándo vale la pena el aislamiento**
El aislamiento está orientado a implementaciones grandes con ingestión continua. Por debajo de aproximadamente 100 TB/mes de datos almacenados, un único service de lectura y escritura suele absorber ambas cargas de trabajo, por lo que probablemente no haga falta un segundo service. Utilice el [sizing model](/docs/es/clickstack/managing/estimating-resources) para estimar su volumen comprimido mensual.
Por qué aislar las lecturas de las escrituras
* **Las escrituras dejan de degradar las lecturas.** La ingestión continua de OpenTelemetry —los inserts en sí, más las fusiones en segundo plano que los siguen— compite con las consultas de dashboards y búsquedas por CPU y memoria. La latencia de lectura puede degradarse de forma notable mientras la ingestión está en curso, y se recupera cuando esta se detiene.
* **Las lecturas dejan de interferir con las escrituras.** La contención se produce en ambos sentidos: una consulta ad-hoc pesada o la renderización costosa de un dashboard pueden agotar la memoria del service y hacer que los inserts fallen directamente, no solo que se ralenticen.
* **El compute de solo lectura se dedica por completo a las consultas.** Los read-only services no realizan fusiones en segundo plano fuera de las system tables. Además, pasan a estado idle sin demora, a diferencia de los read-write services, a los que las fusiones pueden mantener activos.
* **Cada lado se dimensiona por separado.** El [sizing model](/docs/es/clickstack/managing/estimating-resources) estima por separado el compute de ingestión y el de consultas, y un warehouse te permite provisionar cada uno como un service independiente. Por encima del baseline de 1 QPS del modelo, el compute de consultas predomina —su [ejemplo práctico](/docs/es/clickstack/managing/estimating-resources#worked-example) con 5 QPS llega a 58 vCPU para la ingestión frente a 290 para las consultas—, por lo que un service de escritura pequeño puede alimentar a un service de lectura mucho mayor.
* **El idling y el autoscaling se configuran por service.** Cada service tiene su propio número de réplicas y sus propios ajustes de autoscaling y auto-idling, de modo que el service de escritura puede permanecer siempre activo para la ingestión continua mientras el service de lectura pasa a idle fuera del horario laboral.
* **El almacenamiento no se duplica.** Los services de un warehouse comparten la misma carpeta de object storage y las mismas tablas, y [el almacenamiento se factura una sola vez](/docs/es/products/cloud/features/infrastructure/warehouses#pricing).
* **El acceso puede restringirse por endpoint.** Las IP access lists se aplican por service, por lo que el endpoint de escritura puede ser accesible únicamente desde tus collectors y el endpoint de lectura únicamente desde tu implementación de ClickStack. Consulta nuestra guía sobre [Control de acceso de red](/docs/es/products/cloud/features/infrastructure/warehouses#network-access-control).
Arquitectura
La topología recomendada es un warehouse con un servicio read-write para la ingestión y un servicio read-only para ClickStack:
| Servicio | Tipo | Responsabilidades | Clients |
| - | - | - | - |
| Primario | Read-write | Ingestión, fusiones en segundo plano, DDL (creación de tablas, TTL, vistas materializadas) | Collector de OpenTelemetry, ClickPipes, Vector, consola SQL / client para administración |
| Secundario | Read-only | Búsqueda, dashboards, notebooks, evaluación de alertas | UI de ClickStack (HyperDX) |
Ten en cuenta lo siguiente al planificar la topología:
* El primer servicio de un warehouse siempre es read-write, y el tipo de servicio queda **fijado en el momento de su creación**: para cambiar entre read-only y read-write, crea un nuevo servicio en el warehouse.
* Todos los servicios de un warehouse comparten el mismo proveedor de nube, región, versión de ClickHouse y Keeper, así como la programación de upgrade del servicio primario.
* Usa **un solo** servicio read-write para la ingestión. Las fusiones se reparten entre todos los servicios read-write que comparten el almacenamiento, de modo que la fusión correspondiente a un insert en un servicio puede acabar ejecutándose en otro. Si ese otro servicio además atiende consultas pesadas, esas consultas competirán con la fusión por CPU y memoria en el servicio que la ejecuta, lo que ralentiza las fusiones de los inserts del primer servicio y, con ellas, el rendimiento de inserción. Mantén los workloads de consulta en el servicio read-only y añade un segundo servicio read-write solo si necesitas [separar las fusiones de la ingestión](#separating-merges).
Configurar un despliegue aislado
Utiliza tu servicio existente —o el servicio principal de un nuevo warehouse— para la ingestión, dimensionado según el compute de ingesta del [sizing model](/docs/es/clickstack/managing/estimating-resources).
Crea la base de datos y el usuario dedicado a la ingestión en este servicio. Como todos los servicios de un warehouse comparten los controles de acceso, los usuarios que crees aquí estarán disponibles en todos los servicios del 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;
```
Genere la contraseña con una herramienta como `openssl rand -base64 24` y almacénela en un gestor de secretos, no en un manifest ni en el historial del shell. Consulte nuestra guía sobre [Crear un usuario de ingestión](/docs/es/clickstack/ingesting-data/collector#creating-an-ingestion-user) para más detalles.
Si este service ya forma parte de un warehouse, tenga en cuenta que el DDL a nivel de database puede quedarse bloqueado cuando otro service del mismo está idled; consulte [Administración y DDL](#administration).
En la consola de ClickHouse Cloud, haga clic en el signo más del service que acaba de preparar para crear un segundo service que comparta sus datos. Seleccione **read-only** como service type y dimensiónelo según el compute de consultas que indique el sizing model.
Para ver el procedimiento completo, consulte nuestra guía [Cómo configurar un warehouse](/docs/es/products/cloud/features/infrastructure/warehouses#setup-warehouses).
Configure su collector para exportar al service endpoint de **lectura-escritura**, autenticándose como el usuario de ingestión:
```shell theme={null}
CLICKHOUSE_ENDPOINT=https://.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel
```
Consulta las [opciones de configuración del collector](/docs/es/clickstack/managing/config#otel-collector) para más detalles, o los ajustes equivalentes para [Vector](/docs/es/clickstack/ingesting-data/vector) y otras vías de ingestión.
Las escrituras enviadas al endpoint de solo lectura se rechazan, por lo que el collector siempre debe apuntar al servicio de lectura y escritura.
La UI de ClickStack siempre se conecta al ClickHouse service desde el que se inicia en la ClickHouse Cloud console. Para ejecutarla en read-only compute:
1. Seleccione el read-only service en la ClickHouse Cloud console.
2. Seleccione **ClickStack** en la barra de navegación izquierda.
A partir de ese momento, todas las consultas que emita la UI se ejecutan en ese read-only compute. No hace falta ninguna configuración dentro de ClickStack. Consulte nuestra guía sobre [Uso de ClickStack con read-only compute](/docs/es/clickstack/deployment/managed#clickstack-read-only-compute).
**El estado de ClickStack está acotado al service**
Los dashboards, saved searches, alerts y sources pertenecen al service desde el que se inició ClickStack y no le acompañan a otro service del mismo warehouse, aunque ambos services compartan los mismos datos. Los sources que utilizan el [esquema predeterminado de OpenTelemetry](/docs/es/clickstack/deployment/managed#adding-data-sources) se detectan automáticamente en el nuevo service, por lo que la búsqueda sobre esos datos funciona de inmediato, pero los sources personalizados o configurados manualmente —y todo lo demás que haya guardado— deben recrearse.
Elija el service desde el que desea ejecutar ClickStack antes de crear dashboards. Si va a cambiar una implementación ya establecida, tenga en cuenta que los alerts creados en el service anterior se siguen evaluando allí —en el compute de ese service— hasta que los elimine.
Ejecuta una búsqueda o abre un dashboard en ClickStack y luego comprueba dónde se ejecutaron las consultas. Las tablas `system` se escriben en el nodo que ejecutó la consulta, por lo que un servicio con más de una réplica necesita [`clusterAllReplicas`](/docs/es/reference/system-tables/overview#querying-across-nodes) con el nombre de cluster `default` para abarcarlas todas. En el servicio de **solo lectura** deberías ver las consultas de 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 resultado vacío aquí no significa por sí solo que las consultas hayan ido a otra parte: `system.query_log` se vuelca periódicamente —cada 7,5 segundos de forma predeterminada—, por lo que una consulta ejecutada inmediatamente después de una búsqueda puede que aún no aparezca. Espera un momento y vuelve a ejecutarla, o fuerza el volcado con [`SYSTEM FLUSH LOGS`](/docs/es/reference/statements/system#flush-logs) si cuentas con el grant correspondiente.
Agrupar por `user` y `http_user_agent` es lo que permite atribuir el tráfico: distingue la UI de la consola SQL y de cualquier otro elemento que se conecte al endpoint, sean cuales sean las tablas a las que apunten tus sources. Filtrar por `is_initial_query = 1` conserva una fila por consulta tal y como se envió; las consultas secundarias derivadas de la ejecución distribuida, así como las consultas internas que evalúan las [vistas materializadas](/docs/es/reference/system-tables/query_views_log), se registran por separado con `is_initial_query = 0`.
En el service **read-write**, esa misma consulta debería mostrar inserts del usuario de ingestión y ningún tráfico de consultas de ClickStack.
Ejecutar la consulta en cada service, uno por uno, es la comprobación fiable, ya que el cluster `default` contiene únicamente las réplicas del service al que estás conectado. Para obtener una vista de agregación de todo el warehouse, utiliza en su lugar el nombre 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;
```
Hay dos aspectos a tener en cuenta con esta consulta: los servicios que han quedado inactivos (idled) no pueden aportar filas, por lo que debes reactivarlos primero si necesitas resultados completos, y `hostName()` identifica una réplica, no un servicio; para atribuir la actividad a un servicio concreto, consulta directamente ese servicio.
Separar las fusiones de la ingestión
Con tasas de ingestión sostenidas muy altas, las fusiones —y no las inserciones en sí— se convierten en el coste dominante del servicio de ingestión. Dado que las fusiones se reparten entre todos los servicios de lectura y escritura que comparten el almacenamiento, también pueden acabar ejecutándose en un servicio que habías destinado a otra cosa.
En estas implementaciones, las fusiones pueden sacarse por completo del servicio de ingestión, lo que da lugar a una topología de tres servicios:
| Servicio | Tipo | Responsabilidades |
| - | - | - |
| Ingestión | Lectura y escritura, fusiones deshabilitadas | Solo acepta inserciones |
| Fusión | Lectura y escritura | Ejecuta todas las fusiones en segundo plano y mutaciones del warehouse |
| Consulta | Solo lectura | Da servicio a ClickStack |
**Requiere una solicitud a soporte**
Deshabilitar las fusiones en un servicio de lectura y escritura no se puede configurar desde la consola de Cloud. [Contacta con soporte](https://clickhouse.com/support/program) para aplicarlo a un servicio.
Merece la pena considerar esta topología cuando la ingestión por sí sola satura un servicio, o cuando necesitas dos servicios de lectura y escritura porque ambos deben escribir. Si ClickStack atiende por completo tu carga de consultas —y solo lee—, la división más sencilla de [lectura y escritura más solo lectura](#architecture) cubre el requisito y es la opción mejor soportada.
Al utilizar esta topología, ten en cuenta lo siguiente:
* **No dependas del auto-idling en ninguno de los dos servicios de lectura y escritura.** Un servicio con las fusiones deshabilitadas sigue procesando los eventos de descarga y eliminación de partes que generan las inserciones en otros puntos del warehouse, y un número elevado de partes sin fusionar puede bloquear el idling por sí solo. Prevé que ambos servicios de lectura y escritura estén continuamente activos.
* **Mantén las consultas fuera de ambos servicios de lectura y escritura.** Las consultas `SELECT` pesadas en un servicio de lectura y escritura compiten por CPU y memoria con el trabajo de fusión, que es precisamente el modo de fallo que esta topología pretende evitar. Apunta ClickStack al servicio de solo lectura tal como se describe [más arriba](#point-clickstack).
* **Las mutaciones, cuando las haya, se registran en el servicio que las ejecuta.** Las mutaciones son poco frecuentes en observabilidad: el esquema de ClickStack establece [`ttl_only_drop_parts = 1`](/docs/es/clickstack/managing/ttl), por lo que la retención ordinaria elimina partes expiradas completas durante las fusiones de TTL en lugar de mutar filas para borrarlas. Si envías al servicio de ingestión un `ALTER` que produce una mutación, la ejecuta el servicio de fusión, y su progreso aparece allí en [`system.mutations`](/docs/es/reference/system-tables/mutations) y no en el servicio de ingestión.
Administración y DDL
Todos los cambios de esquema deben ejecutarse contra el servicio de **lectura-escritura**, incluidos:
* Creación de tablas: la realiza automáticamente el collector de ClickStack en la primera ingestión
* [Modificar TTL](/docs/es/clickstack/managing/ttl#modifying-ttl) para cambiar la retención
* Crear [vistas materializadas](/docs/es/clickstack/managing/materialized-views) para acelerar las consultas
* Añadir [skip indexes, projections y otras optimizaciones de rendimiento](/docs/es/clickstack/managing/performance-tuning)
Los usuarios, roles y grants no son cambios de esquema: los comparten todos los servicios del warehouse, por lo que basta con crear cada uno una sola vez, desde cualquier servicio. Los [pasos de configuración](#prepare-read-write-service) anteriores crean el usuario de ingestión. Cualquier otro client que apuntes al servicio de solo lectura debería autenticarse como un usuario de consulta de solo lectura independiente, con los [permisos que requiere la UI de ClickStack](/docs/es/clickstack/managing/production#user-permissions), y no con los grants de ingestión mostrados arriba.
Conéctate al servicio de lectura-escritura mediante la [SQL Console o el clickhouse client](/docs/es/clickstack/managing/admin). Como el warehouse comparte almacenamiento y controles de acceso, los cambios son visibles de inmediato para el servicio de solo lectura. Si has [separado los merges de la ingestión](#separating-merges), las sentencias pueden enviarse a cualquiera de los dos servicios de lectura-escritura, pero ten en cuenta que las mutations se ejecutan y se registran en el servicio de merge.
**El DDL de base de datos puede quedarse colgado cuando otro servicio está idled**
Las sentencias `CREATE`, `RENAME` y `DROP DATABASE` pueden verse bloqueadas por servicios idled o detenidos del warehouse, lo que provoca que se queden colgadas. Es fácil que ocurra en esta topología, porque los servicios de solo lectura pasan a idle sin demora. Ejecuta las sentencias a nivel de base de datos con [`distributed_ddl_task_timeout=0`](/docs/es/reference/settings/session-settings/distributed-ddl#distributed_ddl_task_timeout), establecido por consulta o para la session:
```sql theme={null}
CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0
```
Un servicio que hayas detenido manualmente debe iniciarse de nuevo antes de que se puedan ejecutar consultas contra él.
Las vistas materializadas se activan con la inserción, por lo que las ejecuta el servicio de lectura-escritura. El servicio de solo lectura consulta sus tablas de destino como cualquier otra tabla, incluidas las views [registradas contra una fuente de ClickStack](/docs/es/clickstack/managing/config#materialized-views-settings) para acelerar las consultas.
Aislamiento de cargas de trabajo agénticas
Los AI assistants conectados a través del [servidor MCP de ClickStack](/docs/es/clickstack/mcp) generan tráfico de lectura como cualquier dashboard, pero su patrón de carga es distinto: un agent que investiga un incidente emite muchas queries exploratorias en rápida sucesión, sobre rangos que nadie eligió por adelantado. Compartir un único read-only service entre los agents y la UI hace que esa ráfaga se anteponga a los dashboards que un ingeniero está consultando durante ese mismo incidente.
Aquí se aplica el mismo patrón de warehouse: dar a los agents su propio read-only compute:
Cree otro read-only service en el warehouse, exactamente como en [la configuración anterior](#add-read-only-service). Lee las mismas tablas que el service que atiende la UI, sin datos que copiar.
Después, inicie ClickStack en él una vez desde la Cloud console, como en [apuntar ClickStack a un read-only service](#point-clickstack). Cloud MCP necesita un service con ClickStack habilitado, además de MCP en sí: consulte los [prerequisites de MCP](/docs/es/clickstack/mcp#managed-prerequisites).
Dimensiónelo según la carga de queries que espere de los agents y no según el QPS de dashboards del sizing model, y deje el auto-idling habilitado: el uso agéntico suele ser intermitente, por lo que el service puede permanecer inactivo entre investigaciones.
Abra el read-only service en la ClickHouse Cloud console, haga clic en **Connect**, seleccione **Connect with MCP** y actívelo. Consulte [habilitar el Remote MCP server](/docs/es/products/cloud/features/ai-ml/mcp/remote-mcp#enable-remote-mcp-server).
El Cloud MCP endpoint es el mismo para todos los services: las solicitudes se enrutan mediante el encabezado `x-service-id` y, si falta, se dirigen al primer ClickStack service utilizado por su cuenta. Copie su configuración de MCP existente y añada el encabezado con el ID del nuevo read-only service:
```shell theme={null}
claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
--header "x-service-id: "
```
Cualquier MCP client puede enviar el encabezado: consulte [Targeting a specific service](/docs/es/clickstack/mcp#managed-service-override) para ver la configuración equivalente en Cursor, VS Code y otros.
**MCP escribe state en el service al que apunta**
El servidor MCP puede crear dashboards, alerts y saved searches, además de ejecutar queries, y ese state queda delimitado al service al que se enrutó la solicitud, como todo el [state de ClickStack](#point-clickstack). Un dashboard que un agent cree en el service de agents no aparecerá en la UI de ClickStack iniciada desde el service que atiende a sus ingenieros, y un alert creado allí se evalúa con el compute de ese service, donde un service de agents en idling retrasará u omitirá las evaluaciones, como se explica [más abajo](#isolating-alerts). Enrute al mismo service que usa su equipo los agents de los que se espere que creen artifacts duraderos.
Alertas
ClickStack evalúa cada alerta en el service desde el que se creó, por lo que las alertas se ejecutan en el mismo compute que la UI: el read-only service en esta topología.
**Managed ClickStack**
Para habilitar las alertas, al menos un usuario con permisos de **Service Admin** debe iniciar sesión en ClickStack al menos una vez. Esto aprovisiona el usuario de base de datos dedicado que ejecuta las consultas de las alertas, usuario que se comparte entre todos los services del warehouse. Consulte nuestra guía sobre [cómo otorgar acceso a Managed ClickStack](/docs/es/clickstack/deployment/managed#configure-access).
La evaluación de alertas constituye un workload de consultas recurrente. Téngalo en cuenta al calcular el QPS con el que dimensiona el read-only service: el [sizing model](/docs/es/clickstack/managing/estimating-resources#refining-sizing-assumptions) trata las consultas de búsqueda, dashboards y alertas como una única cifra agregada.
Aislar la evaluación de alertas
La carga de las alertas no se puede enrutar de forma centralizada, porque las alertas las crean los usuarios: quien añade una alerta en ClickStack la añade al servicio en el que está trabajando, y esta se evalúa con el compute de ese servicio. No existe ninguna configuración que traslade las alertas de un servicio a otro lugar.
Lo que sí puedes aislar son las alertas que gestionas de forma centralizada: las que un equipo de plataforma mantiene para toda la organización, que además suelen ser las que se evalúan con mayor frecuencia. Asígnales su propio servicio de solo lectura en el warehouse y créalas desde un ClickStack lanzado allí:
| Servicio | Tipo | Da servicio a |
| - | - | - |
| Ingesta | Lectura-escritura | OpenTelemetry collector |
| Consulta | Solo lectura | UI de ClickStack y las alertas que los usuarios crean para sí mismos |
| Alertas | Solo lectura | Alertas comunes mantenidas por el equipo de plataforma |
**Desactiva el auto-idling en el servicio de alertas**
Tener alertas configuradas en un servicio no lo mantiene activo. Las evaluaciones de alertas que llegan a un servicio en estado idle se retrasan por la reactivación o fallan directamente, de modo que un servicio de alertas con el auto-idling habilitado puede perder evaluaciones. Desactiva el auto-idling en ese servicio y prevé que esté siempre activo. Lo mismo se aplica allí donde se evalúen tus alertas: si se ejecutan en el servicio que da servicio a la UI, ese servicio tampoco puede quedar en idle.
Las demás contrapartidas se derivan de que el state sea propio de cada servicio:
* Las alertas comunes, y cualquier dashboard asociado a ellas, existen únicamente en el servicio de alertas y no son visibles para los usuarios que trabajan en el servicio de consulta. En ambos casos, las notificaciones se entregan a los mismos [destinos](/docs/es/clickstack/features/alerts), por lo que lo que los usuarios pierden es la visibilidad de las definiciones, no las alertas en sí.
* Las sources del servicio de alertas son objetos independientes. Las que usan el [esquema predeterminado de OpenTelemetry](/docs/es/clickstack/deployment/managed#adding-data-sources) se detectan automáticamente, pero las sources personalizadas también deben configurarse allí antes de que una alerta pueda hacer referencia a ellas.
Si un único conjunto de alertas es lo bastante pequeño como para que su carga de evaluación resulte insignificante frente al tráfico de los dashboards, mantén todo en un solo servicio de solo lectura: el coste operativo de mantener las definiciones en dos lugares es el mayor de los dos costes.
Consideraciones adicionales
**Auto-idling.** La primera consulta a un read-only service que ha entrado en estado idled debe esperar a que el service arranque, por lo que el uso intermitente sacrifica algo de latencia a cambio de un menor gasto. No cuentes con las alertas para evitar el idling: desactiva el auto-idling en cualquier service del que dependas para evaluarlas, tal como se describe [más arriba](#isolating-alerts). La continuous ingestion sí mantiene despierto el read-write service, pero si tu ingestión es intermitente o programada, el primer batch tras un periodo de inactividad tendrá que esperar igualmente, lo que se traduce en telemetría retrasada.
**Copias de seguridad.** Las copias de seguridad se realizan únicamente en el primary service, y abarcan los datos de todo el warehouse. Restaurar una copia de seguridad crea un service completamente nuevo que no está conectado al warehouse existente.
**Límites de réplicas.** El número combinado de réplicas de todos los services de un warehouse está limitado de forma predeterminada; consulta los [límites de uso](/docs/es/products/cloud/guides/best-practices/usagelimits).
**Aislar ClickStack de otros workloads.** Si añades ClickStack a un service que ya ejecuta otros workloads, como analítica de aplicaciones en tiempo real, se recurre a esa misma funcionalidad de warehouse para dotar a la observabilidad de su propio compute. Consulta nuestra guía sobre [Aislar workloads de observabilidad](/docs/es/clickstack/managing/estimating-resources#isolating-workloads).
Para conocer el conjunto completo de comportamientos y limitaciones de los warehouses, consulta nuestra guía sobre [Warehouses](/docs/es/products/cloud/features/infrastructure/warehouses).