Ingen vet vad som händer i nätverket
En av de första funderingarna jag hade när jag kom in i kundens miljö var: "Vad använder de för övervakning?"
Frågan möttes av axelryckningar. Någon nämnde att det fanns ett gammalt system som någon tidigare anställd satt upp, men att ingen riktigt visste hur det fungerade. En annan nämnde att de "kollar direkt i switcharnas CLI ibland."
Det var ungefär så de jobbade och det är inget ovanligt. Jag har sett det hos många kunder med både stora och små miljöer.
Nätverket fungerade ju i stort sett bra, det visste de eftersom det inte kommit in någon felanmälan den senaste tiden. Det var egentligen det enda mätvärdet kunden jobbade med i praktiken.
Gå igenom vad som faktiskt finns
Innan jag installerade ett enda verktyg eller gjorde någon ändring så avsatte jag tid till att gå igenom miljön och den befintliga övervakningen. Vilka och vad för typ av enheter fanns det? Hur såg miljön ut? Var satt de kritiska tjänsterna?
Den gamla övervakningen visade sig ändå ha de flesta enheterna konfigurerade, men en stor del av kundens mätvärden var antingen felmärkta eller väldigt otydliga. Resten bestod av ping var femte minut mot enheterna. Det genererade då och då larm som ingen ändå uppmärksammade. Tekniskt sett var det övervakning, men i praktiken bara brus.
Börja med det som är viktigast
Frestelsen är att bygga allt på en gång: SNMP-polling, NetFlow, syslog-aggregering, dashboards och larmregler. Resultatet brukar bli ett halvfärdigt system som inte passar verksamheten eller är alldeles för oöverskådligt så att man drunknar i data.
Så vad ska du börja med då? En bra start att bygga vidare på brukar vara CPU, minnesanvändning, svarstider och upptid på enheterna.
I det här fallet sattes LibreNMS upp och samtliga enheter i miljön importerades och började övervakas. SNMP v3, tröskelvärden för resursanvändning ställdes in, larmen ställdes in för att skickas till en dedikerad mailbox och en dashboard lades upp på en TV-skärm på avdelningen. Det tog en arbetsdag, men var väl investerad tid.
Syslog blir ofta bortglömt
SNMP berättar hur en enhet mår just nu. Syslog berättar istället vad som hänt historiskt. Båda källorna av information är viktig när du ska felsöka i efterhand.
Jag tog mig en titt för att säkerställa att syslog på samtliga enheter var igång och konfigurerad mot en central log-server istället för lokalt. Första tiden brukar handla om att börja samla in loggarna – det kommer in hundratusentals rader om dagen. Mycket av det är på informationsnivå och kanske inte relevant för att isolera och felsöka ett eventuellt problem. Nyckeln är att filtrera och kategorisera larmen: interface-flaps från kända problemportar kan du ignorera, autentiseringsfel innebär varning och routing-adjacency som går ner är kritiskt.
Efter ett tag har du en ström av loggar som faktiskt går att läsa och ha användning för.
Ett use-case från verkligheten
Ett par månader efter uppsättningen hos kunden började vi plötsligt få in larm om att flera enheter gått offline. Genom att följa loggarna och mätvärden i övervakningen kunde vi snabbt identifiera att en länk mellan två enheter gått ned på grund av felande SFP. Vi loggade in och bekräftade felet, bytte SFP och allt återgick till normalläge igen.
Ett problem som kanske hade tagit hela dagen att hitta tog nu istället minuter att identifiera och åtgärda.
Det är just det som är poängen med bra övervakning. Du kan använda det som ett stöd för att hitta felkällor när minuterna räknas, men också använda det för proaktiva åtgärder.