Это то самое место, где спотыкался мой первый прототип системы из первой части истории — и где спотыкается почти любая наивная реализация мониторинга. Интуиция подсказывает: медленно — это когда сеть тормозит. На практике всё наоборот. Живой ASIC отвечает за десятки миллисекунд. А мёртвый не отвечает вообще — и вы платите полным TCP-таймаутом операционной системы. По умолчанию это единицы минут на одно устройство. Отсюда парадокс: цикл опроса растягивается на минуты не из-за аварии, а из-за планового отключения. Машины на профилактике исправны — они просто не отвечают, и каждая из них стоит системе полного таймаута. Чем хуже дела на площадке, тем медленнее система, которая должна вам об этом рассказать. Что сделано: Таймаут сокета прибит к 0.3 секунды. Живой ASIC укладывается в этот бюджет с многократным запасом, мёртвый отваливается практически мгновенно. Число не с потолка — оно подобрано по реальным ответам устройств в локальной сети. Перед дорогой пробой — дешёвая проверка достижимости хоста с отдельным коротким таймаутом. Нет смысла разворачивать протокольный диалог с адресом, на котором никого нет. Недоступность — штатный результат, а не исключение. Устройство возвращает статус «ошибка», но сохраняет свой известный тип провайдера. Оно не «теряет личность» из-за одного неудачного опроса и не уходит на повторный перебор всех четырёх протоколов при следующем цикле — иначе именно офлайн-машины и стали бы самыми дорогими в обслуживании. Сформулирую как принцип, который вытащил из этого проекта: В системе мониторинга самый частый сценарий — это не «всё хорошо», а «часть оборудования недоступна». Оптимизировать надо именно его. Кто оптимизировал сетевые опросы — какой таймаут в итоге выбрали и по каким данным?