Перейти к основному содержанию
Попробуйте OTel FYI — простую и понятную документацию по OTel collectorOTel FYI предлагает ясную и лаконичную документацию по OpenTelemetry Collector, охватывающую приёмники, processors, exporters и pipelines. Это отличный дополнительный ресурс для настройки вашего коллектора ClickStack OTel.
На этой странице приведены сведения о настройке официального коллектора ClickStack OpenTelemetry (OTel).

​
Роли коллектора

Коллекторы OpenTelemetry можно развертывать в двух основных ролях:
  • Агент - Экземпляры агента собирают данные на периферии, например на серверах или узлах Kubernetes, либо получают события напрямую от приложений, инструментированных с помощью OpenTelemetry SDK. В последнем случае экземпляр агента запускается вместе с приложением или на том же хосте, что и приложение (например, как сайдкар или ДемонСет). Агенты могут отправлять данные либо напрямую в ClickHouse, либо в экземпляр шлюза. В первом случае это называется шаблоном развертывания агента.
  • Шлюз - Экземпляры шлюза предоставляют автономный сервис (например, развертывание в Kubernetes), как правило, на каждый кластер, центр обработки данных или регион. Они получают события от приложений (или других коллекторов, работающих как агенты) через единую конечную точку OTLP. Обычно развертывается набор экземпляров шлюза, а для распределения нагрузки между ними используется стандартный балансировщик нагрузки. Если все агенты и приложения отправляют свои сигналы в эту единую конечную точку, это часто называется шаблоном развертывания шлюза.
Важно: коллектор, включая стандартные дистрибутивы ClickStack, предполагает описанную ниже роль шлюза и принимает данные от агентов или SDK. Пользователи, развертывающие OTel collector в роли агента, обычно используют стандартный contrib-дистрибутив коллектора, а не версию ClickStack, но также могут использовать другие совместимые с OTLP технологии, такие как Fluentd и Vector.

​
Развертывание коллектора


При отправке данных в Управляемый ClickStack мы рекомендуем использовать официальный дистрибутив коллектора ClickStack в роли шлюза, где это возможно. Если вы предпочитаете использовать собственный коллектор, убедитесь, что он включает ClickHouse exporter.Коллектор можно развернуть с помощью Helm (рекомендуется для Kubernetes) или Docker. Официальный Helm-чарт ClickStack включает upstream-Helm-чарт OpenTelemetry Collector в качестве субчарта с предварительно настроенным образом дистрибутива ClickStack — см. руководство по развертыванию ClickStack через Helm, если вы хотите установить полный стек, включая HyperDX. Для автономного развертывания коллектора upstream-чарт можно использовать напрямую с образом ClickStack, как показано ниже.
Добавьте официальный Helm-репозиторий OpenTelemetry:
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update
Создайте values.yaml, указав образ ClickStack и учетные данные Управляемого ClickStack:
# values.yaml
mode: deployment

image:
  repository: docker.clickhouse.com/clickhouse/clickstack-otel-collector
  tag: "2.19.0"

ports:
  otlp:
    enabled: true
  otlp-http:
    enabled: true

extraEnvs:
  - name: CLICKHOUSE_ENDPOINT
    value: "https://your-instance.clickhouse.cloud:8443"
  - name: CLICKHOUSE_USER
    value: "default"
  - name: CLICKHOUSE_PASSWORD
    value: "<password>"
Установите чарт:
helm install clickstack-otel-collector open-telemetry/opentelemetry-collector -f values.yaml
Для развертываний в продакшн мы рекомендуем хранить CLICKHOUSE_PASSWORD в секрете Kubernetes и ссылаться на него через extraEnvsFrom, а не указывать значение напрямую.
Целевой экземпляр ClickHouse настраивается через переменные среды CLICKHOUSE_ENDPOINT, CLICKHOUSE_USERNAME и CLICKHOUSE_PASSWORD. Переменная CLICKHOUSE_ENDPOINT должна содержать полный HTTP-адрес конечной точки ClickHouse Cloud, включая протокол и порт — например, https://99rr6dm6v3.us-central1.gcp.clickhouse.cloud:8443.Подробнее о получении учётных данных Управляемого ClickStack см. здесь.
Пользователь для продакшнаВ продакшне следует использовать пользователя с подходящими учётными данными.

​
Изменение конфигурации

​
Настройка экземпляра Управляемого ClickStack

OpenTelemetry Collector можно настроить для использования экземпляра Управляемого ClickStack с помощью переменных окружения CLICKHOUSE_ENDPOINT, CLICKHOUSE_USERNAME и CLICKHOUSE_PASSWORD. Способ их настройки зависит от метода развертывания:
Переопределите соответствующие значения в разделе extraEnvs файла values.yaml, затем обновите релиз:
# values.yaml
extraEnvs:
  - name: CLICKHOUSE_ENDPOINT
    value: "<HTTPS_ENDPOINT>"
  - name: CLICKHOUSE_USER
    value: "<CLICKHOUSE_USER>"
  - name: CLICKHOUSE_PASSWORD
    value: "<CLICKHOUSE_PASSWORD>"

helm upgrade clickstack-otel-collector open-telemetry/opentelemetry-collector -f values.yaml

​
Расширение конфигурации OTel collector

Дистрибутив ClickStack с OTel collector поддерживает расширение базовой конфигурации за счёт монтирования пользовательского файла конфигурации и задания переменной окружения.Чтобы добавить пользовательские приёмники, процессоры или конвейеры:
  1. Создайте пользовательский файл конфигурации с дополнительными настройками
  2. Смонтируйте файл по пути /etc/otelcol-contrib/custom.config.yaml
  3. Задайте переменную окружения CUSTOM_OTELCOL_CONFIG_FILE=/etc/otelcol-contrib/custom.config.yaml
Пример пользовательской конфигурации:
receivers:
  # Сбор журналов из локальных файлов
  filelog:
    include:
      - /var/log/**/*.log
      - /var/log/syslog
      - /var/log/messages
    start_at: beginning

  # Сбор метрик хост-системы
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
        metrics:
          system.cpu.utilization:
            enabled: true
      memory:
        metrics:
          system.memory.utilization:
            enabled: true
      disk:
      network:
      filesystem:
        metrics:
          system.filesystem.utilization:
            enabled: true

service:
  pipelines:
    # Конвейер журналов
    logs/host:
      receivers: [filelog]
      processors:
        - memory_limiter
        - transform
        - batch
      exporters:
        - clickhouse
    
    # Конвейер метрик
    metrics/hostmetrics:
      receivers: [hostmetrics]
      processors:
        - memory_limiter
        - batch
      exporters:
        - clickhouse
Разверните автономный коллектор:
docker run -d \
  -e CUSTOM_OTELCOL_CONFIG_FILE=/etc/otelcol-contrib/custom.config.yaml \
  # -e OPAMP_SERVER_URL=${OPAMP_SERVER_URL} \
  -e CLICKHOUSE_ENDPOINT=${CLICKHOUSE_ENDPOINT} \
  -e CLICKHOUSE_USER=default \
  -e CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD} \
  -v "$(pwd)/custom-config.yaml:/etc/otelcol-contrib/custom.config.yaml:ro" \
  -p 4317:4317 -p 4318:4318 \
  clickhouse/clickstack-otel-collector:latest
В пользовательской конфигурации вы определяете только новые приёмники, процессоры и конвейеры. Базовые процессоры (memory_limiter, batch) и экспортёры (clickhouse) уже определены — обращайтесь к ним по имени. Пользовательская конфигурация объединяется с базовой и не может переопределять существующие компоненты.
Для более сложных конфигураций см. конфигурацию коллектора ClickStack по умолчанию и документацию экспортёра ClickHouse.

​
Структура конфигурации

Подробную информацию о настройке коллекторов OTel, включая приёмники, operators и процессоры, рекомендуем смотреть в официальной документации OpenTelemetry Collector.

​
Docker Compose

При использовании Docker Compose измените конфигурацию коллектора, используя те же переменные среды, что указаны выше:
otel-collector:
    image: hyperdx/hyperdx-otel-collector
    environment:
      CLICKHOUSE_ENDPOINT: 'https://mxl4k3ul6a.us-east-2.aws.clickhouse-staging.com:8443'
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      CLICKHOUSE_USER: 'default'
      CLICKHOUSE_PASSWORD: 'password'
      CUSTOM_OTELCOL_CONFIG_FILE: '/etc/otelcol-contrib/custom.config.yaml'
    ports:
      - '13133:13133' # расширение health_check
      - '24225:24225' # приёмник fluentd
      - '4317:4317' # приёмник OTLP gRPC
      - '4318:4318' # приёмник OTLP HTTP
      - '8888:8888' # расширение метрик
    volumes:
      - ./custom-config.yaml:/etc/otelcol-contrib/custom.config.yaml:ro
    restart: always
    networks:
      - internal

​
Защита коллектора

По умолчанию коллектор ClickStack OpenTelemetry при развертывании вне дистрибутивов с открытым исходным кодом не защищён и не требует аутентификации на своих портах OTLP.Чтобы защитить ингестию, укажите токен аутентификации при развертывании коллектора с помощью переменной окружения OTLP_AUTH_TOKEN. Способ настройки зависит от метода развертывания:
Добавьте OTLP_AUTH_TOKEN в extraEnvs вашего values.yaml, затем обновите релиз:
# values.yaml
extraEnvs:
  - name: OTLP_AUTH_TOKEN
    value: "a_very_secure_string"
  - name: CLICKHOUSE_ENDPOINT
    value: "<HTTPS_ENDPOINT>"
  - name: CLICKHOUSE_USER
    value: "<CLICKHOUSE_USER>"
  - name: CLICKHOUSE_PASSWORD
    value: "<CLICKHOUSE_PASSWORD>"

helm upgrade clickstack-otel-collector open-telemetry/opentelemetry-collector -f values.yaml
Для развертываний в продакшн мы рекомендуем хранить OTLP_AUTH_TOKEN и CLICKHOUSE_PASSWORD в Kubernetes secret и ссылаться на них через extraEnvsFrom.
Мы также рекомендуем:
  • Настроить обмен данными между коллектором и ClickHouse по HTTPS.
  • Создать отдельного пользователя для ингестии с ограниченными разрешениями — см. ниже.
  • Включить TLS для конечной точки OTLP, чтобы обеспечить шифрованную связь между SDKs/агентами и коллектором. Это можно настроить через пользовательскую конфигурацию коллектора.

​
Создание пользователя для ингестии

Мы рекомендуем создать отдельную базу данных и пользователя для OTel collector для ингестии в Управляемый ClickStack. Ему следует выдать разрешения на создание и вставку данных в таблицы, создаваемые и используемые ClickStack.
CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY 'ClickH0u3eRocks123!';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;
Здесь предполагается, что коллектор настроен на использование базы данных otel. Это можно задать с помощью переменной окружения HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE. Передайте её в коллектор аналогично другим переменным окружения.

​
Обработка — фильтрация, преобразование и обогащение

Пользователям неизбежно потребуется фильтровать, преобразовывать и обогащать сообщения событий во время ингестии. Поскольку конфигурацию коннектора ClickStack изменить нельзя, пользователям, которым нужна дополнительная фильтрация и обработка событий, мы рекомендуем один из следующих вариантов:
  • Развернуть собственную версию OTel collector, которая выполняет фильтрацию и обработку, и отправлять события в коллектор ClickStack через OTLP для ингестии в ClickHouse.
  • Развернуть собственную версию OTel collector и отправлять события напрямую в ClickHouse с помощью ClickHouse exporter.
Если обработка выполняется с помощью OTel collector, мы рекомендуем выполнять преобразования на экземплярах шлюза и сводить к минимуму объём работы на экземплярах агента. Это позволит минимизировать требования к ресурсам агентов на периферии, работающих на серверах. Обычно пользователи выполняют в агентах только фильтрацию (чтобы сократить лишний сетевой трафик), установку временных меток (через операторы) и обогащение, требующее контекста. Например, если экземпляры шлюза находятся в другом кластере Kubernetes, обогащение k8s должно выполняться в агенте. OpenTelemetry поддерживает следующие возможности обработки и фильтрации, которые вы можете использовать:
  • Процессоры - Процессоры берут данные, собранные приёмниками, и изменяют или преобразуют их перед отправкой в экспортеры. Процессоры применяются в порядке, заданном в разделе processors конфигурации коллектора. Они необязательны, но обычно рекомендуется минимальный набор. При использовании OTel collector с ClickHouse мы рекомендуем ограничиться следующими процессорами:
  • memory_limiter используется для предотвращения ситуаций нехватки памяти в коллекторе. Рекомендации см. в разделе Оценка ресурсов.
  • Любой процессор, выполняющий обогащение на основе контекста. Например, Kubernetes Attributes Processor позволяет автоматически задавать атрибуты ресурса для spans, metrics и журналов на основе метаданных k8s, например обогащать события идентификатором исходного пода.
  • Tail или head sampling, если это требуется для трасс.
  • Базовая фильтрация - отбрасывание ненужных событий, если это нельзя сделать через оператор (см. ниже).
  • Батчинг - необходим при работе с ClickHouse, чтобы данные отправлялись батчами. См. “Оптимизация вставок”.
  • Операторы - Операторы представляют собой самую базовую единицу обработки, доступную на уровне приёмника. Поддерживается базовый парсинг, что позволяет задавать такие поля, как Severity и Timestamp. Здесь поддерживаются парсинг JSON и regex, а также фильтрация событий и базовые преобразования. Мы рекомендуем выполнять фильтрацию событий именно здесь.
Мы рекомендуем пользователям избегать чрезмерной обработки событий с помощью операторов или transform processors. Они могут создавать значительную нагрузку на память и CPU, особенно при парсинге JSON. В ClickHouse можно выполнять почти всю обработку во время вставки с помощью materialized views и столбцов, за некоторыми исключениями — в частности, обогащения с учётом контекста, например добавления метаданных k8s. Подробнее см. в разделе Извлечение структуры с помощью SQL.

​
Пример

В следующей конфигурации показан сбор данных из этого неструктурированного файла журнала. Эту конфигурацию может использовать коллектор, работающий в роли агента и отправляющий данные в шлюз ClickStack. Обратите внимание на использование операторов для извлечения структуры из строк журнала (regex_parser) и фильтрации событий, а также процессора для объединения событий в батчи и ограничения использования памяти.
file=code_snippets/ClickStack/config-unstructured-logs-with-processor.yaml
receivers:
  filelog:
    include:
      - /opt/data/logs/access-unstructured.log
    start_at: beginning
    operators:
      - type: regex_parser
        regex: '^(?P<ip>[\d.]+)\s+-\s+-\s+\[(?P<timestamp>[^\]]+)\]\s+"(?P<method>[A-Z]+)\s+(?P<url>[^\s]+)\s+HTTP/[^\s]+"\s+(?P<status>\d+)\s+(?P<size>\d+)\s+"(?P<referrer>[^"]*)"\s+"(?P<user_agent>[^"]*)"'
        timestamp:
          parse_from: attributes.timestamp
          layout: '%d/%b/%Y:%H:%M:%S %z'
          #22/Jan/2019:03:56:14 +0330
processors:
  batch:
    timeout: 1s
    send_batch_size: 10000
  memory_limiter:
    check_interval: 1s
    limit_mib: 2048
    spike_limit_mib: 256
exporters:
  # HTTP setup
  otlphttp/hdx:
    endpoint: 'http://localhost:4318'
    headers:
      authorization: <YOUR_INGESTION_API_KEY>
    compression: gzip

  # gRPC setup (alternative)
  otlp/hdx:
    endpoint: 'localhost:4317'
    headers:
      authorization: <YOUR_API_INGESTION_KEY>
    compression: gzip
service:
  telemetry:
    metrics:
      address: 0.0.0.0:9888 # Изменено, так как 2 коллектора работают на одном хосте
  pipelines:
    logs:
      receivers: [filelog]
      processors: [batch]
      exporters: [otlphttp/hdx]
Обратите внимание, что при любом взаимодействии по OTLP необходимо включать заголовок авторизации, содержащий ваш ключ API для приёма данных. Для более сложной настройки рекомендуем документацию OpenTelemetry Collector.

​
Оптимизация вставок

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

​
Пакетирование

По умолчанию каждая вставка, отправленная в ClickHouse, приводит к немедленному созданию части хранилища, содержащей данные вставки и другие метаданные, которые необходимо сохранить. Поэтому если отправлять меньше вставок, но с большим объёмом данных в каждой, а не больше вставок с меньшим объёмом данных, это сократит число необходимых операций записи. Мы рекомендуем вставлять данные достаточно крупными батчами — не менее 1 000 строк за раз. Подробнее здесь. По умолчанию вставки в ClickHouse синхронны и идемпотентны, если они идентичны. Для таблиц семейства движков MergeTree ClickHouse по умолчанию автоматически выполняет дедупликацию вставок. Это означает, что вставки устойчивы к следующим ситуациям:
  • (1) Если на узле, принимающем данные, возникают проблемы, запрос на вставку завершится по тайм-ауту (или вернёт более конкретную ошибку), и подтверждение получено не будет.
  • (2) Если узел записал данные, но из-за сетевых сбоев не может вернуть подтверждение отправителю запроса, отправитель получит либо тайм-аут, либо сетевую ошибку.
С точки зрения collector различить случаи (1) и (2) может быть сложно. Однако в обоих случаях вставку, для которой не было получено подтверждение, можно сразу повторить. Если повторный запрос на вставку содержит те же данные в том же порядке, ClickHouse автоматически проигнорирует повторную вставку, если исходная вставка (без подтверждения) прошла успешно. По этой причине дистрибутив ClickStack для OTel collector использует пакетный процессор. Это гарантирует, что вставки отправляются в виде согласованных батчей строк, соответствующих указанным выше требованиям. Если для collector ожидается высокая пропускная способность (событий в секунду) и в каждой вставке можно отправлять не менее 10 000 событий, обычно это единственное пакетирование, необходимое в конвейере. При наличии достаточного объёма памяти можно использовать значения до 100 000. В этом случае collector будет сбрасывать батчи до достижения timeout пакетного процессора, что обеспечивает низкую сквозную задержку конвейера и стабильный размер батчей.

​
Используйте асинхронные вставки

Обычно при низкой пропускной способности коллектора пользователям приходится отправлять меньшие батчи, но при этом они всё равно ожидают, что данные будут поступать в ClickHouse с минимальной сквозной задержкой. В таком случае небольшие батчи отправляются, когда истекает timeout пакетного процессора. Это может создавать проблемы — именно для таких случаев и нужны asynchronous inserts. Эта проблема редко возникает, если вы отправляете данные в коллектор ClickStack, работающий как шлюз: выступая в роли агрегаторов, такие коллекторы смягчают её — см. Роли коллектора. Если нельзя гарантировать большие батчи, можно делегировать пакетирование ClickHouse с помощью Asynchronous Inserts. При asynchronous inserts данные сначала попадают в буфер, а затем позже, то есть асинхронно, записываются в хранилище базы данных. Когда asynchronous inserts включены, ClickHouse ① при получении запроса на вставку ② сразу записывает данные запроса в буфер в памяти. Когда ③ происходит следующий flush буфера, данные из буфера сортируются и записываются как part в хранилище базы данных. Обратите внимание: до записи в хранилище базы данных эти данные недоступны для поиска запросами; flush буфера настраивается. Чтобы включить asynchronous inserts для коллектора, добавьте async_insert=1 в connection string. Мы рекомендуем использовать wait_for_async_insert=1 (значение по умолчанию), чтобы обеспечить гарантии доставки — подробнее см. здесь. Данные из async insert вставляются после flush буфера ClickHouse. Это происходит либо после превышения async_insert_max_data_size, либо через async_insert_busy_timeout_ms миллисекунд с момента первого INSERT-запроса. Если для async_insert_stale_timeout_ms задано ненулевое значение, данные вставляются через async_insert_stale_timeout_ms milliseconds с момента последнего запроса. Эти параметры можно настроить, чтобы управлять сквозной задержкой конвейера. Дополнительные параметры для настройки flush буфера описаны здесь. Как правило, значений по умолчанию достаточно.
Рассмотрите adaptive asynchronous insertsЕсли используется небольшое число агентов, пропускная способность невысока, а требования к сквозной задержке строгие, могут быть полезны adaptive asynchronous inserts. Как правило, они неприменимы к сценариям обсервабилити с высокой пропускной способностью, характерным для ClickHouse.
Наконец, прежнее поведение дедупликации, связанное с синхронными вставками в ClickHouse, по умолчанию не включается при использовании asynchronous inserts. При необходимости см. параметр async_insert_deduplicate. Полные сведения о настройке этой возможности можно найти на этой странице документации или в подробной статье в блоге.

​
Масштабирование

Коллектор ClickStack OTel выступает в роли экземпляра шлюза — см. Роли коллектора. Такие экземпляры предоставляют автономный сервис, обычно на каждый дата-центр или регион. Они принимают события от приложений (или других коллекторов в роли агента) через единую конечную точку OTLP. Обычно развертывается набор экземпляров коллектора, а для распределения нагрузки между ними используется встроенный балансировщик нагрузки. Цель этой архитектуры — вынести ресурсоемкую обработку с агентов, тем самым минимизируя потребление ими ресурсов. Эти шлюзы ClickStack могут выполнять задачи преобразования, которые в противном случае пришлось бы выполнять агентам. Кроме того, агрегируя события от множества агентов, шлюзы могут обеспечивать отправку в ClickHouse крупных батчей, что делает вставку более эффективной. Эти коллекторы-шлюзы легко масштабировать по мере добавления новых агентов и источников SDK, а также роста пропускной способности потока событий.

​
Добавление Kafka

Читатели могут заметить, что в приведённых выше архитектурах Kafka не используется в качестве очереди сообщений. Использование Kafka как буфера сообщений — популярный архитектурный паттерн, часто встречающийся в системах сбора журналов и ставший особенно популярным благодаря стеку ELK. Это даёт несколько преимуществ: прежде всего, помогает обеспечить более надёжные гарантии доставки сообщений и справляться с обратным давлением. Сообщения отправляются от агентов сбора в Kafka и записываются на диск. Теоретически кластер Kafka должен обеспечивать буфер сообщений с высокой пропускной способностью, поскольку последовательная запись данных на диск требует меньше вычислительных ресурсов, чем разбор и обработка сообщений. Например, в Elastic токенизация и индексация создают значительные накладные расходы. Кроме того, если убрать данные с агентов, снижается риск потери сообщений из-за ротации журналов в источнике. Наконец, Kafka поддерживает повторное воспроизведение сообщений и межрегиональную репликацию, что в некоторых сценариях может быть полезно. Однако ClickHouse способен вставлять данные очень быстро — миллионы строк в секунду даже на умеренном по мощности оборудовании. Обратное давление со стороны ClickHouse возникает редко. Во многих случаях использование очереди Kafka означает лишь дополнительную архитектурную сложность и затраты. Если вы готовы исходить из того, что журналам не нужны те же гарантии доставки, что банковским транзакциям и другим критически важным данным, мы рекомендуем избегать лишней сложности, связанной с Kafka. Тем не менее, если вам нужны высокие гарантии доставки или возможность повторного воспроизведения данных (возможно, в несколько источников), Kafka может стать полезным дополнением к архитектуре. В этом случае агенты OTel можно настроить на отправку данных в Kafka через экспортер Kafka. Экземпляры шлюза, в свою очередь, получают сообщения с помощью приёмника Kafka. За дополнительными подробностями рекомендуем обратиться к документации Confluent и OTel.
Конфигурация OTel collectorДистрибутив коллектора ClickStack OpenTelemetry можно настроить для работы с Kafka с помощью пользовательской конфигурации коллектора.

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

Требования к ресурсам для OTel collector зависят от пропускной способности по событиям, размера сообщений и объема обработки. Проект OpenTelemetry поддерживает бенчмарки, которые пользователи могут использовать для оценки требований к ресурсам. По нашему опыту, экземпляр шлюза ClickStack с 3 ядрами и 12 ГБ оперативной памяти может обрабатывать около 60 тыс. событий в секунду. Это предполагает минимальный конвейер обработки, отвечающий за переименование полей, без использования регулярных выражений. Для экземпляров агента, отвечающих за отправку событий в шлюз и только за установку временной метки события, мы рекомендуем подбирать размер исходя из ожидаемого количества журналов в секунду. Ниже приведены примерные значения, которые можно использовать в качестве отправной точки:
Скорость логированияРесурсы для агента collector
1k/second0.2CPU, 0.2GiB
5k/second0.5 CPU, 0.5GiB
10k/second1 CPU, 1GiB

​
Выбор схемы: Map vs JSON

По умолчанию коллектор ClickStack создаёт таблицы, в которых атрибуты хранятся в столбцах Map(LowCardinality(String), String). Это рекомендуемая схема для задач обсервабилити. Схема с типом JSON доступна в статусе бета для оценки на рабочих нагрузках с небольшим и стабильным набором ключей атрибутов. Полное сравнение, рекомендации по выбору подходящего варианта, переменные окружения, необходимые для включения схемы с типом JSON, и пошаговое руководство по миграции см. в разделе Map vs JSON type.
Последнее изменение 10 июня 2026 г.