Визначте об’єкт VPN, перш ніж вибирати SNMP або API

Перед транспортом стоять три рішення: який об’єкт описує оповіщення, який напрямок і обхват воно покриває і наскільки свіжим має бути читання. SNMP, HTTPS API і зонд застосунку можуть повідомляти щось про VPN і не будуть повідомляти те саме. Зміна протоколів без розв’язання цих трьох змінює лише місце, де збирається плутанина. Об’єкт і сенс оповіщення — це дизайн; протокол — доставка.

Панель, яка перетворює чотири різні спостереження на одну зелену іконку, уже ухвалила це рішення погано.

Що оповіщення насправді має означати?

Воно може означати, що партнер не може пройти автентифікацію, що захищеного стану даних немає, що маршрут указує не туди або що застосунок не може завершити свою роботу. Кожне з цього має свого власника, свою першу перевірку і свою частку хибних спрацювань. Партнер, який не може пройти автентифікацію, — проблема ідентичності, відсутня асоціація безпеки — проблема стану протоколу, маршрут — проблема конфігурації, а збій застосунку може не бути жодним із цього. Вирішіть, для якого з них оповіщення, перш ніж вибирати збирач.

Запишіть його як речення, за яким черговий інженер може діяти. Якщо реченню потрібні два об’єкти, це два оповіщення, а не одне наполовину правильне.

Таблиця TCP описує TCP

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

Лічильники інтерфейсів несуть ту саму неоднозначність на грубшому рівні: байти на інтерфейсі об’єднують кожного партнера і кожен потік, що його використовує.

Побудуйте невеликий контракт спостереження

Для кожного показника фіксуйте підтримуваний об’єкт або поле API, пристрій-власник і версію програмного забезпечення, ідентифікатор партнера або служби, напрямок, час збору та очікувану поведінку оновлення. Потім використовуйте задокументований подання асоціацій або сеансів шлюзу для стану протоколу, таблицю маршрутизації для стану шляху і вузький дозволений запит для стану застосунку. Робоча кінцева точка керування доводить, що кінцева точка керування працює, і нічого про застосунок за нею.

Якщо встановлений агент не має потрібних об’єктів, виберіть інший явно підтримуваний інтерфейс лише для читання. Вигадувати OID, читати загальний лічильник TCP як лічильник тунелів або очікувати, що старий API постачальника залишиться незмінним у спорідненому продукті, — усе це глухі кути.

Застарілі дані — не збій тунелю

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

Тримайте вузькими й права на збір. Інтерфейс, який може змінювати конфігурацію або очищати сеанси, несе межу привілеїв, яку завдання моніторингу не повинне успадковувати, а облікового запису лише для читання зазвичай достатньо.

Корисний дизайн називає об’єкт, сенс і вимогу свіжості. Вибір протоколу випливає з них, а не навпаки.