Category: graphite

Publisert

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.

Publisert

Dag 15-19: Metrics gjennom graphite og statsd

Har gjennom hele uken eksperimentert med å lage metrics utav loggene som kan sendes fra logstash til Graphite for grafing. Det som kan grafes så langt er tilgjengelige ressurser på alle compute nodene i OpenStack. Tanken er at disse grafene skal kunne eksponeres ut mot brukerne slik at en kan se hvor mye ressurser det er tilgjengelig til enhver tid på hver av nodene.

I tillegg har jeg laget noen python scripts som skal brukes til å hente ut spesifikke instansdata som også skal kunne grafes. Videre skal jeg også se på muligheten til å hente ut data fra Ceilometer.

Publisert

Dag 13: Grafing av disk, cpu og minnebruk

Metrics til graphite blir sendt på et spesifikt format. Dette er standard uansett hva system man bruker for å lage metrics.  Her spesifiseres først navnet, deretter verdien og til slutt datoen. Eksempelvis:

echo "test.bash.stats 42 `date +%s`" | nc graphite.example.com 2003

Dette vil ikke gi et stort utslag på en graf, men når man sender data over tid vil man på sikt kunne se at det gir utslag. Siden logstash konfigurasjonen henter informasjon om disk, cpu- og minnebruk fra loggfilene kan dette sendes videre for visualisering. Bildet under er visualiserte data basert på denne konfigurasjonen.

metrics-grafer

Bildet viser tre bokser som visualiserer tilgjengelige ressurser. Diskboksen er også konfigurert slik at den endrer farge basert på hvor mye diskplass som er tilgjengelig på disken. Dette er en god begynnelse! I morgen og ut i neste uke kommer jeg til å fortsette med datainnsamling og filtere i Logstash. Følg med!

Publisert

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

Publisert

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

Publisert

Dag 2: Integrering av logstash i «winch»

Under utplasseringen var jeg med på å lage et automatisk oppsett som installerte OpenStack og tilhørende komponenter. Dette ble gjort ufifra et prosjekt på github som het winch. Som jeg tok opp i min forrige bloggpost ønsker jeg å samle alle OpenStack loggene på en og samme maskin. Derfor her jeg laget en ny branch i winch som inkluderer en monitoreringsnode. Denne noden vil være ansvarlig for alt som skjer med tanke på logginnsamling, parsing og visualisering av informasjon. Da er det viktig at verktøyene som skal gjøre dette blir installert på samme måte som tidligere, ved hjelp av puppetmoduler.  Da kan vi sette en ønsket tilstand og si at den nye noden skal være en monitoreringsnode.

Arbeidet med å puppetifisere alle verktøyene er kommet godt i gang. Har laget en manifest fil for logstash som kan sees her. Denne vil benytte seg av puppet modulene lokalisert i puppet/modules og installere verktøyene med konfigurasjonsfiler spesifisert i manifestet. Det som gjenstår for at integreringen skal være komplett er å legge til de puppetmodulene jeg trenger. Disse er submoduler og blir derfor lagt til annerledes. Mer om dette i neste bloggpost.

Publisert

Prosjektbeskrivelse bacheloroppgave

Etter høstens utplassering har jeg fått lov til å skrive bacheloroppgaven min her på IT-avdelingen. I denne sammenhengen publiserer jeg prosjektbeskrivelsen i sin helhet som omhandler monitorering av OpenStack ved UiB. Jeg har også laget en ny side på bloggen øverst til høyre som alltid linker til prosjektbeskrivelsen.

Prosjektbeskrivelse bachelorprosjekt.

Til nå har prosjektet kommet i gang og jeg har såvidt begynt å se på forskjellige løsninger i henhold til problemstillingen som kan brukes til å monitorere OpenStack. Videre vil jeg følge fremdriftsplanen i prosjektbeskrivelsen. Noen verktøy jeg så langt har fått kikket på:

  • Icinga (basert på Nagios)
  • Logstash
  • Elasticsearch / Kibana
  • Monasca
  • Ceilometer / graphite

Denne bloggen har tidligere vært brukt i utplasseringsfaget DAT156 og har hatt en bloggpost for hver dag. Bloggen vil nå bli brukt til bachelorprosjektet som varer frem til juni 2015. Og vil følge samme oppsett med en bloggpost for hver dag. Neste blogginnlegg vil begynne på dag 0 som oppsummerer arbeidet med oppgaven så langt.

Publisert

Dag 31: Logstash & Kibana

Benyttet mesteparten av dagen til å kikke på to verktøy som heter Logstash og Kibana. Logstash er et verktøy for å samle og håndtere logg. Den samler inn, parser og lagrer logg og viser dem i et webpanel kalt Kibana. Her kan man ved hjelp av et kraftig søkeverktøy søke opp alt av hendelser som har skjedd på systemet siden loggingen startet. I webpanelet vil det genereres grafer på hvor ofte en hendelse man har søkt på forekommer. Ganske nyttig dersom man skal filtrere en spesifikk feil for å finne ut om feilen er kritisk eller ikke.

Konfigurasjonsmessig kan man gjøre mye med logstash. Det viktigste av konfigurasjonen skjer ved hjelp av en konfigurasjonsfil der en spesifiserer input, hva som skal filtreres og output. Output delen kan være forskjellige tjenester, i dette tilfellet ble output satt til å være elasticsearch. Elasticsearch er logstash’ sin backend for lagring av logg. Senere vil jeg ta for meg installasjonen og oppsett av logstash og kartlegge tjenester som skal overvåkes. I tillegg ønsker jeg også å kikke nærmere på verktøyet Graphite som kan spesifiseres som output.