Set up docs MCPEsta guía es para usuarios actuales de ClickHouse Cloud. Si eres nuevo en ClickHouse Cloud, te recomendamos nuestra guía de Primeros pasos para Managed ClickStack.
En este patrón de implementación, tanto ClickHouse como la UI de ClickStack (HyperDX) se alojan en ClickHouse Cloud, lo que minimiza la cantidad de componentes que el usuario necesita alojar por su cuenta.
Además de reducir la gestión de la infraestructura, este patrón de implementación garantiza que la autenticación esté integrada con el SSO/SAML de ClickHouse Cloud. A diferencia de las implementaciones autohospedadas, tampoco es necesario aprovisionar una instancia de MongoDB para almacenar el estado de la aplicación, como dashboards, búsquedas guardadas, configuraciones de usuario y alertas. Los usuarios también se benefician de:
- 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 capacidad de aislar de forma independiente las cargas de trabajo de lectura y escritura con Warehouses.
- Autenticación integrada
- Copias de seguridad automatizadas
- Funciones de seguridad y cumplimiento
- Actualizaciones sin complicaciones
En este modo, la ingestión de datos queda completamente en manos del usuario. Puedes ingestar datos en Managed ClickStack usando tu propio OpenTelemetry Collector alojado, ingestión directa desde bibliotecas cliente, motores de tabla nativos de ClickHouse (como Kafka o S3), canalizaciones ETL o ClickPipes, el servicio gestionado de ingestión de ClickHouse Cloud. Este enfoque ofrece la forma más sencilla y de mayor rendimiento de operar ClickStack.
Adecuado para
Este patrón de implementación es ideal para los siguientes escenarios:
- Ya tienes datos de observabilidad en ClickHouse Cloud y deseas visualizarlos con ClickStack.
- Operas una implementación de observabilidad a gran escala y necesitas el rendimiento y la escalabilidad dedicados de ClickStack en ClickHouse Cloud.
- Ya usas ClickHouse Cloud para analítica y quieres instrumentar tu aplicación con las bibliotecas de instrumentación de ClickStack, enviando los datos al mismo clúster. En este caso, recomendamos usar warehouses para aislar la capacidad de cómputo de las cargas de trabajo de observabilidad.
Pasos de configuración
La siguiente guía asume que ya has creado un servicio de ClickHouse Cloud. Si aún no has creado uno, sigue la guía de Primeros pasos para Managed ClickStack. Así tendrás un servicio en el mismo estado que el de esta guía; es decir, listo para recibir datos de observabilidad con ClickStack habilitado.
Crear un nuevo servicio
En la página principal de ClickHouse Cloud, selecciona New service para crear un nuevo servicio.
Especifica el proveedor, la región y el recurso
Seleccione el proveedor de Cloud y la región.
Al seleccionar la CPU y la memoria, calcúlelas en función del throughput de ingestión esperado de ClickStack. La tabla siguiente ofrece una guía para dimensionar estos recursos.
| Volumen mensual de ingestión | Capacidad de cómputo recomendada |
|---|---|
| < 10 TB / mes | 2 vCPU × 3 réplicas |
| 10–50 TB / mes | 4 vCPU × 3 réplicas |
| 50–100 TB / mes | 8 vCPU × 3 réplicas |
| 100–500 TB / mes | 30 vCPU × 3 réplicas |
| 1 PB+ / mes | 59 vCPU × 3 réplicas |
Estas recomendaciones se basan en los siguientes supuestos:
- El volumen de datos se refiere al volumen mensual de ingestión sin comprimir y se aplica tanto a logs como a traces.
- Los patrones de consulta son típicos de los casos de uso de observabilidad, y la mayoría de las consultas se centran en datos recientes, por lo general de las últimas 24 horas.
- La ingestión es relativamente uniforme a lo largo del mes. Si espera tráfico irregular o picos, debe aprovisionar capacidad adicional.
- El almacenamiento se gestiona por separado mediante object storage de ClickHouse Cloud y no es un factor limitante para la retención. Suponemos que a los datos retenidos durante periodos más largos se accede con poca frecuencia.
Puede que se necesite más capacidad de cómputo para patrones de acceso que consultan regularmente intervalos de tiempo más amplios, realizan agregaciones intensivas o dan soporte a un gran número de usuarios concurrentes.
Aunque dos réplicas pueden cubrir los requisitos de CPU y memoria para un throughput de ingestión determinado, recomendamos usar tres réplicas siempre que sea posible para lograr la misma capacidad total y mejorar la redundancia del servicio.
Una vez que haya especificado los requisitos, su servicio de Managed ClickStack tardará varios minutos en aprovisionarse. No dude en explorar el resto de la consola de ClickHouse Cloud mientras espera a que finalice el aprovisionamiento.
Una vez que se complete el aprovisionamiento, la opción 'ClickStack' del menú de la izquierda estará habilitada.
Configura la ingestión
Una vez aprovisionado el servicio, asegúrate de que esté seleccionado y haz clic en "ClickStack" en el menú de la izquierda.
Selecciona "Start Ingestion" y se te pedirá que elijas una fuente de ingestión. Managed ClickStack admite OpenTelemetry y Vector como principales fuentes de ingestión. Sin embargo, los usuarios también pueden enviar datos directamente a ClickHouse con su propio esquema mediante cualquiera de las integraciones compatibles con ClickHouse Cloud.
Para enviar datos de OpenTelemetry a Managed ClickStack, se recomienda usar un OpenTelemetry Collector. El collector actúa como un gateway que recibe datos de OpenTelemetry de sus aplicaciones (y de otros collectors) y los reenvía a ClickHouse Cloud.
Si aún no tiene uno en ejecución, inicie un collector siguiendo los pasos a continuación. Si ya tiene collectors existentes, también se incluye un ejemplo de configuración.
Iniciar un collector
A continuación se asume la ruta recomendada: usar la distribución de ClickStack de OpenTelemetry Collector, que incluye procesamiento adicional y está optimizada específicamente para ClickHouse Cloud. Si desea usar su propio OpenTelemetry Collector, consulte "Configurar collectors existentes."
Para empezar rápidamente, copie y ejecute el comando de Docker que se muestra.
Este comando debería incluir sus credenciales de conexión ya rellenadas.
Al ejecutar este único comando, se inicia el ClickStack collector con endpoints de OTLP expuestos en los puertos 4317 (gRPC) y 4318 (HTTP). Si ya tiene instrumentación y agentes de OpenTelemetry, puede comenzar de inmediato a enviar datos de telemetría a estos endpoints.
Configurar collectors existentes
También es posible configurar sus propios OpenTelemetry Collectors existentes o usar su propia distribución del collector.
Para ello, se proporciona una configuración de ejemplo de OpenTelemetry Collector que usa el exportador de ClickHouse con la configuración adecuada y expone receivers de OTLP. Esta configuración coincide con las interfaces y el comportamiento esperados por la distribución de ClickStack.
Sustituya los marcadores de posición de endpoint y contraseña por las credenciales generadas por ClickStack:
receivers:
otlp/hyperdx:
protocols:
grpc:
include_metadata: true
endpoint: "0.0.0.0:4317"
http:
cors:
allowed_origins: ["*"]
allowed_headers: ["*"]
include_metadata: true
endpoint: "0.0.0.0:4318"
processors:
batch:
memory_limiter:
# 80% of maximum memory up to 2G, adjust for low memory environments
limit_mib: 1500
# 25% of limit up to 2G, adjust for low memory environments
spike_limit_mib: 512
check_interval: 5s
connectors:
routing/logs:
default_pipelines: [logs/out-default]
error_mode: ignore
table:
- context: log
statement: route() where IsMatch(attributes["rr-web.event"], ".*")
pipelines: [logs/out-rrweb]
exporters:
clickhouse/rrweb:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
logs_table_name: hyperdx_sessions
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
clickhouse:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
service:
pipelines:
traces:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
metrics:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/in:
receivers: [otlp/hyperdx]
exporters: [routing/logs]
logs/out-default:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/out-rrweb:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse/rrweb]Para obtener más información sobre cómo configurar collectors de OpenTelemetry, consulte "Ingestión con OpenTelemetry."
Iniciar la ingestión (opcional)
Si tiene aplicaciones o infraestructura existentes para instrumentar con OpenTelemetry, vaya a las guías pertinentes enlazadas desde la UI.
Para instrumentar sus aplicaciones y recopilar traces y logs, use los SDKs de lenguajes compatibles, que envían datos a su OpenTelemetry Collector, que actúa como gateway para la ingestión en Managed ClickStack.
Los logs pueden recopilarse usando OpenTelemetry Collectors que se ejecutan en modo agent y reenvían datos al mismo collector. Para la monitorización de Kubernetes, siga la guía específica. Para otras integraciones, consulte nuestras guías de inicio rápido.
Datos de demostración
Como alternativa, si no tiene datos existentes, pruebe uno de nuestros datasets de ejemplo.
- Dataset de ejemplo - Cargue un dataset de ejemplo de nuestra demo pública. Diagnostique un problema sencillo.
- Archivos locales y métricas - Cargue archivos locales y supervise el sistema en OSX o Linux usando un OTel collector local.
Vector es un pipeline de datos de observabilidad de alto rendimiento y neutral con respecto a los proveedores, especialmente popular para la ingestión de logs por su flexibilidad y bajo consumo de recursos.
Al usar Vector con ClickStack, los usuarios son responsables de definir sus propios esquemas. Estos esquemas pueden seguir las convenciones de OpenTelemetry, pero también pueden ser completamente personalizados y representar estructuras de eventos definidas por el usuario.
A continuación, se asume que tienes una instancia de Vector en ejecución, preconfigurada con pipelines de ingestión y enviando datos.
Crear una base de datos y una tabla
Vector requiere que la tabla y el esquema estén definidos antes de la ingestión de datos.
Primero, crea una base de datos. Esto puede hacerse a través de la consola de ClickHouse Cloud.
Por ejemplo, crea una base de datos para logs:
CREATE DATABASE IF NOT EXISTS logsA continuación, cree una tabla cuyo esquema coincida con la estructura de los datos de su log. El siguiente ejemplo supone un formato clásico de log de acceso de Nginx:
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);La tabla debe ajustarse al esquema de salida generado por Vector. Ajusta el esquema según sea necesario para tus datos, siguiendo las mejores prácticas de esquema recomendadas.
Te recomendamos encarecidamente que entiendas cómo funcionan las claves primarias en ClickHouse y que elijas una clave de ordenación en función de tus patrones de acceso. Consulta la guía específica de ClickStack sobre cómo elegir una clave primaria.
Una vez creada la tabla, copia el fragmento de configuración que se muestra. Ajusta la entrada para que consuma tus pipelines existentes, así como la tabla de destino y la base de datos, si es necesario. Las credenciales deberían aparecer ya rellenadas.
Para ver más ejemplos de ingesta de datos con Vector, consulta "Ingesta con Vector" o la documentación del sink de ClickHouse para Vector para opciones avanzadas.
Accede a la UI de ClickStack
Seleccione 'Launch ClickStack' para acceder a la interfaz de ClickStack (HyperDX). Se le autenticará automáticamente y se le redirigirá.
Se crearán automáticamente orígenes de datos para todos los datos de OpenTelemetry.
Si utiliza Vector, tendrá que crear sus propios orígenes de datos. Se le pedirá que cree uno al iniciar sesión por primera vez. A continuación, mostramos una configuración de ejemplo para un origen de datos de logs.
Esta configuración asume un esquema de estilo Nginx con una columna time_local usada como timestamp. Siempre que sea posible, esta debería ser la columna de timestamp declarada en la clave primaria. Esta columna es obligatoria.
También recomendamos actualizar Default SELECT para definir explícitamente qué columnas se devuelven en la vista de logs. Si hay campos adicionales disponibles, como el nombre del servicio, el nivel de log o una columna Body, también pueden configurarse. La columna de visualización del timestamp también puede sustituirse si difiere de la columna usada en la clave primaria de la tabla y configurada anteriormente.
En el ejemplo anterior, no existe una columna Body en los datos. En su lugar, se define mediante una expresión SQL que reconstruye una línea de log de Nginx a partir de los campos disponibles.
Para ver otras opciones, consulte la referencia de configuración.
Una vez creado, debería ir a la vista de búsqueda, donde podrá empezar a explorar sus datos de inmediato.
Y eso es todo: ya está listo. 🎉
Siga explorando ClickStack: empiece a buscar logs y trazas, vea cómo se correlacionan logs, trazas y métricas en tiempo real, cree dashboards, explore mapas de servicios, descubra event deltas y patterns, y configure alertas para adelantarse a los problemas.
Selecciona un servicio
En la página principal de ClickHouse Cloud, selecciona el servicio en el que deseas habilitar Managed ClickStack.
Accede a la UI de ClickStack
Selecciona 'ClickStack' en el menú de navegación de la izquierda. Se te redirigirá a la UI de ClickStack y se te autenticará automáticamente en función de tus permisos de ClickHouse Cloud.
Si ya existen tablas de OpenTelemetry en tu servicio, se detectarán automáticamente y se crearán los orígenes de datos correspondientes.
Si la detección automática se realiza correctamente, se te dirigirá a la vista de búsqueda, donde podrás empezar a explorar tus datos de inmediato.
Si este paso se completa correctamente, eso es todo: ya lo tienes todo listo 🎉. De lo contrario, continúa con la configuración de la ingestión.
Configura la ingestión
Si la detección automática falla o no hay tablas existentes, se te pedirá que configures la ingestión.
Seleccione "Start Ingestion" y se le pedirá que elija una fuente de ingestión. Managed ClickStack admite OpenTelemetry y Vector como sus principales fuentes de ingestión. No obstante, los usuarios también tienen la opción de enviar datos directamente a ClickHouse con su propio esquema mediante cualquiera de las integraciones compatibles con ClickHouse Cloud.
Para enviar datos de OpenTelemetry a Managed ClickStack, se recomienda usar un OpenTelemetry Collector. El collector actúa como gateway: recibe datos de OpenTelemetry de sus aplicaciones (y de otros collectors) y los reenvía a ClickHouse Cloud.
Si todavía no tiene uno en ejecución, inicie un collector siguiendo los pasos a continuación. Si ya tiene collectors existentes, también se proporciona un ejemplo de configuración.
Iniciar un collector
A continuación se asume la opción recomendada: usar la distribución de ClickStack de OpenTelemetry Collector, que incluye procesamiento adicional y está optimizada específicamente para ClickHouse Cloud. Si quiere usar su propio OpenTelemetry Collector, consulte "Configurar collectors existentes."
Para empezar rápidamente, copie y ejecute el comando de Docker que se muestra.
Modifique este comando con las credenciales de su servicio, que anotó cuando creó el servicio.
Al ejecutar este único comando, se inicia el ClickStack collector con endpoints OTLP expuestos en los puertos 4317 (gRPC) y 4318 (HTTP). Si ya cuenta con instrumentación de OpenTelemetry y agents, puede comenzar de inmediato a enviar datos de telemetry a estos endpoints.
Configurar collectors existentes
También es posible configurar sus propios OpenTelemetry Collectors existentes o usar su propia distribución del collector.
Para ello, se proporciona un ejemplo de configuración de OpenTelemetry Collector que usa el ClickHouse exporter con la configuración adecuada y expone receivers OTLP. Esta configuración coincide con las interfaces y el comportamiento esperados por la distribución de ClickStack.
Sustituya los marcadores de posición de endpoint y contraseña por las credenciales generadas por ClickStack:
receivers:
otlp/hyperdx:
protocols:
grpc:
include_metadata: true
endpoint: "0.0.0.0:4317"
http:
cors:
allowed_origins: ["*"]
allowed_headers: ["*"]
include_metadata: true
endpoint: "0.0.0.0:4318"
processors:
batch:
memory_limiter:
# 80% of maximum memory up to 2G, adjust for low memory environments
limit_mib: 1500
# 25% of limit up to 2G, adjust for low memory environments
spike_limit_mib: 512
check_interval: 5s
connectors:
routing/logs:
default_pipelines: [logs/out-default]
error_mode: ignore
table:
- context: log
statement: route() where IsMatch(attributes["rr-web.event"], ".*")
pipelines: [logs/out-rrweb]
exporters:
clickhouse/rrweb:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
logs_table_name: hyperdx_sessions
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
clickhouse:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
service:
pipelines:
traces:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
metrics:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/in:
receivers: [otlp/hyperdx]
exporters: [routing/logs]
logs/out-default:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/out-rrweb:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse/rrweb]
Para obtener más información sobre la configuración de collectors de OpenTelemetry, consulte "Ingestión con OpenTelemetry."
Iniciar la ingestión (opcional)
Si tiene aplicaciones o infraestructura existentes que quiera instrumentar con OpenTelemetry, vaya a las guías correspondientes enlazadas desde "Conectar una aplicación".
Para instrumentar sus aplicaciones y recopilar traces y logs, use los SDK de lenguaje compatibles, que envían datos a su OpenTelemetry Collector, que actúa como gateway para la ingestión en Managed ClickStack.
Los logs pueden recopilarse con OpenTelemetry Collectors que se ejecutan en modo agent y reenvían datos al mismo collector. Para el monitoreo de Kubernetes, siga la guía específica. Para otras integraciones, consulte nuestras guías de inicio rápido.
Vector es una canalización de datos de observabilidad de alto rendimiento e independiente del proveedor, especialmente popular para la ingestión de logs por su flexibilidad y su bajo consumo de recursos.
Al usar Vector con ClickStack, los usuarios son responsables de definir sus propios esquemas. Estos esquemas pueden seguir las convenciones de OpenTelemetry, pero también pueden ser totalmente personalizados y representar estructuras de eventos definidas por el usuario.
A continuación, se asume que tienes una instancia de Vector en ejecución, preconfigurada con pipelines de ingesta y enviando datos.
Crear una base de datos y una tabla
Vector requiere que se definan una tabla y un esquema antes de la ingestión de datos.
Primero, crea una base de datos. Esto puede hacerse desde la consola de ClickHouse Cloud.
Por ejemplo, crea una base de datos para logs:
CREATE DATABASE IF NOT EXISTS logsLuego, cree una tabla cuyo esquema coincida con la estructura de sus logs. El ejemplo siguiente asume un formato clásico de registro de acceso de Nginx:
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);Tu tabla debe ajustarse al esquema de salida generado por Vector. Ajusta el esquema según sea necesario para tus datos, siguiendo las buenas prácticas para esquemas.
Recomendamos encarecidamente que comprendas cómo funcionan las claves primarias en ClickHouse y que elijas una clave de ordenación en función de tus patrones de acceso. Consulta la guía específica de ClickStack sobre cómo elegir una clave primaria.
Una vez que la tabla exista, copia el fragmento de configuración que se muestra. Ajusta la entrada para consumir tus canalizaciones existentes, así como la tabla y la base de datos de destino si es necesario. Las credenciales ya deberían aparecer rellenadas.
Para ver más ejemplos de ingesta de datos con Vector, consulta "Ingesta con Vector" o la documentación del sink de ClickHouse para Vector para conocer las opciones avanzadas.
Accede a la UI de ClickStack
Una vez que hayas terminado de configurar la ingestión y hayas comenzado a enviar datos, selecciona "Siguiente".
Si has ingerido datos de OpenTelemetry con esta guía, los orígenes de datos se crean automáticamente y no se requiere ninguna configuración adicional. Puedes empezar a explorar ClickStack de inmediato. Se te dirigirá a la vista de búsqueda con un origen seleccionado automáticamente para que puedas comenzar a hacer consultas enseguida.
Eso es todo: ya está todo listo 🎉.
Si has ingerido datos a través de Vector o de otro origen, se te pedirá que configures el origen de datos.
La configuración anterior asume un esquema de estilo Nginx con una columna time_local usada como timestamp. Siempre que sea posible, esta debe ser la columna de timestamp declarada en la clave primaria. Esta columna es obligatoria.
También recomendamos actualizar Default SELECT para definir explícitamente qué columnas se devuelven en la vista de logs. Si hay campos adicionales disponibles, como el nombre del servicio, el nivel de log o una columna body, estos también pueden configurarse. La columna que se muestra como timestamp también puede sobrescribirse si es distinta de la columna usada en la clave primaria de la tabla y configurada anteriormente.
En el ejemplo anterior, no existe una columna Body en los datos. En su lugar, se define mediante una expresión SQL que reconstruye una línea de log de Nginx a partir de los campos disponibles.
Para ver otras opciones posibles, consulta la referencia de configuración.
Una vez configurado el origen, haz clic en "Guardar" y empieza a explorar tus datos.
Tareas adicionales
Conceder acceso a Managed ClickStack
- Vaya a su servicio en la consola de ClickHouse Cloud
- Vaya a Settings → SQL Console Access
- Establezca el nivel de permiso adecuado para cada usuario:
- Service Admin → Full Access - Necesario para habilitar alertas
- Service Read Only → Read Only - Puede ver datos de observabilidad y crear dashboards
- No access - No puede acceder a HyperDX
Uso de ClickStack con capacidad de cómputo de solo lectura
La UI de ClickStack puede ejecutarse por completo en un servicio de ClickHouse Cloud en modo de solo lectura. Esta es la configuración recomendada cuando se quiere aislar las cargas de trabajo de ingestión y consulta.
Cómo ClickStack selecciona la capacidad de cómputo
La UI de ClickStack siempre se conecta al servicio de ClickHouse desde el que se inicia en la consola de ClickHouse Cloud.
Esto significa:
- Si abres ClickStack desde un servicio de solo lectura, todas las consultas emitidas por la UI de ClickStack se ejecutarán en esa capacidad de cómputo de solo lectura.
- Si abres ClickStack desde un servicio de lectura y escritura, ClickStack usará esa capacidad de cómputo en su lugar.
No se requiere ninguna configuración adicional dentro de ClickStack para garantizar el comportamiento de solo lectura.
Configuración recomendada
Para ejecutar ClickStack en capacidad de cómputo de solo lectura:
- Cree o identifique un servicio de ClickHouse Cloud en el warehouse configurado como de solo lectura.
- En la consola de ClickHouse Cloud, seleccione el servicio de solo lectura.
- Inicie ClickStack desde el menú de navegación de la izquierda.
Una vez iniciado, la UI de ClickStack quedará vinculada automáticamente a este servicio de solo lectura.
Añadir más fuentes de datos
ClickStack es compatible de forma nativa con OpenTelemetry, pero no depende exclusivamente de OpenTelemetry: si lo desea, puede usar sus propios esquemas de tabla.
A continuación se describe cómo los usuarios pueden añadir fuentes de datos adicionales, además de las que se configuran automáticamente.
Uso de esquemas de OpenTelemetry
Si está usando un OTel collector para crear la base de datos y las tablas en ClickHouse, mantenga todos los valores predeterminados en el formulario de creación de la fuente y complete el campo Table con el valor otel_logs para crear una fuente de logs. El resto de la configuración debería detectarse automáticamente, lo que le permitirá hacer clic en Save New Source.
Para crear fuentes para traces y metrics de OTel, puede seleccionar Crear nueva fuente en el menú superior.
Desde aquí, seleccione el tipo de fuente requerido y, a continuación, la tabla adecuada; por ejemplo, para traces, seleccione la tabla otel_traces. Toda la configuración debería detectarse automáticamente.
Uso de esquemas personalizados
Quienes deseen conectar ClickStack a un servicio existente con datos pueden completar la configuración de la base de datos y de la tabla según corresponda. La configuración se detectará automáticamente si las tablas se ajustan a los esquemas de OpenTelemetry para ClickHouse.
Si utiliza su propio esquema, le recomendamos crear una fuente de logs y asegurarse de que se especifiquen los campos obligatorios; consulte "Configuración de la fuente de logs" para obtener más información.
Elección del esquema: Map vs JSON
ClickStack almacena los atributos como columnas Map(LowCardinality(String), String) de forma predeterminada. Este es el esquema recomendado para las cargas de trabajo de observabilidad. En combinación con la serialización de mapas por buckets y los índices de texto sobre las claves y los valores del mapa, ofrece lookups selectivos sin la sobrecarga de ingesta por clave de las subcolumnas JSON dinámicas.
También hay disponible, en fase beta, un esquema de tipo JSON para evaluarlo en cargas de trabajo con un conjunto pequeño y estable de claves de atributos. No se recomienda como opción predeterminada. Consulta Map vs tipo JSON para ver la comparación completa y las variables de entorno necesarias para habilitar la compatibilidad con JSON.