Мониторинг DNS-узлов ломается не на алертах, а на плохих метриках

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

Ставьте проверки минимум в трёх слоях:
— синтетический dig к авторитетному и рекурсивному сервису;
— отдельный тест TCP, потому что часть клиентов уходит в fallback;
— замер RTT и доли таймаутов по каждой площадке, а не среднее по больнице.

Для anycast и распределённых узлов смотрите не только успех запроса, но и маршрут до ближайшей ноды. Падение латентности после перестройки BGP может выглядеть как улучшение, хотя на деле трафик просто переехал на менее загруженную точку. Проверим влияние на RTT и консистентность зон — оба параметра должны жить в одном дашборде.

Оповещения делайте по производным метрикам: рост p95/p99, серия таймаутов, расхождение ответов между площадками, а не по одному неудачному пингу. Исключаем Human Error через автоматизацию: одинаковые пробы, одинаковые таймстемпы, одинаковая логика эскалации.

Стабильность DNS — это фундамент, а не опция. Если метрики не отличают «узел отвечает» от «узел обслуживает запросы нормально», мониторинг превращается в декорацию.