Definējiet VPN objektu pirms SNMP vai API izvēles

Pirms transporta ir trīs lēmumi: kādu objektu apraksta brīdinājums, kādu virzienu un tvērumu tas aptver un cik svaigam jābūt nolasījumam. SNMP, HTTPS API un lietojumprogrammas zonde visi var ziņot kaut ko par VPN, un tie neziņos vienu un to pašu. Protokolu maiņa, neatrisinot šos trīs, maina tikai vietu, kur uzkrājas apjukums. Objekts un brīdinājuma nozīme ir dizains; protokols ir piegāde.

Panelis, kas četrus dažādus novērojumus pārvērš vienā zaļā ikonā, šo lēmumu jau ir pieņēmis slikti.

Ko brīdinājumam īsti vajadzētu nozīmēt?

Tas var nozīmēt, ka partneris nevar autentificēties, ka nav aizsargāta datu stāvokļa, ka maršruts norāda uz nepareizu vietu vai ka lietojumprogramma nevar pabeigt savu darbu. Katram no tiem ir savs īpašnieks, sava pirmā pārbaude un sava viltus pozitīvo likme. Partneris, kas nevar autentificēties, ir identitātes problēma, trūkstoša drošības asociācija ir protokola stāvokļa problēma, maršruts ir konfigurācijas problēma, un lietojumprogrammas kļūme var būt neviens no tiem. Izlemiet, kam brīdinājums ir paredzēts, pirms izvēlaties kolektoru.

Uzrakstiet to kā teikumu, pēc kura dežurējošais inženieris var rīkoties. Ja teikumam vajag divus objektus, tie ir divi brīdinājumi, nevis viens, kas ir pa pusei pareizs.

TCP tabula apraksta TCP

RFC 4022 nosaka tcpConnectionTable, kura rindas apraksta izveidotos TCP savienojumus, ar atslēgu pēc adreses tipa, adreses un porta abos galos. Rindas pazūd, kad savienojums tiek aizvērts, un klausošās ligzdas parādās citā tabulā. VPN darbināšana tajā pašā mašīnā nepārvērš TCP tabulu IPsec drošības asociāciju uzskaitē. Tā var aprakstīt pārvaldības sesiju, lietojumprogrammas plūsmu vai tuneli, kas tiek pārvadāts pa TCP, un pati rinda jums nepateiks, kuru.

Saskarnes skaitītāji nes šo pašu neskaidrību rupjākā līmenī: baiti saskarnē apvieno katru partneri un katru plūsmu, kas to izmanto.

Izveidojiet nelielu novērošanas līgumu

Katrai metrikai pierakstiet atbalstīto objektu vai API lauku, īpašniekierīci un programmatūras versiju, partnera vai pakalpojuma identifikatoru, virzienu, ievākšanas laiku un paredzēto atjaunināšanas uzvedību. Pēc tam izmantojiet vārtejas dokumentēto asociāciju vai sesiju skatu protokola stāvoklim, maršrutēšanas tabulu ceļa stāvoklim un šauru atļautu pieprasījumu lietojumprogrammas stāvoklim. Strādājošs pārvaldības galapunkts pierāda, ka pārvaldības galapunkts strādā, un neko par lietojumprogrammu aiz tā.

Ja instalētajam aģentam trūkst nepieciešamo objektu, izvēlieties citu skaidri atbalstītu tikai lasīšanas saskarni. OID izgudrošana, vispārīga TCP skaita lasīšana kā tuneļu skaita vai cerība, ka vecs piegādātāja API nemainīgi izdzīvos māsas produktā, ir visas strupceļi.

Novecojuši dati nav tuneļa kļūme

Ievākšanas taimauts, beidzies akreditācijas dati vai mainīts API ceļš rada trūkstošu telemetriju. Tā ir uzraudzības kļūme un cits incidents nekā nokritis tunelis. Pierakstiet, kurš novērojums novecoja un kad, lai operators iegūtu jēgpilnu pirmo pārbaudi tuneļa atiestatīšanas vietā. Katra taimauta uztveršana kā VPN pārtraukums māca cilvēkiem ignorēt abus.

Turiet šauras arī ievākšanas atļaujas. Saskarne, kas var mainīt konfigurāciju vai notīrīt sesijas, nes privileģiju robežu, ko uzraudzības darbam nevajadzētu mantot, un tikai lasīšanas konts parasti ir pietiekams.

Noderīgais dizains nosauc objektu, nozīmi un svaiguma prasību. Protokola izvēle izriet no tiem, nevis otrādi.