Определите объект VPN, прежде чем выбирать SNMP или API

Перед транспортом стоят три решения: какой объект описывает оповещение, какое направление и охват оно покрывает и насколько свежим должно быть чтение. SNMP, HTTPS API и пробник приложения могут сообщать что-то о VPN, и они не будут сообщать одно и то же. Смена протоколов без решения этих трёх меняет только место, где собирается путаница. Объект и смысл оповещения — это дизайн; протокол — доставка.

Панель, которая превращает четыре разных наблюдения в одну зелёную иконку, уже приняла это решение плохо.

Что оповещение должно на самом деле означать?

Оно может означать, что партнёр не может пройти проверку подлинности, что защищённого состояния данных нет, что маршрут указывает не туда или что приложение не может завершить работу. У каждого из этого есть свой владелец, своя первая проверка и своя доля ложных срабатываний. Партнёр, который не может пройти проверку подлинности, — проблема идентичности, отсутствующая ассоциация безопасности — проблема состояния протокола, маршрут — проблема конфигурации, а сбой приложения может не быть ни одним из этого. Решите, для какого из них оповещение, прежде чем выбирать сборщик.

Запишите его как предложение, по которому дежурный инженер может действовать. Если предложению нужны два объекта, это два оповещения, а не одно наполовину правильное.

Таблица TCP описывает TCP

RFC 4022 определяет tcpConnectionTable, строки которого описывают установленные TCP-соединения с ключом по типу адреса, адресу и порту на обоих концах. Строки исчезают при закрытии соединения, а слушающие сокеты появляются в другой таблице. Запуск VPN на той же машине не превращает таблицу TCP в инвентарь ассоциаций безопасности IPsec. Она может описывать сеанс управления, поток приложения или туннель, переносимый по TCP, и сама строка не скажет вам, что именно.

Счётчики интерфейсов несут ту же неоднозначность на более грубом уровне: байты на интерфейсе объединяют каждого партнёра и каждый поток, который его использует.

Постройте небольшой контракт наблюдения

Для каждой метрики фиксируйте поддерживаемый объект или поле API, владеющее устройство и версию программного обеспечения, идентификатор партнёра или службы, направление, время сбора и ожидаемое поведение обновления. Затем используйте документированное представление ассоциаций или сеансов шлюза для состояния протокола, таблицу маршрутизации для состояния пути и узкий разрешённый запрос для состояния приложения. Работающая конечная точка управления доказывает, что конечная точка управления работает, и ничего о приложении за ней.

Если у установленного агента нет нужных объектов, выберите другой явно поддерживаемый интерфейс только для чтения. Придумывать OID, читать общий счётчик TCP как счётчик туннелей или ожидать, что старый API поставщика сохранится неизменным в родственном продукте, — всё это тупики.

Устаревшие данные — не сбой туннеля

Тайм-аут сбора, истёкшие учётные данные или изменённый путь API дают отсутствующую телеметрию. Это сбой мониторинга и другой инцидент, чем упавший туннель. Зафиксируйте, какое наблюдение устарело и когда, чтобы оператор получил содержательную первую проверку вместо перезапуска туннеля. Отношение к каждому тайм-ауту как к сбою VPN учит людей игнорировать и то и другое.

Держите узкими и права на сбор. Интерфейс, который может менять конфигурацию или очищать сеансы, несёт границу привилегий, которую задача мониторинга не должна наследовать, а учётной записи только для чтения обычно достаточно.

Полезный дизайн называет объект, смысл и требование свежести. Выбор протокола следует из них, а не наоборот.