Overvåking - The next generation / Zabbix

Skalering

Skalering i Zabbix er avhengig av flere variabler:

• Antall "Items" (rådata verdier) og oppdateringsfrekvens: For å håndtere innsamling av et stort antall Items kan man bruke flere Zabbix-proxier som kan samle disse verdier.

  I tillegg kan innsamling av data utføres i aktiv eller passiv modus. Zabbix agenter som kjører i aktive modus samler data og kontakter Zabbix proxier når de har data å sende. På denne måten slipper man å måte spørre agentene om verdier som skal samles.

  Det anbefales å ikke bruke oppdateringsfrekvenser mindre enn 60 sek for å ikke overbelaste systemet og databasen.

• Antall triggere/handlinger: Triggere og handlinger i Zabbix håndteres av Zabbix serveren. Denne serveren må ha nok resursser for å håndtere prossesering av data som skal analyseres og handlinger som skal utføres.

  Et eksempel på ressursene som trenges for å å håndtere 76.000+ triggere for 690.000+ items og ca 7.000 hoster kan finnes på en blog innlegg i Zabbix Weblog. Zabbix serveren i dette tilfelle kjøres på en server med 12x Intel Xeon E5-2630 og 16GB minne.

  Ref: http://blog.zabbix.com/scalable-zabbix-lessons-on-hitting-9400-nvps/2615/

• Historiskk data: All data som samles inn lagres i en database. Hvor mye data lagres og for hvor lenge man gjør dette kan ha en innvirkning på total ytelsen av overvåkingssystemet.

  Zabbix lagrer to type historiskk data:

  • Rådata: All rådata (Items) som samles inn.
  • Trender: min, max, avg av numerisk rådata.

  Zabbix anbefaler å lagre 1-2 uker med rådata og minst 1-2 år med trend data for kapasitetsplanlegging.

  Trend data regnes ut og lagres 1 gang i time.

  Triggere bruker rådata for å regne ut logiske utrykk for en tidsperiode, man burde ha nok rådata i databasen for å klare å prosessere disse triggere.

  Database systemet som brukes av Zabbix er en veldig sentral komponent og en god konfigurasjon og vedlikehold av den er avgjørende for at systemet skal fungere uten problemer.

  I store systemer med tusenvis av hoster, items og triggers anbefales å kjøre databasen på en dedikert server og å bruke partisjonering av tabellene som brukes for lagring av historiskk data.

• Antall brukere: Antall brukere som akseserer webkonsollet og API-et er også noe man må ta i betrakting når det gjelder skalering av Zabbix.

  Man kan skalere webløsningen som brukes av webkonsollet og API-et via en standard HA løsning i aktiv-aktiv konfigurasjon. PHP:APC burde også brukes for opcode cache i PHP.

Redundans

Vanligvis pleier man å ha redundans på disse komponenter:

• Zabbix serveren: Zabbix serveren kan ikke brukes i en aktiv-aktiv HA løsning. Den kan kun fungere i en aktiv-passiv HA løsning.

• Zabbix webkonsoll / API: Webkonsollet og API-et snakker direkte med Zabbix databasen. Man kan bruke en aktiv-aktiv HA løsning hvor alle webservere kan levere data samtidig.

• Zabbix database: Er Zabbix databasen nede, kan man ikke aksesere systemet eller endre konfigurasjon. Innsamling av data burde fortsette å fungere via Zabbix proxier men data kan ikke leveres videre til Zabbix serveren er tilgjengelig.

  Man burde bruke en replikeringsløsning i aktiv-passiv modus hvis man ikke kan tåle noe nedetid av databasen.

Vurdering

• Veldig rent arkitektur, enkel å installere og konfigurere.
• Veldig gode muligheter for distribuert overvåking og skalering.
• Støtte for aktive/passive koblinger.
• Kan levere TSD overvåking

Distribusjon av programvare: source, rpm, deb?

Zabbix distribueres via source, rpm og deb pakker.

Vi har testet RPM distribusjonen med RHEL6. RPM pakkene er tilgjengelige via et offiselt repository fra Zabbix eller fra EPEL repository.

Vi har testet de to repoer, men EPEL inneholder en ca et år gammel versjon av produktet. Å vente i et år for å få en oppdatert versjon kan gjøre vedlikehold av systemet vanskelig i noen tilfeller. På grunn av dette har vi brukt det offiselle repoet under testing .

Zabbix repoet er tilgjengelig på denne adressen: http://repo.zabbix.com/zabbix/2.2/rhel/6/x86_64/

Programvare avhengigheter

Zabbix har veldig få avhengigheter og alle leveres via RPM filer.

Zabbix server og proxy er avhengig av:

OpenIPMI
libssh2
fping
libcurl
net-snmp

Webserveren trenger en webserver med PHP støtte for å kunne kjøre webkonsollen og API-et. Disse pakker må være installert:

httpd
mod_ssl
php
php-common
php-pgsql
php-gd
php-bcmath
php-ctype
php-xml
php-xmlreader
php-xmlwriter
php-session
php-net-socket
php-mbstring
php-gettext
php-pecl-apc
php-mcrypt
php-cli
php-pdo
php-pear
php-ldap

Installasjon av database

Zabbix støtter flere databaser, vi har brukt siste versjon av PostgreSQL (9.3) under testing med standard installasjon via PostgreSQL.org yum repository.

Etter at databasen og Zabbix serveren har blitt installert må man kjøre noen SQL scripter som finnes under /usr/share/doc/zabbix-server-pgsql-2.2.5/create for å initialisere den sentrale databasen. Noe tilsvarende må gjøres med hver database som brukes av en proxy server.

Ikke noen problemer har blitt oppdaget med databasen.

Installasjon av sentral server

Installasjonen av Zabbix server trenger kun en RPM pakke:

zabbix22-server-pgsql

Problemer med SElinux etter installasjon. SElinux ble slått av under testing av Zabbix server. Man må bruke litt tid med SElinux regler før Zabbix serveren kan brukes i produksjon med SElinux aktivert.

Installasjon av distribuert / proxy komponenter

Installasjon av Zabbix proxy trenger kun en RPM pakke:

zabbix-proxy-pgsql

Problemer med SElinux etter installasjon. SElinux ble slå av under testing av Zabbix proxy. Man må bruke litt tid med SElinux regler før Zabbix proxy kan brukes i produksjon med SElinux aktivert.

Installasjon av webkonsoll og API

Installasjon av webkonsoll og API-et trenger kun en pakke:

zabbix22-web-pgsql

Ikke noen problemer har blitt oppdaget under installasjon av webkonsoll / API.

Installasjon av native agenter

Zabbix agenter trenger kun en pakke på linux/unix:

zabbix-agent

Og en EXE fil på Windows.

Installasjon av SNMP agenter

SNMP agenter er integrert i Zabbix server og proxy og trenger ikke ekstra installasjon.

Installasjon av IPMI agenter

IPMI agenter er integrert i Zabbix server og proxy og trenger ikke ekstra installasjon.

Installasjon av add-ons / plugins

Zabbix støtter ikke add-ons eller plugins for å utvide Zabbix funksjonalitet på samme måte som andre produkter.

Zabbix har muligheter til å utvide sin funksjonalitet med å definere nye maler eller type rådata som skal overvåkes. Dette kan brukes for å levere samme funksjonalitet som leveres via plugins i andre produkter.

Zabbix støtter ikke add-ons for å endre på webkonsollen. Man kan bare opprette nye "themes" hvis man vil endre på utseende.

Man kan bruke API-et for å lage tredje part software som leverer ekstra funksjonalitet men som ikke er integrert i Zabbix webkonsollet. e.g. Mange mobil applikasjoner som kan brukes for å aksesere Zabbix bruker API-et for å aksessere Zabbix.

Ref: https://www.zabbix.com/documentation/2.2/manual/installation

Vurdering

• Enkel å installere via RPM pakker. Anbefales å bruke Zabbix yum repo for å få tilgang til oppdaterte versjoner og et enklere vedlikehold av systemet.

• Installasjon kan automatiseres uten problemer med CFengine e.l.

• Den har ikke avhengigheter til tredje part software som kan være et problem i fremtidige oppgraderinger.

• Noen SElinux problemer med Zabbix server/proxy/agenter som må jobbes med for å få alt til å fungere 100% med SElinux. Noen av disse problemer ble forårsaket av en bug i selinux-policy pakken til RHEL.6.5, dette burde være fikset i RHEL6.6 oppgradering. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1039851

  Utvider man Zabbix med flere sjekk som skal ha tilgang til informasjon som ikke tillates av SElinux, må man sannsynligvis definere SElinux regler som tillater dette.

Konfigurasjonsoversikt

Hele konfigurasjonen av komponenter som skal overvåkes, hostgrupper, brukere, brukergrupper, tilganger, maler, grafer, triggere, handlinger, webkonsollen, osv lagres i databasen og kan oppdateres via webkonsollen eller API-et.

Webkonsollen trenger i tillegg en konfigurasjonsfil med informasjon om Zabbix hoveddatabasen.

Zabbix serveren trenger en konfigurasjonsfil med bl.a. database informasjon og noen parametere som definerer hvordan serveren skal oppføre seg, cache verdier, antall prosseser som er tillat, porter, osv.

Zabbix proxyer trenger en konfigurasjonsfil med bl.a. database informasjon og noen parametere som definerer hvordan proxyen skal oppføre seg, aktive/passiv modus, zabbix serveren, cache verdier, porter, osv.

Zabbix agenter trenger en konfigurasjonsfil med bl.a. noen parametere som definerer hvordan agenten skal oppføre seg, proxy server, porter, osv.

Ref: https://www.zabbix.com/documentation/2.2/manual/appendix/config

Konfigurasjon av alarmer, triggere, osv

Denne informasjonen er fullt tilgjengelig via webkonsollen og kan oppdateres etter behov.

Ref: https://www.zabbix.com/documentation/2.2/manual/config

Dette er også fullt tilgjengelig via API-et og kan oppdateres etter behov.

Ref: https://www.zabbix.com/documentation/2.2/manual/api

Webkonsoll konfigurasjon

Webkonsollen er det eneste stedet hvor man kan konfigurere parametere som er relatert til webkonsollen.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface

Dette er ikke tilgjengelig via API-et.

Intern konfigurasjon (timeouts, ldap parametere, database, osv)

Denne informasjonen er delvis tilgjengelig via webkonsollen og delvis tilgjengelig via konfigurasjonsfiler.

Dette kan ikke konfigurares via API-et.

Konfigurasjon av roller / grupper / tilganger

Denne informasjonen er full tilgjengelig via webkonsollen og kan oppdateres etter behov.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/users_and_usergroups

Dette er også fullt tilgjengelig via API-et og kan oppdateres etter behov.

Ref: https://www.zabbix.com/documentation/2.2/manual/api

Auto-discovery

Zabbix levereres med funksjonalitet for å oppdage systemer og komponenter, de kaller denne funksjonaliteten Auto-discovery.

Auto-discovery kan brukes for tre ting:

• Oppdage og registrere/slette systemer som skal/ikke skal overvåkes
• Auto-registrering via Zabbix agenter.
• Low-level auto-discovery (Filsystemer, nettverkskort, SNMP OIDs). Man kan også lage custom low-level auto-discovery regler (e.g oppdage databaser i en cluster)

Denne funksjoneliteten leverer mange muligheter for å kontrollere det som skal oppdages og registreres og det kan lette arbeidet i noen tilfeller med å konfigurere overvåking hvis den blir brukt smart.

Ref: https://www.zabbix.com/documentation/2.2/manual/discovery/

Templates

En template eller mal er et sett med komponenter og definisjoner som grupperes for å gjenbruke dem på flere hoster. Templates er en viktig funksjonalitet når det gjelder automatisering av Zabbix konfigurasjon.

En mal aktiviseres på en host, ikke på en hostgruppe. En host kan ta i bruk en eller flere maler og man kan kjøre bulk oppdatering av hoster basert på hostgrupper. Dette gjøres slik for å kunne definere avhengigheter mellom hoster på trigger nivå.

Alle hoster som bruker en mal får automatisk alle fremtidige oppdateringer som gjøres på malen.

Zabbix leveres per default med et sett med ferdige maler klare til bruk:

• Viktigste netttjenester som kan kjøres på en maskin
• Zabbix infrastruktur
• IPMI Intel SR1530/1630
• JMX generic/tomcat
• Linux/Unix OS
• Windows OS
• SNMP
• VMware

De komponentene som kan registreres i en template er:

• Rådata som overvåkes (Items)
• Triggere
• Grafer
• Applikasjoner
• Lerreter (Screens): Skreddersydde websider som defineres av brukere for visning av data.
• Oppdagelses regles (low-level discovery rules)
• Web overvåkingsregler (web scenarios)

Ref: https://www.zabbix.com/documentation/2.2/manual/config/templates

Import / eksport av konfigurasjon.

Zabbix støtter eksport og import av konfigurasjon via XML og JSON.

Denne funksjonaliteten kan brukes for å eksportere eller importere disse elementer via webkonsollet eller API-et:

• Host grupper (Zabbix API only)
• Maler (items, triggers, graphs, screens, discovery rules og template linkage)
• Host (items, triggers, graphs, discovery rules og template linkage)
• Karter
• Bilder
• Lerret (Screens): Skreddersydde websider som defineres av brukere for visning av data.

Vurdering

• Konfigurasjon av componentene (server, proxy, agent og webkonsoll) kan automatiseres uten problemer med CFengine e.l.
• All konfigurasjon relatert til overvåking og tilgang lagres i en sentral database som kan akseseres eller endres via webkonsollen eller API-et. API dokumentasjon kunne trenge flere eksempler.
• Ekstremt fleksibel konfigurasjonshåndtering med mange muligheter til å få ønsket resultat.
• Veldig fleksibel håndtering av maler og elementene i malene.
• Fleksibel auto-discovery funksjonalitet som kan brukes i flere tilfeller hvis den blir brukt smart.
• Gode muligheter for toveis integrasjon med andre systemer via API-et.
• Gode muligheter for å hente data via API-et for e.g. å lage rapporter eller commandline applikasjoner/skripter.

Autentisering via ldap/ad

Zabbix kan kobles via LDAPS til en ldap katalog for å autentisere brukere som skal logge inn via webkonsollet eller API-et.

Brukere som skal logge inn via LDAP må uansett være opprettet i Zabbix før de skal kunne logge inn. Dette kan automatiseres via Zabbix API-et.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/administration/authentication

Autorisering via ldap/ad

Zabbix støtter ikke autorisering via eksterne kilder (LDAP / AD). Autoriseringsregler må defineres i Zabbix. Skal man synkronisere Zabbix grupper med Cerebrum må en synkroniseringsjobb lages. Dette kan automatiseres via Zabbix API-et.

Autentisering via Kerberos

Zabbix støtter Apache-based (HTTP) autentisering, man kan i teorien bruke dette for å koble Apache til en kerberos server via mod-auth-kerb. Dette er ikke testet, selv om det finnes informasjon i Zabbix forum om folk som bruker dette for å tilby kerberos autentisering.

Grupper av ressurser (maskiner,osv)

Zabbix støtter Hostgruppe for å gruppere ressurser. Man kan definere brukergrupper som skal ha tilgang til å se og modifisere disse grupper.

En ressurs kan være medlem i flere hostgrupper.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/configuration/hostgroups

Grupper av tjenester

Man kan også bruke Hostgrupper funksjonalitet for å definere alle komponentene som leverer en tjeneste.

Grupper av brukere

Zabbix støtter brukergruppe funksjonalitet for å gruppere brukere. Tilgangsregler defineres på brukergruppe nivå.

En bruker kan være medlem i flere grupper.

Grupper kan ikke være medlem i andre grupper, sannsynligvis fordi håndtering av inkompatible tilgansregler blir for komplisert.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/users_and_usergroups/usergroup

Assosiering mellom grupper

En brukergruppe kan få tilgang til en eller flere hostgrupper, templates eller enkelte hoster. Tilgangen kan være av type lese/skrive, kun lesing eller deny.

Vurdering

• Tilgangskontroll til de forskjellige hostgrupper og templates støttes via brukergrupper. Det er et fleksibel system.
• Gode muligheter for delegering av administrasjonsoppgaver via "Zabbix admin" rolen.
• Autentisering via LDAP støttes.
• Autentisering via kerberos kan i teorien brukes via HTTP autentisering i Zabbix og mod-auth-kerb i Apache. Dette er ikke testet.
• Synkronisasjon mellom brukergrupper i Zabbix og Cerebrum må implementeres. Dette kan gjøres via Zabbix API-et.

Brukere og rettigheter som trenges under installasjon

Man må være root for kunne installere alle pakkene som trenges via yum.

Brukere og rettigheter som trenges under innhenting av data

Zabbix kan kjøres som brukeren zabbix både på serveren/proxyer og på agentene.

Autentisering mellom komponenter

Zabbix bruker ikke noen form for autentisering mellom komponentene.

Man kan definere hvilke host har lov til å koble seg til en server/proxy eller agent. I tillegg må hoster og proxyer være definert i den sentrale Zabbix serveren for at de skal kunne levere informasjon.

Man kan bruke IPtables regler på Zabbix serveren og Zabbix proxyer for å implementere et ekstra sikkerhetsnivå på løsningen.

Kryptering av trafikk mellom komponenter

Zabbix støtter ikke per default SSL kryptering av trafikken mellom Zabbix komponenter. Man kan ta i bruk eksterne metoder hvis man vil implementere kryptering mellom komponentene. Zabbix anbefaler å bruke tunnelering via SSH eller Stunnel hvis man trenger å implementere kryptering.

Tilgang til webkonsollet og API-et støtter SSL kryptering via webserveren.

Kryptering av trafikk under innhenting av data

Zabbix støtter ikke per default SSL kryptering mellom Zabbix proxyer og Zabbix agenter. Igjen, man kan implementere dette via eksterne metoder som tunnelering via SSH eller Stunnel.

SNMPv3 og sjekker via SSH støttes av Zabbix, så man kan eventuelt bruke disse metoder hvis man skal hente konfidensiell data og ikke vil bruke tunnelering.

API tilgangskontroll

Tilgangskontroll til API-et bruker samme data som brukes for å definere tilgangen til Zabbix webkonsollet. Man akseserer API-et via HTTPS på samme serveren som kjører webkonsollet.

Man må logge inn første gang med en gyldig brukenavn/passord for å få tildelt en auth-token som kan brukes videre i følgende kommandoer i en sesjon. Man kan definere om en bruker skal logges ut automatisk eller ikke etter X antall sekunder uten aktivitet.

Kjøres innloggingsprosedyre automatisk fra et ikke interaktiv skript/program må brukernavn/passord være definert et sted.

Integrasjon mot andre systemer

Integrasjon mot andre systemer kan gjøres via Zabbix API-et. Dette må programeres og man kan bruke hvilket som helst programmeringsspråk så lenge det klarer å håndtere JSON/XML data og RPC kall.

Aktive / passiv koblinger

Både Zabbix agenter og Zabbix proxyer kan brukes i aktive eller passive modus. Når de fungerer i aktive modus er det de som starter koblinger mot en Zabbix proxy eller Zabbix server. I passive modus er det omvendt og de venter på en kobling fra en Zabbix proxy eller Zabbix server.

Denne funksjonaliteten kan brukes for å implementere overvåking i TSD prosjektet, med en eller flere Zabbix proxyer på innsiden av TSD i aktive modus som starter koblingen mot en Zabbix server på utsiden for sending av overvåkingsdata.

Backup

Backup av Zabbix data kan implementeres med backup av den sentrale databasen som brukes for å lagre konfigurasjons og overvåkingsdata.

Ved bruk av PostgreSQL kan dette implementeres via logical backups og PITR (Point in time recovery) funksjonalitet.

Konfigurasjon av Zabbix server, Zabbix proxyer og Zabbix agenter trenger ikke backup da informasjonen som trenges for å installere/konfigurere disse komponenter håndteres via CFengine e.l.

Vurdering

• Oversiktlig arkitektur med veldig klare metoder og regler for interaksjon mellom komponenter.
• Støtter ikke SSL kryptering per default. Man må bruke eksterne metoder for å implementere dette hvis det trenges (SSH tunnelering og Stunnel).
• Zabbix bruker ikke noe autentiseringsmetode mellom komponenter (Zabbix server, proxy og agenter), kun IP tilgang. Dette kan være et problem på nettverk som ikke kan stoles. Hoster og proxyer må være registrert i Zabbix for at de skal få lov til å levere data.
• Man burde bruke IPtables regler på Zabbix serveren og Zabbix proxyer for å implementere et ekstra sikkerhetsnivå på løsningen.
• Tilgang til webkonsollen og API-et krypteres via webserveren og krever autentisering.

Via native agenter

Zabbix agenten er en daemon som bruker veldig få ressurser og som kan brukes for innhenting av data fra de systemene hvor den kjøres. De prosseserer ikke noe data da dette gjøres i Zabbix serveren.

De kommer med et sett predefinerte sjekker per default og kan på en enkel måte utvides med flere sjekker etter behov. De kan i tillegg brukes for å hente system data som kan brukes for å oppdatere inventar funksjonalitet i Zabbix.

Det finnes Zabbix agenter for Linux/Unix, Windows og Mac.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/zabbix_agent

Via SNMP

Agenter for SNMPv2 og SNMPv3 er tilgjengelige på Zabbix server og alle Zabbix proxyer og kan utføre sjekker via tcp eller traps. Low level auto-discovery brukes for å finne ut de SNMP attributter som er tilgjengelige i et system.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/snmp

Via IPMI

Agenter for IPMI sjekker er tilgjengelige på Zabbix server og alle Zabbix proxyer og kan utføre sjekker via IPMI protokollen for overvåking av hardware komponenter. Denne funksjonaliteten har ikke blitt testet.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/ipmi

Via ICMP

Zabbix støtter sjekker via ICMP.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/simple_checks

Via port sjekk

Zabbix støtter sjekker av tcp porter for å overvåke netverkstjenester. Den leveres med et sett default tjenester definert og man kan definere andre ved behov.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/simple_checks

Via eksterne plugins, ssh, powershell, osv

Zabbix støtter sjekker via SSH, Telnet, eksterne programmer og "trappers".

Sjekker via SSH, Telnet og eksterne programmer er tilgjengelig via Zabbix serveren og Zabbix proxyer, mens "trappers" er programmer som kjøres på komponenter som overvåkes og kan sende data direkte til Zabbix serveren eller Zabbix proxyer.

Via java/JMX

Agenter for JMX sjekker er tilgjengelige på Zabbix server og alle Zabbix proxyer og kan utføre sjekker via JMX på komponenter og systemer som kan bruke denne teknologien. Denne funksjonaliteten har ikke blitt testet.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/jmx_monitoring

Sjekk av websider / tjenester

Zabbix støtter sjekker av websider og webapplikasjoner, den sjekker nedlastingshastighet, responstid og statuskode. Den kan også hente innholdet i en side og simulere handlinger som en bruker kan utføre på sidene.

Sjekk av databaser

Zabbix støtter sjekker av databaser via ODBC. Alle databasene som støttes av ODBC kan overvåkes via Zabbix.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/odbc_checks

Hente data fra andre overvåkingssystemer, Scom, SSCM, vcops

Så lenge man kan hente data fra disse overvåkingssystemer burde det være mulig å importere det til Zabbix med en av de metodene som støttes for datasamling.

Data fra virtuelle løsninger

Zabbix støtter overvåking av VMware systemer. Den krever VMware vCenter eller vSphere versjon >= 4.1.

Den leveres med templates som kan brukes for å implementere overvåking av diverse komponenter i VMware vCenter og ESX hypervisor. Zabbix bruker VMware web services via SOAP protokoll for å hente data. Denne funksjonaliteten har ikke blitt testet.

Ref: https://www.zabbix.com/documentation/2.2/manual/vm_monitoring

Via Nagios plugins

I tilfeller hvor en komplisert Nagios plugin med mye logikk i koden ikke kan erstattes på en enkel måte med Zabbix items og trigger funksjonalitet, kan man ta i bruk Nagios pluginen på følgende måte, hvis status leveres i outputen fra plugingen:

• Definere en text "Item" som får som input tekststrengen fra Nagios plugin output.
• Definere en trigger for Nagios Warning status som bruker funksjonen Item-navn.regexp() for å generere en alarm med Zabbix viktighetsgrad Warning eller Average.
• Definere en trigger for Nagios Critical status som bruker funksjonen Item-navn.regexp() for å generere en alarm med Zabbix viktighetsgrad High eller Disaster.

Hvis status ikke leveres via output men via plugin return verdi, må man bruke en generell wrapper som kjører plugin, leser return verdi og output og sender dette inn i Zabbix.

Er Nagios plugin ikke komplisert anbefales å definere en vanlig Zabbix Item/Trigger som erstatter den.

Vurdering

• Bredt spekter av sjekker når det gjelder protokoller og type data som kan hentes inn.
• Alle data typer vi har behov for og noen ekstra er tilgjengelig per default.
• Muligheter for å gjenbruke Nagios plugins selv om man ikke får bruke alt funksjonalitet tilgjengelig i Zabbix (trender, aggregering, osv med numeriske verdier). Man kan kun få tekststrenger fra pluginen selv om det man kanskje overvåker er numeriske verdier.

Varslingsoversikt

Hovedsiden i Zabbix webkonsollet har flere områder som brukes for å vise en oversikt over alarmer og snarveier til andre viktig datakilder.

Man kan flytte disse områder mellom tre kolonner og man har muligheter til å filtrere hostgrupper og type alarmer som skal vises her. De viser kun data man har tilgang til.

Detaljerte varslinger

Det finnes flere menyer som har oversikter og detaljer over de sjekkene og alarmer som genereres. Man kan i de fleste tilfeller filtrere informasjonen som vises etter hostgrupper, sjekk typer og enkelte hoster.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/monitoring/overview

Grafer / trending

All data som hentes inn i Zabbix lagres i en database hvor man har trending data. Det er denne dataen som kan brukes for å generere grafer.

Zabbix leveres med et sett default grafer som blir tilgjengelige via forskjellige maler. Nye grafer kan defineres etter behov.

Zabbix har interne minneområder for historiskk data som brukes for å cache trend og rådata data (maks.2GB + 2GB) så man slipper å spørre databasen hele tiden.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/monitoring/graphs

Søkemuligheter

Zabbix leveres med et globalt søk funksjonalitet tilgjengelig via webkonsollet. Man kan på en enkel måte søke etter verdier i disse områder og få en detaljert oversikt over resultatet:

• Hoster
  • Navn / alias
  • IP
  • DNS
• Maler:
  • Navn
• Host grupper:
  • Navn

Med denne funksjonaliteten kan man få oversikt veldig rask over e.g. maskiner som inneholder prod eller test i navnet, eller komponenter som kjøres på en bestemt subnett.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/global_search

Man kan også bruke API-et for å søke etter komponenter som tilfredsstiller andre kriterier som ikke inkluderes i søk funksjonalitet som er tilgjengelig via webkonsollet.

Kart funksjonalitet

Zabbix kan levere kart funksjonalitet. Denne funksjonaliteten er veldig fleksibel og med mange muligheter men den støtter desverre ikke automatisk generering av et kart.

Kart kan defineres via webkonsollet eller API-et og kan bli importert/eksportert til JSON/XML filer.

Man kunne implementere automatisk oppdatering/generering av kart via API-et med data fra eksterne kilder men dette krever å utvikle kode som kan levere dette og det er ukjent hvor mye jobb dette krever.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/configuration/maps

Custom visning

Webkonsollen gir muligheter til å definere lerret (screens) som viser tilpasset og filtrert informasjon. Disse sider kan vise grafer, alarmer og andre komponenter som er tilgjengelige i Zabbix konsollen.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/configuration/screens

Slideshow muligheter

Lysbilderserier (slideshows) kan vise forskjellige lerret i en loop.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/configuration/slides

Tilgang til raw data

All data som hentes via Zabbix lagres i en sentral database og er tilgjengelige i tidsperioden som man har definert den skal leve i databasen.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/monitoring/latest_data

Inventar / CMDB

Zabbix leverer inventar funksjonalitet. Man lagrer denne informasjonen i databasen og den kan akseseres via webkonsollet eller API-et. Dataen i inventaren kan også brukes via macroer for å tilpasse informasjonen som sendes i meldinger som genereres etter en alarm.

Det burde ikke være veldig vanskeling å bruke denne informasjonen for å generere avanserte rapporter via API-et.

Ref: https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/inventory/hosts

Konsoll på mobile enheter

Det finnes flere mobile applikasjoner som kan brukes for å aksesere Zabbix.

Ref: http://www.zabbix.com/third_party_tools.php

Vurdering

• Gode muligheter for å lage tilpasset lerret og lysbildeserier med informasjonen man trenger.
• God støtte for inventar funksjonalitet.
• Muligheter for å aksesere Zabbix via mobile applikasjoner.
• Litt gammeldags webgrensesnitt.
• Det er ikke 100% intuitivt å bruke webgrensesnittet noen steder før man blir vant til det.

Trigger definisjoner

Trigger definisjoner i Zabbix er en av de sterke sidene i dette produktet. En kraftig funksjonalitet som tillater veldig fleksible trigger definisjoner som kan brukes for å levere svært nøyaktige alarmer.

En trigger i Zabbix tar imot rådata som har blitt hentet, og bruker funksjoner og logiske uttrykk for å levere en tilstand. Tilstanden på en Zabbix trigger kan være:

• OK: Alt er normal
• Problem: Noe har skjedd (logisk uttrykk er TRUE)

I tillegg har en trigger viktighetsgrader og de definerer dem slik:

• Not classified: Ikke klassifisert
• Information: Informasjon
• Warning: Advarsel
• Average: Gjennomsnittlig problem
• High: Viktig hendelse
• Disaster: Katastrofe hendelse med økonomiske og omdømme tap

Ref: https://www.zabbix.com/documentation/2.2/manual/config/triggers

Triggere som bruker data fra flere kilder før en alarm aktiveres

Man kan generere "calculated items" med data fra forskjellige kilder / komponenter før man bruker disse i en trigger definisjon. Dette gir muligheter til å definere alarmer bl.a. på HA løsninger hvor nedetid på noen komponenter ikke er kritiske på grunn av redudansen i systemet.

Dette kan også brukes for å sjekke e.g. diskfyllingsrate i en periode, eller tid til disk fylles med gjeldende fyllingsrate.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/calculated

Aggregering av data

Man kan også aggregere data før den brukes videre i en trigger definisjon. Det finnes flere funksjoner som kan brukes for å aggregere data for en tidsperiode.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/aggregate

Avhengigheter må kunne håndteres for å unngå unødvendige alarmer

Zabbix støtter avhengigheter mellom sjekker og mellom komponenter for å unngå unødvendig alarmer og vise rotårsak til et problem.

Avhengighetene defineres på trigger nivå.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/triggers/dependencies

Alvorlighetsgrader

Som nevnt under trigger avsnittet, bruker Zabbix konseptet viktighetsgrader i tillegg til trigger tilstand og de definerer dem slik:

• Not classified: Ikke klassifisert
• Information: Informasjon
• Warning: Advarsel
• Average: Gjennomsnittlig problem
• High: Viktig hendelse
• Disaster: Katastrofe hendelse med økonomiske og omdømme tap

Dette gir oss muligheter til å få enda mer kontroll på alarmer som genereres. e.g. at en standalone server går ned kan være kritisk (high/disaster) mens hvis en server i en HA løsning går ned kan det defineres som et problem som må fikses men ikke er kritisk (average).

Vedlikehold og bekreftelse av alarmer

Man kan definere vedlikeholdsperioder for hoster eller host grupper. Tidsplanen definisjon for vedlikeholdsjobber er veldig fleksible med flere muligheter. Dette kan gjøres via webkonsollet og API-et.

Man kan bekrefte alarmer både via webkonsollet og API-et. Man kan skrive en melding når man bekrefter en alarm og man har tilgang til meldingshistorikk.

Varsling

Zabbix kan definere handlinger (Action) til en hendelse (Event) og en av handlingene som kan defineres er varsling etter at en alarm har blitt generert.

Man har flere muligheter for å varsle en alarm:

• Epost
• SMS
• Jabber
• Custom / integrasjon med andre systemer web, RT, Jira, osv.

Hva varsles, når og til hvem kan kontrolleres med mange parametere og en hendelse kan ha flere forsjellige handlinger assosiert til den.

Ref: https://www.zabbix.com/documentation/2.2/manual/config/notifications

Kjøring av kommandoer som svar på en hendelse

Zabbix har muligheter til å definere handlinger som kjører eksterne eller interne kommandoer når en hendelse genereres. Muligheter for autokonfigurasjon/automatisering.

SLA oppfølging

Zabbix støtter SLA oppfølging av tjenester registrert i systemet. Man kan lage en tjenesteoversikt i en trestruktur som viser tilstanden til tjenestene. Hver node har en tilstand og Zabbix beregner automatisk SLA verdien til hver node/tjeneste i en tidsperiode.

Ref: https://www.zabbix.com/documentation/2.2/manual/it_services

Vurdering

• Kraftig trigger funksjonalitet med støtte for avanserte logiske uttrykk.
• Veldig god støtte for triggere som baserer seg på "calculated items" og agreggert data.
• Veldig god håndtering av avhengigheter mellom sjekker og mellom komponenter av en tjeneste gir muligheter til å identifisere rotårsak av et problem.
• Seks alvorlighetsgrader i tillegg til tilstand på en alarm gir oss god fleksibilitet til å kategorisere alarmer riktig.
• Gode muligheter til å definere forskjellige type handlinger som svar til en hendelse.