Определете VPN обекта, преди да изберете SNMP или API

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

Табло, което превръща четири различни наблюдения в една зелена икона, вече е взело това решение лошо.

Какво всъщност трябва да означава сигналът?

Той може да означава, че партньор не може да се удостовери, че не съществува защитено състояние на данните, че маршрут сочи на грешно място или че приложение не може да завърши работата си. Всяко от тях има свой собственик, своя първа проверка и своя дял фалшиви тревоги. Партньор, който не може да се удостовери, е проблем с идентичността, липсваща асоциация за сигурност е проблем със състоянието на протокола, маршрутът е проблем с конфигурацията, а отказ на приложение може да не е нито едно от тях. Решете за кое е сигналът, преди да изберете колектор.

Напишете го като изречение, по което дежурният инженер може да действа. Ако изречението изисква два обекта, това са два сигнала, а не един наполовина верен.

TCP таблицата описва TCP

RFC 4022 определя tcpConnectionTable, чиито редове описват установени TCP връзки, ключови по тип адрес, адрес и порт в двата края. Редовете изчезват, когато връзката се затвори, а слушащите сокети се появяват в друга таблица. Стартирането на VPN на същата машина не превръща TCP таблица в инвентар на IPsec асоциации за сигурност. Тя може да описва сесия за управление, поток на приложение или тунел през TCP и самият ред няма да ви каже кое.

Броячите на интерфейса носят същата двусмисленост на по-грубо ниво: байтовете на интерфейс обобщават всеки партньор и всеки поток, който го използва.

Изградете малък договор за наблюдение

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

Ако инсталираният агент няма необходимите обекти, изберете друг изрично поддържан интерфейс само за четене. Измислянето на OID, четенето на общ TCP брой като брой тунели или очакването стар API на доставчик да остане непроменен в родствен продукт са все задънени улици.

Остарелите данни не са отказ на тунел

Изтичане на времето за събиране, изтекли идентификационни данни или променен път на API създават липсваща телеметрия. Това е отказ на мониторинга и различен инцидент от тунел, който е паднал. Запишете кое наблюдение е остаряло и кога, за да получи операторът смислена първа проверка вместо нулиране на тунела. Третирането на всяко изтичане на времето като прекъсване на VPN учи хората да игнорират и двете.

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

Полезният дизайн назовава обекта, значението и изискването за свежест. Изборът на протокол следва от тях, а не обратното.