Как сломать свой HA мониторинг одним дашбордом.
Все мы знаем что HA делается для “высокой доступности” - распределения нагрузки на несколько инстансов плюс на случай если один упадёт, второй-третий продолжат работать без него.
И это правильно. Но всегда есть нюансы. Например, сломать или перегрузить внутреннюю логику самого приложения - когда выполняя заложенную функцию оно дохнет. На это направлены атаки DoS: заставить приложение выполнять тяжёлую работу простым запросом.
Само приложение работало нормально. Все мы знаем что ботнеты сканят всё подряд в поисках уязвимостей - возможно доступные php файлы, известные пути, всё такое. Не персональная атака, просто вдруг что найдётся.
Но как результат этих запросов мы получали быстрорастущий список уникальных метрик - каждая метрика имела label endpoint с уникальным путём, который ботнет перебирал сотнями. Не нескольких метрик с разными значениями, а тысячи уникальных метрик с несколькими значениями каждая.
Для Prometheus это очень дорого - на каждую метрику создаётся своя серия данных. И если в одной серии данные хранятся компактно, то много коротких серий занимают гораздо больше места.
Thanos storage пух. Незаметно.
При чём здесь дашборд?
Да, Prometheus хранил лишние данные, это неприятно. Но уронился мониторинг не этим, а одним дашбордом показывающим параметры приложения: здоровье, время отклика, количество ошибок, всё такое.
И этот дашборд для графиков дёргал метрики. Все метрики приложения. Все серии данных. Они короткие, но их очень много.
И тут не помогал никакой HA - при выполнении запроса promql thanos-query выжирал память как не в себя и убивался по resource limit. Каждая реплика, по очереди.
(А до этого убивал ноды, специально выделенные под мониторинг - изначально лимиты не были прописаны. Вот такой HA.)
Попытка сделать высокую доступность мониторинга успешно херилась кривыми метриками приложения.
Дашборд который должен был показывать что всё работает - ронял мониторинг при открытии.