> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8a08bda2.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Puesta en producción > Puesta en producción con ClickStack export const Image = ({img, alt, size}) => { return {alt} ; }; Al desplegar ClickStack en producción, hay varias consideraciones adicionales para garantizar la seguridad, la estabilidad y una configuración correcta. Estas varían según la distribución utilizada: open source o Managed. Para despliegues de producción, se recomienda [Managed ClickStack](/es/clickstack/getting-started/managed). Aplica [prácticas de seguridad](/es/products/cloud/features/security) estándar del sector de forma predeterminada, incluidas la mejora del cifrado, la autenticación y la conectividad, y controles de acceso gestionados, además de ofrecer las siguientes ventajas: * Escalado automático de la capacidad de cómputo independiente del almacenamiento * Retención de bajo costo y prácticamente ilimitada basada en almacenamiento de objetos * La posibilidad de aislar de forma independiente las cargas de trabajo de lectura y escritura con Warehouses. * Autenticación integrada * [Backups](/es/products/cloud/features/backups/overview) automatizados * Actualizaciones sin interrupciones **Sigue estas [buenas prácticas](/es/products/cloud/guides/production-readiness) de ClickHouse Cloud al usar Managed ClickStack.** ### Proteger la ingestión De forma predeterminada, ClickStack OpenTelemetry Collector no está protegido cuando se despliega fuera de las distribuciones open source y no requiere autenticación en sus puertos OTLP. Para proteger la ingestión, especifica un token de autenticación al desplegar el collector mediante la variable de entorno `OTLP_AUTH_TOKEN`. Consulta ["Proteger el collector"](/es/clickstack/ingesting-data/collector#securing-the-collector) para obtener más información. #### Crear un usuario de ingestión Se recomienda crear un usuario dedicado para el OTel collector para la ingestión en Managed ClickHouse y para garantizar que la ingestión se envíe a una base de datos específica, por ejemplo, `otel`. Consulta ["Crear un usuario de ingestión"](/es/clickstack/ingesting-data/collector#creating-an-ingestion-user) para obtener más información. ### Configurar Time To Live (TTL) Asegúrate de que [Time To Live (TTL)](/es/clickstack/managing/ttl) esté [configurado adecuadamente](/es/clickstack/managing/ttl#modifying-ttl) para tu despliegue de Managed ClickStack. Esto controla durante cuánto tiempo se conservan los datos; el valor predeterminado de 3 días a menudo debe modificarse. ### Estimación de recursos Lo siguiente ofrece un modelo para estimar los recursos de cómputo y almacenamiento necesarios para un despliegue de ClickStack en función del volumen de ingestión previsto. Los valores resultantes son **solo estimaciones** y deben utilizarse como una **línea base inicial**; no constituyen una respuesta prescriptiva. Los requisitos reales dependen de la complejidad de las consultas, la concurrencia, las políticas de retención y la variabilidad del rendimiento de ingestión. Supervise siempre el uso de recursos y escale según sea necesario. **Todas las cifras se basan en la ingestión bruta sin comprimir** Todas las cifras de esta página —rendimiento (MB/s, TB/mes), dimensionamiento de CPU y almacenamiento— se expresan en términos de **volumen de ingestión bruta sin comprimir**, es decir, el tamaño de los datos tal como los generan sus aplicaciones y se envían al colector de OpenTelemetry antes de aplicar cualquier compresión. Esta es la cifra que debe estimar a partir de sus canalizaciones actuales de logs, traces y métricas. Las cifras de almacenamiento de la tabla siguiente ya tienen aplicada sobre este volumen bruto la **relación de compresión de 10x** asumida. Al desplegar ClickStack, aprovisione cómputo para cubrir dos cargas de trabajo independientes: **ingestión** y **consulta**. | Carga de trabajo | Recursos estimados | | ---------------- | ------------------------------------------------------------------------- | | **Ingestión** | 1 vCPU por cada 10 MB/s de rendimiento de ingestión sostenido | | **Consulta** | 1 vCPU por 1 QPS y por cada 10 MB/s de rendimiento de ingestión sostenido | **Aislamiento de consultas frente a ingestión** En la mayoría de los despliegues autogestionados, la ingestión y la consulta comparten los mismos nodos. En este caso, use las **CPU totales** como línea base. El escalado aislado —donde el cómputo de ingestión y el de consulta se aprovisionan de forma independiente— es compatible con ClickHouse Cloud mediante [grupos de cómputo independientes, también conocidos como Warehouses](/es/products/cloud/features/infrastructure/warehouses). * Una **relación de compresión de 10x** para el almacenamiento, normalmente conservadora para logs y traces. * SLA de consultas con un P50 de 1.5 segundos y un P99 de 5 segundos. * Suponemos que la mayoría de las consultas se realizan sobre datos recientes, siguiendo una distribución log-normal que alcanza su pico en torno a una hora y se extiende hasta aproximadamente seis horas. Los usuarios pueden optar por aprovisionar cómputo dedicado para consultar datos más antiguos. En ClickHouse Cloud, este puede permanecer inactivo (y, por tanto, no generar costos) cuando no se utilice. * Aunque el cómputo de consultas puede escalarse de forma independiente del cómputo de ingestión, sigue estando intrínsecamente vinculado al volumen de ingestión. Suponemos que, a medida que aumenta la ingestión, crece la densidad de datos, lo que da lugar a mayores volúmenes de escaneo en tiempo de consulta y, en consecuencia, a mayores requisitos de cómputo para las consultas. La siguiente tabla muestra ejemplos de dimensionamiento basados en un rendimiento de ingestión creciente en megabytes por segundo, junto con los volúmenes de datos correspondientes en terabytes por mes. Esto supone un promedio sostenido de **1 QPS** desde ClickStack en todos los tipos de consultas (búsqueda, dashboards y alertas). | MB/s | TB/mes | CPU de ingestión | CPU de consulta | CPU totales | Almacenamiento total (por mes) (GB) | | ---: | -----: | ---------------: | --------------: | ----------: | ----------------------------------: | | 10 | 25.92 | 1 | 3 | 4 | 2,592 | | 20 | 51.84 | 2 | 6 | 8 | 5,184 | | 50 | 129.6 | 5 | 15 | 20 | 12,960 | | 100 | 259.2 | 10 | 30 | 40 | 25,920 | | 200 | 518.4 | 20 | 60 | 80 | 51,840 | | 500 | 1,296 | 50 | 150 | 200 | 129,600 | | 1000 | 2,592 | 100 | 300 | 400 | 259,200 | Para obtener más información sobre cómo ajustar las hipótesis de dimensionamiento para tu entorno, consulta ["Ajustar las hipótesis de dimensionamiento para tu entorno"](/es/clickstack/managing/estimating-resources#refining-sizing-assumptions). #### Aislar cargas de trabajo de observabilidad Si estás añadiendo ClickStack a un **servicio de ClickHouse Cloud existente** que ya admite otras cargas de trabajo, como análisis de aplicaciones en tiempo real, se recomienda encarecidamente aislar el tráfico de observabilidad. Usa [**Managed Warehouses**](/es/products/cloud/features/infrastructure/warehouses) para crear un **servicio hijo** dedicado a ClickStack. Esto te permite: * Aislar la carga de ingestión y de consultas de las aplicaciones existentes * Escalar las cargas de trabajo de observabilidad de forma independiente * Evitar que las consultas de observabilidad afecten a los análisis de producción * Compartir los mismos datos subyacentes entre servicios cuando sea necesario Este enfoque garantiza que tus cargas de trabajo existentes no se vean afectadas y, al mismo tiempo, permite que ClickStack escale de forma independiente a medida que crecen los datos de observabilidad. Para despliegues más grandes o recomendaciones de dimensionamiento personalizadas, ponte en contacto con soporte para obtener una estimación más precisa. ### Seguridad de red y puertos De forma predeterminada, Docker Compose expone puertos en el host y los hace accesibles desde fuera del contenedor, incluso si herramientas como `ufw` (Uncomplicated Firewall) están habilitadas. Este comportamiento se debe a la pila de red de Docker, que puede saltarse las reglas de firewall a nivel de host a menos que se configure explícitamente. **Recomendación:** Exponga únicamente los puertos necesarios para uso en producción. Normalmente, los endpoints OTLP, el servidor de API y el frontend. Por ejemplo, elimine o comente las asignaciones de puertos innecesarias en su archivo `docker-compose.yml`: ```yaml theme={null} ports: - "4317:4317" # OTLP gRPC - "4318:4318" # OTLP HTTP - "8080:8080" # Solo si es necesario para la API # Evite exponer puertos internos como ClickHouse 8123 o MongoDB 27017. ``` Consulte la [documentación de redes de Docker](https://docs.docker.com/network/) para obtener más información sobre el aislamiento de contenedores y el endurecimiento del acceso. ### Configuración del secret de sesión En producción, debe establecer un valor aleatorio y robusto para la variable de entorno `EXPRESS_SESSION_SECRET` de la UI de ClickStack (HyperDX), a fin de proteger los datos de sesión y evitar manipulaciones. A continuación se muestra cómo añadirlo al archivo `docker-compose.yml` para el servicio de la aplicación: ```yaml theme={null} app: image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION} ports: - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT} - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT} environment: FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT} HYPERDX_API_KEY: ${HYPERDX_API_KEY} HYPERDX_API_PORT: ${HYPERDX_API_PORT} HYPERDX_APP_PORT: ${HYPERDX_APP_PORT} HYPERDX_APP_URL: ${HYPERDX_APP_URL} HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL} MINER_API_URL: 'http://miner:5123' MONGO_URI: 'mongodb://db:27017/hyperdx' NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT} OTEL_SERVICE_NAME: 'hdx-oss-api' USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true} EXPRESS_SESSION_SECRET: "super-secure-random-string" networks: - internal depends_on: - ch-server - db1 ``` Puede generar un secret seguro con `openssl`: ```shell theme={null} openssl rand -hex 32 ``` Evite incluir secretos en el control de versiones. En producción, considere usar herramientas de gestión de variables de entorno (p. ej., Docker Secrets, HashiCorp Vault o configuraciones de CI/CD específicas del entorno). ### Ingestión segura Toda la ingestión debe realizarse a través de los puertos OTLP expuestos por la distribución ClickStack del colector de OpenTelemetry (OTel). De forma predeterminada, esto requiere una API key de ingesta segura generada al inicio. Esta clave es necesaria para enviar datos a los puertos OTel y puede encontrarse en la UI de HyperDX en `Team Settings → API Keys`. Claves de ingestión Además, se recomienda habilitar TLS para los endpoints OTLP. #### Crear un usuario de ingestión Se recomienda crear un usuario dedicado para el OTel collector para la ingestión en ClickHouse y asegurarse de que los datos se envíen a una base de datos específica, por ejemplo, `otel`. Consulte ["Creación de un usuario de ingestión"](/es/clickstack/ingesting-data/collector#creating-an-ingestion-user) para obtener más información. ### ClickHouse Los usuarios que administren su propia instancia de ClickHouse deben seguir las siguientes buenas prácticas. #### Buenas prácticas de seguridad Si administra su propia instancia de ClickHouse, es fundamental habilitar **TLS**, aplicar autenticación y seguir las buenas prácticas para reforzar el control de acceso. Consulte [esta entrada de blog](https://www.wiz.io/blog/clickhouse-and-wiz) para obtener más información sobre configuraciones incorrectas en entornos reales y cómo evitarlas. ClickHouse OSS ofrece funciones de seguridad sólidas listas para usar. Sin embargo, estas requieren configuración: * **Usa TLS** con `tcp_port_secure` y `` en `config.xml`. Consulta [guides/sre/configuring-tls](/es/concepts/features/security/tls/configuring-tls). * **Configura una contraseña segura** para el usuario `default` o desactívalo. * **Evita exponer ClickHouse externamente** salvo que así se pretenda explícitamente. De forma predeterminada, ClickHouse solo escucha en `localhost`, a menos que se modifique `listen_host`. * **Utilice métodos de autenticación** como contraseñas, certificados, claves SSH o [autenticadores externos](/es/concepts/features/security/external-authenticators). * **Restrinja el acceso** mediante el filtrado por IP y la cláusula `HOST`. Consulte [sql-reference/statements/create/user#user-host](/es/reference/statements/create/user#user-host). * **Habilite el control de acceso basado en roles (RBAC)** para conceder privilegios granulares. Consulte [operations/access-rights](/es/concepts/features/security/access-rights). * **Aplique cuotas y límites** mediante [cuotas](/es/concepts/features/configuration/server-config/quotas), [perfiles de configuración](/es/concepts/features/configuration/settings/settings-profiles) y modos de solo lectura. * **Cifre los datos en reposo** y utilice almacenamiento externo seguro. Consulte [operations/storing-data](/es/concepts/features/configuration/server-config/storing-data) y [cloud/security/CMEK](/es/products/cloud/guides/security/cmek). * **Evite codificar credenciales de forma fija.** Use [colecciones con nombre](/es/concepts/features/configuration/server-config/named-collections) o roles de IAM en ClickHouse Cloud. * **Audite el acceso y las consultas** con [los logs del sistema](/es/reference/system-tables/query_log) y [los logs de sesión](/es/reference/system-tables/session_log). Consulte también [autenticadores externos](/es/concepts/features/security/external-authenticators) y [configuración de complejidad de consultas](/es/concepts/features/configuration/settings/query-complexity) para gestionar usuarios y garantizar los límites de consultas y recursos. #### Permisos de usuario para la UI de ClickStack El usuario de ClickHouse para la UI de ClickStack solo necesita ser un usuario `readonly` con acceso para modificar las siguientes configuraciones: * `max_rows_to_read` (al menos, hasta 1 millón) * `read_overflow_mode` * `cancel_http_readonly_queries_on_client_close` * `wait_end_of_query` De forma predeterminada, el usuario `default` tanto en OSS como en ClickHouse Cloud tendrá estos permisos disponibles; no obstante, se recomienda crear un nuevo usuario con dichos permisos. ### Configurar Time To Live (TTL) Asegúrese de que el [Time To Live (TTL)](/es/clickstack/managing/ttl) esté [configurado correctamente](/es/clickstack/managing/ttl#modifying-ttl) para su implementación de ClickStack. Esto controla durante cuánto tiempo se retienen los datos; el valor predeterminado de 3 días suele requerir ajustes. ### Directrices de MongoDB Consulte la [lista de comprobación de seguridad de MongoDB](https://www.mongodb.com/docs/manual/administration/security-checklist/) oficial.