Innhold
1 Introduksjon
Sensu er et open source monitorerings rammeverk som forsøker å være enkelt, modifiserbart og skalerbart. Sensu er utviklet i Ruby og designet med tanke på skyen og for automasjon.
Sensu har en helt annerledes tilnærming til monitorering en de fleste andre løsninger. I steden for en monolitisk tilnærming som prøver å gjøre alt fokuserer Sensu på kjernen av monitorering. En av Konsekvensen er at Sensu ikke har den funksjonaliteten man er vant med fra andre monitoreringsløsninger. Fordelen med denne tilnærmingen er at Sensu kan integreres mot andre systemer som feks Graphite som er regnet som et av de bedre verktøy for grafing. Denne modulære tilnærmingen gir Sensu en fleksibilitet og et fravær av kompleksitet som gjør at den skiller seg fra andre monitoreringsløsninger.
Sensu virker som en monitorerings ruter som tar resultet fra en sjekk og videresender informasjon fra disse til en eller flere håndterere. Et sjekk skript kan for eksempel følge med på om en tjeneste er oppe eller måle ressursbruk fra feks en database. Et håndterer skript bestemmer hvilke handling(r) som skal utføres basert på resultatene fra en sjekk. Dette kan for eksempel være utsendelse av en mail eller videresending av data til Graphite.
Sensu har opphav fra sky selskapet Sonian som i 2011 gjorde det til et open source prosjekt.
Hovedsiden til Sensu er http://sensuapp.org.
2 Komponenter og arkitektur
Sensu består av seks komponenter. Tre av disse er kjerne komponenter, server, klient og api. To av disse er tredje parts komponenter, Redis og RabbitMQ som kjerne komponentene har avhengighet til og den siste er Uchiwa webkonsoll.
Sensu server har ansvaret for å skedulerer og holder styr på at klienter har kjørt de sjekkene de skal. Den lytter til RabbitMQ etter resultater fra klientene som den så ruter til en eller flere håndterer og til slutt lagrer den data i Redis.
Sensu klient lytter til RabbitMQ etter beskjed fra serveren om sjekker den skal kjøre. Når en sjekk er kjørt legger den resultatene i en kø som RabbitMQ videresender til serveren. Klienten sende periodiske keepalive meldinger til serveren for å gi beskjed om at den er i live. Dersom klienten har en standalone sjekk vil den kjører denne på egenhånd, uten først å få beskjed fra serveren, og vil så videresende resultatene til serveren når sjekken er ferdig.
Sensu api gir tilgang til den informasjonen Sensu lagrer, som klient informasjon og hendelser. Apiet kan også brukes for å løse hendelser og be om utføring av sjekker.
Webkonsollen Uchiwa henter data fra apiet og presenter denne i et oversiktlig og minimalistisk web grensensnitt. Fra webkonsollen har man mulighet til å slette klienter, fjerne alarmer eller sette systemet til å ignorere en alarm i en gitt tidsperiode. Webkonsollen er ikke ment for konfigurasjonsendring og gir heller ingen muligheter for dette utover det som akkurat er nevnt.
Redis blir brukt som datastore. Redis er en NoSQL key/value datastore kjent for sin hastighet. APIet og Sensu-server er de komponentene som snakker med Redis.
RabbitMQ er et system for utvekslinger av meldinger og Sensu benytter RabbitMQ for kommunikasjon mellom server, klienter og api. Ved å ta i bruk RabbitMQ får Sensu et meldingssystem som er kjent for sin robusthet og gode skalerings muligheter.
Det er anbefalt at man installerer Sensus komponenter på forskjellige maskiner da dette gir bedre ytelse og mulighet for konfigurasjon som skalerer bedre og samtidig er mer robust. Redis kan settes opp med i et master/slave forhold med failover dersom dette er ønskelig. For skalering kan man legge til nye Sensu-servere og valg av master vil skje automatisk. Dersom en master server går ned vil Sensu automatisk ta en av slavene og gi denne master rollen. Master er den som er ansvarlig for å be klienter utføre sjekker mens mottaking av resultater og lagring til databasen blir delt mellom servere.
3 Installasjon
Første steg i installasjonen av Sensu er å sette opp en sertifikat autoritet og generere sertifikater for RabbitMQ. Dette gjøres gjennom et skript man får fra Sensu, skriptet bruker openssl for opprettelse av en CA og generering av sertifkater.
Sensu kjerne komponenter kan installeres med en rpm pakke ved å legge til Sensus repository. Når man installerer Sensu pakken blir de tre kjerne komponentene installert.
RabbitMQ kan installeres i form av en rpm pakke man kan hente fra RabbitMQs web side. Før man installerer RabbitMQ må man først installere Erlang. Erlang er tilgjengelig via rpm fra epel. Da man ønsker kryptert kommunikasjon må man opprette et område under RabbitMQs fil området og kopiere over sertifikatene til denne. Lokasjonen til disse må også legges inn i RabbitMQs konfigurasjonsfil. Da Sensu bruker en virtuel host i RabbitMQ må denne opprettes og gis et bruker navn og passord slik at man har kontroll på at kun Sensu klienter med riktig brukernavn og passord kan registere seg på Sensu-server og dermed også motta en sjekk forespørsler.
Redis installers fra epel i form av en rpm pakke. Det vil være naturlig å sette opp Redis med en master og flere slaver slik at data blir replikert til slavene. Failover med redis kan man gjøre med det de kaller sentinel som da vil periodisk sjekke at master er oppe og om denne ikke gir svar seg sette en av slavene til master.
Uchiwa kan installeres fra Sensus repository med en rpm pakker. Uchiwa Konfigurasjonsfilen trenger lokasjon for sensus api og det er mulig å legge til bruker navn og passord dersom man ønsker autentisering for å komme inn på webkonsollen.
Installasjon av sjekk skript og håndterer skript kan enten gjøres ved å bruke Ruby sitt pakke program rubygems eller ved å laste ned skriptene manuelt for så å gi de kjørerettigheter.
4 Konfigurasjon
Sensus kjerne komponenter har sin konfigurasjon under /etc/sensu.
Sensu-server vil i /etc/sensu/conf.d inneholde en fil som peker til Redis, en fil som peker til APIet og sjekk definisjoner som inneholder parametere om hvordan en sjekk skal kjøres, hvilke håndterer som skal være gjellende osv. I /etc/sensu/handlers/ vil serveren ha håndterer skript som inneholder data om hvilke handlinger som skal utføres når en sjekk trigges.
Sensu-klient vil i /etc/sensu/conf.d inneholde en fil som som sier hvordan den skal koble seg opp til RabbitMQ, inkludert peker til klient sertifikat, RabbitMQs broker og port. I tillegg vil den ha sin egen konfigurasjonsfil som inneholder data om hvilken sjekk gruppe den tilhører samt informasjon som serveren bruker når den lagrer data om klienten. I /etc/sensu/plugins vil klienten ha sine sjekk skript som er de skriptene som henter ut data fra klienten hvorav resultatene eller dataen, avhengig av type skript vil sende til serveren.
Uchiwa webkonsoll har sin konfigurasonsfil i /etc/sensu/uchiwa.json som inneholder en peker til Sensu api samt bruker navn og passord dersom dette er satt for tilgang til APIet. Dersom man ønsker tilgangskontroll for Uchiwa kan man sette brukernavn og passord i denne filen.
Redis har sin konfigurasjon i /etc/redis/redis.conf og man setter her bla hvilke rolle Redis instansen skal ha. For failover av redis vil denne ha sin egen konfigurasjonens fil og være lokalisert i /etc/redis/sentinel.conf.
RabbitMQ har sin konfigurasjon i /etc/rabbitmq/rabbitmq.conf og man setter her pekere til sertifkat RabbitMQ benytter, hvilke port den skal lytte på osv.
5 Tilgangskontroll
Tilganskontroll er per dags dato en av de største manglene i Sensu. Det er i skrivende stund ingen mulighet for kobling mot ldap eller tilgang basert på grupper. Gruppering av ressurser er heller ikke dekket i skrivende stund.
De samme manglene gjelder også for Uchiwa webkonsoll som heller ikke har mulighet til integrering mot ldap eller views basert på gruppe med inndeling av ressurser.
6 Sikkerhet
Under installasjonen av Sensu trenger man root tilgang. For innhenting av data så vil det være avhengig av hvilke rettigheter sjekk skriptene trenger for å kjøre. I noen tilfeller holder det med vanlig bruker rettigheter men for andre typer innhenting må brukeren ha opphøyde rettigheter.
RabbitMQ bruker port 5671 dersom den er satt opp med SSL. Det er ikke støtte i RabbitMQ for å ha et sertifikat per klient slik at man ved et kompromitert sertifikat kunne byttet ut det ene. Man må, om så er tilfelle, opprette nye sertifikater og bytte ut sertifikater på alle klienter.
Redis er designet for kommuniksjon i sikre nettverk og har derfor ingen innebygd støtte for kryptert kommunikasjon. Dersom man ønsker kryptert kommunikasjon til Redis kan man sette opp feks stunnel som er en SSL krypterings wrapper. Redis bruk port 6379.
Når klienten og serveren snakker sammen går kommunikasjonen over RabbitMQ. RabbitMQ har støtte for SSL så kryptert kommuniksjon er mulig. I tillegg må det være gyldig brukernavn og passord for at klienter skal få tilgang til RabbitMQ køen som serveren og klienten snakker via.
APIet har mulighet for basic HTTP autentisering.
7 Datasamling
Datasamling i Sensu forgår med bruk av sjekk skript som kjøres på klientene. Nagios plugins kan benyttes i Sensu og så lenge Nagios syntax blir fulgt kan man utvikle egne skript i alle programmerings språk. Det er tre type sjekker i Sensu. Vanlig sjekk, standalone og keepalive.
Standalone sjekker kjøres av klienten uten at serveren har bedt om det. Svaret fra en standalone sjekk blir lagt på en RabbitMQ kø som serveren kan plukke opp. Fordelen med denne type sjekker er at det eneste serveren bruker resurser på er når den mottar resultater fra klienter. Ulempene med denne type sjekker er at man mister kontroll. Serveren vet ikke dersom en standalone sjekk har feilet. Det er heller ikke mulig med aggregering på standalone sjekker.
Keepalive blir sendt fra klienter hvert 20 sekund og default vil det bli opprettet en hendelse av type advarsel dersom klienten ikke har gitt svar fra seg i løpet av 120 sekunder og kritisk etter 180 sekunder.
Vanlige sjekker er det severen som skedulerer og passer på at klienter har kjørt og gitt tilbake resultater. I sjekk definisjonen på serveren vil man bestemme hvilke gruppe en sjekk skal tilhøre og på denne måten kan man gruppere sjekker slik at man på i klient konfigurasjonen hos klient kan angi vilken gruppe sjekker den skal kunne kjøre. For at en klient skal kunne kjøre sjekker man også ha installert sjekk skript på klienten. Hvor ofte en sjekk skal kjøres settes med interval opsjonen i sjekk definisjonen og man setter også her hvilke håndterer skript som skal kjøres når resultatene kommer tilbake fra klienten.
Som et resultat av at Sensu kan gjennbruke nagios plugins har man tilgang til hundrevis av måter å hente data fra forskjellige kilder på. Det er også mulig å hente metrisk data eller raw data og videresende dette til andre systemer. Sensu er bygd slik at det gir en generisk måte å hente data fra klienter på samt en generisk måte å håndtere resultatene på. Dette gir stor fleksibilitet og muligheten for å bygge sjekker og håndtere selv.
8 Visualisering / rapportering
Uchiwa gir en oversikt med søkemuligheter over hendelser, klienter og sjekker som systemet bruker. Uchiwa har i skrivende stund ingen mulighet for grafer, kart, slideshow, custom visning eller konsoll på mobile enheter. Men det er viktig å poengtere her at ut i fra Sensu sin filosofi er ingen av disse tingene det monitorering fundamentalt handler om og derfor heller ikke noe utviklerne av Sensu har brukt noe tid på. For grafing er det som nevnt ment at man tar i bruk et system er som spesifkt utviklet for dette og denne filosofien vil også være gjelldende for mye av den andre funksjonaliteten man i dag ikke har i Sensu men man er vant med fra andre monitoreringsløsninger.
Det er ingen innebygd mulighet for oppsett av SLA'r eller rapportering i Sensu. Sensu har en RT hånterer plugin som kan opprette saker basert på events så med litt bygging kunne man fått lagd noen rapporter.
9 Feilhåndtering
Sjekk skriptene i sensu har lik syntax som nagios plugins og returnerer status koder hvor 0 betyr at alt er ok, 1 advarsel, 2 kritisk og 3 eller høyere verdier er ukjent eller egendefinert.
Hva som blir gjort utifra resultatene på en sjekk er det håndterer skriptene som avgjør. Dette kan være utsending av mail, sms, posting på twitter, opprettesle av sak i RT, kjøring av kommandoer osv. Det er som med det meste i Sensu mulig å utvikle håndterer skript selv.
Sensu har aggregerings sjekker som gir varsel basert på resultater fra flere sjekker. Ved å sette aggregerings parameteret i en sjekk definisjon vil resultatene bli lagret som aggregeringsdata. Man trenger så en aggregerings sjekk som tar alle resultatene og gir varsler basert på summen av disse. En aggregeringsjekk kan feks gi advarsel dersom 80 prosent av en gruppe servere har last over 90 prosent.
Det er mulig å definiere avhengigheter i et håndterer skript slik at den ikke starter dersom den den har avhengighet til allerede har oprettet en event.
10 Vurdering
Utviklerne bak Sensu har forsøkt å abstrahere monitorering slik man kan bygge noe fra grunn av som har fokus på kjernen i monitorering. Dette har de klart og til tross for dårlig dokumentasjon er det veldig enkelt å sette opp og jobbe med Sensu. Nagios-plugins kan brukes i Sensu og dette gjør at man har videreført det beste fra Nagios men bygd et nytt rammeverk for håndtering av disse. Sensus er modulært og isteden for at Sensu innebygd feks grafing er det utviklet slik at man heller kan videresende data til et verktøy som er regnet som et av de beste for dette, Graphite. Fordi Sensu ikke inneholder mye av den funksjonaliteten man er vant med fra andre monitoreringsløsninger er Sensu minimalistisk men samtidig er Sensu veldig fleksibilitet fordi man enkelt kan integrere og bygge ut etter behov.
Manglene til Sensu handler først å fremst om det adminstrative selv om det også har litt å gå på når det gjelder modenhet i form av ting som skalering og stabilitet. Sensu er per dags dato ikke egnet for store organisasjoner med mange administratorer. Tilgangskontrollen, enten det gjelder for konfigurasjonsendring eller for tilgang til webkonsollen er i dag egnet for en mindre gruppe brukere og inndeling av ressurser basert på gruppe eller tjeneste er i dag ikke støttet.
For mindre prosjekter er Sensu fenomenalt. Men for større organisasjoner med kritiske tjenester trenger Sensu tid for å bli klart.