Судя по вашему куцому объяснению - проблема скорее всего в приложении, а не в базе. Хотя на настройки постгреса я бы тоже обратил внимание. Без логов разговаривать предметно не о чем.
Частота проверок к выражению триггера отношения не имеет. Вам нужно настраивать именно последнее, указав что-нибудь типа nodata(86400)=1 или max(86400)<1 в зависимости от того, что отдаёт пинг в случае неудачи.
Если имеется в виду Oracle Cloud - то по умолчанию правила фаерволла там настраиваются в двух местах, глобально в панели управления вашей виртуальной сетью, и непосредственно в iptables виртуалки.
1. Что-нибудь опенсорсное (но не российское, естессна).
2. Что-нибудь опенсорсное.
3. Ничего, потому что PKI - система, построенная на доверии удостоверяющим центрам, а в РФ, слава богу шифрования, их нет.
Мониторинг должен быть комплексным. Вы сейчас только нашли виновника торжества - теперь настала пора лезть в потроха СУБД, отслеживать запросы, при необходимости профилировать или копать в сторону приложения, эти запросы генерирующие.
А может у вас просто СУБД фигово настроена, кто знает.
Поднимаете локальный HTTP-прокси и добавляете на него блэклист. Мимо прокси трафик наружу не выпускаете. То же самое можно сделать с помощью локального DNS-сервера, но значительно менее надёжно.
Представьте обратную ситуацию - хост и его шлюз НЕ находятся в пределах одной сети. Тогда, очевидно, чтобы отправить пакет шлюзу, требуется какой-то узел в сети, маршрутизирующий пакеты за её пределы. Хоп, вы получили новый шлюз.
