12.4. Monitorering

Monitorering er en fellesbetegnelse, og de ulike involverte aktiviteter har flere mål: På den ene siden, som følge av ressursene maskinen gir, kan metning forutsees, med de påfølgende oppgraderinger som kreves. På den annen side varsles administrator så snart en tjeneste ikke er tilgjengelig, eller ikke fungerer, som betyr at oppståtte problemer kan fikses tidligere.

Munin dekker det første området, ved å vise grafiske diagrammer for historiske verdier for en rekke parametere (benyttet RAM, anvendt diskplass, prosessorbelastning, nettverkstrafikk, Apache/MySQL-last (bruk), og så videre). Nagios dekker det andre området, ved å regelmessig kontrollere at tjenestene fungerer og er tilgjengelig, og sende varsler gjennom de riktige kanaler (e-post, tekstmeldinger, og så videre). Begge har et modulært design, som gjør det enkelt å lage nye programtillegg for å følge med på bestemte parametere eller tjenester.

ALTERNATIV Zabbix, et integrert monitoreringsverktøy

Selv om Munin og Nagios er svært mye brukt, er de ikke de eneste på monitoreringsområdet, og hver av dem behandler kun halvparten av oppgaven (grafer på den ene side, varsling på den andre). Zabbix, derimot, integrerer begge sider ved overvåkningen; den har også et nettgrensesnitt for å sette opp de vanligste tingene. Den har vokst med stormskritt i løpet av de siste årene, og kan nå betraktes som en levedyktig konkurrent. På overvåkningstjeneren vil du installere zabbix-server-pgsql (eller zabbix-server-mysql), muligens sammen med zabbix-frontend-php for å få et nettgrensesnitt. Hos verten du skal følge med på, så installerer du zabbix-agent for å sende data tilbake til tjeneren.

→ https://zabbix.com/

12.4.1. Oppsett av Munin

Hensikten med Munin er å monitorere mange maskiner. Derfor bruker den ganske naturlig en klient/tjener-arkitektur. Den sentrale verten - graftegneren - samler data fra alle de monitorerte vertene, og genererer historiske grafer.

12.4.1.1. Sette opp verter til monitor

Det første trinnet er å installere munin-node-pakken. Bakgrunnsprosessen som denne pakken har installert, lytter på port 4949, og sender tilbake data samlet inn av alle de aktive programtilleggene. Hvert programtillegg er et enkelt program som returnerer en beskrivelse av de innsamlede data, samt den siste målte verdi. Programtilleggene er lagret i /usr/share/munin/plugins/, men bare de med en symbolsk lenke i /etc/munin/plugins/ er virkelig i bruk.

Når pakken er installert vil et sett aktive programtillegg fastsettes basert på programvaren som er tilgjengelig og nåværende oppsett av verten. Dog avhenger dette auto-oppsettet av at funksjonen er å finne i hvert programtillegg, og det er vanligvis en god idé å gjennomse og justere resultatene for hånd. Å utforske programtilleggsgalleriet kan være interessant selv om ikke alle programtillegg har fullstendig dokumentasjon.

→ https://gallery.munin-monitoring.org

Dog er alle programtillegg skript, og de fleste er ganske enkle og godt kommentert. Å surfe /etc/munin/plugins/ er derfor en god måte å få en idé om hva hvert programtillegg handler om, og å avgjøre hvilke som bør fjernes. Tilsvarende, å aktivere et interessant programtillegg som finnes i /usr/share/munin/plugins/ er så enkelt som å sette opp en symbolsk lenke med ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Merk at når navnet på et programtillegg ender med en understrekning "_", krever programtillegg en parameter. Denne parameteren må lagres i navnet på den symbolske lenken; for eksempel må "if_" programtillegg bli aktivert med en symbolsk if_eth0-lenke, og den vil monitorere nettverkstrafikk på eth0-grensesnittet.

Når alle programtilleggene er satt opp riktig, må bakgrunnsprosessoppsettet oppdateres til å beskrive adgangskontrollen for de innsamlede dataene. Dette inkludererallow-anvisninger i /etc/munin/munin-node.conf-filen. Standardoppsettet er allow ^127\.0\.0\.1$, og gir bare gir tilgang til den lokale verten. En administrator vil vanligvis legge til en lignende linje med IP-adressen til graftegner-verten, og deretter starte bakgrunnsprosessen på nytt med systemctl restart munin-node.

FOR VIDEREKOMMENDE Å lage lokale programtillegg

Munin inkluderer detaljert dokumentasjon om hvordan programtilleggene skal fungere, og hvordan man kan utvikle nye programtillegg.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

Et programtillegg kan best testes når det kjøres under samme forhold som det ville blitt når det utløses av munin-node. Dette kan simuleres ved å kjøre munin-run plugin som rot. Et potensielt andre parameter som gis til denne kommandoen (slik som config) formidles til programtillegget som et parameter.

Når et programtillegg brukes med config-parameteret, må det beskrive seg selv ved å returnere et sett med felt:

# munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average

De forskjellige tilgjengelige feltene er beskrevet av «Plugin reference» (Plugin-referansen) som er tilgjengelig som en del av «Munin guide»-en.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Når startet uten en parameter, vil programtillegget bare returnere de siste måleverdiene: For eksempel, å kjøre sudo munin-run load kunne returnere load.value 0.12.

Til slutt, når et programtillegg startes med parameteret autoconf, skal det returnere «yes» (og exit-status 0) eller «no» (med exit-status 1) avhengig av om programtillegget bør være aktivert på denne verten.

12.4.1.2. Oppsett av graftegneren

«Graftegneren» aggregerer rett og slett dataene, og genererer de tilhørende grafer. Den nødvendige programvaren er i munin-pakken. Standardoppsettet kjører munin-cron (en gang hvert 5. minutt). Den samler data fra alle verter som er oppført i /etc/munin/munin.conf (kun den lokale verten er oppført som standard), lagrer historiske data i RRD-filer (Round Robin Database, et filformat utviklet for å lagre data som varierer i tid) lagret under /var/lib/munin/, og genererer en HTML-side med grafene i /var/cache/munin/www/.

Alle monitorerte maskiner må derfor være oppført i oppsettsfilen /etc/munin/munin.conf. Hver maskin er oppført som en full blokk med et navn som stemmer med maskinen, og minst et address-innslag som gir den tilhørende IP-adressen.

[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes

Seksjoner kan være mer komplekse, og beskrive ekstra grafer laget ved å kombinere data fra flere maskiner. Prøvene som er gitt i oppsettsfilen er gode utgangspunkter for tilpasninger.

Det siste trinnet er å publisere de genererte sidene. Dette innebærer å sette opp en nett-tjener, slik at innholdet i /var/cache/munin/www/ blir tilgjengelig på et nettsted. Tilgang til denne nettsiden vil ofte være begrenset, enten ved hjelp av en autentiseringsmekanisme eller IP-basert adgangskontroll. Se Seksjon 11.2, «Nett-tjener (HTTP)» for de relevante detaljene.

12.4.2. Oppsett av Nagios

I motsetning til Munin, installerer ikke Nagios nødvendigvis noe på de monitorerte vertene. Mesteparten av tiden brukes Nagios til å kontrollere tilgjengeligheten for nettverkstjenester. For eksempel kan Nagios koble til en nett-tjener, og sjekke at en gitt nettside kan nås innen en gitt tid.

12.4.2.1. Installasjon

Det første trinnet i å sette opp Nagios er å installere pakkene nagios4 og monitoring-plugins. Installasjon av pakkene setter opp nettsidegrensesnittet og Apache-tjeneren. authz_groupfile og auth_digest/Apache-modulene må være aktivert, med den kjøringen:

# a2enmod authz_groupfile
Considering dependency authz_core for authz_groupfile:
Module authz_core already enabled
Module authz_core already enabled
Enabling module authz_groupfile.
To activate the new configuration, you need to run:
  systemctl restart apache2
# a2enmod auth_digest
Considering dependency authn_core for auth_digest:
Module authn_core already enabled
Enabling module auth_digest.
To activate the new configuration, you need to run:
  systemctl restart apache2
# systemctl restart apache2

For å legge til andre brukere, er en enkel sak å sette dem inn i filen /etc/nagios4/hdigest.users.

Grensesnittet vises ved å la nettleseren gå til http://tjener/nagios4/. Vær spesielt oppmerksom på at Nagios allerede følger med på noen parametere på maskinen der den kjører. Men noen interaktive funksjoner, som å legge til kommentarer til en vert, virker ikke. Disse funksjonene er deaktivert under Nagios standardoppsett, som av sikkerhetsgrunner er svært restriktiv.

Aktivering av noen egenskaper innebærer å redigere /etc/nagios4/nagios.cfg. Vi må også sette opp skrivetilgang til katalogen som Nagios bruker, med kommandoer som de følgende:

# systemctl stop nagios4
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4
# systemctl start nagios4

12.4.2.2. Oppsett

Nagios nettgrensesnitt er ganske fint, men det tillater ikke oppsettet, heller ikke kan det brukes til å legge til monitorerte verter og tjenester. Hele oppsettet styres via filer som det er referert til i den sentrale oppsettsfilen,/etc/nagios4/nagios.cfg.

Disse filene bør en ikke dykke ned i uten en viss forståelse av Nagios-konsepter. Oppsettet lister objekter av følgende typer:

en vert (host) er en maskin som skal monitoreres;
en vertsgruppe (hostgroup) er et sett av verter som bør grupperes sammen for visning, eller å utnytte vanlige oppsettselementer;
en service er et testbart element knyttet til en vert eller en gruppe verter. Det vil som oftest være en sjekk for en nettverkstjeneste, men det kan også innebære å sjekke om noen parametere er innenfor et akseptabelt spenn (for eksempel ledig diskplass eller prosessorbelastning);
en servicegruppe (servicegroup) er et sett av tjenester som skal grupperes sammen for visning;
en kontakt (contact) er en person som kan motta varsler;
en kontaktgruppe (contactgroup) er et sett med slike kontakter;
en tidsperiode (timeperiod) er et tidsspenn innenfor hvilket enkelte tjenester må kontrolleres;
en kommando (command) er kommandolinjen som brukes for å sjekke en gitt tjeneste.

Alt etter typen, har hvert objekt en rekke egenskaper som kan tilpasses. En fullstendig liste ville bli for lang til å ta med her, men de viktigste egenskapene er forholdet mellom objektene.

En service bruker en kommando (command) til å sjekke statusen til en egenskap på en vert (host) (eller en vertsgruppe (hostgroup)) innenfor en tidsperiode (timeperiod). Om det oppstår et problem, sender Nagios et varsel til alle medlemmer av kontaktgruppe (contactgroup) knyttet til tjenesten. Hvert medlem får sendt varselet ifølge den kanalen som er beskrevet i det samsvarende kontakt (contact)-objektet.

Et arvesystem tillater enkel deling av et sett med egenskaper på tvers av mange objekter uten å duplisere informasjon. Videre har det opprinnelige oppsettet en rekke standardobjekter; i mange tilfeller er det å definere nye verter, tjenester og kontakter en enkel sak å utlede fra de angitte generiske objektene. Filene i /etc/nagios4/conf.d/ er en god kilde til informasjon om hvordan de fungerer.

Falcot Corp-administratorene bruker følgende oppsett:

Eksempel 12.5. /etc/nagios4/conf.d/falcot.cfg-fil

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.12
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp'-kommando med tilpassede parameter
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generisk Falcot-tjeneste
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Tjenester som skal kontrolleres på www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Tjenester som skal kontrolleres på ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}

This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup.

Legg merke til bruken av arv: Et objekt er satt til å arve fra et annet objekt med «bruk foreldre-navn». Foreldre-objektet må kunne identifiseres, noe som krever å gi det et «navn identifikator»-egenskap. Hvis det overordnede objektet ikke er ment å være et reelt objekt, men bare skal tjene som en forelder, og gir det en «register 0»-egenskap som sier til Nagios om å ikke vurdere det, og derfor om å ignorere mangelen på noen parametere som ellers ville vært nødvendig.

FOR VIDEREKOMMENDE Eksterne tester med NRPE

Mange av Nagios programtillegg tillater å sjekke noen parametere lokalt hos en vert; hvis mange maskiner trenger disse kontrollene, og en sentral installasjon samler dem, så må en legge inn programtillegget NRPE (Nagios Remote Plugin Executor). nagios-nrpe-plugin-pakken må installeres på Nagios tjeneren, og nagios-nrpe-server på vertene der lokale tester skal kjøres. Sistnevnte får sitt oppsett fra /etc/nagios/nrpe.cfg. Denne filen skal inneholde de testene som kan startes over nettet, og IP-adressene til maskinene som får lov til å starte dem. På Nagios-siden aktivers disse eksterne testene ved å legge aktuelle tjenester ved hjelp av den nye check_nrpe-kommandoen.