Сбор аналитики на своём железе: что сломает отчёты раньше, чем трафик

Сбор аналитики на своём железе: что сломает отчёты раньше, чем трафик

Собственная аналитика полезна только тогда, когда данные приходят без дыр и дублей. Иначе вы строите отчёты на мусоре: часть событий теряется, часть улетает дважды, а UTM-метки разваливаются на редиректах.

Базовая схема простая:
— отдельный домен под сбор, без смешивания с основным сайтом;
— HTTPS везде, HSTS включён;
— Nginx как reverse proxy, backend — в изолированном контейнере или отдельном сервисе;
— Redis или очередь для буферизации, чтобы не терять события при пиках;
— PostgreSQL/MySQL с бэкапами и ротацией логов.

Проверяйте не только доступность, но и качество потока:
— 4xx и 5xx на endpoint сбора;
— задержку доставки событий;
— долю дубликатов по event_id;
— расхождение между кликами и сессиями;
— время ответа p95. Если оно растёт, сначала ищите узкое место в proxy, диске и DNS, потом в коде.

Безопасность не опция: ограничьте доступ по IP, закройте панель админки, используйте SSH-ключи, отключите парольный вход, включите fail2ban и отдельные права для сервисных аккаунтов. Проблема не в сервере, проблема в его настройке.

Если хотите, чтобы аналитика работала годами, начинайте не с красивого дашборда, а с логов, очереди и резервного копирования. Разворачиваем, проверяем, мониторим.