Hands-on med Paessler PRTG 9 overvågningsværktøj

Jeg kan godt lide infrastrukturovervågningsværktøjer og har testet en hel del forskellige produkter. Et produkt, som jeg i øjeblikket tester, er den seneste version af et produkt, som jeg plejede at køre hos en tidligere arbejdsgiver: Paessler PRTG. Den seneste version er PRTG 9, og den kan prale af nogle fede nye funktioner i forhold til ældre versioner, men har også en alvorlig begrænsning med det.

Husk, at jeg kører PRTG 9 i en temmelig grundlæggende tilstand lige nu, da jeg simpelthen tester produktet, så jeg ikke nøje har kategoriseret og beskåret de emner, der overvåges.

En PRTG-primer

I PRTG-land oprettes sensorer til overvågning af individuelle ydelseselementer. En sensor er det mest basale overvågningselement. I PRTG ofte stillede spørgsmål "definerer en en (1) sensor som enhver særlig, individuel overvågningsenhed." En enkelt sensor er muligvis ansvarlig for at se tilgængelig diskplads på drevene på en server, mens en anden sensor muligvis er ansvarlig for at se diskkølengden. PRTG fungerer ikke på forestillingen om overvågede enheder eller IP'er. I stedet køber du sensorlicenser, og du kan overvåge så dybt eller så højt niveau, som du vil, så længe du forbliver inden for det licenserede sensortælling.

Virksomheden angiver, at enhver rimelig desktopcomputer let skal kunne overvåge 1.000 eller flere sensorer. Fra PRTG FAQ: " SNMP V1 / V2 , PING, PORT og HTTP er de anbefalede sensortyper til scenarier med tusinder af sensorer. Med disse teknologier er op til 20.000 sensorer mulige" i en enkelt PRTG-installation.

Objekthierarki

Jeg har nævnt, at den grundlæggende overvågningsenhed er en sensor, men der er grupper på højere niveau, der indeholder disse sensorer. Umiddelbart over sensorer er du på enhedsniveau. Alle sensorer relateret til en enkelt enhed falder ind i dette hierarkiniveau.

Over det er en gruppe. Du kan inkludere mange enheder i en enkelt gruppe, der udelukkende bruges til organisatoriske formål. Du kan også indlejre grupper for at gøre det lettere at navigere i dit overvågningshierarki.

Dernæst er du på sondeniveau, som er inkluderet i rodgruppen . Du kan have mange sonder i din enkelt rodgruppe. En sonde er den "platform, hvorpå overvågningen finder sted. Alle objekter, der er konfigureret under en sonde, overvåges via denne sonde."

Igen fra PRTG FAQ er her et kig på objekthierarkiet ( figur A ).

Figur A

PRTG-objekthierarkiet

Et kig på PRTG i aktion

Mit mål i det foregående afsnit var ikke at dybe dybt ned i PRTG, men at give dig en kontekst om, hvad du vil se på i resten af ​​denne artikel. Igen er installationen, du ser på, kun til "play" for nu.

I figur B kan du se et højt niveau på det overvågede miljø. I øjeblikket viser jeg alt - fejl-, advarsels- og god statusfølere. Ved at fjerne markeringen af ​​det relevante afkrydsningsfelt øverst på skærmen kan jeg lettere bore ned i problemområder. For eksempel, hvis jeg fravælger alt undtagen den røde boks, vises jeg bare de sensorer, der er i en fejltilstand. Dette er en opfattelse, som jeg virkelig kan lide i PRTG.

I figur B vil du også bemærke, at hver overvåget enhed er på en enkelt linje med sensorer i forskellige tilstande til højre. I stedet for at vise dig hver sensor, fortæller PRTG bare dig, at for eksempel 11 sensorer er i en grøn tilstand og fremhæver dem, der er problemer.

Jeg vil også bemærke, at jeg endnu ikke har ændret nogen af ​​standardtærsklerne for PRTG's skærme, så meget mere vises som gul eller rød end det ville være, hvis jeg skulle sætte PRTG i produktion.

Før du fortsætter, skal du tage et højdepunkt i øverste højre hjørne af skærmen. Du vil se, at 24 sensorer er i en fejltilstand, 44 er i en advarselstilstand, 1001 er grøn og 79 sensorer er i øjeblikket midlertidigt standset. Jeg vil forklare lidt senere, hvorfor 79 sensorer er sat på pause.

Figur B

Klik for at forstørre.
I figur C har jeg boret ned til en netværksenhed, som er en core router / switch. Her får jeg vist alle de sensorer, der er tilgængelige for den enhed; der er 123. Jeg er primært interesseret i båndbreddeudnyttelse her og har flyttet mit primære interessepunkt - vores internetforbindelse - til toppen af ​​listen, så jeg kan se det først. Omskifterporten hedder "NetEnforcer-switch - Inside Interface" på kontakten.

Fig

Klik for at forstørre
Når jeg først har klikket på NetEnforcer-interfaceføleren, borer jeg lidt dybere i statistikken, som du kan se i figur D. Her får jeg detaljerede oplysninger om portens nuværende og historiske status. I øjeblikket er denne port i en OK-tilstand, og anvendelsen er lige over 72 Mbps. I højre side af vinduet kan du se nogle andre grafer. Den øverste graf viser livedata i realtid, mens nedenstående grafer får lidt mindre granular, men viser dig tendenser.

Figur D

Klik for at forstørre
Figur E er et stort billede af fanen Live data øverst i vinduet til overvågning af havne. Dette giver mig et godt overblik over, hvad der sker. Som du kan se, har vi i løbet af den overvågede periode brugt så meget som 94 Mbps internetbåndbredde på et hvilket som helst tidspunkt og faldet til mindst 64 Mbps. Vores forbindelse til Internettet er 100 Mbps.

Figur E

Klik for at forstørre
Den to dage lange visning af internettrafik, der er vist i figur F, viser dig ebben og strømmen af ​​vores internetforbrug og identificerer, at vi har nået et højt niveau på godt 96 Mbps og faldet til så lavt som omkring 3 Mbps i de små timer om morgenen. Denne type graf identificerer trafikmønstre, der kan hjælpe os med planlægningen.

Den blå del af grafen viser udgående trafik, hvilket er meget, meget lavere end indkommende.

Figur F

Klik for at forstørre
PRTG er dog meget mere end bare en trafikmonitor. Produktet har evnen til at dybt overvåge tjenester på virksomhedsniveau såsom Exchange og levere metrics, der hjælper administratorer med at gribe ind, når det er nødvendigt. I figur G kan du se, at den gennemsnitlige leveringstid for meddelelser i øjeblikket er 3.179 ms på vores Exchange-system. Baseret på disse oplysninger vil jeg uafhængigt verificere, at PRTG rapporterer nøjagtige oplysninger og i bekræftende fald gribe ind; det virker lidt højt, men jeg er nødt til at tjekke det ud.

Øverst i dette vindue skal du også bemærke, at du hurtigt får vist antallet af sensorer i forskellige tilstande på denne enhed. Én sensor er i en alarmtilstand, mens den anden er i en advarselstilstand.

Figur G

Klik for at forstørre

Ulemper

PRTG er ikke perfekt. Jeg kan dog godt lide værktøjet. Selvom grænsefladen først var forvirrende, efter nogle dages brug kunne jeg godt lide det. Og produktet er ikke uhyrligt dyrt.

Jeg har bemærket nogle sensorer, der rapporterer virkelig skøre ting. Efter nærmere undersøgelse har jeg opdaget, at nogle sensorer simpelthen får dårlige oplysninger tilbage fra kildesystemer, eller at nogle sensorer bare ikke viser nøjagtige oplysninger. Når det er sagt, er de sensorer, jeg har set, langt fra kritiske, og det har ikke været almindeligt.

Den største mangel er måske PRTG 9's aktuelle manglende evne til at overvåge vSphere 5 og vCenter 5-systemer. Med det meste af vores miljø, der kører i VMware (værterne er alle 4.1, bur vCenter er i version 5 på grund af et behov for at implementere en VMware View 5-pilot), der ikke har nogen indsigt i VMware er en ikke-starter. Fra den 6. oktober angav Paessler, at der ikke var nogen ETA for overvågningskapaciteten. Dette er desværre et enormt rødt mærke for hvad der ser ud til at være et ellers fint produkt.

Resumé

Når vSphere / vCenter 5-support er inkluderet i PRTG 9, tror jeg, at produktet vil være en stor investering for mange organisationer. Selvom det ikke er perfekt, er den slags overvågningsovervågning, som jeg har brug for, udført meget godt i PRTG 9, hvilket giver let identificerede signaler, der angiver, hvor handling er påkrævet.

© Copyright 2020 | mobilegn.com