Сбор аналитики на своем железе: что ломает проект чаще всего

Сбор аналитики на своем железе: что ломает проект чаще всего

Если трафик уже идет, а события теряются, проблема обычно не в трекере, а в базе, сети и правах. Схема простая: сборщик принимает события, очередь буферизует, хранилище пишет, дашборд читает. Любой сбой в одном звене превращает отчет в мусор.

Минимальный набор проверок:
— отдельный сервер или VM под сбор
— диски с запасом по IOPS, а не только по объему
— очередь между входом и БД
— firewall только на нужные порты
— SSH по ключам, парольный вход отключен
— SSL на внешнем контуре, даже если трафик «свой»

Самая частая ошибка — писать события сразу в основную таблицу. Под нагрузкой это дает блокировки, рост latency и потерю пакетов. Нормальная схема: принимать в API, складывать в очередь, пачкой писать в БД, а сырье держать отдельно для повторной обработки. Так проще пережить сбой парсера, кривой тег или всплеск трафика.

Мониторить нужно не «сервер жив», а конкретные метрики: длину очереди, время записи, процент ошибок API, свободное место, нагрузку на диск, количество dropped events. Если алерт только по CPU, вы узнаете о проблеме слишком поздно. Разворачиваем, проверяем, мониторим.

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