Määritä VPN-objekti ennen SNMP:n tai API:n valintaa

Ennen siirtoa on kolme päätöstä: mitä objektia hälytys kuvaa, minkä suunnan ja laajuuden se kattaa ja kuinka tuore lukeman on oltava. SNMP, HTTPS-API ja sovellusanturi voivat kaikki raportoida jotain VPN:stä, eivätkä ne raportoi samaa asiaa. Protokollien vaihtaminen ratkaisematta näitä kolmea muuttaa vain sitä, mihin hämmennys kerääntyy. Objekti ja hälytyksen merkitys ovat suunnittelu; protokolla on toimitus.

Kojelauta, joka muuttaa neljä eri havaintoa yhdeksi vihreäksi kuvakkeeksi, on jo tehnyt tämän päätöksen huonosti.

Mitä hälytyksen pitäisi oikeastaan tarkoittaa?

Se voi tarkoittaa, että vertaiskone ei voi todentaa, että suojattua datatilaa ei ole, että reitti osoittaa väärään paikkaan tai että sovellus ei voi saattaa työtään loppuun. Jokaisella näistä on oma omistajansa, oma ensimmäinen tarkistuksensa ja oma väärien positiivisten osuutensa. Vertaiskone, joka ei voi todentaa, on identiteettiongelma, puuttuva suojausliitos on protokollatilaongelma, reitti on kokoonpano-ongelma, ja sovellusvirhe ei ehkä ole mitään näistä. Päätä, mille hälytys on tarkoitettu, ennen kuin valitset kerääjän.

Kirjoita se lauseena, jonka perusteella päivystävä insinööri voi toimia. Jos lause tarvitsee kaksi objektia, se on kaksi hälytystä, ei yksi puoliksi oikea.

TCP-taulukko kuvaa TCP:tä

RFC 4022 määrittelee tcpConnectionTable, jonka rivit kuvaavat muodostettuja TCP-yhteyksiä avaimena osoitetyyppi, osoite ja portti molemmissa päissä. Rivit katoavat, kun yhteys sulkeutuu, ja kuuntelevat pistokkeet näkyvät toisessa taulukossa. VPN:n ajaminen samalla koneella ei tee TCP-taulukosta IPsec-suojausliitosten luetteloa. Se voi kuvata hallintasession, sovellusvirran tai TCP:n yli kuljetetun tunnelin, eikä rivi itse kerro, mikä niistä.

Liitäntälaskurit kantavat saman monitulkintaisuuden karkeammalla tasolla: liitännän tavut kokoavat yhteen jokaisen vertaiskoneen ja jokaisen virran, joka sitä käyttää.

Rakenna pieni havaintosopimus

Kirjaa jokaisesta mittarista tuettu objekti tai API-kenttä, omistava laite ja ohjelmistoversio, vertaiskoneen tai palvelun tunniste, suunta, keräysaika ja odotettu päivityskäyttäytyminen. Käytä sitten yhdyskäytävän dokumentoitua liitos- tai istuntonäkymää protokollatilaan, reititystaulukkoa poluntilaan ja kapeaa sallittua pyyntöä sovellustilaan. Toimiva hallintapäätepiste todistaa, että hallintapäätepiste toimii, eikä mitään sen takana olevasta sovelluksesta.

Jos asennettu agentti ei sisällä tarvittavia objekteja, valitse toinen nimenomaisesti tuettu vain luku -liitäntä. OID:n keksiminen, yleisen TCP-määrän lukeminen tunnelimääränä tai odottaminen, että vanha toimittajan API säilyy muuttumattomana sisarustuotteessa, ovat kaikki umpikujia.

Vanhentunut data ei ole tunnelin vika

Keräyksen aikakatkaisu, vanhentunut tunnus tai muuttunut API-polku tuottavat puuttuvaa telemetriaa. Se on valvontavirhe ja eri tapahtuma kuin kaatunut tunneli. Kirjaa, mikä havainto vanheni ja milloin, jotta operaattori saa mielekkään ensimmäisen tarkistuksen tunnelin nollauksen sijaan. Jokaisen aikakatkaisun kohteleminen VPN-katkona opettaa ihmiset jättämään molemmat huomiotta.

Pidä myös keräysoikeudet kapeina. Liitäntä, joka voi muuttaa kokoonpanoa tai tyhjentää istuntoja, kantaa käyttöoikeusrajaa, jota valvontatyön ei pitäisi periä, ja vain luku -tili on yleensä riittävä.

Hyödyllinen suunnittelu nimeää objektin, merkityksen ja tuoreusvaatimuksen. Protokollan valinta seuraa niistä, ei päinvastoin.