> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8a08bda2.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Ввод в эксплуатацию > Ввод ClickStack в эксплуатацию export const Image = ({img, alt, size}) => { return {alt} ; }; При развертывании ClickStack в производственной среде необходимо учитывать несколько дополнительных факторов, чтобы обеспечить безопасность, стабильность и корректную конфигурацию. Они различаются в зависимости от используемого варианта развертывания — с открытым исходным кодом или управляемого. Для production-развертываний рекомендуется [Managed ClickStack](/ru/clickstack/getting-started/managed). По умолчанию он использует [стандартные для отрасли практики безопасности](/ru/products/cloud/features/security), включая усиленное шифрование, аутентификацию и защищённое подключение, а также управляемое управление доступом, и предоставляет следующие преимущества: * Автоматическое масштабирование вычислительных ресурсов независимо от хранилища * Недорогое и практически неограниченное хранение на базе Объектного хранилища * Возможность независимо изолировать рабочие нагрузки чтения и записи с помощью Warehouses. * Встроенная аутентификация * Автоматизированные [резервные копии](/ru/products/cloud/features/backups/overview) * Бесшовные обновления **Следуйте этим [рекомендуемым практикам](/ru/products/cloud/guides/production-readiness) ClickHouse Cloud при использовании Managed ClickStack.** ### Защита ингестии По умолчанию коллектор ClickStack OpenTelemetry не защищён при развертывании вне дистрибутивов с открытым исходным кодом и не требует аутентификации на своих портах OTLP. Чтобы защитить ингестию, укажите токен аутентификации при развертывании коллектора с помощью переменной окружения `OTLP_AUTH_TOKEN`. Дополнительные сведения см. в разделе ["Защита коллектора"](/ru/clickstack/ingesting-data/collector#securing-the-collector). #### Создание пользователя для ингестии Рекомендуется создать отдельного пользователя для OTel collector для ингестии в Managed ClickHouse и чтобы данные направлялись в конкретную базу данных, например `otel`. Дополнительные сведения см. в разделе ["Создание пользователя для ингестии"](/ru/clickstack/ingesting-data/collector#creating-an-ingestion-user). ### Настройка Time To Live (TTL) Убедитесь, что [Time To Live (TTL)](/ru/clickstack/managing/ttl) [настроен должным образом](/ru/clickstack/managing/ttl#modifying-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](/ru/products/cloud/features/infrastructure/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 | Дополнительные сведения о корректировке предположений по размеру для вашей среды см. в разделе ["Корректировка предположений по размеру для вашей среды"](/ru/clickstack/managing/estimating-resources#refining-sizing-assumptions). #### Изоляция рабочих нагрузок обсервабилити Если вы добавляете ClickStack в **существующий сервис ClickHouse Cloud**, который уже поддерживает другие рабочие нагрузки, такие как аналитика приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити. Используйте [**Managed Warehouses**](/ru/products/cloud/features/infrastructure/warehouses), чтобы создать **дочерний сервис**, выделенный для ClickStack. Это позволяет: * Изолировать нагрузку приёма данных и запросов от существующих приложений * Независимо масштабировать рабочие нагрузки обсервабилити * Предотвратить влияние запросов обсервабилити на production-аналитику * При необходимости использовать одни и те же базовые датасеты в разных сервисах Такой подход гарантирует, что существующие рабочие нагрузки не пострадают, и при этом позволит ClickStack масштабироваться независимо по мере роста объёма данных обсервабилити. Для более крупных развертываний или получения рекомендаций по индивидуальному подбору ресурсов обратитесь в службу поддержки, чтобы получить более точную оценку. ### Безопасность сети и портов По умолчанию Docker Compose открывает порты на хосте, делая их доступными извне контейнера — даже если такие инструменты, как `ufw` (Uncomplicated Firewall), включены. Такое поведение обусловлено сетевым стеком Docker, который может обходить правила брандмауэра на уровне хоста, если не настроен явным образом. **Рекомендация:** Открывайте только те порты, которые необходимы для работы в production-среде. Как правило, это конечные точки OTLP, API-сервер и фронтенд. Например, удалите или закомментируйте ненужные маппинги портов в файле `docker-compose.yml`: ```yaml theme={null} ports: - "4317:4317" # OTLP gRPC - "4318:4318" # OTLP HTTP - "8080:8080" # Только если требуется для API # Не открывайте внутренние порты, такие как ClickHouse 8123 или MongoDB 27017. ``` Подробнее об изоляции контейнеров и усилении защиты доступа см. в [документации по сетям Docker](https://docs.docker.com/network/). ### Настройка секрета сеанса В производственной среде необходимо задать надёжное случайное значение для переменной окружения `EXPRESS_SESSION_SECRET` интерфейса ClickStack (HyperDX) — для защиты данных сеанса и предотвращения несанкционированного изменения. Вот как добавить это в файл `docker-compose.yml` для сервиса приложения: ```yaml theme={null} 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`: ```shell theme={null} 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`. Подробнее см. в разделе ["Создание пользователя для ингестии"](/ru/clickstack/ingesting-data/collector#creating-an-ingestion-user). ### ClickHouse Пользователям, управляющим собственным экземпляром ClickHouse, рекомендуется следовать приведённым ниже рекомендациям. #### Рекомендации по безопасности Если вы управляете собственным экземпляром ClickHouse, крайне важно включить **TLS**, настроить аутентификацию и следовать рекомендациям по усилению защиты доступа. Ознакомьтесь с [этой публикацией в блоге](https://www.wiz.io/blog/clickhouse-and-wiz) — в ней описаны реальные примеры неправильной конфигурации и способы их предотвращения. ClickHouse OSS предоставляет широкие возможности безопасности «из коробки». Однако для их использования требуется настройка: * **Используйте TLS** с помощью `tcp_port_secure` и `` в `config.xml`. См. [guides/sre/configuring-tls](/ru/concepts/features/security/tls/configuring-tls). * **Задайте надежный пароль** для пользователя `default` или отключите его. * **Не открывайте внешний доступ к ClickHouse** без явной необходимости. По умолчанию ClickHouse прослушивает только `localhost`, если не изменён параметр `listen_host`. * **Используйте такие методы аутентификации, как** пароли, сертификаты, SSH-ключи или [внешние аутентификаторы](/ru/concepts/features/security/external-authenticators). * **Ограничьте доступ** с помощью фильтрации по IP и предложения `HOST`. См. [sql-reference/statements/create/user#user-host](/ru/reference/statements/create/user#user-host). * **Включите ролевое управление доступом (RBAC)**, чтобы назначать более детализированные привилегии. См. [operations/access-rights](/ru/concepts/features/security/access-rights). * **Настраивайте квоты и ограничения** с помощью [квот](/ru/concepts/features/configuration/server-config/quotas), [профилей настроек](/ru/concepts/features/configuration/settings/settings-profiles) и режимов только для чтения. * **Шифруйте данные в состоянии покоя** и используйте защищённое внешнее хранилище. См. [operations/storing-data](/ru/concepts/features/configuration/server-config/storing-data) и [cloud/security/CMEK](/ru/products/cloud/guides/security/cmek). * **Не прописывайте учётные данные в коде.** Используйте [именованные коллекции](/ru/concepts/features/configuration/server-config/named-collections) или роли IAM в ClickHouse Cloud. * **Проводите аудит доступа и запросов** с помощью [системных журналов](/ru/reference/system-tables/query_log) и [журналов сеансов](/ru/reference/system-tables/session_log). См. также [внешние аутентификаторы](/ru/concepts/features/security/external-authenticators) и [настройки сложности запросов](/ru/concepts/features/configuration/settings/query-complexity) для управления пользователями и установки ограничений на запросы и ресурсы. #### Разрешения пользователя для интерфейса 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)](/ru/clickstack/managing/ttl) — [подробнее о настройке](/ru/clickstack/managing/ttl#modifying-ttl). Этот параметр определяет срок хранения данных; значение по умолчанию (3 дня) зачастую требует изменения. ### Рекомендации по MongoDB Следуйте официальному [контрольному списку безопасности MongoDB](https://www.mongodb.com/docs/manual/administration/security-checklist/).