Innlegg

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 9: Ferdig med eksamen

I dag var siste eksamen på Høgskolen og resten av dagen jobbet jeg på UiB. Nå som det finnes en god del informasjon som sendes til Logstash er det på tide å se på hvordan denne informasjonen kan visualiseres. I Logstash kan man lage metrics av informasjon som er kommet inn, og dette kan sendes videre til ulike grafverktøy for visualisering. Dette er noe jeg ønsker for at vi skal kunne se data i sammenheng og kunne forutse problemer før de oppstår. Ettersom jeg allerede har funnet et eksempeloppsett på en vagrantboks som installerer to grafverktøy kommer jeg til å se videre på dette på mandag.

 

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.