Overvågning - men hvordan og af hvad?

Efter et alvorligt nedbrud har du indset nødvendigheden af at overvåge din infrastruktur, men hvordan griber du sagen ad og hvad skal du overvåge?

Det er en problemstilling mange kan nikke genkendende til og den umiddelbare reaktion er at skrive overvågning som søgeord i Google. Det giver imidlertid 2,39 millioner hits! Finder du egentlig frem til nogle forskellige alternativer så står der ofte af pågældende løsning klarer præcist det samme uanset em den koster kr. 10.000 eller en million.

Samtidigt hører du brugerne og din IT organisation klage over fx:

• Det går for langsomt
• Det er "nok" serverne / netværket / SANet osv...
• Patch Management systemet har installeret opdateringer og nu virker applikationen ikke
• Virtualiseringen har gjort alt uoverskueligt og langsomt
• Varmen fik serverne til at gå ned
• Vi mistede strømmen pga fejl i UPSen

Der er jo tusinder fejlkilder og du står i dag med ingenting, en lille løsning som er for simpel (fx. en gratis løsning baseret på Ping) eller en kompliceret enterpriseløsning som ingen rigtigt kan betjene (foruden leverandøren som skal on-site til kr. 1.500 i timen). I har kort sagt prøvet at finde en løsning før men det har vist sig at være en tidskrævende, dyr og besværlig øvelse uden et garanteret brugbart resultat. 

Fortvivl ikke for går du lidt struktureret tilværks er der gode chancer for at få en successful oplevelse. Du kunne som en god start læse min BLOG om valg af den "rigtige løsning". Når du har været igennem disse vurderinger, så tænk på hvilke af følgende elementer, der udgør dine "main pains". Det er næppe sandsynligt at du vil investere i en løsning som på én gang klarer dem alle eller har tid til at vente på en implementering, som kan tage måneder (eller år): 

• #1: Netværket (LAN/WAN/WiFi)
• #2: Serverne (fysiske såvel som virtuelle)
• #3: SAN og storage
• #4: Applikationerne - både interne og eksterne
• #5: Det virtuelle miljø
• #6: Log Management
• #7: Prober og særligt udstyr (temp, batteri, fugt, lys, luft m.fl)

Når du har afgjort hvilke elementer der er vigtigste at måle på (prioriter dem eventuelt fra 1 til 7) og vurder så hvilke af følgende målepunkter, der kan give jeres drift relevant information om status og tendenser:

• Netværk: (Impact på #1, #3 & #5)
  A) Tilgængelighed ("Availability") baseret på ping hvis det er netværksnoder eller servere
  B) Trafikmængden (antallet af pakker, mængde og båndbreddeforbrug)
  C) Trafiktypen (porte, protokoller og applikationer) typisk baseret på sFlow/NetFlow
  D) Opsamling af hardware fejl (syslogs / traps)
  E) Environment status og særlige målepunkter
  F) Evt. topologisk info som hjælper med mapning og alarmhåndtering
  
  
  
• Servere: (Impact på #2 #4 & #5) A) Tilgængelighed ("Availability") helst baseret på noget andet end ping (fx WMI forespørgsler til OS)
  B) Båndbreddeforbrug på netkortet
  C) Throughput til SAN
  D) Opsamling af hardwarefejl (syslogs / traps / fra HW agenter som fx HP SIM)
  E) Særlige metrics for virtuelle servere relateret til deling af CPU, MEM & Disk.
  
  
  
• SAN & Storage: (Impact på #2, #3, #4 & #5)
  A) Målepunkter for IOPS
  B) Throughput
  C) Read/Write operationer til storage
  D) Båndbreddeforbrug på interfaces på SAN
  E) Evt. topologisk info som hjælper med mapning og alarmhåndtering
  
  
  
• Applikationerne: (Impact på #4)
  A) Tilgængelighed på applikationer / komponenter (typisk baseret på WMI, Perfmon eller på en lokal agent som rulles ud fra overvågningssystemet)
  B) Svartid på applikationer og URLs
  C) Synthetiske transaktioner med applikationer
  D) End-2-End performance målinger
  E) Transaktionsmålinger på fx web transaktioner
  
  
  
• Det virtuelle miljø: (Impact på #2, #3 & #5)
  A) Nuværende problemer (flaskehalse, CPU/MEM/DISK*)
  B) Hvor opstår de fremtidige problemer
  C) Rightsizing - genvinding af ressourcer som er over/under fordelt
  D) Eventuelt rapportering på prisen for de udnyttede ressourcer (Chargeback)
  
  
  
• Log Management: (Impact på #1 - #7)A) Opsamling, konsolidering og indexering af logs fra servere (Fx Windows, Unix, Linux og ESX), applikationer (Fx SQL, Mail og Web), Netværksnoder (Fx switches, routere, AP/WLC & Firewalls)
  B) Mulighed for søgning på tværs af alle logs på bestemte tidspunkter efter en bestemt type af data (fx IP adresse, brugerkonto, event ID, severity, facility mm)
  C) Event log korrelering hvilket vil sige sammenstilling af forskellige logs baseret på type og frekvens til brug for alarmering og rapportering
  D) Alarmering på basis af automatisk genkendte dele af logs (fx eventid eller bestemte logs fra hardware leverendører som feks. Cisco og  HP)
  
   
• Prober og særligt udstyr: (Impact på #1 - #7)
  A) Custom SNMP baseret polling af værdier fra prober som giver alarmer (Fx temperatur, fugt, lys, luft, åben/lukket, spænding mv)
  B) Overvågning af UPS og alarmer om batteritilstand

Når du har valgt hvad der er vigtigst for din infrastruktur så er det en god idé at kende faldgrupperne så du forhåbentlig kan undgå de værste og få en hurtig og smidig implementering af overvågningen. Derfor har jeg listet nogle af de problemer som vi oftets ser ved overvågningsystemer og implementering / brug:

• Den forkromede løsning: I din "iver" for at vælge et system som kan alt hvad I gerne vil er det endt med et framework system fra en af de store leverandører. Disse systemer er ofte komplicerede, store meget funktionsrige. Det kan betyde følgende for jer:
  
  
  A) En meget lang implementeringstid (måneder til år)
  B) Afhængighed af få specialister i egen organisation (eller endnu værre hos en ekstern kilde)
  C) Manglende fleksibilitet i systemet gør det til en supertanker (svær at manøvrere)
  D) Meget kostbart både i indkøb, vedligehold og interna/eksterne ressourcer til at implementere og vedligeholde systemet.
  
  
  
• Fejlalarmer: Du vælger et system hvor alle alarmer er slået til så hele implementeringen går ud på at slå de unødvendige alarmer fra. Eller du får sat en række alarme op der ikke er specifikke nok så IT driften drukner i alarmer. Derfor sletter du/I bare alle alarmer hver morgen... inklusive den vigtige om at exchangeserveren er ved at løbe tør for diskplads.
  
  Alarmer skal deles op i tilghængelighed og performance og være meget specifikke. Det er vigtigt at de i alarmteksten som minimum fortæller følgende:
  A) Hvor alarmen kommer fra
  B) Hvad der har udløst alarmen
  C) Hvordan fejlen rettes
  
  
  
• Afstemning af forventninger: Det nye IT overvågningssystem kan kun betjenes af en eller to personer i afdelingen og passer godt til hvad de ønsker. Men systemet passer ikke til hvad alle andre forventede af udbytte, inklusive chefen som har betalt for systemet eller brugerne som burde få inddirekte glæde af en højere oppetid eller en hurtigere problemløsning. Husk at vælge successkriterierne for systemet før det vælges, indkøbes og implementeres!
  
  
• Vi vil have alt i ét system: Du ønsker en fælles platform eller ét system der kan udbygges til at klare alle opgaver. Det er besnærende at forestille sig at du kun skal kigge i et overvågningssystem for at se alle problemer i driften, men det fører næsten altid til valg af "den forkromede løsning" og det har som tidligere beskrevet ofte nogle uheldige konsekvenser. Prøv i stedet at vælge nogle specialistløsninger som kan rapportere ind til et fælles system som fx ServiceDesken som samler alle trådene. Det er alligevel specialister som kigger på netop deres område i systemet som fx Serverne, netværket, applikationerne, storage osv.
  
  
  
• Brugerne:Husk at vælge en system som ret faktisk giver brugerne noget værdi i form af nedenstående punkter. Disse punkter bør være en del af successkriterierne for valg af et system.
  
  A) Hurtigere fejlretning
  B) Bedre information om problemer
  C) Højere oppetid
  D) Hurtigere svartid
  E) Bedre performance

For at få inspiration til flere af de nævnte udfordringer og, emner og teknikker kan du fx se på følgende links: [Emner] [Metoder] [Problemer]

* Se vores blog om vigtige performance parametre i det virtuelle miljø.

Af Christian Schmidt (chr@draware.dk)