Icinga sluttrapport

2.1   Icinga 2 komponenter

Kort beskrivelse av komponenter som Icinga 2 består av:

Api: er ansvarlig for kommunikasjonen mellom nodene i en klynge løsning, synker konfigurasjon filene mellom klynge noder, sikrer kommunikasjonen vha. ssl. I tilfellet master noden feiler i en ha løsning, så er det api komponenten på nodene i klyngen som bestemmer en ny master node.

Checker: er ansvarlig for planlegging av aktive sjekker.

Compat, CompatLog: sørger for bakvendt kompatibilitet med Icinga 1, skriver status data object.cache og icinga.log i Icinga 1.x format.

Command: oppretter en command pipe slik at man kan sende kommandoer fra web-grensesnitt og tredjeparts applikasjoner.

Perfdata: ytelse data fra sjekk resultater skrives til filer som kan brukes for integrasjoner mot graphing verktøys som inGraph, PNP4nagios osv.

Statusdata: skriver status data til to filer en for maskiner og en for tjenester. Man kan definere hvor ofte statusdata filene Icinga 2 skal oppdatere. Integrasjon mot Icinga 2 med Statusdata grensesnittet bruker mer CPU ressurser og disk i/o og skalerer ikke så bra. Classic UI bruker disse filene for å vise status om maskiner og tjenester.

Livestatus: skriver ikke status og historiske data til filer. En binær modul som loades med Icinga 2 prosess sørger for at status og ytelse data kan hentes etter forespørsel direkte fra memory via en tcp socket. Integrasjon mot Icinga 2 med Livestatus grensesnittet skalerer mye bedre.

Ido-mysql: gir støtte for mysql server, er ansvarlig for innhenting og oppdatering av databasen.

Ido-pgsql: gir støtte for postgresql server, er ansvarlig for innhenting og oppdatering av databasen.

Mainlog, debuglog, syslog: aktiverer logging.

Graphite: tilrettelegger for Graphite integrasjon, skriver ytelse data til Graphite Carbon Cache tcp socket.

Notification: aktiverer varsling funksjonalitet, må aktiveres på master noden i klyngen.

2.2   Icinga 2 integrasjons oversikt

2.3   Icinga Web komponent oversikt

Kort beskrivelse av Icinga Web komponenter:

Command Control Interface: muliggjør sending av kommandoer (for eks. re-sjekk, aktivering/deaktivering av aktiv/passiv sjekker), sending av varslinger osv. til Icinga2.

Doctrine abstraction layer: brukes for å få tak i overvåking data lagret i IDO databasen.

Rest api: presenterer data samlet fra IDO databasen i JSON og XML format. Tredjepart utvidelser bruker Rest-api for å hente overvåkings data.

2.4   Utvidelser

Det er kun Business Process Addon og inGraph som er testet.

2.5   Plugins

I tillegg til Nagios Plugins, kan det man benytte følgene plugins som er utviklet av Netways:

• AutoIT: http://www.netways.de/en/de/produkte/icinga_and_nagios_plugins/autoit/
• Check_cache: http://www.netways.de/en/de/produkte/icinga_and_nagios_plugins/check_cache/
• VMware ESX: http://www.netways.de/en/de/produkte/icinga_and_nagios_plugins/vmware_esx/

For oversikt over alle plugins utviklet av Netways.

3.1   Distribusjon av programvare: source, rpm, deb?

Det finnes en offisielt Icinga repository. Her kan man finne rpm pakker for RHEL 5, 6, og 7 blant annet. Etter registrering av Icinga repositorien i yum.repos.d, kan men enkelt installere Icinga 2, Icinga Classic UI, Icinga Web osv.

3.2   Programvare avhengigheter

3.3   Installasjon av database

Icinga 2 støtter både mysql og postgresql database servere. Postgresql er blitt valgt.

3.4   Installasjon av sentral server

Etter installasjon av "icinga2" pakken, kan man aktivere/deaktivere komponenter ved å bruke to scripter som følger med installasjonen:

• icinga2-enable-feature
• icinga2-disable-feature

Dagens setup består av en master zone og en satellitt zone (proxy zone):

«ido», «api» og «notification» komponentene må aktiveres i sentral/master noden.

«Checker», «statusdata», «perfdata» «command» og «livestatus» komponentene er aktivert i master noden også ifm. utføring av sjekker og integrasjoner mot andre utvidelser.

3.5   Installasjon av distribuert / proxy komponenter

Etter installasjon av "icinga2" pakken, må "api" komponenten aktiveres på satellitt/proxy noden.

Andre komponentene kan aktiveres på satellitt/proxy noden ved behov.

3.6   Installasjon av webkonsoll og API

Det finnes rpm pakker i Icinga offisiell repository som brukes for å installere web konsollet og api. Installasjon av «icinga-web» og «icinga-web-pgsql» er intuitiv. Icinga-web er installert på master noden i klyngen.

3.7   Installasjon av native agenter

Det finnes native agenter for Linux/Unix, Windows og iOS systemer. Nrpe agenten kan brukes for å overvåke Linux/Unix og iOS systemer. Nsclient++ kan brukes for å overvåke Windows systemer.

3.8   Installasjon av SNMP agenter

Snmp sjekker utføres av «check_snmp» Nagios plugin. Det finnes en rpm pakke som kan installeres lett på overvåking servere.

3.9   Installasjon av IPMI agenter

Det finnes en rpm pakke som heter freeipmi og det er avhengig av perl-IPC-Run.noarch pakken.

3.10   Installasjon av add-ons / plugins

4.1   Konfigurasjon av distribuert overvåking

Man oppretter en master og en satellitt/proxy zone. Kommunikasjonen mellom nodene i master og satellitt/proxy zonen krypteres i Icinga 2. Kommunikasjonen kan initieres fra satellitt/proxy noden. Jeg opprettet en Certificat Authority (CA) på master noden vha. en script som følger med installasjonen. I et produksjonsmiljø bør man ha CA på en annen server. Etter at CA er opprettet, utsteder man sertifikater for både master noden og satellitt/proxy noden. Api komponenten konfigureres for å sette opp kommunikasjonen.

Man må sørge for at alle noder har samme status derfor kopierer man /var/lib/icinga2/icinga2.state filen fra master serveren til andre noder. Icinga instansen på alle node må stoppes før kopiering av status filen.

Deretter oppretter man oppsettmappestrukturen i master zonen (config master node). Icinga api komponenten tar seg av oppgaven med å synke konfigurasjonsfiler mellom nodene. Man kan kun ha en konfigurasjon master i en zone.

I tillegg til "api" komponenten, må "checker" komponenten aktiveres hvis man skal utføre sjekker vha. satellitt/proxy noden.

For detaljert info om konfigurasjon av distribuert overvåking.

4.2   Konfigurasjon av HA løsning

Man kan definere en master zone med flere noder. Man kan samtidig ha flere proxy zoner med flere noder knyttet til master zonen. I tillegg til "api" komponenten må man ha "ido" komponenten aktivert på alle noder i master zonen. I tilfellet master noden feiler i en ha løsning, så er det "api" komponenten på nodene i master zonen som bestemmer en ny master node. Kommunikasjonen mot databasen gjenopprettes på nye master noden.

HA løsning er ikke testet for denne vurderingen.

Les mer om HA oppsett i Icinga 2.

Les mer om HA for Icinga 2 komponenter.

4.3   Konfigurasjonsoversikt

"apply" regel:

4.4   Konfigurasjon av alarmer, triggers, osv.

Objekter som brukes for å sette opp "notifications"

• TimePeriod
• Notifications
• User, UserGroups
• Host
• Service
• NotificationCommand

Notification komponenten må være aktivert på master noden i klyngen.

Det er mange måter å sende varslinger som for eks. via. e-post, XMPP, Irc, Twitter osv. Icinga 2 er avhengig av eksterne scripter for å utføre utsendelse av varslinger.

Les mer om varsling i Icinga.

4.5   Webkonsoll konfigurasjon

Konfigurasjonen kan utføres vha. tekst basert konfigurasjonsfiler.

Les mer om Icinga Web konfigurasjon.

4.6   Intern konfigurasjon (ldap parametere, database, osv)

Database og ldap kan konfigureres vha. en tekst basert konfigurasjonsfil.

For å lese mer, se på database og ldap konfigurasjon.

4.7   Konfigurasjon av roller / grupper / tilganger via webkonsoll

Brukere og grupper må opprettes/administreres i både i Icinga 2 konfigurasjonsfiler og i Icinga Web databasen vha. Icinga Web konsollet.

Man kan bruke api-en til Cerebrum for å importere liste over brukere/grupper som er relevant for tilgangstyring.

Man kan enkelt generere konfigurasjonsfiler for Icinga 2, som inneholder definisjon av brukere og brukergrupper, vha. en egen utviklet script som parser/bearbeider bruker/gruppe lister importert fra Cerebrum.

Samtidig kan man utvikle en annen script som oppretter brukere og brukergrupper automatisk på Icinga Web databasen. Brukermedlemskap til brukergrupper kan håndteres av samme script. Brukergruppene kan brukes for å administrere roller og tilganger.

Man har mulighet til å administrere roller/grupper og tilganger definert i Icinga Web vha. web konsollet manuelt. Det er bedre å bruke egen utviklet scripter som automatiserer administrasjon.

4.8   Konfigurasjon av roller / grupper / tilganger via API

Det finnes ikke noe api for å konfigurere roller og grupper i Icinga 2. Icinga Community har planer om å utvikle an api i fremtiden som gir dette funksjonalitet.

4.9   Auto-discovery

Icinga har ikke innebygd auto-discovery støtte. Icinga community har planer å utviklet funksjonaliteten i fremtiden.

4.10   Templates

Man kan opprette maler for maskiner, tjenester, varslinger og kommandoer. Se på Konfigurasjons oversikt kapittel.

4.11   Import / eksport av konfigurasjon.

Konfigurasjon av Icinga 2 er tekst fil basert. Derfor er det enkelt å importere/eksportere.

Icinga web lagrer webkonsoll-spesifikk oppsett i databasen. Aksess til databasen, integrasjoner mot andre utvideler osv, kontroleres vha. konfigurasjonsfiler.

4.12   SELinux

Man trenger å generere unntaksregler i SElinux for å bøte på problemer med integrasjon mot Business process utvidelsen, kommandoeksekvering fra Icinga Web konsollet osv.

5.1   Kobling mot ldap/ad for autentisering

Icinga Web kan integreres med Ldap/AD for autentisering. Icinga Web konsollet i testmiljøet bruker uio ldap løsning for autentisering.

5.2   Kobling mot Kerberos for autentisering/Single sign on (SSO)

I tillegg til Ldap autentisering, kan Icinga Web konfigureres til å bruke Microsoft AD/Kerberos for autentisering/SSO.

Følgende kreves for dette oppsettet:

• Apache (med Kerberos module)
• Key Distribution Center (KDC i AD)
• Samba
• Linux maskinen hvor Icinga-Web kjøres må meldes inn i AD.
• Man trenger å opprette en Service Pricipal Name (SPN) og knytte den til enten linux maskinkontoen eller en tjenestekonto i AD opprettet for dette formålet.

Man trenger å opprette en tjenestekonto i AD for REST-API tilgang.

Kerberos autentisering/SSO er ikke testet for denne vurderingen.

Les mer om Kerberos oppsett for autentisering og SSO.

5.3   Kobling mot ldap/ad for autorisering

Ldap integrasjonen kun gir autentisering funksjonalitet, ikke autorisering.

5.4   Grupper av ressurser (maskiner,osv)

Maskiner kan grupperes i maskin grupper i Icinga 2. Disse gruppene er tilgjengelig i Icinga Web for autorisering.

5.5   Grupper av tjenester

Tjenestene kan grupperes i tjeneste grupper i Icinga 2. Disse gruppene er tilgjengelig i Icinga Web for autorisering.

5.6   Grupper av brukere

Man kan opprette brukergrupper både i Icinga 2 og Icinga Web.

Brukergruppene i Icinga Web kan brukes for autorisering.

5.7   Assosiering mellom grupper

I Icinga 2 konfigurasjonen:

Man kan assosiere en tjeneste og maskin grupper vha. regel-drevet konfigurasjon. Man kan ikke assosiere brukergrupper med maskin eller tjeneste grupper.

I Icinga Web konfigurasjonen:

Man kan assosiere brukergrupper med maskin eller tjeneste grupper for autorisering.

6.1   Brukere og rettigheter som trenges under installasjon

Installasjon av Icinga2 og Icinga Web utføres under root kontekst.

6.2   Brukere og rettigheter som trenges under innhenting av data

Alle sjekker av nettverk tjenester som kjøres på overvåking serveren utføres i icinga bruker kontekst.

NRPE daemon på maskiner som skal overvåkes kjøres på en bruker kontekst som heter "nrpe". Alle sjekker som utføres av NRPE daemon kjøres i nrpe bruker kontekst.

6.3   Autentisering mellom komponenter

PKI basert autentisering mellom api komponenter i Icinga noder i en klyngeløsning.

6.4   Kryptering av trafikk mellom komponenter

Api komponenten i Icinga 2 sørger for at kommunikasjonen mellom Icinga noder er kryptert.

Les mer om CA innstillinger i klynge løsninger.

6.5   Kryptering av trafikk under innhenting av data

Kryptering kan aktiveres når man bruker NRPE / NSCLIENT++ agenter for å hente overvåkings data.

6.6   API tilgangskontroll

Api tilgangskontroll styres fra Icinga Web konsollet. Man oppretter en brukerkonto som gir tilgang til Web api adator. Autentiseringsmetoden for denne kontoen settes til "auth_key" og en nøkkel defineres samtidig. Rettighetene til api brukeren styres på samme måte som en vannlig brukerkonto i Icinga Web.

Se på tilgangskontroll kapittelet. Autorisering vha. "auth_key" i forespørsel eller cookier.

Les mer om REST API.

6.7   Integrasjon mot andre systemer

Integrasjon mot andre systemer kan gjennomføres vha.

• REST-API (Icinga Web),
• Perfdata komponent (Icinga 2)
• Statusdata komponent (Icinga 2)
• Livestatus komponent (Icinga 2)
• Graphite komponenet (Icinga 2)

6.8   Aktive / passiv sjekk

Aktive sjekk

NRPE og Nsclient++ har ssl støtte. Icinga 2 støtter også innhenting av data vha. SNMPv3 som er sikrere enn SNMPv2.

Passiv sjekk

NSCA-NG

Nsca-ng bruker TLS kryptering og shared-secret autentisering. Kommunikasjonen er kryptert basert på krypteringskonfigurasjonen i nsca-ng.cfg og send_nsca.cfg. Nsca-ng daemon skal validere og dekryptere dataen og sende kommandoen videre til Icinga 2 command pipe.

6.9   Backup

Dagens backup regimet for databaser og maskiner kan anvendes her også. Konfigurasjonensfiler kan samles/administreres vha. Nvilheim/filloger.

7.1   Passiv sjekk

Det finnes to måter å utføre passive sjekker:

• nsca-ng (klient/server applikasjon)
• snmptrap

NSCA-NG

Man installerer en NSCA-NG daemon på en av de overvåkingserver nodene i klynge løsningen og en klient applikasjon, send_nsca på maskinen som skal overvåkes vha. passiv sjekker. NSCA server daemon og klienten autentiserer seg vha. en pre-shared key og trafikken mellom nsca klient og nsca server krypteres vha. TLS.

På klient maskinen kan man fritt utvikle scripter som genererer sjekk resultater i Nagios format, dvs, maskinnavn;tjenestenavn;statuskode;beskrivelse. Sjekk restultanene kan sendes til overvåkingserveren vha. send_nsca klient applikasjonen.

Nsca-ng daemon på overvåking serveren mottar sjekk resultanene og videresender til Icinga 2 gjennom "command pipe" som blir opprettet ved å aktivere command komponenten.

SNMPTRAP

Snmp klienten på maskinen som skal overvåkes konfigureres slik at den sender snmptraper til overvåkingserveren. På overvåkingserveren installerer/konfigurer man snmptrap handler. Trap handler videresender mottatte snmptrap til snmptrap translater. Snmptrap translater bruker en mib database for å oversette snmptraper til Nagios format, maskinnavn;tjenestenavn;statuskode;beskrivelse. Oversatte trap data sendes videre til Icinga 2 gjennom "command pipe" som blir opprettet ved å aktivere command komponenten.

Man må definere maskinen og tjenesten i Icinga 2 for at passiv overvåking skal fungere som det skal.

7.2   Via native agenter

7.2.1   NRPE

Nrpe tjenesten og Nagios plugins må installeres på alle maskiner som skal overvåkes vha. NRPE.

Man må definere i NRPE konfigurasjonsfil hvilket plugin som kan kjøres på maskinen som skal overvåkes vha. NRPE. Icinga 2 "checker" komponenten initierer utføring av sjekker på remote maskin vha. "check_nrpe" plugin installert på overvåking serveren.

Terskel verdiene kan administreres sentralt som vi gjør i dagens Nagios system. Pga. en sikkerhetshull i hvordan nrpe håndterer argumentene som er sendt til remote plugins, må terskel verdiene til sjekker utført av NRPE defineres på maskiner som overvåkes.

For mer info om sikkerhetshullet, se på linken http://seclists.org/fulldisclosure/2014/Apr/240. Man kan tillate kun overvåkingsmaskiner til å utføre sjekker vha. NRPE agent for å bøte på sikkerhet problemet.

Icinga community som nevnt på introduksjon kapittelet utvikler en Icinga 2 agent. Agenten skal ha støtte for kryptering, autentisering og autorisering vha. pki arkitektur. I følge utviklere skal den lanseres sannsynligvis i november i år. Icinga 2 agenten kan brukes i stedet for NRPE for å bøte på sikkerhetsproblemet.

Les mer om konfigurasjon av NRPE sjekker,

Les mer om CheckCommand objekt for check_nrpe

7.3   Via SNMP

Icinga Template Library (ITL) har forhåndsdefinerte sjekk maler som kan brukes for å hente tilstand og ytelses data via. SNMP.

Les mer om icinga snmp sjekk.

7.4   Via IPMI

Ipmi agenten er installert men ikke testet.

7.5   Via ICMP

ICMP sjekker kan enkelt defineres vha. forhåndsdefinerte ping4/ping6 sjekker i ITL.

Les mer om icinga ping sjekk.

7.6   Via port sjekk

Tcp og udp kan sjekkes vha. forhåndsdefinerte sjekker i ITL.

Les mer om icinga tcp port sjekk.

Les mer om icinga udp port sjekk.

7.7   Via eksterne plugins, ssh, powershell, osv

Utføring av sjekker gjennom ssh kan defineres vha. forhåndsdefinerte sjekker i ITL.

Icinga by_ssh sjekk eksempel,

Kjøring av powershell scripter kan utføres vha. NSClient++.

7.8   Via java/JMX

Det ble ikke testet. Det finnes mange Nagios plugins som kan brukes for å overvåke JEE server via JMX.

Tilgjengelig plugins som kan brukes.

7.9   Sjekk av web sider / tjenester / applikasjoner

Man kan overvåke respons tiden, status, utløpsdato for sertifikater, sjekke inneholde av en side osv.

Dokumentasjon.

Plugin som kan brukes.

7.10   Sjekk av databaser

Det ble ikke testet. Det finnes mange Nagios plugins som kan tas i bruk for å sjekke database servere.

Tilgjengelige plugins.

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

Integrasjon mot SCOM er ikke testet. Det finnes en "connector" mellom SCOM og Nagios/Icinga.

Les mer om SCOM connector.

7.12   Data fra virtuelle løsninger

Icinga kan bruke følgende plugins som er utviklet for Nagios for å overvåke VMware miljøet:

• Check_view_pool
• Check_view_pool_provisions
• Check_vmware_api
• Check_vmware_esx

De to første plugins kan brukes for å overvåke virtuell arbeidsflater.

Check_vmware_api bruker vSphere APi for å overvåke esx hostene og vCenter servere. Man kan overvåke blant annet følgende metrisk for esx hostene, Virtuell maskiner og Datacenter:

cpu, minne, swap, balloning, nettverk, disk io, read/write latency, overordnede host status osv. for en hel liste av metrisk se linken under:

Mer om check_vmware_api.

Check_vmware_esx er en fork av check_vmware_api.

I tillegg til det, kan man bruke snmp og ssh for å overvåke esx hostene og vCenter servere.

8.1   Varslingsoversikt

Icinga Web konsollet viser tilstander om alle maskiner og tjenester som overvåkes på toppen av siden.

Linker er gruppert i en meny på venstre siden hvor man kan få lett info om

• alle tjeneste/maskin problemer
• tilstand om tjenester/maskiner, tjente grupper/maskin grupper
• historiske data,
• logger ,

Samtidig finnes det linker til installerte utvidelser på menyen

8.2   Detaljerte varslinger

Man kan få mer detaljert info om varslingen som for eks. når sjekken sist utført, ytelse data, om tjenesten er "flapping" osv.

8.3   Grafer / trending

Icinga kan integreres med PNP4Nagios, Graphite, inGraph og NagiosGraph. Under testing ble inGraph installert.

Mer informasjon om integrasjoner mot graphing verktøy kan leses her.

Overvåking av trender kan gjennomføres vha. Graphite. Ytelse data samlet vha. Nagios plugins sendes videre til Graphite gjennom graphite komponenten i Icinga 2. Deretter kan man bruke blant annet innebygte funksjoner i Graphite til å regne ut trender basert på historiske datagrunnlag for ytelsesdata. Man kan også ha beregningslogikken av trender i et eget utviklet script. Resultatet til beregningen kan mates inn til Icinga 2 for videre prosessering.

8.4   Søkemuligheter

I Icinga web konsollet kan man søke etter maskiner, tjenester, maskingrupper og tjeneste grupper.

8.5   Kart funksjonalitet

Icinga Web konsollet har en enkel visning av tilstandskart.

I tillegg til det, kan man installere utvidelser som gir dette funksjonalitet.

Les mer om icinga virtualisering og kart.

8.6   Custom visning

Man har til en vis grad mulighet til å endre visning i web konsollet etter sitt behov. Man kan filterere bort irrelevante maskiner/tjenester i visningsfaner.

8.7   Slideshow muligheter

Icinga Web konsollet har støtte for det. Man kan åpne flere faner som vises i slideshow.

8.8   Tilgang til raw data

Raw data lagres på Icinga 2 databasen. Dessutten, kan ytelse og tilstand data sendes videre til utvidelser som Graphite, inGraph,PNP4Nagios osv. Man kan hente raw data fra både Icinga 2 databasen og databasen til graphing utvidelsene.

Det finnes også andre måter å hente raw data:

• vha. egenutviklet script som henter data fra db.
• vha. livestatus tcp socket.

8.9   Inventar / CMDB

Icinga 2 har ikke inventar / CMDB funksjonalitet.

8.10   Konsoll på mobile enheter

Det finnes flere mobil applikasjoner både for både iOS og Android. De er ikke testet.

• aNag,
• Nagify,
• iNag,

I tilleg finnes det en Icinga mobil web grensesnitt som kan konfigureres vha. linken her.

9.1   Trigger/Terskel definisjoner

Terskel verdiene til nettverkstjeneste sjekker kan defineres på overvåkingserveren.

Terskel verdiene til aktive sjekker utført av NRPE, by_ssh, SNMP og nsclient++ kan defineres på overvåkingserveren.

Selv om terskel verdiene til sjekker utført av NRPE agent kan defineres på overvåkingserveren sentralt, bør terskel verdiene defineres på maskiner som overvåkes pga. sikkerhetshull nevnt på NRPE kapittelet.

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

Se på avhengigheter kapittelet.

9.3   Aggregering av data

Aggregeringslogikk kan defineres i plugins som utfører sjekker. Det finnes ikke en sentral aggregeringslogikk i Icinga 2.

Man kan integrere Icinga 2 mot Graphite ved å aktivere graphite komponenten. Deretter kan man bruke Nagios plugins som for eks. check_graphite, check_graphite.py osv. som er utviklet for å hente tilstand og ytelse data fra Graphite. Disse plugins har aggregeringslogikk. Man kan definere terskel verdier for sjekkene utført av disse plugins og varsle iht. sjekkresultater.

I tillegg til disse plugins, kan man etter behov utvikle sine egne plugins med aggregeringslogikk.

9.4   Avhengigheter

Man kan definere avhengighetsobjekter. Maskin-til-maskin, maskin-til-tjeneste, tjeneste-til-tjeneste og tjeneste-til-maskin avhengigheter kan defineres. Icinga 2 oppretter automatisk en implisitt avhengighet mellom en maskin og tjenester som kjøres på maskinen. Dersom maskinen er nede, sender ikke Icinga unødvendige varsler om tjenestene som kjøres på maskinen.

Maskin-til-maskin avhengigherter er reflektert i tilstandskartet på web grensesnittet.

Her finner man eksempler for avhengighets konfigurasjon.

Her finner man attributer for avhengighets objekt.

9.5   Alvorlighetsgrader

Alvorlighetsgrader er lik Nagios:

• 0 (OK)
• 1 (WARNING)
• 2 (CRITICAL)
• 3 (UNKNOWN)

Maskin og tjeneste tilstander

• Maskin tilstander,
• Tjeneste tilstander,
• HARD og SOFT tilstand,

9.6   Varsling

Varsling håndteres av "Notification" objektet i Icinga 2. "Notification" objektet kan anvendes til maskiner og tjenester.

For mer info om varsling objekt,

Varslings konfigurasjon eksempel,

9.7   SLA oppfølging

Dette funksjonalitet er avhengig av en tredjeparts (open source) rapportering server som heter JasperReports. Integrasjonen mellom Icinga og JasperReports er avhengig av blant annet en fil som er kun utviklet for mysql database server. Filen definerer en tilgjengelighetsfunksjon for mysql databasen. Derfor kan man ikke ha reporting funksjonalitet så lenge man bruker postgresql som bakend db. Icinga community utvikler en tilsvarende fil for postgresql. Se på utviklings siden.

Skjermdumper av Icinga SLA rapporter.

9.8   Kjøring av kommandoer som svar på alarmer

"EventCommand" objekter defineres for kjøring av kommandoer i tilfellet en maskin eller tjeneste tilstand endrer.

Kommandoer kjøres hvis:

• maskin/tjeneste er i "SOFT" tilstand.
• maskin/tjeneste tilstanden er endret til "HARD" tilstand.
• maskin/tjeneste tilstanden gjenopprettes fra "SOFT/HARD" tilstand til "OK/UP" tilstand.

EventCommand eksempel.

EventCommand objekt.