<b>Сбор аналитики на своём железе: что проверить до первого трафика</b>

<b>Сбор аналитики на своём железе: что проверить до первого трафика</b>

Собственный стек нужен не ради «контроля», а ради предсказуемости: данные не теряются, логика атрибуции не зависит от внешнего сервиса, нагрузка масштабируется по вашим правилам. Но это работает только если сборка сразу проектируется как инфраструктура, а не как набор скриптов.

Базовый минимум:
— отдельный сервер под приём событий и отдельный под хранение;
— TLS на входе, SSH только по ключам, firewall закрывает всё лишнее;
— очередь между приёмом и записью, чтобы пики не валили базу;
— retention и архивирование, иначе диск закончится быстрее, чем кампания.

Дальше смотрите не на «работает/не работает», а на метрики: p95 задержки записи, процент отбрасывания событий, рост очереди, IOPS диска, нагрузка на CPU в пике. Если очередь растёт, узкое место не в трекере, а в записи или сети. Если события приходят, но не сходятся с отчётами, сначала проверяйте дедупликацию, таймстемпы и одинаковые идентификаторы сессии.

Отдельно проверьте отказоустойчивость: бэкап конфигов, репликацию хранилища, алерты на заполнение диска и падение процесса сбора. Без этого «свой сервер» превращается в один точечный отказ.

Разворачиваем, проверяем, мониторим. Стабильность — это отсутствие магии, только предсказуемая конфигурация.