Zdefiniuj obiekt VPN, zanim wybierzesz SNMP lub API

Przed transportem stoją trzy decyzje: jaki obiekt opisuje alert, jaki kierunek i zakres obejmuje oraz jak świeży musi być odczyt. SNMP, API HTTPS i sonda aplikacji mogą wszystkie zgłosić coś o VPN i nie zgłoszą tego samego. Zmiana protokołów bez rozstrzygnięcia tych trzech zmienia tylko miejsce, w którym gromadzi się zamieszanie. Obiekt i znaczenie alertu to projekt; protokół to dostarczanie.

Pulpit, który zamienia cztery różne obserwacje w jedną zieloną ikonę, już podjął tę decyzję źle.

Co alert powinien właściwie znaczyć?

Może oznaczać, że partner nie może się uwierzytelnić, że nie istnieje żaden chroniony stan danych, że trasa wskazuje złe miejsce albo że aplikacja nie może dokończyć swojej pracy. Każdy z tych przypadków ma własnego właściciela, własną pierwszą kontrolę i własny odsetek fałszywych alarmów. Partner, który nie może się uwierzytelnić, to problem tożsamości, brakujące stowarzyszenie bezpieczeństwa to problem stanu protokołu, trasa to problem konfiguracji, a awaria aplikacji może nie być żadnym z nich. Zdecyduj, którego dotyczy alert, zanim wybierzesz kolektor.

Zapisz go jako zdanie, na którym inżynier dyżurny może działać. Jeśli zdanie wymaga dwóch obiektów, to dwa alerty, a nie jeden w połowie poprawny.

Tabela TCP opisuje TCP

RFC 4022 określa tcpConnectionTable, którego wiersze opisują nawiązane połączenia TCP, kluczowane według typu adresu, adresu i portu na obu końcach. Wiersze znikają, gdy połączenie się zamyka, a gniazda nasłuchujące pojawiają się w innej tabeli. Uruchamianie VPN na tej samej maszynie nie zamienia tabeli TCP w inwentarz stowarzyszeń bezpieczeństwa IPsec. Może opisywać sesję zarządzania, przepływ aplikacji lub tunel przenoszony przez TCP, a sam wiersz nie powie ci który.

Liczniki interfejsów niosą tę samą niejednoznaczność na grubszym poziomie: bajty na interfejsie agregują każdego partnera i każdy przepływ, który go używa.

Zbuduj mały kontrakt obserwacji

Dla każdej metryki zapisz obsługiwany obiekt lub pole API, urządzenie i wersję oprogramowania właściciela, identyfikator partnera lub usługi, kierunek, czas zbierania i oczekiwane zachowanie odświeżania. Następnie użyj udokumentowanego widoku stowarzyszeń lub sesji bramy dla stanu protokołu, tabeli routingu dla stanu ścieżki i wąskiego dozwolonego żądania dla stanu aplikacji. Działający punkt końcowy zarządzania dowodzi, że punkt końcowy zarządzania działa, i niczego o aplikacji za nim.

Jeśli zainstalowany agent nie ma wymaganych obiektów, wybierz inny jawnie obsługiwany interfejs tylko do odczytu. Wymyślanie OID, czytanie ogólnego licznika TCP jako licznika tuneli lub oczekiwanie, że stary interfejs API dostawcy przetrwa bez zmian w produkcie siostrzanym, to wszystkie ślepe uliczki.

Nieaktualne dane nie są awarią tunelu

Limit czasu zbierania, wygasłe poświadczenie lub zmieniona ścieżka API dają brakującą telemetrię. To awaria monitorowania i incydent inny niż tunel, który padł. Zapisz, która obserwacja stała się nieaktualna i kiedy, aby operator otrzymał sensowną pierwszą kontrolę zamiast resetu tunelu. Traktowanie każdego limitu czasu jako awarii VPN uczy ludzi ignorować oba.

Utrzymuj też wąskie uprawnienia zbierania. Interfejs, który może zmieniać konfigurację lub czyścić sesje, niesie granicę uprawnień, której zadanie monitorujące nie powinno dziedziczyć, a konto tylko do odczytu zwykle wystarcza.

Użyteczny projekt nazywa obiekt, znaczenie i wymóg świeżości. Wybór protokołu wynika z nich, a nie odwrotnie.