Начало работы с Managed ClickStack

Beta feature. Learn more.

Самый простой способ начать — развернуть Managed ClickStack в ClickHouse Cloud, что обеспечивает полностью управляемый, безопасный бекенд при сохранении полного контроля над ингестией, схемой и обсервабилити-процессами. Это устраняет необходимость самостоятельной эксплуатации ClickHouse и даёт ряд преимуществ:

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

Чтобы создать сервис Managed ClickStack в ClickHouse Cloud, сначала выполните первый шаг из руководства по быстрому старту ClickHouse Cloud.

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
Vector

Для отправки данных 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]

Расширенный источник данных для OTel collector

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

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

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

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

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

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

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

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

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
Vector

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

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

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

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

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

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

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

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

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

Дальнейшие шаги

Запишите учётные данные по умолчанию

Если вы не записали свои учётные данные по умолчанию на предыдущих шагах, перейдите к сервису и выберите Connect, зафиксировав пароль и HTTP- и native-эндпоинты. Сохраните эти административные учётные данные в надёжном месте — их можно будет повторно использовать в следующих руководствах.

Для выполнения задач, таких как создание новых пользователей или добавление дополнительных источников данных, см. руководство по развёртыванию Managed ClickStack.

Зарегистрируйтесь в ClickHouse Cloud​

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

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

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

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

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

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

Перейдите в интерфейс ClickStack​

Дальнейшие шаги​

Зарегистрируйтесь в ClickHouse Cloud