Month: mars 2015

Publisert

Dag 8: Filtrering av unyttig informasjon

Ikke alle data som kommer inn gjennom Logstash er nyttige data. Data som ikke gir noen nyttig informasjon eller rett og slett bare er støy er nødt til å skjules eller filtreres bort. I Logstash kan alle datafelter som blir opprettet når man lager filter søkes i. På bakgrunn av dette kan man ved hjelp av regulære uttrykk søke etter informasjon man vil filtrere bort slik at dette ikke kommer med. Hvis man for eksempel ikke skulle ønske å se alle infomeldinger som et system genererer kan dette filtreres bort på denne måten.

if «INFO» in [openstack_loglevel] {drop {}

}

Videre vil jeg ta en fullstendig gjennomgang av hva informasjon som skal filtreres bort slik at dette ikke overskygger viktige data i henhold til problemstillingen.

 

 

Publisert

Dag 7: Filtrering av instanshendelser

Dagen ble benyttet til å lage grok-filtre som henter ut informasjon fra OpenStack-instanser. Om en instans blir opprettet, slettet, rebootet, re-initialisert, utvidet eller skulle få en feil vil dette bli truffet av filteret og vi vil kunne se denne hendelsen og all informasjon i webpanelet Kibana.

logstash-output

Her ser vi at all informasjon som jeg publisert i forrige bloggpost har kommet inn som egne felter. Disse kan nå søkes opp i og en kan visualisere dette på forskjellige måter. Neste steg blir å se på andre data i OpenStack og hvordan vi kan hente ut informasjon om opprettelser av eksempelvis nettverk og rutere.

Publisert

Dag 6: Grok-filtre i Logstash

For å kunne hente ut informasjon fra data som kommer inn i Logstash kan man benytte seg av grok-filtre. Grok-filtre er bygget på toppen av regulære uttrykk og på bakgrunn av dette kan man hente ut den informasjonen man ønsker, eksempelvis fra loggdata. For å hente ut relevante data er man avhengig av å vite noe om dataene på forhånd. For eksempel sier følgende logglinje hvilken dato hendelsen skjer på, hvilket loglevel informasjonen er i, hvilken tjeneste som genererer meldingen og hvilken instans i OpenStack meldingen omhandler. At en instans starter kan være nyttig informasjon dersom den ikke skulle komme opp som forventet.

2015-03-20T08:38:51+00:00 compute 2015-03-20 08:38:51.292 11139 AUDIT nova.compute.manager [req-414b1736-9bf6-4457-a848-1295ebb12d7c b251c86204eb44b6822a998da0d28ad4 1a49bb7c49914d96b95ade9b1345eac2] [instance: 4e86c611-0914-4da2-9ed4-4c2ca5529ffb] Rebooting instance

Ved hjelp av grok debugger har jeg laget et filter som henter ut informasjonen og gjør den svært oversiktlig og enkel å organisere. Etter at informasjonen er kommet gjennom filteret ser den slik ut:

{
  "openstack_hostname": [
    "compute"
  ],
  "timestamp": [
    "2015-03-20 08:38:51.292"
  ],
  "openstack_pid": [
    " 11139"
  ],
  "openstack_loglevel": [
    "AUDIT"
  ],
  "openstack_program": [
    "nova.compute.manager "
  ],
  "request_id_list": [
    "414b1736-9bf6-4457-a848-1295ebb12d7c",
    "1a49bb7c49914d96b95ade9b1345eac2"
  ],
  "openstack_instance_id": [
    "4e86c611-0914-4da2-9ed4-4c2ca5529ffb"
  ],
  "openstack_instance_action": [
    "Rebooting instance"
  ]
}

Dette sendes så videre fra Logstash til Elasticsearch der man kan søke opp spesifikke data og visualisere dette på mange ulike måter. Visualisering vil bli et eget tema på bloggen senere.

 

Publisert

Dag 5: Start av fysisk testmiljø

Som tidligere publisert på bloggen har jeg fått tildelt en 32GB fysisk blade server der winch har blitt installert. Hensikten med dette er å kjøre et virtuelt OpenStack-testmiljø der jeg kan teste ulike monitoreringssystem. For øyeblikket er jeg i gang med å teste Logstash, Elasticsearch og Kibana og har satt opp dette i winch under en egen monitoreringsbranch. I denne branchen har jeg laget en logstash node som er konfigurert til å ta imot alle loggdata som kommer fra OpenStack.

Her vil jeg ha muligheten til å se hvilke data som kommer inn slik at jeg kan hente ut den informasjonen som er relevant. Samtidig ønsker jeg å kunne filtrere vekk all unyttig informasjon slik at dette ikke overskygger viktige data. Jeg har laget en vagrantboks som installerer Logstash automatisk ved hjelp av puppet. Dersom noe feil skulle skje eller testoppsettet ikke skulle fungere som det skal, kan jeg enkelt slette og starte maskinen på nytt for å komme tilbake til der jeg var før feilen skjedde. Ved hjelp av dette sparer jeg mye tid og kan fokusere mer på testingen av de ulike verktøyene. Vagrantboksen er definert slik.

Publisert

Dag 4: Videre konfigurasjon av winch

Dagen ble benyttet til å teste at provisjoneringen av controller og compute fungerer sammen med logstash. Det er mye av konfigurasjonen som utføres manuelt for øyeblikket. Blant annet må alle OpenStack tjenestene manuelt endres for at de skal logge til syslog og sende til logstash noden som tar imot og parser loggende.

Førsteprioritet er uansett å få opp et fysisk testmiljø der jeg har muligheten til å starte flere instanser og sjekke at all informasjon som blir generert i loggfilene blir samlet og håndtert. Videre må nøkkelfunksjonalitet i systemet testes på en slik måte at loggdataene som blir generert kan si noe om hvilken tilstand systemet er i. Om tjenester er oppe og går, om det har forekommet feil den siste tiden osv.

Publisert

Dag 3: Submoduler i git og installasjon på blade server

I forrige uke fikk jeg problemer med å legge til enkelte puppetmoduler til monitoreringsbranchen på github. Etter en del feilsøking endte jeg  opp med å legge disse til som submoduler. Fordelen med submoduler er at man slipper å måtte oppdatere modulene i sitt eget repository. Ved å kjøre kommandoen nedenfor vil modulen lastes ned, og det vil ligge en sti til det remote repositoriet i .gitmodules.

git submodule add https://github.com/elastic/puppet-logstash

I tillegg til submodulene er det også blitt lagt til en egen mappe for alle konfigurasjonsfiler og patterns til logstash. Rsyslog.conf ligger også her, men planen videre er å legge til rsyslog puppetmodulen slik at det aller meste kan styres gjennom puppet. Jeg begynte også å installere winch på blade serveren jeg har fått tildelt. Denne serveren har 32GB med minne og jeg har derfor mulighet til å ha kjørende en god del instanser som jeg skal teste med. Mer om dette i morgen!

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

Dag 1: Installasjon og oppsett av logstash, elasticsearch & kibana

Etter tips fra prosjektleder i UH-sky prosjektet er et av monitoreringsverktøyene jeg har valgt å se på logstash. Et  kraftig  verktøy som brukes til å håndtere hendelser og logger.

logstash

Logstash samler inn logger fra ulike kilder, parser loggene og lagrer de til senere bruk.  Når man installerer logstash kommer det også med et webinterface der man kan søke etter hendelsene i loggfilene og visualisere dette slik man ønsker. Dette for å kunne kartlegge feil, se endringer i systemer over tid, sette sammen data som har påvirkning på herandre osv. Logstash er et åpent kildekodeverktøy og er lisensiert under Apache 2.0.

OpenStack er et komplekst rammeverk som består av mange tjenester. Hver tjeneste har sitt eget bruksområde og sitt eget API. Det er mye informasjon som til daglig vil være spredt rundt om i  systemet. Dette gjør det viktig å samle all loggdata på et samlet sted slik at det blir enklere å hente ut den informasjonen vi trenger for å sørge for at rammeverket til enhver tid fungerer som det skal. Logstash er veldig egnet til dette formålet. I logstash.conf kan vi tagge innkommende logger og videre kan det så kjøres filter basert på disse taggene for å hente ut den spesifikke informasjonen vi vil ha tak i. For eksempel tjenestenavn, diskbruk, antall påloggingsforsøk, brukere, IP adresser,  nettleser osv. Alt av informasjon som finnes i en loggfil kan ekstraheres, lagres og videresendes til en eller annen form for visualisering.

Jeg har til nå arbeidet med en kodebase som jeg forket på github som installerer disse tre verktøyene som nevnt i overskriften. Videre har jeg tenkt å integrere denne mot winch slik at den passer øvrig prosjektstruktur. Under følger et bilde av hvordan visualiseringen av loggdataene ser ut.

kibana4-visualisering

 

 

Publisert

Dag 0: Oppsummering

Denne bloggposten er en oppsummering av arbeidet som har blitt gjort før forprosjektet i bacheloroppgaven har kommet i gang.

I henhold til problemstillingen skal jeg «kartlegge forskjellige monitoreringsverktøy og teste bruken av disse». Dette er arbeid som jeg har kommet godt i gang og jeg har fått tilegnet med rimelig god oversikt over forskjellige verktøy som eksisterer for bruk i OpenStack per i dag. Videre skal jeg også «belyse fordeler og ulemper med forskjellige overvåkningsverktøy. Hva passer best til vårt bruk? Er noen verktøy bedre for sky enn for tradisjonell bruk?»
Så langt kan jeg se klare fordeler med enkelte verktøy som jeg linket til tidligere. Verktøene er godt vedlikeholdte, populære og de er alle av åpen kildekode. Sistnevnte punkt tillater meg i aller største grad å spesialtilpasse verktøyene til mitt formål. Jeg har muligheten til å få ut den informasjonen som er av relevans for å kunne identifisere og løse problemer som oppstår. I tillegg til at jeg veldig enkelt kan tagge informasjon som ikke er av relevans som unødvendig slik at dette ikke overskygger faktiske problemer som eventuelt kan forekomme.

Dette har gjort jobben med å finne et verktøy som passer problembeskrivelsen noe enklere. Det er ikke alle verktøy en vil ha mulighet til å spesialtilpasse i så stor grad, og disse verktøyene vil naturligvis bli valgt bort.

Jeg også fått tildelt en egen blade server der uttestingen av forskjellige monitoreringsverktøy skal foregå. Blade serveren har betydelige ressurser som er i stand til å simulere et OpenStack miljø i mye større grad enn det arbeidsstasjonen min til nå har hatt mulighet for. Dette gjør testingen av potensielle verktøy enklere i tillegg til at dataene jeg kommer til å teste med blir mest mulig reelle.

 

2015-02-24 13.13.52

2015-02-24 13.13.37

 

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.