Как понять, почему не отвечают сервисы/почему сервер не доступен?

Периодически без всяких причин может заглючить сервер. Два типа глюков:
1) Машина в принципе перестаёт отвечать. Запросы не идут к ней. По ssh не зайти.
2) На машину зайти можно зайти, но она тупит. К примеру, сервисы вроде запущены, но работать с ними не получаются. Тот же redis или consul. В процессах висят, но при попытке выполнить любой cli запрос, он тупо виснет. Даже операция find подвисает. nginx проксирует некоторые запросы к nodejs сервисам. Они тоже отваливаются по таймауту. Лимиты на серверах большие (ulimit, ограничение на сокеты и т.п.).
CPU не жрётся, на диске место есть, оперативки хватает. После ребута машины, логично, что всё ок.
Все виртуалки с Ubuntu 16.04.4 LTS
В какую сторону копать и что смотреть, если это снова случится?
Я не разбираюсь в iptables, но я сохранил список во время проблемы и после:
Когда присутствует проблема, то есть такие правила:
Chain RESET (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
Chain PROHIBIT (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Они могут быть причиной? Если да, то как найти виновника? Единственное, что я нашёл в логах:
Jul 15 06:25:01 journey-test python3[1090]: 2018/07/15 06:25:01.935420 INFO Successfully added Azure fabric firewall rules Jul 15 06:25:01 journey-test python3[1090]: 2018/07/15 06:25:01.963119 INFO Firewall rules: Jul 15 06:25:01 journey-test python3[1090]: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) Jul 15 06:25:01 journey-test python3[1090]: pkts bytes target prot opt in out source destination Jul 15 06:25:01 journey-test python3[1090]: Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) Jul 15 06:25:01 journey-test python3[1090]: pkts bytes target prot opt in out source destination Jul 15 06:25:01 journey-test python3[1090]: Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) Jul 15 06:25:01 journey-test python3[1090]: pkts bytes target prot opt in out source destination Jul 15 06:25:01 journey-test python3[1090]: 0 0 ACCEPT tcp -- * * 0.0.0.0/0 168.63.129.16 owner UID match 0 Jul 15 06:25:01 journey-test python3[1090]: 0 0 ACCEPT tcp -- * * 0.0.0.0/0 168.63.129.16 ctstate INVALID,NEW
UPD: в /etc/waagent.conf нашёл OS.EnableFirewall=y. На старых виртуалках, где всё норм, такого правила нет. На всех новых виртуалках есть. Azure поменял дефолтное поведение своего агента. Сейчас он может менять правила фаервола. Не знаю, может ли это быть причиной.

Ответ

На серваках крутится Азуровский WALinuxAgent. Я заметил в логах, что он зачем-то лезет править фаервол. С каких-то пор они поменяли дефолтное поведение агента. Это я случайно заметил сравнив /etc/waagent.conf на старых машинах и на новых. Там теперь OS.EnableFirewall=y, он теперь может править фаервол. Я использую apf для настройки доступа. В какой-то момент у них возник конфликт. После установки в false этого флага OS.EnableFirewall=n проблема больше не повторяется.
Небольшое дополнение. Вероятно, при поднятии новой машины я забыл убрать basic настройки фаервола.

Как следствие, их агент, вероятно, переопределял мои настройки в apf и ломали доступ по ssh и т.п.