Examensarbete

Nätverksövervakning En jämförelse av Sensu och op5 Monitor

Författare: Kristoffer NILSSON & Ashour SHAMOUN Handledare: Marcus WILHELMSSON Examinator: Jacob LINDEHOFF Termin: VT2014 Ämne: Datavetenskap Nivå: G1E Kurskod: 1DV41E Sammanfattning

Rapporten beskriver arbetet och resultaten av en jämförelse mellan Sensu och op5 Monitor, vilka är verktyg som används för att övervaka enheter i nätverk, så kallade network monitoring systems. Arbetet har utförts för att utbudet av nätverksövervak- ningsverktyg ständigt växer och det ansågs värdefullt att jämföra en ny aktör med ett äldre verktyg som är byggd på ett annat tankesätt. Det som ansågs intressant att testa var hur dessa verktyg hanterade de rapporter som skapades och samlades in, om det slutgiltiga resultatet från detta skulle skilja sig åt eller inte. För att testa detta sattes en virtuell testmiljö upp, där Sensu och op5 Monitor rullade parallellt med varandra och övervakade samma system och använde sig utav samma plugin för övervakningen. Experimenten utfördes på två stycken tjänster, BIND9 samt Apache2, i och med att de två pluginen som användes var uppbyggda på olika sätt konstruerades även olika experiment. Under dessa experiment samlades information in om hur de två över- vakningsverktygen hanterade de rapporter de fick in, vilket sedan sammanställdes och analyserades. Slutsatsen av det hela var att Sensu och op5 Monitor hanterar sina insamlade rapporter på ett likvärdigt sätt, de rapporterade resultaten blev i samtliga fall detsamma, således fungerade de två övervakningsverktygen på ett jämgott vis.

Nyckelord: Sensu, op5 monitor, Nagios, nätverksövervakning, nms

Abstract

The report describes the work and results of a comparison between Sensu and op5 Monitor, which are both tools used to monitor devices in a network, more commonly known as network monitoring systems. The subject was chosen due to the fact that there is such a wide range of network monitoring systems, and it is constantly ex- panding. It was considered valuable to compare a newcomer with an older tool that is built with a different mindset. It was considered interesting to test how these tools handled the reports created and collected by them, to see if the final results from this would differ or not. To test this a virtual testing environment was built, where Sensu and op5 Monitor were run in parallel to each other and monitored the same systems and used the same set of plugins. The experiments were conducted on two services, BIND9 and Apache2, since the plugins were constructed in different ways, so were the various experiments. In these experiments information was gathered about how the two monitoring tools handled the reports they received, which was then compiled and analysed. The conclusion of it all was that Sensu and op5 Monitor handles the collected information in a similar manner. The reported results were in all cases the same, thus the two monitoring tools behave in the same fashion.

Keywords: Sensu, op5 Monitor, Nagios, Network Monitoring system, nms

i Förord Sedan en gästföreläsning har vi fått upp ögonen för nätverksövervakning och när tiden kom önskade vi att skriva vårt examensarbete om just detta ämne. Då Nagios är en jätte i sammanhanget föreföll det sig naturligt att använda op5 Monitor som den ena halvan i vårt arbete, där den andra hälften föll på Sensu. Vi vill rikta ett stort tack till Marcus Wilhelmsson, som under arbetets gång givit oss värdefull handledning.

ii Innehåll

1 Introduktion 1 1.1 Inledning ...... 1 1.2 Tidigare forskning ...... 1 1.3 Frågeställning och syfte ...... 2 1.4 Avgränsningar ...... 3

2 Bakgrund 4 2.1 Ordlista ...... 4 2.2 Nätverksövervakning ...... 4 2.2.1 Simple Network Management Protocol ...... 4 2.3 Sensu ...... 5 2.3.1 RabbitMQ ...... 5 2.3.2 Redis ...... 5 2.4 Op5 Monitor ...... 6 2.4.1 Ninja ...... 6 2.4.2 Merlin ...... 6 2.4.3 Naemon ...... 6 2.5 VMware ESXi ...... 7 2.6 Httperf ...... 7

3 Metod 8 3.1 Genomförande ...... 8 3.2 Testmiljö ...... 8 3.3 Testverktyg ...... 9 3.3.1 Httperf ...... 9 3.4 Experiment ...... 9 3.4.1 BIND9 ...... 10 3.4.2 Apache ...... 10

4 Resultat 12 4.1 BIND9 ...... 12 4.2 Apache ...... 13

5 Analys och slutsats 15 5.1 BIND ...... 15 5.2 Apache ...... 15 5.3 Slutsats ...... 15 5.4 Förslag till fortsatt forskning ...... 16 1 Introduktion

Under detta kapitel presenteras ämnesområdet, tidigare forskning kring ämnet, problem- beskrivningen, undersökningens avgränsning samt motiveringen till valet av undersök- ningen.

1.1 Inledning

Nätverksteknikernas främsta uppgift är underhållet av nätverken och se till att det fungerar optimalt och effektiv. Nätverken kan bestå av routrar, switchar, servrar, datorer, trådlösa enheter och applikationer. Det är många olika tekniker, enheter och kommunikationslän- kar som behöver samverka för ändamålet. Att övervaka nätverken och samla information för analys ger teknikern insikt i hur de olika delarna samverkar och hur hotbilden ser ut. Hoten kan vara allt från skadlig mjukvara till överbelastningar, men även fysiska faror som exempelvis en brand. [1] IT-systemen blir allt mer affärskritiska och företagen är väldigt beroende av ett välfun- gerande och tillgängligt system. IT-infrastrukturen är numera verksamheten, eftersom om vissa essentiella tjänster går ned kan det orsaka driftstopp som i sin tur kan leda till stora ekonomiska förluster och företaget förlorar sitt anseende. Ett exempel på det kan vara en anställd som inte kan komma åt sina filer på grund av att de inte är tillgängliga och or- saken till problemet är en överbelastad server. Den anställde är inte längre produktiv och kan inte utföra sina arbetsuppgifter. Med ett Network Monitoring System (NMS) kunde problemet fångats upp tidigare och den obalanserade lasten inom infrastrukturen korri- gerats och därmed undvikit ett potentiellt förödande driftstopp. Att övervaka nätverken möjliggör att personalen fokuserar på att utföra sina arbeten och möjliggör många ekono- miska fördelar för organisationen, därmed är nätverksövervakningen en kritisk funktion som inte bör underskattas. [1] Datorns snabba utveckling har lett till att dagens nätverk är allt större och mer komplexa, och det är därmed betydligt svårare att förutse beteendet. Dessa faktorer har lett till NMS- rollens betydelse inom större organisationer. [2] NMS är ett väldigt brett område och täcker allt från Ping-verktygen till mer komplexa lösningar och oftast är det öppna källkodslösningar som fungerar lämpligast tack vare möjligheten att modifiera mjukvaran och anpassa det till miljön, och det till ett mer till- fredsställande pris. Öppen källkodsvarianterna bygger på att samla informationen och an- vänder sig av SNMP-protokollet för att skicka värden till egenskrivna grafiska lösningar. [3]. Arbetet behandlar nätverksövervakningssytem som används för att övervaka de olika or- ganisationernas nätverksinfrastrukturer och kommer att vara fokuserat på Sensu och op5 Monitor.

1.2 Tidigare forskning

Det finns ett tidigare stort antal forskningspublikationer i ämnet nätverksövervakning. I och med att Sensu är ett så pass nytt verktyg finns det däremot ingenting som är direkt inriktat på detta verktyg.

1 I artikeln Nagios Based Enchaned IT Management System beskriver författarna hur det inte finns någon fri och öppen lösning som täcker alla de områden och funktioner som krävs för att på ett bra sätt kunna övervaka ett nätverk. Författarna tar även upp hur de proprietära lösningarna är dyra och ofta även kräver en dyr utbildning för att kunna han- teras och administreras. Författarna pekar ut Nagios oförmåga till att sköta konfiguration av de underliggande tjänster på en maskin som en av dess största nackdelar. På grund av detta lägger författarna fram ett eget förslag på en Nagiosbaserad lösning och uppvisar hur denna skulle kunna täcka upp allt som tidigare påpekats att sakna i de fria lösningarna. [4] I uppsatsen En kartläggning av nätverksövervakningssystem, skriven år 2010 av Robin Rudeklint, där författaren lägger fram en kartläggning av en rad, vid tiden, tillgängliga övervakningssystem. Författaren har valt ett brett spann av verktyg, dels giganter så som Nagios och OpenNMS som används för att övervaka stora nätverk, samt verktyg som är lättare att använda och implementera, så som Munin. Arbetet fokuserar på tre stycken delfrågor, vilka tjänster systemen kan övervaka, hur hög prestanda respektive system har, samt hur hög användbarhet varje system har. [5] Året därpå gjordes ett fortsättningsarbete på Robin Rudeklints uppsats, då på B-nivå och av Peter Sandqvist, Övervakningsverktyg: En jämförelse mellan Zabbix och op5 Monitor. Här fokuserade författaren istället på två stycken verktyg och ställde dem mot varandra. Utöver de avgränsningar författaren gjorde var utförandet likvärdigt mot vad Rudeklint hade i sitt arbete. Däremot valde författaren att lägga till tjänsterna DNS och IMAP och därmed möjliggöra notifieringar via e-post. [6]

1.3 Frågeställning och syfte

Arbetet ämnar undersöka hur två stycken olika nätverksövervakningsverktyg hanterar de rapporter som genereras i systemen. Verktygen som valdes är Sensu och op5 Monitor. Valet föll på dessa på grund av att Sensu är ett så pass nytt och intressant övervaknings- verktyg, som till skillnad från många andra övervakningssystem inte bygger på en Nagi- oskärna. I den andra ringhalvan placerades ett övervakningsverktyg baserat på Nagios, baserat på att Nagios länge varit en av de ledande öppen källkodslösningarna [7]. Op5 Monitor, som är baserat på Nagios, valdes för att den levereras som en komplett lösning, där endast minimala åtgärder krävs för att den ska vara färdig att köras. Således är frågeställningen: • Hanterar olika övervakningskärnor rapporter genererade av samma plugin på sam- ma sätt? Detta arbete kommer att behandla de skillnader som kan uppstå när olika nätverksöver- vakningsverktyg genererar rapporter om samma händelse. Arbetet syftar till att undersöka hur olika nätverksövervakningsmjukvaror hanterar samma sorts rapporter, där fokus lig- ger på om de under några omständigheter ger olika varning när avbrott i tjänster simuleras. Undersökningen kommer ge en djupare förståelse för hur de två mjukvarorna agerar när de får en rapport från sina agenter.

2 1.4 Avgränsningar

Undersökningen tar inte hänsyn till eventuella prestandaoptimeringar som manuellt kan göras i Sensu eller op5 Monitor. Mjukvarorna undersöks i sina standardkonfigurationer, utan försök till prestandaoptimeringar. Testmiljön är begränsad till det mindre slaget på grund av att tid till att bygga upp en verklighetstrogen miljö inte finns tillgänglig. Undersökningen sker mot en liten och väldigt specifik miljö, vilket i sin tur innebär att resultaten i sin helhet inte kan översättas direkt till verkligheten. Detta gäller även ut- formningen av avbrotten som inte är tagna från verkligheten och behöver därmed inte vara kända eller vanligt förekommande problem som kan uppstå på ett nätverk. Arbetet är avgränsat till endast Sensu och op5 Monitor. Detta då en jämförelse mellan något nytt och en av de mest populära lösningarna sågs som mest intressant, därför har inte ytterligare verktyg blandats in. För arbetets skull är endast tester på övervakningskärnan intressanta, varvid övrig funk- tionalitet, så som grafning, grafiskt gränssnitt, användarvänlighet och så vidare, inte är av intresse.

3 2 Bakgrund

Detta kapitel förklarar de tekniska delar som krävs för att förstå hur undersökningen har utförts. Kapitlet går igenom de två olika nätverksövervakningsverktygen, såväl som den mjukvara som används för att bygga den virtuella miljön de återfinns i under tester- na.

2.1 Ordlista

Nedan beskrivs vanligt förekommande termer nödvändiga för att förenkla läsandet av arbetet. Agenter I nätverksövervakningssammanhang är agenter en mjukvarumodul som är installerad på enheter som ska övervakas. Agenten samlar in data från enheten den är installerad på och gör den tillgänglig för övervakningsservern. Checkar Används för att exempelvis kontrollera om en tjänst är uppe eller inte. Checkar kan även användas för att samla in data. Handler Använder informationen som skickas till den för att agera. Den kan exempelvis skicka ett e-postmeddelande, eller ett sms till administratören för att rapportera nuvarande sta- tus.

2.2 Nätverksövervakning

Nätverksövervakning är metoden för att samla information om nätverksutrustningen och därmed få en överblick på nätverket. Med den informationen kan nätverksteknikerna ar- beta proaktivt med de olika resurserna för att säkerställa att utrustningen fungerar optimalt och enligt behovet. Network Monitoring System, även kallad NMS, är ett övervaknings- verktyg som används för att fånga upp den viktiga information som kan vara av betydelse för IT-miljön. [8] IT-miljön kan vara liten med få tjänster eller stor och komplex. Dagens övervaknings- verktyg är anpassade för att vara kompatibla med små och stora nätverk, trådbundna och trådlösa nätverk samt har stöd för olika operativsystems plattformar. [8, 9]

2.2.1 Simple Network Management Protocol

Protokollet SNMP ger administratörerna möjligheten att samla information eller skriva ändringar till ett nätverk. Protokollet har stöd för de flesta enheterna och kan även han- tera specifik hård- eller mjukvara. Protokollet har sedan standardiseringen utvecklats och säkerheten i kommunikationen mellan noderna har implementerats och förbättrats i och med SNMP V2 och SNMP V3, där den sistnämnda versionen har stöd för kryptering och autentisering. [10, 11]

4 Manager är servern som kan hantera resurserna på nätverket. Via mjukvaran styr den kommunikationen till agenterna för att antingen skicka en förfrågan till agenten för att få någon specifik information eller ta emot information om något inträffat. Agenterna instal- leras på de hanterade noderna och kommunicerar med managern med hjälp av traps, som skickas asynkront till servern och skickas när något har inträffat. Traps innehåller nöd- vändig och beskrivande information som kan vara betydelsefull för systemet och utifrån den informationen utför managern en mekanism, kallat handler, för att förhoppningsvis motverka händelsen. [12]

2.3 Sensu

Sensu såg först dagens ljus i juli 2011. I detta skede var Sensu inte mer än en idé på GitHub, där utvecklaren, Sean Porter, specificerade vad han tänkte sig att servrar samt klienter tillsammans skulle utföra. Sean beskriver bland annat hur klienter ska skicka keep alives via TCP till servern för att visa att de är aktiva. Han redogör även hur det är tänkt att servern ska fungera i sitt mest grundläggande utförande, tankar om hur data ska skickas, sparas och presenteras för användaren. [13] Sensu beskrivs enligt dem själva som en “monitoring router”. Detta innebär att Sensu samlar in all information som dess checkar genererar. Om vissa villkor uppfylls kom- mer informationen sedan att skickas vidare till en handler, som sedan bestämmer vad informationen kommer att användas till, exempelvis skulle ett mail kunna skickas ut till administratören. [14] I dagsläget innehåller Sensus publika plugindatabas på GitHub omkring 190 olika plugin. En av Sensus styrkor är möjligheten att kunna använda plugin skrivna för Nagios. Det- ta möjliggör användandet av alla de plugin som skrivits till Nagios, vilket i sin tur ger möjligheten till att fylla Sensu med funktionalitet som ännu inte finns genom dedikerade Sensuplugin. Sensu består av ett antal komponenter som binds ihop med hjälp av Ruby. Bortsett från den egna koden för servern, klienten och API:n använder Sensu sig av RabbitMQ för att tillåta Sensukomponenterna att kommunicera mellan varandra. Vissa av komponenterna i Sensu behöver Redis för att lagra beständig data. [14]

2.3.1 RabbitMQ

RabbitMQ är en öppen källkodsmjukvara skriven i programmeringsspråket Erlang [15]. RabbitMQ är en så kallad “message broker“, detta innebär, förenklat, att den tar emot och skickar vidare meddelanden [16]. I fallet Sensu innebär detta att all meddelandetrafik som går mellan servern och klienten sköts av RabbitMQ.

2.3.2 Redis

Redis, eller REmote DIctionary Server, är en öppen källkodsminnesdatabas och är idag den mest populära databasen för att spara nyckelvärden [17, 18]. Redis lagrar alla sina värden i RAM, men tillåter även att man sprider sin dataset över flera olika noder om den primära noden inte har tillräckligt stort minne. [17]

5 2.4 Op5 Monitor

Op5 Monitor är ett mjukvaruverktyg som används för övervakning av enheter i ett nätverk. Mjukvaran är baserat på öppen källkodsprojektet Nagios. Historien om op5 började med två individer som såg ett problem och hade en lösning på det. I början av 2000-talet var Jan Josephson och Fredrik Åkerström involverade i ett stort projekt som var alldeles för komplext och dyrt att övervaka. Det var då de fick idén att skapa en produkt som skulle vara enklare att använda, kunna hantera det mesta som de stora övervakningsverktygen klarade och till ett rimligt pris. För att hålla kostnaderna nere valde de att bygga sitt system på Nagios kärna och kombinera mjukvaran med de egna komponenter Merlin och Ninja. Detta gör att plugins och tillägg för Nagios är kompatibla med op5 Monitor. Mjukvaran har sedan etableringen av bolaget under 2004 växt sig starkt och är idag marknadsledande inom sin bransch. [19]

2.4.1 Ninja

Nagios is now Just Awesome, Ninja, är utvecklad av op5 som ett alternativ till Nagios egna grafiska gränssnitt. Tanken med Ninja är att skapa ett mer användarvänligt webbgränssnitt för Nagios. [20] Projektet är ett krafttag för att skriva ett helt nytt gränssnitt och på så vis helt och hållet ersätta de gamla CGI-alternativen. Ninja är skrivet i PHP, vilket ger större flexibilitet när det kommer till att anpassa gränssnittet till sina egna krav och behov. [21]

2.4.2 Merlin

Merlin, eller Module for Effortless Redundancy and Loadbalancing in Nagios, är back- endmotor som används för att ge op5 Monitor möjligheter till lastbalansering. Merlin används för att tillåta op5 Monitors processer att direkt utbyta information med varandra, som ett alternativ till Nagios lösning som använder NSCA [22]. NSCA, Nagios Service Check Acceptor, är en daemon som tar emot resultat från tester de övervakade maskinerna själva kör, så kallade passiva tester [23]. När Ninjaprojektet inleddes insåg op5 att de kunde vidareutveckla Merlin att fungera som en back-end till Ninja genom att lägga till support för att lagra statusdata i en databas för Ninjas användning. [22]

2.4.3 Naemon

Efter att i flera år ha stöttat Nagiosprojektet med mängder utav kod kände op5 att gemen- skapen de en gång var del av inte längre var där, det berodde till stor del på förändringar i Nagios organisation [24]. I och med detta valde Andreas Ericsson, anställd på op5 som dessutom gjort väldigt mycket arbete på Nagioskärnan, att forka projektet och skapa Nae- mon. Förhoppningarna med Naemon är att projektet ska fortsätta utvecklas av användarna, för användarna [25].

6 2.5 VMware ESXi

VMware är mjukvaruutvecklare och marknadsledande inom molntjänster och virtualise- ring. Företaget har utvecklat bland annat vSphere, även kallad ESXi som är en mjukvara avsett för virtualiseringar inom servermiljö och körs på x86-64 bitars plattform. Hyper- visorn är ”bare-metal” vilket betyder att den är en Type 1 hypervisor, med andra ord körs gäst-operativsystemet direkt mot hårdvaran och behöver därmed inget underliggan- de operativsystem. Detta gör VMware ESXi skalbart, högpresterande, effektivt och kan köras med hög säkerhet. ESXi har tre funktioner som är användbara inom servervirtualiseringar. DRS (Distributed Resource Scheduling) tillsammans med DPM (Dynamic Power Management) möjliggör hög tillgänglighet, lastbalanserar belastningen och skalar systemet genom att ha en pool av resurser som den kan styra och fördela effektivt utifrån belastningen på de olika servrarna. Hypervisorn kan med andra ord live-migrera virtuella maskiner mellan olika fysiska serv- rar utan att påverka de körande tjänsterna. Därefter kan DPM reglera strömförbrukningen utifrån arbetsbelastningen och ger därmed en lägre strömförbrukning [26]. vMotion är ansvarig för Live-migreringen mellan de fysiska servrarnna [27].

2.6 Httperf

Httperf är ett verktyg som används för att utföra prestandamätningar på webbapplika- tioner och webbservrar. Verktyget belastar nätverksutrustningen med HTTP-trafik för att möjliggöra prestanda mätningar och genererar en rapport på resultaten. Rapporten inklu- derar antal sessioner, sessionskvot, antal förfrågningar samt annan viktig information som exempelvis olika fel som kan ha uppstått vid mätningen. [28]

7 3 Metod

Detta kapitel behandlar genomförandet, hur de experimentella scenarierna byggdes upp och förklarar även hur testmiljön såg ut under experimentfasen av arbetet.

3.1 Genomförande

Genomförandet av arbetet gjordes genom två stycken nätverksövervakningssystem, Sensu och op5 Monitor. I testmiljön kördes dessa parallellt för att underlätta testandet och i en högre grad kunna garantera korrekta testresultat. Att köra dessa verktyg parallellt i en skarp miljö är däremot osannolikt. För att kunna säkerställa resultatens korrekthet användes samma plugin till båda övervak- ningssystemen, det vill säga ett för övervakningen av Apache samt ett för övervakningen av BIND. Pluginen som användes för Apache och BIND var av olika karaktärer. Pluginet för att övervaka Apache behövde inte installeras utan kunde köras direkt från övervak- ningssystemet, då det utförde sina kontroller på resurser tillgängliga utifrån systemet. För övervakningen av BIND9 behövde pluginet installeras på de noder som skulle övervakas, då pluginet utförde sina kontroller med hjälp av information som inte fanns inte tillgänglig från utsidan. För att se huruvida systemen reagerade olika på samma sorts avbrott kördes de parallellt och dess rapporter övervakades. Istället för att vänta på avbrott i tjänsterna simulerades dessa genom att framtvinga de olika kriterier som ställdes av pluginen för att skapa rap- porter. Avbrotten är inte verklighetsförankrade, det vill säga att de simulerade avbrotten är base- rade på pluginets funktionalitet och inte på de vanligaste felen som kan uppstå i tjänsterna Apache och BIND.

3.2 Testmiljö

Testmiljön var uppbyggd virtuellt på en fysisk server. I samtliga fall, bortsett från op5 Mo- nitor, valde vi att använda Debian. Till op5 Monitor använde vi CentOS 6, detta på grund av att op5 själva tillhandahöll en virtuell avbild av operativsystemet med op5 Monitor installerat och grundkonfigurerat. Detta gjordes på grund av att installation och konfigu- ration av op5 Monitor kunde ha upptagit mycket av den tid som åsidosatts för experimen- ten. De virtuella maskiner som användes i testmiljön var: • Sensu_server med operativsystemet Debian 7. Servern hade Sensu version 0.12 in- stallerat och konfigurerat. • Op5_server med operativsystemet CentOS 6. Servern hade op5 Monitor version 6.2 installerat och konfigurerat. Maskinen var baserad på den virtuella avbild op5 själva tillhandahåller. • Webserver med operativsystemet Debian 7. Servern hade Apache2 installerat och konfigurerat.

8 • Nameserver med operativsystemet Debian 7. Servern hade BIND9 installerat och konfigurerat. De två maskiner som tillhandahöll tjänster att övervaka hade även agenter för både Sensu och op5 Monitor installerade. Utöver dessa maskiner fanns även en virtuell klient tillgänglig, den var däremot inte in- stallerad på den fysiska servern utan på en av maskinerna i nätverkslabbet.

Figur 1: Logisk topologi

Figur 1 visar en logisk topologi över nätverket som användes under experimentet.

3.3 Testverktyg

Under detta kapitel presenteras testverktyget som tillämpats under vissa delar av under- sökningen.

3.3.1 Httperf

Verktyget httperf användes till att mäta prestandan på webbservern genom att belasta ser- vern med HTTP-trafik. Trafiken bestämdes utifrån ett antal parametrar som överensstäm- de med kriterierna och pluginen för att simulera avbrotten. Httperfs styrka ligger i dess flexibilitet i att styra trafiken och detta gjorde verktyget bäst lämpad för undersökningen av miljön.

3.4 Experiment

Experimenten för att undersöka hur Sensu samt op5 Monitor hanterade de felkoder som rapporterades till dem var baserade på den information pluginen kunde tillhandahålla. För att kunna säkerställa konsekvent testdata upprepades samtliga tester tre gånger.

9 Insamlingen av data utfördes simultant på de båda övervakningssystemen. På grund av de två övervakningsverktygens uppbyggnad var det inte möjligt att samla in data vid exakt samma tidpunkt. Experimentens uppbyggnad är baserad på hur pluginen är utformade och vad de kan rap- portera på. I och med att arbetet inte tar hänsyn till ett verklighetstroget scenario går inte alla experiment att direkt koppla till verkligheten. Detta då det ansågs viktigare att kunna samla in data att bygga resultat på än att samla in data som skulle kunna uppstå under drift. Således är viss insamlad data baserad på rapporter från incidenter som sällan eller aldrig skulle uppstå i verkligheten, men de är simulerade till förmån för att samla in de rapporter som arbetet grundar sina slutsatser på.

3.4.1 BIND9

Pluginet som användes för att kontrollera BIND9 agerar i sex stycken steg för att samla in data om processen. 1. Kontrollerar om PID-filen existerar. Returnerar ett kritiskt fel om den saknas eller är tom. 2. Läser PID-filens innehåll och kontrollerar om processen körs. Returnerar ett kritiskt fel om PID inte finns i processlistan. 3. Kör ”rndc stats” för att generera information från BIND9. 4. Öppnar filen som genererades i steg 3 och läser dess innehåll. Returnerar en varning om filen inte kan öppnas, eller om korrekt information inte återfinns i filen. 5. Kör ”rndc status” och läser av utdatan. Returnerar en varning om datan inte kan återfinnas. 6. Returnerar status och prestandauppgifter. Således baserades experimenten på ett urval av dessa steg. I test nummer ett tvångsavslu- tades tjänsten under drift för att undersöka vilken sorts varning detta skulle framkalla. I test nummer två raderades PID-filen under tiden som tjänsten var igång. I det slutgiltiga testet togs läsrättigheter bort från filen named.stats, innehållandes statistik från ”rndc stats”.

3.4.2 Apache

För att kontrollera Apaches status användes ett plugin som med hjälp av Apachemodu- len mod_status och dess genererade statussida samt verktyget ps gör en utläsning av den tillgängliga informationen och rapporterar resultatet av denna till övervakningsverkty- get. Pluginet övervakar förfrågningar per sekund, bytes per sekund/request, mängden upptag- na/stillastående workers och dess CPU-belastning. Av dessa övervakningsområden var det endast förfrågningar per sekund pluginet rapporterar varningar samt kritiska förhållanden för, därav var experimenten baserade på detta.

10 Testet för att kontrollera hur övervakningsverktygen hanterade informationen som levere- rades från Apache-pluginet delades experimentet i två delar. Den ena halvan utav testen bestod av att framkalla en varning, den andra av att framkalla en kritisk varning. För att underlätta detta specificerades det att varningar skulle ske vid 100 förfrågningar per se- kund och kritiska varningar vid 150 förfrågningar per sekund. För att på ett konsekvent sett kunna framkalla dessa förfrågningar användes verktyget httperf.

11 4 Resultat

Under detta kapitel presenteras en sammanställning av experimentens resultat.

4.1 BIND9

Tabell 1 visar resultat från det inledande testet där BIND9-processen tvångsavslutades och information om detta samlades in genom de två övervakningsverktygen. Den insamlade datan visar att PID-filen innehåller ett nummer som refererar till en process som inte körs. Statusdelen av rapporterna visar att samtliga tre försök returnerade identiska resultat, vilket visas tydligt med tillståndstyp 2, critical.

Tabell 1: Test 1 (Tvångsavslutning av process) Sensu op5 Monitor Försök 1-3 ”output”:”BIND9 PID file status;CRITICAL;HARD;2;BIND9 /var/run/named/named.pid contains PID file /var/run/named/named.pid not-running PID 2087”,”status”:2 contains not-running PID 2087

I tabell 2 presenteras resultaten från testet där PID-filen för BIND9 raderades samtidigt som tjänsten kördes. I och med att filen är raderad rapporteras även detta av övervaknings- systemen. Här returneras tillståndstyp 2, critical, i samtliga fall.

Tabell 2: Test 2 (Radera PID-fil) Sensu op5 Monitor Försök 1-3 ”output”:”BIND9 PID file status;CRITICAL;HARD;2;BIND9 /var/run/named/named.pid not PID file /var/run/named/named.pid not found”,”status”:2 found

Tabell 3 presenterar resultatdata från det sista testet gällande BIND9. I sista testet gjordes försök att testa steg fyra i pluginets körordning, att hindra läsning av filen named.stats innehållandes informationen framtagen av ”rndc stats”. Information som mottogs visar att filen named.stats inte går att öppna, på grund av att rättighetsproblem. I samtliga fall returnerades en varning, tillståndstyp 1.

Tabell 3: Test 4 (Hindra läsning av named.stats) Sensu op5 Monitor Försök 1-3 ”output”:”rndc: ’stats’ failed: status;WARNING;HARD;2;BIND9 permission denied BIND9 Failed to open –stats-path Failed to open –stats-path /var/cache/bind/named.stats: Per- /var/cache/bind/named.stats: mission denied. : PID 6902 : Running: Permission denied. ; PID 6902 ; 0/0/1000 UDP, 0/100 TCP, 0 xfers: 0 Running: 0/0/1000 UDP, 0/100 deferred xfers: 19 zones :: TCP, 0 xfers; 0 deferred xfers; 19 zones ;”,”status”:1

12 4.2 Apache

Tabell 4 beskriver resultaten från testet där gränsen för varning vid 100 förfrågningar per sekund överskreds. I samtliga fall rapporteras samma resultat och en varning skickas. Resultaten mellan Sensu och op5 Monitor skiljer sig något sånär på grund av att resultaten inte kunde insamlas vid exakt samma tidpunkt.

Tabell 4: Test 1 (Överstiger antal slots för varning) Sensu op5 Monitor Försök 1 ”output”:”WARNING - Apache status;WARNING;HARD;2;WARNING serves 104 Requests per second - Apache serves 109 Requests per with an average CPU utilization second with an average CPU of 7.3%. Busy workers: 1, idle: 9 utilization of 0%. Busy workers: 2, | ’cpu_load’=7.3 ’req_psec’=104 idle: 8 ’bytes_psec’=124882 ’by- tes_preq’=176.97 ’workers_busy’=1 ’workers_idle’=9”,”status”:1 Försök 2 ”output”:”WARNING - Apache status;WARNING;HARD;2;WARNING serves 105 Requests per second - Apache serves 104 Requests per with an average CPU utilization second with an average CPU of 10.1%. Busy workers: 1, idle: 9 utilization of 0%. Busy workers: 1, | ’cpu_load’=10.1 ’req_psec’=105 idle: 9 ’bytes_psec’=112401 ’by- tes_preq’=176.973 ’workers_busy’=1 ’workers_idle’=9”,”status”:1 Försök 3 ”output”:”WARNING - Apache status;WARNING;HARD;2;WARNING serves 105 Requests per second - Apache serves 105 Requests per with an average CPU utilization second with an average CPU of 10.9%. Busy workers: 1, idle: 9 utilization of 0%. Busy workers: 1, | ’cpu_load’=10.9 ’req_psec’=105 idle: 9 ’bytes_psec’=102354 ’by- tes_preq’=176.977 ’workers_busy’=1 ’workers_idle’=9”,”status”:1

I tabell 5 presenteras resultaten från testet där gränsen för kritisk varning vid 150 förfråg- ningar per sekund överskreds. Även i detta fall rapporteras samma resultat konsekvent från de två övervakningsverktygen med endast en ytterst liten avvikelse i antal förfråg- ningar per sekund för varje inhämtning av data. Den relevanta information som visas i dessa tabeller är primärt statusen samt indikationen till vilken nivå av varning det är. Det är i båda fallen förfrågningar per sekund (requests per second) som får varningarna att lösas ut. Den återstående informationen beskriver lasten som servern utsätts för.

13 Tabell 5: Test 2 (Överstiger antal slots för kritisk varning) Sensu op5 Monitor Försök 1 ”output”:”CRITICAL - Apache status;CRITICAL;HARD;2;CRITICAL serves 156 Requests per second - Apache serves 157 Requests per with an average CPU utilization second with an average CPU of 12.9%. Busy workers: 1, idle: 9 utilization of 0%. Busy workers: 2, | ’cpu_load’=12.9 ’req_psec’=156 idle: 8 ’bytes_psec’=94684.8 ’by- tes_preq’=176.98 ’workers_busy’=1 ’workers_idle’=9”,”status”:2 Försök 2 ”output”:”CRITICAL - Apache status;CRITICAL;HARD;2;CRITICAL serves 156 Requests per second - Apache serves 156 Requests per with an average CPU utilization second with an average CPU of 13.9%. Busy workers: 1, idle: 9 utilization of 0%. Busy workers: 1, | ’cpu_load’=13.9 ’req_psec’=156 idle: 9 ’bytes_psec’=88281.5 ’by- tes_preq’=176.983 ’workers_busy’=1 ’workers_idle’=9”,”status”:2 Försök 3 ”output”:”CRITICAL - Apache status;CRITICAL;HARD;2;CRITICAL serves 156 Requests per second - Apache serves 156 Requests per with an average CPU utilization second with an average CPU of 15.8%. Busy workers: 1, idle: 9 utilization of 0%. Busy workers: 1, | ’cpu_load’=15.8 ’req_psec’=156 idle: 9 ’bytes_psec’=83247.5 ’by- tes_preq’=176.986 ’workers_busy’=1 ’workers_idle’=9”,”status”:2

14 5 Analys och slutsats

I följande kapitel jämförs och analyseras de resultat som presenterades i det föregående kapitlet. Datan har sammanställts och förts in i tabeller för att få en tydligare överblick av de insamlade resultaten.

5.1 BIND

Resultaten från experimenten visade att övervakningsverktygen Sensu och op5 Monitor i sin grundkonfiguration klarade av att uppmärksamma de avbrotten som simulerades och att de agerade på ett likvärdigt sätt vid inhämtande och rapportering av datan. Under expe- rimentet lyckades övervakningsverktygen att fånga upp och identifiera de olika orsakerna till avbrottshändelsen.

5.2 Apache

I samtliga av de experiment som utfördes med pluginet för att övervaka Apache2 re- turnerades överensstämmande resultat från samtliga tester. Samtliga tester vittnar om att övervakningskärnorna i de två övervakningsverktygen agerar på samma sätt när de häm- tar in information på egen hand. I detta fall skedde inhämtandet av information genom att läsa den från statussidan som Apache2 levererar med hjälp av modulen mod_status samt verktyget ps. Sensus rapporter kan uppfattas som mer svårlästa och röriga, men är utförligare än op5 Monitors. Op5 Monitor kunde inte rapportera CPU-belastningen på webbservern medan Sensu gav en grundligare bild av belastningen i procentform, antalet förfrågningar per sekund och dess storlek.

5.3 Slutsats

Som analysen i det föregående avsnittet visade så agerar de två övervakningssystemen på högst likvärdiga sätt när de möter samma utmaning, att övervaka samma tjänster och med samma plugin. Det är enligt oss endast obetydliga skillnader mellan den insamlade datan från de två över- vakningssystemen. Den enda egentliga skillnaden var att Sensu rapporterade om proces- soranvändning under Apache2-testerna medan op5 Monitor inte gjorde detsamma. Detta vittnar däremot om att någonting måste skilja de två kärnorna åt, då Sensu kunde plocka ut informationen med ett plugin som i grund och botten är skrivet åt just Nagios och inte Sensu. Resultaten och slutsatsen vi dragit talar för att även om arbetet utökats med ännu ett, eller flera övervakningsverktyg, så hade resultaten blivit detsamma, vi hade inte sett några nämnvärda skillnader i slutresultatet. Detta då verktyg vars plugin skulle vara kompatibla med varandra, för en rättvis jämförelse, med största sannolikhet behandlar rapporter på samma sätt på grund av hur pluginen är skrivna. Pluginen definierar tydligt när en viss tillståndstyp ska skickas och förutsatt att agenten korrekt rapporterar detta kommer samma resultat att uppnås även med andra verktyg.

15 5.4 Förslag till fortsatt forskning

I och med de avgränsningar som gjordes för arbetets skull finns det många outforskade områden som hade kunnat inkluderas. Man skulle kunna utföra tester liknande de som utfördes i detta arbete, men istället för att endast använda Nagiosbaserade plugin skulle testen kunna delas i två. En uppsättning tester för ett Nagiosbaserat övervakningssystem med Nagiosplugin och ett för Sensu, med Sensuplugin. I sådana fall skulle tester utfö- ras på de vardera plattformarna med deras individuella plugin för att se om detta skulle generera varierande resultat. När Sensu mognat och fått mer funktioner i sitt grundutförande vore det lämpligt att göra en mer funktionsmässigt baserad undersökning för att se hur den kan konkurrera på detta plan.

16 Referenser

[1] E. Wong, “Network Monitoring Fundamentals and Standards,” 1997. [Online]. Tillgänglig: http://www.cse.wustl.edu/ jain/cis788-97/ftp/net_monitoring/ [Hämtad: 2014-04-25] [2] A. Clemm, “Network Management Complexities: From Afterthought to Key Topic,” in Network Management Fundamentals. Indianapolis: Cisco Press, 2008, ch. Chapter 1, pp. 21–22. [3] “What kinds of network monitoring systems are available?” [Online]. Tillgänglig: http://www.cio.com/article/133700/Network_Monitoring_Definition_and_Solutions?page=9#network [Hämtad: 2014-04-10] [4] A. D. Kora and M. M. Soidridine, “Nagios Based Enhanced IT Management System,” International Journal of Engineering Science and Technology, vol. 4, no. 03, pp. 1199–1207, 2012. [Online]. Tillgänglig: http://adsabs.harvard.edu/abs/2012arXiv1206.1611D [5] R. Rudeklint, “En kartläggning av nätverksövervakningssystem,” C-nivå, Högskolan i Skövde, 2010. [Online]. Tillgänglig: http://his.diva-portal.org/smash/get/diva2:323437/FULLTEXT01.pdf [6] P. Sandqvist, “Övervakningsverktyg: En jämförelse mellan Zabbix och op5 Monitor,” B-nivå, Högskolan i Skövde, 2011. [Online]. Tillgänglig: http://his.diva-portal.org/smash/get/diva2:440839/FULLTEXT01.pdf [7] J. Reams, “Extensible Monitoring with Nagios and Messaging Middleware,” in Proceedings of the 26th International Conference on Large Installation System Administration: Strategies, Tools, and Techniques, ser. lisa’12. Berkeley, CA, USA: USENIX Association, 2012, pp. 153–162. [Online]. Tillgänglig: http://dl.acm.org/citation.cfm?id=2432523.2432536 [8] K. Nash and A. Behr, “What is network monitoring?” 2009. [Online]. Tillgänglig: http://www.cio.com/article/133700/Network_Monitoring_Definition_and_Solutions [Hämtad: 2014-04-25] [9] D. Mauro and K. Schmidt, “Network Management and Monitoring,” in Essential SNMP. Sebastopol: O’Reilly, 2001, ch. 1.1, pp. 7–8. [10] ——, “What Is SNMP?” in Essential SNMP. Sebastopol: O’Reilly, 2001, ch. 1, p. 7. [11] ——, “RFCs and SNMP Versions,” in Essential SNMP. Sebastopol: O’Reilly, 2001, ch. 1.2, pp. 9–10. [12] ——, “Managers and Agents,” in Essential SNMP. Sebastopol: O’Reilly, 2001, ch. 1.3, pp. 10–11. [13] S. Porter, “README.org,” 2011. [Online]. Tillgänglig: https://github.com/sensu/sensu/tree/9ef6ff00a4451d8a7dcd3bbf257040928d678da8 [Hämtad: 2014-04-03] [14] “What is Sensu?” 2014. [Online]. Tillgänglig: http://sensuapp.org/docs/0.12/overview [Hämtad: 2014-04-03]

17 [15] M. Radestock and T. Garnock-Jones, “RabbitMQ: Open-Standard Business Messaging in 5000 lines of Erlang,” p. 7. [Online]. Tillgänglig: http://www.rabbitmq.com/resources/erlang-exchange-talk-final/ex.html [Hämtad: 2014-04-11] [16] “RabbitMQ Tutorial - Hello world.” [Online]. Tillgänglig: http://www.rabbitmq.com/tutorials/tutorial-one-python.html [Hämtad: 2014-04-11] [17] “FAQ.” [Online]. Tillgänglig: http://redis.io/topics/faq [Hämtad: 2014-04-14] [18] “DB-Engines Ranking of Key-value Stores,” 2014. [Online]. Tillgänglig: http://db-engines.com/en/ranking/key-value+store [Hämtad: 2014-04-14] [19] “History.” [Online]. Tillgänglig: https://www.op5.com/about/history/ [Hämtad: 2014-04-11] [20] J. Artoun, “GUI (Ninja) Home.” [Online]. Tillgänglig: https://kb.op5.com/display/GUI/GUI+%28Ninja%29+Home [Hämtad: 2014-04-26] [21] M. Lars, “Ninja – The alternative Nagios GUI.” [Online]. Tillgänglig: http://nagios.larsmichelsen.com/ninja-the-alternative-nagios-gui/ [Hämtad: 2014-04-26] [22] F. Mikker, “Distributed (Merlin) Home.” [Online]. Tillgänglig: https://kb.op5.com/display/MERLIN/Distributed+%28Merlin%29+Home [Hämtad: 2014-04-26] [23] “NSCA.” [Online]. Tillgänglig: http://docs.icinga.org/latest/en/nsca.html [Hämtad: 2014-04-26] [24] Janj, “op5 on Naemon, Nagios and the future,” 2014. [Online]. Tillgänglig: https://www.op5.com/blog/news/op5-naemon-nagios-future/ [Hämtad: 2014-04-11] [25] “The Project.” [Online]. Tillgänglig: http://www.naemon.org/project.html [Hämtad: 2014-04-26] [26] “Distributed Resource Scheduler, Distributed Power Management.” [Online]. Tillgänglig: http://www.vmware.com/products/vsphere/features-drs-dpm [Hämtad: 2014-04-11] [27] “vMotion.” [Online]. Tillgänglig: http://www.vmware.com/products/vsphere/features/vmotion.html [Hämtad: 2014-04-11] [28] “httperf.” [Online]. Tillgänglig: http://www.hpl.hp.com/research/linux/httperf/httperf-man-0.9.txt [Hämtad: 2014-05-14]

18