Переход в продакшен

При развертывании ClickStack в продакшн-среде необходимо учитывать ряд дополнительных аспектов, чтобы обеспечить безопасность, стабильность и корректную конфигурацию. Эти аспекты зависят от используемого дистрибутива — Open Source или Managed.

Управляемый ClickStack

Для продуктивных развертываний рекомендуется использовать Managed ClickStack. Он по умолчанию применяет отраслевые практики безопасности — включая усиленное шифрование, аутентификацию и сетевое подключение, а также управляемый контроль доступа, — а также предоставляет следующие преимущества:

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

Следуйте этим передовым практикам для ClickHouse Cloud при использовании Managed ClickStack.

Защита ингестии

По умолчанию ClickStack OpenTelemetry Collector не защищён при развертывании вне Open Source-дистрибутивов и не требует аутентификации на своих OTLP-портах.

Чтобы защитить ингестию, укажите токен аутентификации при развертывании коллектора с использованием переменной окружения OTLP_AUTH_TOKEN. Подробности см. в разделе "Securing the collector".

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

Рекомендуется создать выделенного пользователя для OTel collector для приёма данных в Managed ClickHouse и обеспечить, чтобы ингестия выполнялась в конкретную базу данных, например otel. Подробности см. в разделе "Creating an ingestion user".

Настройка Time To Live (TTL)

Убедитесь, что Time To Live (TTL) корректно настроен для вашего развертывания Managed ClickStack. Это управляет сроком хранения данных — значение по умолчанию в 3 дня часто требует изменения.

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

Ниже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания 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

Подробнее о том, как скорректировать исходные допущения по размеру под вашу среду, см. в разделе "Refining sizing assumptions for your environment".

Изоляция нагрузок обсервабилити

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

Используйте Managed Warehouses, чтобы создать дочерний сервис, посвящённый ClickStack. Это позволит вам:

• Изолировать нагрузку на приём и запросы от существующих приложений
• Масштабировать нагрузки обсервабилити независимо
• Не допустить влияния запросов обсервабилити на продуктивную аналитику
• При необходимости совместно использовать одни и те же базовые датасеты между сервисами

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

Для более крупных развертываний или получения рекомендаций по кастомным размерам обратитесь в службу поддержки для более точной оценки.

ClickStack с открытым исходным кодом

Безопасность сети и портов

По умолчанию Docker Compose открывает порты на хосте, делая их доступными извне контейнера — даже при включённых инструментах, таких как ufw (Uncomplicated Firewall). Это поведение обусловлено сетевым стеком Docker, который может обходить правила межсетевого экрана на уровне хоста, если не настроено явным образом.

Рекомендация:

Открывайте только те порты, которые необходимы для использования в промышленной эксплуатации. Обычно это OTLP конечные точки, API-сервер и фронтенд.

Например, удалите или закомментируйте ненужные маппинги портов в файле docker-compose.yml:

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # Only if needed for the API
# Avoid exposing internal ports like ClickHouse 8123 or MongoDB 27017.

Подробнее об изоляции контейнеров и усилении защиты доступа см. в документации по сетям Docker.

Конфигурация секрета сессии

В продакшене необходимо задать надёжное случайное значение для переменной окружения EXPRESS_SESSION_SECRET для UI ClickStack (HyperDX) — это защитит данные сессии и предотвратит их подделку.

Добавьте это в файл docker-compose.yml для сервиса приложения следующим образом:

  app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
    ports:
      - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
      - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
    environment:
      FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
      HYPERDX_API_KEY: ${HYPERDX_API_KEY}
      HYPERDX_API_PORT: ${HYPERDX_API_PORT}
      HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
      HYPERDX_APP_URL: ${HYPERDX_APP_URL}
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      MINER_API_URL: 'http://miner:5123'
      MONGO_URI: 'mongodb://db:27017/hyperdx'
      NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
      OTEL_SERVICE_NAME: 'hdx-oss-api'
      USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
      EXPRESS_SESSION_SECRET: "super-secure-random-string"
    networks:
      - internal
    depends_on:
      - ch-server
      - db1

Для генерации надёжного секрета используйте openssl:

openssl rand -hex 32

Не фиксируйте секреты в системе контроля версий. В продакшене используйте инструменты управления переменными окружения (например, Docker Secrets, HashiCorp Vault или конфигурации CI/CD для конкретных окружений).

Защита ингестии

Весь приём данных должен осуществляться через порты OTLP, предоставляемые дистрибутивом ClickStack коллектора OpenTelemetry (OTel). По умолчанию для этого требуется защищённый ключ API для приёма данных, сгенерированный при запуске. Этот ключ необходим при отправке данных на порты OTel и находится в интерфейсе HyperDX в разделе Team Settings → API Keys.

Кроме того, рекомендуется включить TLS для конечных точек OTLP.

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

Рекомендуется создать выделенного пользователя для OTel collector для ингестии в ClickHouse и обеспечить, чтобы данные ингестии отправлялись в конкретную базу данных, например otel. Подробнее см. "Creating an ingestion user".

ClickHouse

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

Рекомендации по обеспечению безопасности

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

ClickHouse OSS предоставляет надёжные функции безопасности «из коробки». Однако для их использования требуется настройка:

• Используйте TLS с помощью tcp_port_secure и <openSSL> в config.xml. См. раздел guides/sre/configuring-tls.
• Установите надежный пароль для пользователя default или отключите этого пользователя.
• Не открывайте доступ к ClickHouse извне, если только это не требуется явно. По умолчанию ClickHouse слушает только localhost, пока не будет изменён параметр listen_host.
• Используйте методы аутентификации, например пароли, сертификаты, SSH-ключи или внешние аутентификаторы.
• Ограничьте доступ с помощью фильтрации по IP и предложения HOST. См. sql-reference/statements/create/user#user-host.
• Включите ролевое управление доступом (RBAC), чтобы предоставлять детализированные права доступа. См. operations/access-rights.
• Устанавливайте квоты и ограничения с помощью квот, профилей настроек и режимов «только для чтения».
• Шифруйте данные при хранении и используйте безопасное внешнее хранилище. См. operations/storing-data и cloud/security/CMEK.
• Не размещайте учетные данные в коде. Используйте именованные коллекции или роли IAM в ClickHouse Cloud.
• Проводите аудит доступа и запросов с помощью системных журналов и журналов сессий.

См. также внешние аутентификаторы и настройки сложности запросов для управления пользователями и установки ограничений на запросы и ресурсы.

Разрешения пользователя для интерфейса ClickStack

Пользователю ClickHouse для интерфейса ClickStack достаточно иметь права readonly с доступом к изменению следующих настроек:

• max_rows_to_read (как минимум до 1 000 000)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

По умолчанию пользователь default как в OSS, так и в ClickHouse Cloud имеет эти разрешения, однако рекомендуется создать нового пользователя с этими разрешениями.

Настройка Time To Live (TTL)

Убедитесь, что Time To Live (TTL) корректно настроен для вашего развертывания ClickStack. Это управляет сроком хранения данных — значение по умолчанию в 3 дня часто требует изменения.

Рекомендации MongoDB

Следуйте официальному контрольному списку безопасности MongoDB.