Puesta en producción

Puesta en producción con ClickStack

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.

ClickStack gestionado

Para despliegues de producción, se recomienda Managed ClickStack. Aplica prácticas de seguridad 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 automatizados
• Actualizaciones sin interrupciones

Sigue estas buenas prácticas 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” 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” para obtener más información.

​

Configurar Time To Live (TTL)

Asegúrate de que Time To Live (TTL) esté configurado adecuadamente 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.

Suposiciones

• 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”.

​

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 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.

ClickStack Open Source

​

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:

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 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:

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:

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.

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” 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 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 <openSSL> en config.xml. Consulta guides/sre/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.
• Restrinja el acceso mediante el filtrado por IP y la cláusula HOST. Consulte sql-reference/statements/create/user#user-host.
• Habilite el control de acceso basado en roles (RBAC) para conceder privilegios granulares. Consulte operations/access-rights.
• Aplique cuotas y límites mediante cuotas, perfiles de configuración y modos de solo lectura.
• Cifre los datos en reposo y utilice almacenamiento externo seguro. Consulte operations/storing-data y cloud/security/CMEK.
• Evite codificar credenciales de forma fija. Use colecciones con nombre o roles de IAM en ClickHouse Cloud.
• Audite el acceso y las consultas con los logs del sistema y los logs de sesión.

Consulte también autenticadores externos y configuración de complejidad de consultas 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) esté configurado correctamente 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 oficial.