Телеметрия установки

Короткий ответ: по умолчанию установка не отправляет вендору ничего. Ни событий, ни метрик, ни данных об использовании, ни отчёта об ошибках. Есть один необязательный ping с версией, выключенный в поставке, и он единственный. Всё остальное исходящее движение появляется только там, где вы сами настроили интеграцию.

Эта страница написана так, чтобы её можно было перепроверить: ниже указано, что именно смотреть в конфигурации и в исходном коде.

Что проверялось

Всё перечисленное проверяется по файлам, которые у вас уже есть, и по поведению работающей установки — верить на слово не нужно.

Утверждение	Как перепроверить у себя
Пинг версии выключен по умолчанию	TELEMETRY_OPTIN=false в шаблоне .env.example комплекта; в docker-compose.onprem.yml та же переменная имеет значение по умолчанию false; в значениях чарта — telemetryOptIn: false
Пока пинг выключен, отправок нет	в метриках основного API нет ряда pp_onprem_telemetry_ping_total — счётчик появляется только у включённой телеметрии
Пинг умеет отправлять только основной API	ни ingest-api, ни ch-writer, ни worker не обращаются к внешним адресам вендора; в поставляемом Compose исходящий доступ есть только у сети приложения, сети данных и наблюдаемости помечены внутренними
Состав пинга фиксирован	структура тела задана в коде продукта: четыре поля, произвольных меток и полезной нагрузки нет — состав приведён ниже целиком
Включение вне режима «на своих серверах» невозможно	проверка конфигурации при старте отказывается принимать TELEMETRY_OPTIN в облачном режиме
Единственный внешний адрес вендора — этот endpoint	во всей поставке нет другого адреса вендора: остальные внешние адреса появляются только из ваших настроек (перечень в конце страницы)

Финальная проверка — сетевая: снимите исходящий трафик установки на периметре и убедитесь, что кроме настроенного вами ничего нет. Ниже перечислено всё, что там может законно оказаться.

Если пинг включён

Пинг включается одной переменной TELEMETRY_OPTIN=true. Он существует, чтобы вендор знал, какие версии реально работают у клиентов, и ничего больше.

Отправляется ровно четыре поля (значения в примере условные):

{
  "schema_version": 1,
  "product": "actionpulse",
  "instance_id": "0f6c2b64-9f6a-4a5f-9c3e-3f0f2a1d6b77",
  "version": "v1.4.0"
}

• instance_id — псевдоним установки, который задаёте вы в TELEMETRY_INSTANCE_ID. Это должен быть UUID; без него включённая телеметрия не запустится. Это не идентификатор организации, не номер лицензии и не имя хоста. Значение стоит сохранять между обновлениями и делать одинаковым на всех экземплярах основного API, иначе один установленный продукт будет выглядеть как несколько.
• version — версия продукта из PP_VERSION.

Ни организаций, ни проектов, ни пользователей, ни событий, ни настроек, ни данных лицензии, ни имени хоста, ни IP-адресов в теле нет — добавить их нельзя, состав задан структурой в коде.

Свойство	Значение
Куда	адрес из TELEMETRY_ENDPOINT; по умолчанию — публичный HTTPS-адрес вендора, точное значение видно в docker-compose.onprem.yml комплекта
Как часто	один запрос при старте сервиса и далее раз в 24 часа
Таймаут	5 секунд, отдельно ограничены соединение и TLS-рукопожатие
Перенаправления	не выполняются
Транспорт	только HTTPS, TLS не ниже 1.2, учитываются переменные прокси окружения
Влияние на работу	никакого: неудачный запрос только увеличивает счётчик и пишет предупреждение в журнал

Конфигурация проверяется при старте fail-closed: адрес обязан быть абсолютным HTTPS без учётных данных, без строки запроса и без фрагмента. Адрес во внутренней или петлевой сети отклоняется — направить пинг на свой коллектор можно только осознанно, добавив TELEMETRY_ALLOW_PRIVATE_ENDPOINT=true, и он всё равно должен быть HTTPS.

Как выключить и как убедиться

# из каталога комплекта
# 1. TELEMETRY_OPTIN=false в .env (или уберите строку совсем)
# 2. Перезапустите основной API
docker compose -f docker-compose.onprem.yml --env-file .env up -d query-api

# 3. Счётчик пингов больше не растёт: при выключенной телеметрии ряда нет вовсе
docker compose -f docker-compose.onprem.yml --env-file .env \
  exec query-api wget -qO- http://localhost:9090/metrics \
  | grep pp_onprem_telemetry_ping_total

Ряд pp_onprem_telemetry_ping_total{result} с метками success и error — это и есть аудит отправки: если он не появляется, отправок не было. Второй независимый способ — журнал исходящих соединений на вашем периметре.

Что уходит с трассировкой

Трассировка — отдельный механизм, и решение о ней принимаете вы. Всё зависит от одной переменной OTEL_EXPORTER_OTLP_ENDPOINT:

• пусто — экспорт выключен полностью, спаны не создаются;
• встроенный Jaeger — так настроен поставляемый Compose по умолчанию: трассы остаются внутри установки, в памяти контейнера, и никуда не уезжают;
• ваш внешний коллектор — вы указали адрес, и с этого момента спаны уходят туда. Это ваш выбор и ваша ответственность как оператора: продукт не подставляет сюда никаких адресов вендора.

Что попадает в спан: имя и версия сервиса, метод HTTP, шаблон маршрута, статус ответа и идентификатор запроса. Реальный путь запроса заменяется шаблоном маршрута ещё до старта спана, а из инструментального запроса удаляются Authorization, Proxy-Authorization, Cookie, Referer, X-Api-Key, X-Auth-Token, X-Forwarded-For и X-Real-IP.

Что ещё может уйти наружу — только по вашей настройке

Всё перечисленное выключено или отсутствует в поставляемом шаблоне, пока вы не заполните соответствующие переменные.

Направление	Включается	Что уходит
Почта уведомлений	SMTP_HOST и связанные переменные; пусто — доставка выключена	письма на ваш SMTP-сервер
Вебхуки оповещений	адрес вебхука в правиле	тело оповещения на указанный вами адрес
SMS и Telegram	SMS_PROVIDER (в шаблоне disabled), TG_BOT_TOKEN	текст уведомления провайдеру
Импорт из вашего ClickHouse	параметры импорта в кабинете	запросы к указанному вами серверу
Резервные копии	профиль backup и параметры S3	копии данных в указанное вами хранилище
Сертификат TLS	реальный домен в PP_DOMAIN	обращения Caddy к удостоверяющему центру для автоматического выпуска сертификата
Скачивание образов	обновление установки	обращения Docker к вашему реестру образов

Два уточнения по этому списку:

• Вебхуки оповещений по умолчанию принимают только HTTPS и только публичные адреса. Для внутренних интеграций в установке на своих серверах есть отдельные явные исключения — ALERT_WEBHOOK_ALLOW_PRIVATE и ALERT_WEBHOOK_ALLOW_HTTP; адреса служб метаданных облачных провайдеров запрещены при любых настройках, и перенаправления не выполняются.
• Автоматический выпуск сертификата — единственное исходящее соединение, которое появляется «само» при указании реального домена. Если внешние обращения недопустимы, оставляйте установку за своим reverse proxy с вашим сертификатом.

Внутренние компоненты наблюдаемости — Prometheus, Grafana, Alertmanager, Elasticsearch, Kibana, Jaeger — никуда за пределы установки не обращаются. У них нет опубликованных на хост портов, а сети данных и наблюдаемости в поставляемом Compose помечены как внутренние.

Что проверить

1. В .env установки TELEMETRY_OPTIN=false (или строки нет вовсе) — тогда отправлять нечему.
2. Ряда pp_onprem_telemetry_ping_total в метриках нет. Если он есть — пинг включён, посмотрите значение переменной.
3. OTEL_EXPORTER_OTLP_ENDPOINT указывает туда, куда вы решили: пусто, внутренний Jaeger или ваш коллектор. Внешний адрес здесь — сознательное решение, а не значение по умолчанию.
4. SMTP_HOST, SMS_PROVIDER, TG_BOT_TOKEN и параметры резервного копирования заполнены только там, где вы этого хотите.
5. На сетевом периметре видно ровно те исходящие направления, которые вы перечислили сами. Расхождение — повод разбираться, а не списывать на «телеметрию продукта»: включённого по умолчанию канала к вендору здесь нет.