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

При развертывании 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 дня часто требует изменения.

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

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

Ежемесячный объём ингестии	Рекомендуемые вычислительные ресурсы
< 10 ТБ / месяц	2 vCPU × 3 реплики
10–50 ТБ / месяц	4 vCPU × 3 реплики
50–100 ТБ / месяц	8 vCPU × 3 реплики
100–500 ТБ / месяц	30 vCPU × 3 реплики
1 ПБ+ / месяц	59 vCPU × 3 реплики

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

• Под объёмом данных понимается несжатый объём ингестии в месяц; это относится как к логам, так и к трейсам.
• Паттерны запросов типичны для сценариев обсервабилити: большинство запросов обращается к недавним данным, обычно за последние 24 часа.
• Ингестия распределена относительно равномерно в течение месяца. Если вы ожидаете всплески трафика или пиковые нагрузки, следует заложить дополнительный запас.
• Хранение организовано отдельно через ClickHouse Cloud Объектное хранилище и не является ограничивающим фактором для retention. Мы предполагаем, что к данным, хранящимся длительное время, обращаются редко.

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

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

Примечание

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

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

Если вы добавляете 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. Подробнее см. "Создание пользователя для ингестии".

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.