Зачем нам мониторинг, который умирает вместе с кодом

За время работы с кодом у меня выработалась личная неприязнь к системам слежения, которые падают раньше основного сервиса. Кажется, идея простая. Нам нужен инстурмент, который вовремя заорёт, если всё пошло не по плану. Но на деле мы часто собираем систему, которая умирает от той же нагрузки, что и само приложение.
Помню, как то у нас резко вырос трафик, упала база данных, а вместе с ней тихо лёг и Prometheus. Ему тупо не хватило памяти под всплеск метрик. В итоге приложение лежит, оповещения молчат, а я узнаю о проблеме из сообщений от бизнеса. Это классическая ошибка. Мы разворачиваем мониторинг на том же сервере или в том же кластере, который он должен отслеживать. При сбое мы теряем и сервис, и инструмент диагностики одновременно. Ещё одна проблема - избыточность. Я сам грешил этим раньше. Хотелось собирать вообще всё: каждую таску, каждый HTTP-запрос, время работы каждого метода. В итоге логи превращаются в кашу, а база метрик начинает задыхаться. Написать декоратор на Python, который кидает метрику при каждом вызове функции, дело пяти минут. Но когда эти функции вызываются миллионы раз в минуту, система мониторинга начинает потреблять больше ресурсов, чем сама бизнес-логика. Сейчас я соблюдаю несколько простых правил, которые берегут мои нервы. Во-первых, мониторинг должен жить отдельно. В идеале - на полностью отдельной инфраструктуре. На неё не должны влиять каскадные сбои основного приложения. Во-вторых, нужно мониторить сам мониторинг. Звучит странно, но простой внешний хелсчек для проверки системы реально спасает.