Övervakning med GnilronEye Av Torben Norling - Gnilron AB - 2007-11-25 Denna artikel beskriver hur övervakningsplatformen GnilronEye kan hjälpa till att hålla koll på ditt distribuerade system. Artikeln ger en kort introduktion till vad GnilronEye är och dess primära styrkor. Vad är GnilronEye? GnilronEye är en freeware övervakningsplatform som är 100% javabaserad. Systemet består av en central serverdel som i praktiken består av ett stycke webapplikation deployad i Tomcat 5.5+ med en tillhörande MySQL-databas. Själva övervakningen hanteras av agenter (en per maskin (host) med övervakningsbehov). En agent är konkret en java-console-applikation, dvs en java-applikation utan GUI. Dessa agenter kommunicerar över http(s) med den centrala servern för att dels få sin "attövervaka-lista" samt för att skicka händelser som sedan den centrala serverdelen informerar vidare till slutanvändaren. Den centrala serverdelen tillhandahåller förutom agent-kommunikation ett web-gränssnitt för slutanvändarna. Via detta gränssnitt definieras vad som ska övervakas, när och hur det ska övervakas. Vilka som ska få information om något går snett osv. All konfiguration av vad som ska övervakas sker alltså via detta webgränssnitt och agenterna blir automatiskt medveten om ev. förändringar. Man måste alltså inte manuellt starta om agenter "för att det ska ta skruv". De operativsystem som stöds för agent-övervakning är i dagsläget: Linux, Solaris, HP-UX och Windows (2003/XP/Vista). Givetvis erbjuds en AJAX-baserad dashboard där man kan få en "online-vy" av ett distribuerat systems ingående delar med övervakningspunkter m.m. Denna dashboard-vy förklaras mer nedan. Här är ett exempel från den "live-demo" som snurrar på GnilronEye's hemsida. Logga in själv för att se det hela "in action". Se URL'er i slutet av artikeln
Övervakning - Hålla koll på total CPU-last för en maskin GnilronEye kan bevaka hur mycket "CPU Idle percentage" som en maskin har. Det går att sätta tröskelvärden för när man anser att nu är det så hög totallast i maskinen CPU-mässigt att jag måste skicka ett larm. Övervakning - Hålla koll på processer och dess CPU-last GnilronEye håller koll på att en process lever samt kan dessutom hålla koll på en process CPU-last. En viktig del är att identifiera en process. Processer identifieras på två olika sätt. PID-file: För de processer som tillhandahåller en PID (Process ID) fil så kan GnilronEye läsa denna och hitta processen via denna mekanism. Finder expression: Ofta saknas en PID-fil och här erbjuder GnilronEye en avancerad mekanism med dynamiska uttryck för att hitta en process. Man kan t.ex. säga att "Processen jag söker ska köras av user xyzzy, kommandoraden ska innehålla texten java och processen ska förbruka mer än 200MB minne. På ren GnilronEye'ska skulle detta heta: proc.user == 'xyzzy' && proc.memmega>200 && proc.cmdcontains('java')
När man definierar själva övervakningspunkten för t.ex. att en process lever så talar man om hur ofta kontrollen ska ske, t.ex. var 10'e sekund. Man kan även ange en "inkubationstid" vilken kan används för att filtrera bort kortvariga störningar. T.ex. man kanske kan leva med att en process lastar mer än 80% CPU last om det pågår max 30 sekunder. Pågår det mer än 30 sekunder så ska det larma. Det är rätt så vanligt att ett system kortvarigt peakar CPU-mässigt men återhämtar sig snabbt. Då är det viktigt att ett övervakningssystem är med i matchen och inte "spottar ur sig" en massa brus-alarm. Det är illa om man sitter med en vardag fylld med larm som man ignorerar "för att det ska vara så" och sedan kanske missar något viktigt! Övervakning - Hålla koll på diskutrymmen Diskar övervakas enkelt genom att man sätter en tröskelnivå för när larm ska aktiveras. Av liknande anledning som inkubationstiden så sätter man förutom en nedre tröskelnivå en övre nivå för när "tillbaka till normal status" inträffar. Anledningen till detta är att slippa att en skur av larm skickas om diskutrymmet studsar fram och tillbaka kring tröskelnivån. T.ex. sätter man kanske tröskelnivån till att larma om det är mindre än 4 GB data ledigt, sedan sätter man lämpligtvis "normalnivån" till 5GB. Se nedan hur detta konfigureras i GnilronEye samt själva poängen i "graf-form".
Övervakning - Hålla koll på logfiler Många system loggar en massa bra information som ofta enbart används först när något går snett för att felsöka just "vad som gick snett i torsdags natt". GnilronEye kan "tail'a" en logfil och dessutom kan man deklarera regular-expressions som matchas mot logfilens rader en efter en allt eftersom det skrivs i loggen. Givetvis hanteras logg-rullningar, dvs när systemet börjar logga på en ny fil och döper om den gamla. Är man en fena på reg-exp kan man göra en massa skoj. Förutom själva regexp matchningen kan man ange hur många matchningar som måste ske under hur lång tidsrymd för att ett alarm ska triggas. Sedan anger man regler för hur normalläget ska återinträda. Web-GUI't tillhandahåller dessutom ett "regexp-test-gui" där man kan labba fram ett lämpligt regularexpression utifrån eget logfils-innehåll.
Övervakning - Hålla koll på http(s)-baserade tjänster Vi har nu behandlat en massa "lågnivå-övervakning" som processer, diskar och logfiler. Förutom allt detta så kan GnilronEye simulera webläsar-trafik inkl. alla teknikaliteter som https, cookies för sessionshantering, diverse säkerhetsmekanismer som "basic, digest och NTLM (Windows NT) authentication schemes". Detta gör att GnilronEye ska kunna övervaka de flesta typer av webapplikationer. För att hantera detta så definerar man upp ett körschema i det web-baserade admingränssnittet med de http-requests som ska genomföras i vilken ordning. Det går sedan att tilldela ett skript till en eller flera agenter för att t.ex. täcka in olika regional-kontor eller olika ISP'er beroende på övervakningsbehoven. De konkreta övervakningspunkterna som sedan finns att påföra är följande:
http responskoder, dvs 200 (ok) och liknande Svarstider. Dvs tiden för svar inkl. nerladdning av "http-response". Innehålls-kontroll: Här kan man definera ett regular-expression som matchas mot nerladdat innehåll för relevant http-request. På ren svenska kan man med denna övervakningspunkt verifiera att en webapplikation funkar som den ska, dvs inte bara returnerar "något innehåll" utan dessutom "önskat innehåll". Övervakning - Styrning Vi har nu kikat på en massa detaljer kring vad man kan övervaka men vi har inte ännu kikat på när övervakning ska ske. Övervakningspunkter eller Monitors som de heter i GnilronEye grupperas ihop i vad som kallas en MonitorView. Denna MonitorView håller förutom listan med Monitors (övervakningspunkter) ett körschema (Schedule) som talar om när övervakningen ska vara aktiv eller ej. Man kan vrida och vända en hel del på detta körschema för att det ska passa. Det är t.ex. väldigt enkelt att lägga till ett stopp i övervakningen för t.ex. en planerad systemuppgradering. Givetvis blir alla agenter som påverkas av en körschemaändring medveten om den nya stoptiden. Se nedan exempel som inkluderar alla dagar men sedan undantar 23:30-23:45 lördagar, då en backup kör och systemet har "planerad downtime". Larm - När, hur och koll på läget Finfint, nu har vi en massa bra övervakning på plats. Men hur får jag reda på när något går snett? Även om GnilronEye är kul så kanske jag inte nöjes-åker i GnilronEye hela dagarna :-) GnilronEye delger larm eller "events" som det heter i GnilronEye på två olika sätt. e-mail: SMTP utan krussiduller. RSS 2.0 / ATOM: Newsfeed. Antingen på global GnilronEye nivå eller på specifik MonitorView nivå. Förutom att GnilronEye informerar om larm (events) så håller GnilronEye koll på vilka som inne i GnilronEye har kikat på detaljvyn för ett problem. Detta är klart underskattat och enligt mig en av
GnilronEye's huvudpoänger. Just vetskapen kring vilka andra som vet om något som gått snett underlättar / driver på processen att åtgärda problemet. Det vanliga utan denna feature är att de inblandade måste ringa runt till varandra kors och tvärs för att få en bild av vilka som vet om problemet och vem som "tar på sig" att lösa problemet. Det sistnämnda hanterar GnilronEye via en mini-process kring varje larm. Denna process drivs både av manuella ingrepp (Jag tar på mig, tilldelar till X osv) samt av att problemet är identifierat som löst (Dvs resolved på GnilronEye'ska), här är det agenten som indikerar problemet som löst. Ajax-Dashboard - Realtidsvy GnilronEye tillhandahåller en s.k. dashboard som konkret innebär en centraliserad realtidsvy av ditt distribuerade system. Denna dashboard använder AJAX-teknologi för att hålla gränssnittet uppdaterat vilket tekniskt sker var 5:e sekund. Det finns ett antal färdiga layouter att välja mellan i vilka du sedan placerar ut information du vill se i layouternas "place-holders".på detta sätt kan du enkelt bygga upp en vy som passar just ditt system. Det finns tre olika objekt-typer som du kan placera in i en "placeholder": En applikationsvy där applikationsinstanserna framgår med "jag-lever-status" samt CPU last. En lista med en MonitorViews alla Monitors, dvs alla övervakningspunkter och dess värden. En "live-vy" av en övervakad logfil inkl. ett filter som du definerar via regular expression. Detta är i princip en: tail -f minlogfil grep mittfilter En "messenger-liknande" lista över inloggade användare samt agenter online, båda med information kring när användaren / agenten loggade in.
Statistik Givetvis tillhandahåller webapplikationen en möjlighet att ta ut rapporter kring "övervakningspunkternas läge i tiden". Installation Jag tänkte inte gå in på detalj hur man installerar GnilronEye men det är inte svårare än att installera en forum-applikation eller motsvarande. Kika i referensguidens installations-avsnitt för detaljer. Robusthet GnilronEye är designat från botten med robusthet i åtanke. Detta innebär att det t.ex. inte spelar någon roll om du startar agenterna före servern eller om du måste ta ner agenterna eller servern temporärt. Ifall en agent inte lyckas koppla upp sig mot servern av någon anledning köas ev. event och när servern blir online igen så delges de events som inträffade under serverns downtime. Skulle du ta ner en agent med en eller flera uppköade events så kommer dessa events att sparas på disk så agenten kommer ihåg de events som inte lyckats skickas till servern. Dvs när agenten startar igen så återetableras event-kön igen.
Sammanfattning För att sammanfatta det hela så kan man säga att: GnilronEye erbjuder en hel del övervakningsmöjligheter på låg nivå och applikationsnivå i form av loggfiler samt http-övervakning. Övervakar Linux, Solaris, HP-UX och Windows 2003/XP/Vista Har en Ajax-baserad dashboard som erbjuder en kraftfull realtidsvy av ditt distribuerade system. Är enkelt att installera. Är robust och okänsligt för hur du startar/startar om de ingående delarna Freeware. Referenser Hemsida - http://gnilron.se/eye Refguide - http://gnilron.se/eye/docs.shtml Live-demo - http://gnilron.se/eyedemo/