This is a video that presents the core components of the bachelor thesis. Thanks to Christian Schüler for allowing me to borrow his Druid version (grassroots mix) for background music.
Prosjektrapport bacheloroppgave
Da har jeg fullført bacheloroppgaven min. Endelig prosjektrapport ligger nå ute for nedlastning her: Monitorering av OpenStack ved UiB
Dag 35-39: Skriveuke
Gjennom hele uken har tiden gått med til å skrive ferdig utkast til prosjektrapporen. Denne ble levert inn 26. mai og endelig innleveringsfrist er 9. juni. Arbeidet som gjenstår er å skrive dokumentasjon om det endelige monitoreringsoppsettet slik at dette enkelt kan tas i bruk. Dette forventes å være ferdig i neste uke.
Oppsummert har det i under uttestingen av Logstash blitt prosessert 8,943,279 millioner hendelser som har blitt lagret i Elasticsearch og visualisert gjennom Kibana og Graphite.
Endelig innleveringsdato for prosjektrapporten er 9. juni..
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: 
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:
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 25-29: Oppsett av dashing-ceph/openstack, rydding av config
Den siste uken har gått med til å sette opp dashing-ceph, dashing-openstack, rydding av Logstash config og oppdatering av bacheloroppgaven. Dashing er kort fortalt et dashbord rammeverk for å visualisere informasjon i «fine bokser», se bilde nedenfor. Det er mye ting i luften akkurat nå og det kommer til å bli en hektisk tid fremover mot innleveringen andre uken i juni.
Bachelorprosjektet skal framføres enten den 10, 11 eller 15 juni og alle som er interessert må komme å høre på! Planen er å ha en enkel men oversiktlig presentasjon med live demo som viser hva jeg har jobbet med dette semesteret. I uken som kommer vil de siste tekniske bitene bli implementert før skriveperioden starter for fullt.
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.
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.
Day 14: Summary: Collecting OpenStack logs with Logstash
This blog post is a summary of the first 14 days of work on my bachelor degree. It is written in English to satisfy some of our Brazilian readers at the University in São Paulo.
Openstack consists of many different services and components, and all of these services are logging information to their own log files respectively. However, it would be an impossible job for a system administrator to monitor all of these log files by simply tailing them through the terminal. This is where Logstash is useful. Logstash is an open-source tool for managing events and logs. It is primarily used for collecting logs, parsing them and save them for later use. The tool also comes with an interface for searching in the logs you’ve collected.
Based on the winch project on GitHub I have created a Logstash node where all logs coming from OpenStack have been centralized. On this node all logs are parsed, information extracted and saved in Elasticsearch. Seconds after, the extracted information is visible on the Kibana dashboard (a front-end to Elasticsearch) ready for searching, filtering and visualization. Extracting the information from the log files is a bit more complex than it sounds. However, Logstash is very easy to get started with and once the basics are covered you’re ready to write complex filters yourself. Having the grok debugger in hand and a quick tutorial in the other also helps 🙂
In my configuration I’m pretty much finished with the filters that covers all the lines of log that the nova services in OpenStack are generating. Launching, rebooting, deleting instances and error messages related to instances is now hit by a filter in Logstash and saved for later searches. Additionally I’ve made a filter that caches everything that is not matched by any previous filter in the configuration. This is in case some special event should occur or if the system goes haywire (not that I expect that to happen). The ‘all-matching’ filter is tagged with «unmatched_event» , and from here we can go back and change the original filter to take «these» special events into account. By doing this we will at all times have an overview if something should go wrong. Also we won’t miss any data that somewhat could be important for us to know. The Logstash configuration can be found here.
Further on I’ve also created some metrics which can been seen in the configuration file. Winch monitoring also consist of a Graphite node where these metrics are sent and visualized. I believe that some data are best when they are graphed in some way or the other providing an overview on a day-to-day basis (or even minute-to-minute basis) on how the system is performing. Graphs also helps seeing systems in context which is very useful.
During the next couple of weeks I will continue to make filters, extract data from logs until all OpenStack services are covered, visualize data and put data in context by making graphs and much more. Stay tuned!
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.
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!
Dag 12: Kartlegging og sending av metrics
Metrics som vi kan sende til visualiseringssystemer er data. Informasjon som representerer en eller annen verdi kan grafes og visualiseres og på denne måten gi oss oversikt over hvordan systemet fungerer til enhver tid. Dagen i dag har for det meste blitt brukt til å lese dokumentasjon og teste ulike fremgangsmåter på hva metrics jeg ønsker å ha med og hvordan disse dataene skal sendes og visualiseres.
Metrics er ikke så veldig bra dokumentert på Logstash sine nettsider. I tillegg er de aller fleste eksempler på metrics er basert på å hente ut informasjon fra apache-aksesslogger. Siden jeg skal hente ut mer data enn dette blir det mye prøving og feiling fremover på å få metrics til å fungere på den måten jeg vil. Mer om dette i morgen!