Dag 30-34: Grafing av API responskoder & responstider

Siden vi allerede ekstraherer alle loggmeldinger som genereres i OpenStack kan vi også hente ut og visualisere API-responskoder og API-responstider.  Dette grafes på følgende måte: api-responses

Med en API responstid følger også en responskode.  For å  se hvor mange ganger responskodene forekommer i forhold til hverandre kan dette visualiseres på denne måten:

total api-response-codes

Etter helgen 17. mai vil jeg hovedsaklig fokusere på å fullføre et utkast til prosjektrapporten som skal inn den 26. mai. Endelig innleveringsfrist er satt til 9 juni og prosjektrapporten vil selvfølgelig bli publisert på bloggen.

Dag 20-24: Grafing av instansdata

Etter å ha eksperimentert med ulike metrics fra Logstash og statsd i forrige uke har jeg laget noen enkle python scripts som spør keystone databasen ved jevne mellomrom for instansdata. Antallet kjørende instanser, slettede instanser, instanser som har feilet, samt type instans blir nå grafet i Grafana.

Grunnen for dette er at vi skal kunne holde en enkel oversikt over alle instansene og deres status. I tillegg skal vi kunne kartlegge fremtidige ressursbehov dersom totalkapasiteten i systemet er i ferd med å bli nådd. Dette går under kategorien proaktiv overvåking, og vi kan løse ressursbehov ved å legge til mer ressurser under drift istedenfor når systemet har nådd sin totale kapasitet.

metrics-grafer

 

instans-graf

Dag 11: Generering av testgrafer

Noe mer konfigurasjon måtte til for at den nye grafnoden skulle fungere som den skulle. Provisjonering av noden måtte kjøres to ganger, i tillegg til at en rekke småting måtte konfigureres manuelt. Med alle disse hindringene til side var det tid for å generere noen grafer.

Ved hjelp av et script som heter ceilometer publisher har jeg hatt mulighet til å pushe enkelte data direkte fra ceilometer og inn til Graphite. Data som cpu- og minnebruk har vært de to mest aktuelle, og ved å opprette instanser i OpenStack har jeg kunne sett at grafene utvikler seg over tid. Dette gir et interessant overblikk over tilgjengelige ressurser på systemet og hjelper oss å se data i sammenheng. Samtidig som det også tilbyr systemadministratorer proaktiv overvåkning ved å kunne forutse og hindre problemer før de oppstår.

Når man skal sette opp grafer i Graphite/Grafana baserer man seg på såkalte metrics. Hvis man for eksempel ønsker å se på CPU bruk på en maskin het metric’en i vårt tilfelle: carbon.agents.graphite_winch_local-a.cpuUsage. Denne visualiseres slik:

cpu-bruk

Dag 10: Oppsett av Graphite og Grafana

Logstash, Kibana og Elasticsearch kjører per i dag på en egen node i winch. For at lasten ikke skal bli for stor på denne virtuelle noden hadde jeg i første omgang tenkt å lage en ny node for grafvirtualisering. Grafnoden skal kjøre verktøyet Graphite, som støtter metrics som kommer fra Logstash. I tillegg skal vi benytte oss av en annen frontend enn det Graphite tilbyr og derfor skal også verktøyet Grafana installeres.

Jeg benytter meg av puppetmodulene til echocat siden disse er godt vedlikeholdte og konfigurasjonen av puppetkoden var rett fram. Det meste gikk greit for seg og vagrantboksen har en oppstart- og installasjonstid på mellom 3 og 4 minutter.  For de som er interessert i å se litt på koden og øvrige detaljer rundt oppsettet av vagrantboksen kan ta en kikk på winch repoet.

provision-graphite