Ввод в эксплуатацию

Ввод ClickStack в эксплуатацию

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

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

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

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

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

​

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

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

Чтобы защитить ингестию, укажите токен аутентификации при развертывании коллектора с помощью переменной окружения OTLP_AUTH_TOKEN. Дополнительные сведения см. в разделе “Защита коллектора”.

​

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

Рекомендуется создать отдельного пользователя для OTel collector для ингестии в Managed ClickHouse и чтобы данные направлялись в конкретную базу данных, например otel. Дополнительные сведения см. в разделе “Создание пользователя для ингестии”.

​

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

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

​

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

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

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

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

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

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

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

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

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

Допущения

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

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

MB/s	TB/month	CPUs для приёма	CPUs для запросов	Всего 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, который уже поддерживает другие рабочие нагрузки, такие как аналитика приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити.

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

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

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

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

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

​

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

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

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

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

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

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # Только если требуется для API
# Не открывайте внутренние порты, такие как ClickHouse 8123 или MongoDB 27017.

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

​

Настройка секрета сеанса

В производственной среде необходимо задать надёжное случайное значение для переменной окружения EXPRESS_SESSION_SECRET интерфейса 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 миллиона)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

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

​

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

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

​

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

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