Управляемый

Beta feature. Learn more.

Бета-функция

Эта функция находится в бета-версии ClickHouse Cloud.

Это руководство предназначено для существующих пользователей ClickHouse Cloud. Если вы новичок в ClickHouse Cloud, мы рекомендуем наше руководство Getting Started по Managed ClickStack.

В этом варианте развертывания и ClickHouse, и UI ClickStack (HyperDX) размещены в ClickHouse Cloud, что минимизирует количество компонентов, которые пользователю необходимо разворачивать и обслуживать самостоятельно.

Помимо снижения затрат на управление инфраструктурой, такой вариант развертывания обеспечивает интеграцию аутентификации с ClickHouse Cloud SSO/SAML. В отличие от самостоятельных развертываний, здесь также нет необходимости поднимать экземпляр MongoDB для хранения состояния приложения — такого как дашборды, сохранённые поисковые запросы, пользовательские настройки и алерты. Пользователи также получают следующие преимущества:

• Автоматическое масштабирование вычислительных ресурсов независимо от хранилища
• Низкая стоимость и практически неограниченный срок хранения данных на основе объектного хранилища
• Возможность независимо изолировать нагрузки на чтение и запись с помощью Warehouses
• Интегрированная аутентификация
• Автоматизированные резервные копии
• Функции безопасности и соответствия требованиям
• Бесшовные обновления

В этом режиме ингестия данных полностью остаётся на стороне пользователя. Вы можете выполнять ингестию данных в Managed ClickStack, используя собственный развернутый OpenTelemetry collector, прямую ингестию из клиентских библиотек, нативные для ClickHouse табличные движки (такие как Kafka или S3), ETL-конвейеры или ClickPipes — управляемый сервис ингестии в ClickHouse Cloud. Такой подход обеспечивает самый простой и наиболее производительный способ эксплуатации ClickStack.

Подходит для

Эта модель развертывания оптимальна в следующих сценариях:

1. У вас уже есть данные обсервабилити в ClickHouse Cloud, и вы хотите визуализировать их с помощью ClickStack.
2. У вас крупное развертывание обсервабилити, и вам необходима выделенная производительность и масштабируемость ClickStack, работающего поверх ClickHouse Cloud.
3. Вы уже используете ClickHouse Cloud для аналитики и хотите инструментировать свое приложение с помощью библиотек инструментирования ClickStack, отправляя данные в тот же кластер. В этом случае мы рекомендуем использовать warehouses для изоляции вычислительных ресурсов для нагрузок обсервабилити.

Этапы настройки

В данном руководстве предполагается, что вы уже создали сервис ClickHouse Cloud. Если вы ещё не создали сервис, следуйте руководству Getting Started для Managed ClickStack. В результате у вас будет сервис в том же состоянии, что и в этом руководстве, то есть готовый к приёму данных обсервабилити с включённым ClickStack.

Создайте новый сервис

Создайте новый сервис

На главной странице ClickHouse Cloud выберите New service, чтобы создать новый сервис.

Укажите провайдера, регион и ресурсы

Scale vs Enterprise

Мы рекомендуем этот тариф Scale для большинства нагрузок ClickStack. Выберите тариф Enterprise, если вам требуются расширенные функции безопасности, такие как SAML, CMEK или соответствие требованиям HIPAA. Он также предлагает индивидуальные профили оборудования для очень крупных развертываний ClickStack. В таких случаях мы рекомендуем связаться со службой поддержки.

Выберите поставщика Cloud и регион.

При указании CPU и памяти оценивайте их исходя из ожидаемой пропускной способности ingesтa ClickStack. Таблица ниже предоставляет рекомендации по размеру этих ресурсов.

Ниже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания ClickStack, на основе ожидаемого объёма приёма данных. Полученные значения являются лишь оценочными и должны использоваться как начальная точка отсчёта — это не готовый рецепт. Фактические требования зависят от сложности запросов, уровня параллелизма, политик хранения и колебаний пропускной способности ингестии. Всегда отслеживайте использование ресурсов и масштабируйте систему по мере необходимости.

Все показатели основаны на несжатом исходном объёме приёма

Все значения на этой странице — пропускная способность (MB/s, TB/month), размер CPU и объём хранилища — выражены через несжатый исходный объём приёма, то есть размер данных в том виде, в котором они создаются вашими приложениями и отправляются в OpenTelemetry collector до применения какого-либо сжатия.

Именно этот показатель следует оценивать на основе ваших существующих конвейеров логов, трейсов и метрик. Значения объёма хранилища в таблице ниже уже рассчитаны с применением предполагаемого 10-кратного коэффициента сжатия к этому исходному объёму.

При развертывании ClickStack выделяйте вычислительные ресурсы под две независимые рабочие нагрузки: приём и запросы.

Рабочая нагрузка	Оценка ресурсов
Приём	1 vCPU на каждые 10 MB/s устойчивой пропускной способности приёма
Запросы	1 vCPU на 1 QPS и на каждые 10 MB/s устойчивой пропускной способности приёма

Изоляция запросов и приёма

В большинстве самоуправляемых развертываний приём и запросы используют одни и те же узлы. В этом случае используйте общее число CPU как базовую точку отсчёта. Изолированное масштабирование — при котором вычислительные ресурсы для приёма и запросов выделяются независимо — поддерживается в ClickHouse Cloud через отдельные вычислительные пулы, также называемые хранилищами.

Допущения

• 10-кратный коэффициент сжатия для хранилища — обычно это консервативная оценка для логов и трейсов.
• SLA для запросов: P50 на уровне 1,5 секунды и P99 на уровне 5 секунд.
• Мы исходим из того, что большинство запросов выполняется по свежим данным и следует логнормальному распределению с пиком примерно через один час и спадом примерно к шести часам. Пользователям может потребоваться выделить отдельные вычислительные ресурсы для запросов к более старым данным. В ClickHouse Cloud такие ресурсы могут простаивать (и, следовательно, не создавать затрат), когда не используются.
• Хотя вычислительные ресурсы для запросов можно масштабировать независимо от ресурсов для приёма, они по-прежнему напрямую связаны с объёмом приёма. Мы предполагаем, что по мере роста приёма увеличивается плотность данных, что приводит к большим объёмам сканирования во время выполнения запросов и, как следствие, к более высоким требованиям к вычислительным ресурсам для запросов.

В следующей таблице приведены примеры размеров ресурсов на основе роста пропускной способности приёма в мегабайтах в секунду, а также соответствующие объёмы данных в терабайтах в месяц. Предполагается устойчивое среднее значение 1 QPS в ClickStack для всех типов запросов (поиск, дашборды, оповещения).

MB/s	TB/month	CPU для приёма	CPU для запросов	Всего CPU	Общее хранилище (в месяц) (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

После того как вы укажете требования, ваш управляемый сервис ClickStack будет подготовлен в течение нескольких минут. Пока идёт подготовка, вы можете изучить остальную часть ClickHouse Cloud console.

Подробнее о том, как уточнить предположения по подбору размеров для вашей среды, см. в разделе "Уточнение предположений по подбору размеров для вашей среды".

После завершения подготовки опция 'ClickStack' в левом меню будет доступна.

Настройте ингестию

После создания сервиса убедитесь, что он выбран, и нажмите "ClickStack" в левом меню.

Выберите "Начать ингестию", после чего вам будет предложено выбрать источник ингестии. Управляемый ClickStack поддерживает OpenTelemetry и Vector как основные источники ингестии. Однако пользователи также могут отправлять данные напрямую в ClickHouse в собственной схеме, используя любую из интеграций, поддерживаемых ClickHouse Cloud.

Рекомендуется OpenTelemetry

Использование формата OpenTelemetry настоятельно рекомендуется для ингестии. Он обеспечивает самый простой и оптимизированный рабочий процесс с готовыми схемами, которые специально спроектированы для эффективной работы с ClickStack.

OpenTelemetry

Для отправки данных OpenTelemetry в управляемый ClickStack рекомендуется использовать OpenTelemetry Collector. Коллектор действует как шлюз, принимающий данные OpenTelemetry от ваших приложений (и других коллекторов) и передающий их в ClickHouse Cloud.

Если у вас еще не запущен коллектор, запустите его, выполнив приведенные ниже шаги. Если у вас уже есть работающие коллекторы, также предоставлен пример конфигурации.

Запустите коллектор

Далее предполагается рекомендуемый подход с использованием дистрибутива OpenTelemetry Collector от ClickStack, который включает дополнительную обработку и оптимизирован специально для ClickHouse Cloud. Если вы планируете использовать собственный OpenTelemetry Collector, см. раздел "Настройка существующих коллекторов."

Чтобы быстро начать работу, скопируйте и выполните показанную команду Docker.

Эта команда будет содержать предварительно заполненные учетные данные для подключения.

Развертывание в production

Хотя эта команда использует пользователя default для подключения к Managed ClickStack, при переходе в production следует создать отдельного пользователя и изменить конфигурацию.

Выполнение этой команды запускает коллектор ClickStack с конечными точками OTLP, доступными на портах 4317 (gRPC) и 4318 (HTTP). Если у вас уже настроены инструментация и агенты OpenTelemetry, вы можете сразу начать отправку телеметрических данных на эти конечные точки.

Настройте существующие коллекторы

Также можно настроить собственные существующие коллекторы OpenTelemetry или использовать собственный дистрибутив коллектора.

Требуется экспортер ClickHouse

Если вы используете собственный дистрибутив, например contrib-образ, убедитесь, что он включает экспортер ClickHouse.

Для этого предоставлен пример конфигурации OpenTelemetry Collector, использующий экспортер ClickHouse с соответствующими настройками и предоставляющий OTLP-приемники. Данная конфигурация соответствует интерфейсам и поведению, ожидаемым дистрибутивом 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:
  debug:
    verbosity: detailed
    sampling_initial: 5
    sampling_thereafter: 200
  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]

Для получения дополнительной информации по настройке коллекторов OpenTelemetry см. раздел "Ingesting with OpenTelemetry."

Запустите процесс ингестии (необязательно)

Если у вас есть существующие приложения или инфраструктура, которые нужно инструментировать с помощью OpenTelemetry, перейдите к соответствующим руководствам, на которые есть ссылки в UI.

Чтобы инструментировать приложения для сбора трассировок и логов, используйте поддерживаемые языковые SDKs, которые отправляют данные в ваш OpenTelemetry Collector, выступающий шлюзом для приёма данных в Managed ClickStack.

Логи можно собирать с помощью OpenTelemetry Collectors, запущенных в режиме агента и перенаправляющих данные в тот же коллектор. Для мониторинга Kubernetes используйте специальное руководство. Для других интеграций см. наши руководства по быстрому старту.

Демонстрационные данные

В качестве альтернативы, если у вас нет существующих данных, попробуйте один из наших тестовых наборов данных.

• Пример набора данных — загрузите пример набора данных из нашего публичного демо и продиагностируйте простую проблему.
• Локальные файлы и метрики — загрузите локальные файлы и отслеживайте состояние системы под управлением OSX или Linux, используя локальный OTel collector.

Vector

Vector — это высокопроизводительный, независимый от вендора конвейер данных для обсервабилити, особенно популярный для ингестии логов благодаря своей гибкости и низким требованиям к ресурсам.

При использовании Vector с ClickStack пользователи сами отвечают за определение собственных схем. Эти схемы могут соответствовать соглашениям OpenTelemetry, но также могут быть полностью настраиваемыми, представляя пользовательские структуры событий.

Требуется временная метка

Единственное строгое требование для Managed ClickStack заключается в том, что данные должны содержать столбец временной метки (или эквивалентное поле времени), который можно задать при настройке источника данных в ClickStack UI.

Далее предполагается, что у вас уже запущен экземпляр Vector, предварительно настроенный с конвейерами ингестии, которые доставляют данные.

Создайте базу данных и таблицу

Vector требует, чтобы таблица и схема были определены до начала ингестии данных.

Сначала создайте базу данных. Это можно сделать через консоль ClickHouse Cloud.

Например, создайте базу данных для логов:

CREATE DATABASE IF NOT EXISTS logs

Затем создайте таблицу со схемой, соответствующей структуре ваших логов. В приведённом ниже примере используется классический формат access-логов 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);

Ваша таблица должна соответствовать результирующей схеме, создаваемой Vector. При необходимости скорректируйте схему под ваши данные, следуя рекомендуемым практикам по выбору схемы.

Настоятельно рекомендуется разобраться, как работают Primary keys в ClickHouse, и выбрать ключ сортировки на основе ваших сценариев доступа. См. также рекомендации специфичные для ClickStack по выбору первичного ключа.

После создания таблицы скопируйте показанный фрагмент конфигурации. Скорректируйте input, чтобы он использовал ваши существующие пайплайны, а также целевую таблицу и базу данных при необходимости. Учетные данные будут предзаполнены.

Для получения дополнительных примеров приёма данных с помощью Vector см. "Ingesting with Vector" или документацию по приёмнику ClickHouse для Vector для расширенных возможностей настройки.

Перейдите в пользовательский интерфейс ClickStack

Выберите 'Launch ClickStack', чтобы открыть UI ClickStack (HyperDX). Вы будете автоматически аутентифицированы и перенаправлены.

OpenTelemetry

Источники данных будут предварительно созданы для любых данных OpenTelemetry.

Vector

Если вы используете Vector, вам потребуется создать собственные источники данных. При первом входе вам будет предложено создать один. Ниже приведён пример конфигурации источника данных для логов.

В этой конфигурации предполагается схема в стиле Nginx с использованием столбца time_local в качестве временной метки. По возможности это должен быть столбец временной метки, объявленный в первичном ключе. Этот столбец обязателен.

Мы также рекомендуем обновить Default SELECT, чтобы явно определить, какие столбцы возвращаются в представлении логов. Если доступны дополнительные поля, такие как имя сервиса, уровень логирования или столбец с телом сообщения, их также можно настроить. Столбец отображения временной метки также может быть переопределён, если он отличается от столбца, используемого в первичном ключе таблицы и настроенного выше.

В приведённом выше примере столбец Body в данных отсутствует. Вместо этого он определяется с помощью SQL-выражения, которое реконструирует строку лога Nginx из доступных полей.

Другие возможные варианты см. в справочнике по конфигурации.

После создания вы будете перенаправлены в представление поиска, где сможете сразу начать исследовать свои данные.

Вот и всё — вы готовы к работе. 🎉

Исследуйте ClickStack: начинайте поиск по логам и трейсам, смотрите, как логи, трейсы и метрики коррелируют в режиме реального времени, создавайте дашборды, изучайте карты сервисов, выявляйте дельты и паттерны событий и настраивайте алерты, чтобы опережать инциденты.

Использовать существующий сервис

Выберите сервис

На главной странице ClickHouse Cloud выберите сервис, для которого требуется включить управляемый ClickStack.

Оценка ресурсов

Данное руководство предполагает, что вы выделили достаточные ресурсы для обработки объёма данных обсервабилити, которые планируете принимать и запрашивать с помощью ClickStack. Для оценки необходимых ресурсов обратитесь к руководству Оценка ресурсов.

Если ваш сервис ClickHouse уже обслуживает существующие рабочие нагрузки, например, аналитику приложений в реальном времени, рекомендуется создать дочерний сервис с помощью функции warehouses в ClickHouse Cloud для изоляции нагрузки обсервабилити. Это обеспечит бесперебойную работу существующих приложений, сохраняя при этом доступность датасетов из обоих сервисов.

Перейдите в пользовательский интерфейс ClickStack

Выберите 'ClickStack' в меню навигации слева. Вы будете перенаправлены в интерфейс ClickStack и автоматически авторизованы на основе ваших прав доступа ClickHouse Cloud.

Если в вашем сервисе уже существуют таблицы OpenTelemetry, они будут обнаружены автоматически, и для них будут созданы соответствующие источники данных.

Автообнаружение источников данных

Автообнаружение использует стандартную схему таблиц OpenTelemetry, предоставляемую дистрибутивом ClickStack коллектора OpenTelemetry. Источники создаются для базы данных с наиболее полным набором таблиц. При необходимости дополнительные таблицы можно добавить как отдельные источники данных.

При успешном автоматическом обнаружении вы будете перенаправлены в представление поиска, где сможете сразу приступить к исследованию данных.

Если этот шаг выполнен успешно, то на этом всё — всё готово 🎉, в противном случае переходите к настройке ингестии.

Настройте ингестию

Если автоматическое обнаружение завершится неудачей или у вас нет существующих таблиц, вам будет предложено настроить ингестию.

Выберите "Start Ingestion", и вам будет предложено выбрать источник для ингестии. Управляемый ClickStack поддерживает OpenTelemetry и Vector в качестве основных источников ингестии. Однако пользователи также могут отправлять данные напрямую в ClickHouse по собственной схеме, используя любую из интеграций, поддерживаемых ClickHouse Cloud.

Рекомендуется OpenTelemetry

Настоятельно рекомендуется использовать OpenTelemetry в качестве формата ингестии. Это обеспечивает наиболее простой и оптимизированный опыт работы с готовыми схемами, специально разработанными для эффективной работы с ClickStack.

OpenTelemetry

Чтобы отправлять данные OpenTelemetry в Managed ClickStack, рекомендуется использовать OpenTelemetry Collector. Collector выступает в роли шлюза, который получает данные OpenTelemetry от ваших приложений (и других коллекторов) и пересылает их в ClickHouse Cloud.

Если у вас ещё не запущен collector, запустите его, выполнив шаги ниже. Если у вас уже есть существующие коллекторы, также приведён пример конфигурации.

Запустить collector

Далее предполагается рекомендуемый путь использования дистрибутива ClickStack OpenTelemetry Collector, который включает дополнительную обработку и оптимизирован специально для ClickHouse Cloud. Если вы планируете использовать собственный OpenTelemetry Collector, см. раздел "Configure existing collectors."

Чтобы быстро начать, скопируйте и выполните показанную команду Docker.

Измените эту команду, подставив учётные данные сервиса, которые вы сохранили при его создании.

Развёртывание в production

Хотя в этой команде используется пользователь default для подключения к Managed ClickStack, при переходе в production следует создать выделенного пользователя и изменить конфигурацию.

Выполнение этой единственной команды запускает ClickStack collector с OTLP-эндпоинтами, доступными на портах 4317 (gRPC) и 4318 (HTTP). Если у вас уже есть инструментация и агенты OpenTelemetry, вы можете сразу начинать отправлять телеметрию на эти эндпоинты.

Настроить существующие коллекторы

Также можно настроить ваши уже существующие OpenTelemetry Collectors или использовать собственный дистрибутив collector.

Требуется ClickHouse exporter

Если вы используете собственный дистрибутив, например contrib image, убедитесь, что он включает ClickHouse exporter.

Для этой цели приведён пример конфигурации OpenTelemetry Collector, который использует ClickHouse exporter с соответствующими настройками и предоставляет OTLP-приёмники. Эта конфигурация соответствует интерфейсам и поведению, ожидаемым дистрибутивом 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:
  debug:
    verbosity: detailed
    sampling_initial: 5
    sampling_thereafter: 200
  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]

Для получения дополнительной информации по настройке OpenTelemetry collectors см. раздел "Ingesting with OpenTelemetry."

Запуск ингестии (необязательно)

Если у вас уже есть приложения или инфраструктура, которые нужно инструментировать с помощью OpenTelemetry, перейдите к соответствующим руководствам по ссылкам из раздела "Connect an application".

Чтобы инструментировать приложения для сбора трассировок и логов, используйте поддерживаемые языковые SDKs, которые отправляют данные в ваш OpenTelemetry Collector, выступающий шлюзом для приёма данных в Managed ClickStack.

Логи можно собирать с помощью OpenTelemetry Collectors, работающих в режиме агента и пересылающих данные в тот же collector. Для мониторинга Kubernetes следуйте специальному руководству. Для других интеграций см. наши руководства по быстрому старту.

Vector

Vector — это высокопроизводительный, независимый от поставщика конвейер данных обсервабилити, особенно популярный для приёма логов благодаря своей гибкости и низкому потреблению ресурсов.

При использовании Vector с ClickStack пользователи сами отвечают за определение собственных схем. Эти схемы могут следовать соглашениям OpenTelemetry, но также могут быть полностью пользовательскими, представляя пользовательские структуры событий.

Требуется метка времени

Единственное строгое требование для Managed ClickStack состоит в том, что данные должны содержать столбец с меткой времени (или эквивалентное поле времени), который можно задать при настройке источника данных в интерфейсе ClickStack.

Далее предполагается, что у вас уже запущен экземпляр Vector, предварительно сконфигурированный с конвейерами приёма и доставляющий данные.

Создать базу данных и таблицу

Vector требует, чтобы таблица и схема были определены до начала ингестии данных.

Сначала создайте базу данных. Это можно сделать через консоль ClickHouse Cloud.

Например, создайте базу данных для логов:

CREATE DATABASE IF NOT EXISTS logs

Затем создайте таблицу со схемой, соответствующей структуре ваших логов. В примере ниже предполагается классический формат access-логов 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);

Ваша таблица должна соответствовать схеме выходных данных, формируемой Vector. При необходимости скорректируйте схему под ваши данные, следуя рекомендуемым передовым практикам проектирования схемы.

Настоятельно рекомендуем разобраться, как работают Primary keys в ClickHouse, и выбрать ключ упорядочивания в соответствии с вашими сценариями доступа. См. рекомендации специфичные для ClickStack по выбору первичного ключа.

После создания таблицы скопируйте показанный фрагмент конфигурации. Настройте input для чтения из ваших существующих конвейеров, а также целевую таблицу и базу данных, если это требуется. Учётные данные должны быть подставлены автоматически.

Для дополнительных примеров приёма данных с помощью Vector см. "Ingesting with Vector" или документацию по Vector ClickHouse sink для расширенных возможностей.

Перейдите в пользовательский интерфейс ClickStack

После завершения настройки ингестии и начала отправки данных выберите "Next".

OpenTelemetry

Если вы осуществили приём данных OpenTelemetry, следуя этому руководству, источники данных будут созданы автоматически, и дополнительная настройка не потребуется. Вы можете сразу начинать работу с ClickStack. Вы будете перенаправлены в интерфейс поиска с автоматически выбранным источником, чтобы вы могли немедленно начать выполнять запросы.

На этом всё — вы полностью готовы 🎉.

Vector

Если вы выполняли приём данных с помощью Vector или из другого источника, вам будет предложено настроить источник данных.

Конфигурация выше предполагает схему в стиле Nginx с использованием столбца time_local в качестве метки времени. По возможности это должен быть столбец метки времени, объявленный в первичном ключе. Этот столбец является обязательным.

Мы также рекомендуем обновить Default SELECT, чтобы явно определить, какие столбцы возвращаются в представлении логов. Если доступны дополнительные поля, такие как имя сервиса, уровень логирования или столбец с телом сообщения, их также можно сконфигурировать. Отображаемый столбец метки времени также можно переопределить, если он отличается от столбца, используемого в первичном ключе таблицы и указанного выше.

В приведённом выше примере столбец Body в данных отсутствует. Вместо этого он определяется с использованием SQL-выражения, которое восстанавливает строку журнала Nginx из доступных полей.

Другие возможные варианты см. в справочнике по конфигурации.

После настройки источника нажмите "Save" и начните исследовать свои данные.

Дополнительные задачи

Предоставление доступа к Managed ClickStack

1. Перейдите к своему сервису в консоли ClickHouse Cloud
2. Откройте раздел Settings → SQL Console Access
3. Установите соответствующий уровень прав доступа для каждого пользователя:
   • Service Admin → Full Access — требуется для включения оповещений
   • Service Read Only → Read Only — может просматривать данные обсервабилити и создавать дашборды
   • No access — не имеет доступа к HyperDX

Для оповещений требуется доступ администратора

Чтобы включить оповещения, как минимум один пользователь с правами Service Admin (соответствует Full Access в выпадающем списке SQL Console Access) должен хотя бы один раз войти в HyperDX. При этом в базе данных создаётся выделенный пользователь, выполняющий запросы для оповещений.

Использование ClickStack с вычислительными ресурсами только для чтения

Веб-интерфейс ClickStack может полностью работать на сервисе ClickHouse Cloud только для чтения. Это рекомендуемая конфигурация, если вы хотите изолировать нагрузки на ингестию и выполнение запросов.

Как ClickStack выбирает вычислительные ресурсы

Интерфейс ClickStack всегда подключается к сервису ClickHouse, из которого он был запущен в консоли ClickHouse Cloud.

Это означает:

• Если вы открываете ClickStack из сервиса только для чтения (read-only), все запросы, выполняемые интерфейсом ClickStack, будут выполняться на соответствующих вычислительных ресурсах только для чтения.
• Если вы открываете ClickStack из сервиса с поддержкой чтения и записи (read-write), ClickStack будет использовать связанные с ним вычислительные ресурсы.

Для обеспечения режима только для чтения (read-only) не требуется дополнительная конфигурация внутри ClickStack.

Рекомендуемая конфигурация

Чтобы запустить ClickStack на вычислительных ресурсах в режиме только для чтения:

1. Создайте или выберите сервис ClickHouse Cloud в warehouse, настроенный в режиме только для чтения.
2. В консоли ClickHouse Cloud выберите этот read-only сервис.
3. Запустите ClickStack из левого навигационного меню.

После запуска пользовательский интерфейс ClickStack автоматически подключится к этому сервису только для чтения.

Добавление дополнительных источников данных

ClickStack нативно интегрирован с OpenTelemetry, но не ограничивается только им — при необходимости вы можете использовать собственные схемы таблиц.

Ниже описано, как можно добавить дополнительные источники данных помимо тех, которые настраиваются автоматически.

Использование схем OpenTelemetry

Если вы используете OTel collector для создания базы данных и таблиц в ClickHouse, сохраните все значения по умолчанию в форме создания источника, заполнив поле Table значением otel_logs — для создания источника логов. Все остальные настройки должны определяться автоматически, после чего вы сможете нажать Save New Source.

Чтобы создать источники для трейсов и метрик OTel, выберите Создать Новый Источник в верхнем меню.

Здесь выберите требуемый тип источника, а затем соответствующую таблицу, например, для трейсов выберите таблицу otel_traces. Все настройки должны определяться автоматически.

Корреляция источников

Обратите внимание, что разные источники данных в ClickStack — такие как логи и трейсы — можно коррелировать друг с другом. Чтобы это включить, необходима дополнительная конфигурация для каждого источника. Например, в источнике логов вы можете указать соответствующий источник трейсов и наоборот — в источнике трейсов. Подробнее см. раздел "Коррелированные источники".

Использование пользовательских схем

Пользователи, которые хотят подключить ClickStack к существующему сервису с данными, могут настроить базу данных и таблицы соответствующим образом. Настройки будут автоматически определены, если таблицы соответствуют схемам OpenTelemetry для ClickHouse.

При использовании собственной схемы рекомендуется создать источник Logs и убедиться, что указаны все необходимые поля — подробности см. в разделе "Log source settings".

Поддержка типа JSON

Beta feature. Learn more.

Beta Feature - not production ready

Поддержка типа JSON в ClickStack находится в статусе бета-версии. Хотя сам тип JSON готов к промышленной эксплуатации в ClickHouse 25.3+, его интеграция в ClickStack всё ещё активно разрабатывается и может иметь ограничения, изменяться в будущем или содержать ошибки.

Поддержка типа JSON в ClickStack доступна в статусе бета-версии, начиная с версии 2.0.4.

О преимуществах этого типа см. раздел Преимущества типа JSON.

Чтобы включить поддержку типа JSON, вам необходимо задать следующие переменные окружения:

• OTEL_AGENT_FEATURE_GATE_ARG='--feature-gates=clickhouse.json' — включает поддержку в OTel collector, гарантируя, что схемы создаются с использованием типа JSON.
• BETA_CH_OTEL_JSON_SCHEMA_ENABLED=true (только ClickStack Open Source) — включает поддержку в приложении ClickStack UI, позволяя выполнять запросы к данным JSON.

Кроме того, вам следует связаться с support@clickhouse.com, чтобы убедиться, что поддержка JSON включена в вашем сервисе ClickHouse Cloud.