Hands-on med Paessler PRTG 9 overvåkningsverktøy

Jeg liker verktøy for overvåking av infrastruktur og har testet ganske mange forskjellige produkter. Et produkt jeg nå tester, er den siste versjonen av et produkt som jeg kjørte hos en tidligere arbeidsgiver: Paessler PRTG. Den siste versjonen er PRTG 9, og den kan skilte med noen kule nye funksjoner i forhold til eldre versjoner, men har også en alvorlig begrensning.

Husk at jeg kjører PRTG 9 i en ganske grunnleggende tilstand akkurat nå, da jeg bare tester produktet, så jeg ikke har kategorisert og beskjært varene som blir overvåket nøye.

En PRTG-grunning

I PRTG-land blir sensorer laget for å overvåke individuelle ytelseselementer. En sensor er det mest grunnleggende overvåkingselementet. I PRTG-vanlige spørsmål definerer selskapet en en (1) sensor som enhver spesiell, individuell overvåkingsenhet. " En enkelt sensor kan være ansvarlig for å se på tilgjengelig diskplass på stasjonene til en server, mens en andre sensor kan være ansvarlig for å se på diskkølengden. PRTG fungerer ikke på forestillingen om overvåkede enheter eller IP-er. I stedet kjøper du sensurlisenser, og du kan overvåke så dypt eller så høyt nivå du vil, så lenge du holder deg innenfor det lisensierte sensortallet.

Selskapet indikerer at enhver rimelig stasjonær datamaskin lett skal kunne overvåke 1000 eller flere sensorer. Fra FAQ om PRTG: " SNMP V1 / V2 , PING, PORT og HTTP er de anbefalte sensortypene for scenarier med tusenvis av sensorer. Med disse teknologiene er opptil 20.000 sensorer mulig" i en enkelt PRTG-installasjon.

Objekthierarki

Jeg har nevnt at den grunnleggende overvåkningsenheten er en sensor, men det er grupperinger på høyere nivå som inneholder disse sensorene. Umiddelbart over sensorene er du på enhetsnivå. Alle sensorene relatert til en enkelt enhet faller inn i dette hierarkinivået.

Over det er en gruppe. Du kan inkludere mange enheter i en gruppe som bare brukes til organisatoriske formål. Du kan også hekke grupper for å gjøre det lettere å navigere i overvåkningshierarkiet.

Neste gang er du på sondenivå, som er inkludert i rotgruppen . Du kan ha mange sonder i din enkelt rotgruppe. En sonde er den "plattformen som overvåkningen foregår på. Alle objekter som er konfigurert under en sonde vil bli overvåket via den sonden."

Igjen, fra PRTG FAQ, her er en titt på objekthierarkiet ( figur A ).

Figur A

PRTG-objekthierarkiet

En titt på PRTG i aksjon

Målet mitt i forrige seksjon var ikke å fordype dypt i PRTG, men å gi deg litt kontekst om hva du vil se på i resten av denne artikkelen. Igjen, installasjonen du ser på er bare for "spill" for nå.

I figur B vil du se et høyt nivå på det overvåkede miljøet. For øyeblikket viser jeg alt - sensorer for feil, advarsel og god status. Ved å fjerne markeringen av riktig avkrysningsrute øverst på skjermen, kan jeg lettere bore ned i problemområder. Hvis jeg for eksempel fjerner markering av alt bortsett fra den røde ruten, vil jeg få vist bare sensorene som er i en feiltilstand. Dette er et syn som jeg virkelig liker i PRTG.

I figur B vil du også legge merke til at hver overvåket enhet er på en enkelt linje med sensorer i forskjellige tilstander til høyre. I stedet for å vise deg hver sensor, forteller PRTG deg bare at for eksempel 11 sensorer er i en grønn tilstand og fremhever de som er problemer.

Jeg vil også merke at jeg ennå ikke har endret noen av standardtersklene for PRTGs skjermer, så mye mer dukker opp som gult eller rødt enn det ville gjort hvis jeg skulle sette PRTG i produksjon.

Før du fortsetter, ta en topp i øverste høyre hjørne av skjermen. Du vil se at 24 sensorer er i en feiltilstand, 44 er i en advarselstilstand, 1001 er grønne og 79 sensorer er for øyeblikket pauset. Jeg skal forklare litt senere hvorfor 79 sensorer er satt på pause.

Figur B

Klikk for å forstørre.
I figur C har jeg boret ned til en nettverksenhet, som er en kjerneruter / -bryter. Her får jeg vist alle sensorene som er tilgjengelige for den enheten; det er 123. Jeg er først og fremst interessert i båndbreddebruk her og har flyttet den viktigste interesseposten - internettforbindelsen vår - til toppen av listen, slik at jeg kan se det først. Bryterporten heter "NetEnforcer switch - Inside Interface" på bryteren.

Figur C

Klikk for å forstørre
Når jeg klikker på NetEnforcer-grensesnittføleren, borer jeg litt dypere i statistikken, som du kan se i figur D. Her får jeg detaljert informasjon om portens nåværende og historiske status. Foreløpig er porten i OK tilstand og utnyttelsen er rett over 72 Mbps. På høyre side av vinduet kan du se noen andre grafer. Den øverste grafen viser live-data i sanntid, mens grafene nedenfor blir litt mindre kornete, men viser deg trender.

Figur D

Klikk for å forstørre
Figur E er et stort bilde av fanen Live Data øverst i portovervåkningsvinduet. Dette gir meg en flott oversikt over hva som skjer. Som du kan se, i løpet av den overvåkede perioden har vi brukt så mye som 94 Mbps internett båndbredde til enhver tid og falt til minimum 64 Mbps. Vår forbindelse til Internett er 100 Mbps.

Figur E

Klikk for å forstørre
Den to dagers visningen av Internett-trafikk vist i figur F viser deg ebben og flyten av internettbruken vår og identifiserer at vi har toppet litt over 96 Mbps og falt til så lavt som rundt 3 Mbps i de små timene om morgenen. Denne typen graf identifiserer trafikkmønstre som kan hjelpe oss i planleggingen.

Den blå delen av grafen viser utgående trafikk, som er mye, mye lavere enn innkommende.

Figur F

Klikk for å forstørre
PRTG er imidlertid mye mer enn bare en trafikkovervåker. Produktet har muligheten til å dypt overvåke tjenester på bedriftsnivå, for eksempel Exchange, og tilby beregninger som hjelper administratorer med å iverksette tiltak når det er nødvendig. I figur G kan du se at gjennomsnittlig leveringstid for meldinger for tiden er 3 179 ms på vårt Exchange-system. Basert på denne informasjonen vil jeg uavhengig bekrefte at PRTG rapporterer nøyaktig informasjon og, hvis den er, iverksette tiltak; det virker litt høyt, men jeg må sjekke det ut.

Øverst i dette vinduet, vær også oppmerksom på at du raskt får vist antall sensorer i forskjellige tilstander på denne enheten. Én sensor er i alarmtilstand mens den andre er i en advarselstilstand.

Figur G

Klikk for å forstørre

Ulemper

PRTG er ikke perfekt. Jeg liker imidlertid verktøyet. Selv om grensesnittet først var forvirrende, likte jeg det etter noen dager med bruk. Og produktet er ikke skandaløst dyrt.

Jeg har lagt merke til noen sensorer som rapporterer virkelig sprø ting. Etter nærmere undersøkelser har jeg oppdaget at noen sensorer ganske enkelt får dårlig informasjon tilbake fra kildesystemer, eller at noen sensorer bare ikke viser nøyaktig informasjon. Når det er sagt, sensorene som jeg har sett dette er langt fra kritiske, og det har ikke vært vanlig.

Den kanskje største mangelen er PRTG 9s nåværende manglende evne til å overvåke vSphere 5 og vCenter 5-systemer. Med det meste av miljøet vårt som kjører i VMware (vertene er alle 4.1, er bur vCenter i versjon 5 på grunn av et behov for å implementere en VMware View 5-pilot), og har ingen innsikt i VMware er en ikke-starter. Fra 6. oktober indikerte Paessler at det ikke var noen ETA for overvåkningsevnen. Dette er dessverre et enormt rødt merke for det som ser ut til å være et ellers fint produkt.

Sammendrag

Når vSphere / vCenter 5-støtte er inkludert i PRTG 9, tror jeg at produktet vil være en stor investering for mange organisasjoner. Selv om det ikke er perfekt, er den typen tilsynsovervåkning jeg trenger gjort veldig bra i PRTG 9, og gir lett identifiserte ledetråder som indikerer hvor handling er nødvendig.

© Copyright 2021 | pepebotifarra.com