Contact: | it-drift-gd-gid@usit.uio.no |
---|---|
$Date: | 2021-01-07 09:02:48 +0100 (Thu, 07 Jan 2021) $ |
Innhold:
1 Hensikt
Dette dokumentet beskriver systemet for innsamling og grafing av tidsserie-data som blir benyttet til bl.a.:
- m?ling/historikk p? bruk av maskinvare-ressurser (collectd).
- m?ling/historikk for applikasjoner (statsd)
- m?ling/historikk for nettverkskomponenter (NAV)
- m?ling/historikk generert med script
2 Arkitektur
2.1 Overordnet beskrivelse
F?lgende figur viser konseptskisse av hvordan ting henger sammen
En viktig komponent i systemet er innsamlingsverkt?yet collectd. Collectd's eneste fokus er ? samle inn tidsserie-data. Verkt?yet er plug-in- basert i , og har mange ferdiglagede plugins tilgjengelig i tillegg til muligheten for ? enkelt lage egne.
Det er viktig at verkt?y som samler inn slike data bruker minst mulig resssurser p? selve innsamlingen slik at verkt?yet i minst mulig grad p?virker m?leresultatet, dvs. at ressursbruken man m?ler er for?rsaket av applikasjoner og ikke selve m?leverkt?yet. Collectd er skrevet i C og er "en av de beste i klassen" med hensyn til lav ressursbruk. Verkt?yet er mye brukt, aktivt vedlikeholdt og har et aktivt ?community?.
Hvorvidt Collectd er en klient, tjener eller bare en selvstendig enhet konfigureres med nettverks-plugin'en. Vi benytter en sentral server (metrics02.uio.no) hvor collectd kj?rer som server. Linux-maskiner som er RHEL7 eller nyere og er i produksjon, konfigureres automatisk til ? sende basisdata som CPU, minne, disk og nettverk til collectd-serveren. Automatisk konfigurasjon av collectd-klienter skjer ved hjelp av Cfengine for maskiner i produksjon.
P? metrics02 kj?rer ogs? graphite. Graphite best?r av to hovedkomponenter: ?carbon daemon? og Graphite web-app. ?Carbon daemon? tar imot data fra collectd og lagrer i lokale filer i whisper format.
Data sendes fra collectd p? metrics02 med output-pluginen "write_graphite" og mottas av carbon-c-relay som s? sprer lasten utover 20 instanser av carbon-daemon. Dette for ? kunne utnytte alle CPU'en og ytelsen til SSD-diskene.
3 Grafer
3.1 Graphite
Cnamet graphite.uio.no peker p? metrics02 sin instans av den vanlige graphite django-baserte applikasjon. Denne krever ingen innlogging og brukes utelukkende for ? browse metrics som er tilgjengelig i metricbiblioteket. Her finnes alt som samles til graphite.
Som nevnt over har Graphite et url-API som kan brukes for scripting. Dette er dokumentert p? API-referansen. Det g?r an ? sp?rre Graphite hvilke metrics som er tilgjengelig via /metrics/expand?query=<regexp>. Data returneres som JSON. Man kan n?ste seg helt ned i hierarkiet ved ? sp?rre ett og ett niv? nedover til man n?r bunnen, f.eks. hvilke metrics finnes for alven: /metrics/expand?query=collectd.alven_uio_no.* Dette kan igjen brukes til ? lage spesialtilpassede sett med grafer og sammenstilling av data av interesse.
Notat
Dashboards skal kun lages/lagres i grafana. Dashboard som lagres i graphite-GUI vil forsvinne n?r web-applikasjonen restartes.
3.2 Grafana
Grafana er stedet hvor man definerer egne ?dashboard?, dvs. samlinger av metric-visualiseringer som man ?nsker ? f?lge med p? og se i sammenheng.
I grafana kan man mikse metrics fra hele graphite-biblioteket (scripts,collectd,nav,statsd) og alt som finnes i Zabbix.
Grafana har et sett med interne organisasjoner som man kan veksle mellom. Alle grupper ved USIT har en egen organisasjon hvor medlemmer i ansattgruppen (ldap) har full tilgang til ? opprette, endre og slette dashboard-definisjoner.
Notat
Man kan ikke slette eller endre bakenforliggende metrics i grafana, kun sammenstillinger og visualiseringer i form av dashboards.
I tillegg til egen organisasjon finnes det to fellesorganisasjoner: ?usit? og ?public?
Samtlige i ldapgruppen ?usit? har lesetilgang til grafana-organisasjonen ?usit?. I tillegg har medlemmer i gruppen ?grafana-usit-edit? mulighet til ? lage,endre og slette dashboards. Tanken er at ?usit? skal inneholde dashboards som man kan tenkes ? dele med andre grupper p? usit, men et begrenset utvalg brukere har tilgang til ? vedlikeholde disse for ? unng? kaos og sletting ved uhell.
Gruppen ?grafana-usit-edit? har ogs? tilgang til ? gj?re endringer i organisasjonen ?public?. Forskjellen p? public og ?usit? er at alle som kan n? grafana.uio.no ip-messig har tilgang til dashboards i ?public? uten innlogging. Dvs. at direktelenker til dashboards i denne organisasjonen vil kunne n?s av brukere som ikke er innlogget i grafana.
3.2.1 Endring i tilgangsstyring
Vi ser behovet for ? endre tilgangsstyring nevnt ovenfor slik at det blir enda lettere dele ?dashboard? mellom USIT organisasjoner. ITI-DIA oppretter en mappe for hver USIT organisasjon under grafana-organisasjonen ?usit?. Eksisterende dashboards som er opprettet under grafana-organisasjoner importeres til disse mappene. Dashboardene blir tatt backup av daglig. Samtlige i ldapgruppen ?usit? skal f? skrivetilgang til grafana-organisasjonen ?usit?. Brukere av grafana oppfordres til ? opprette nye dashboard under disse mapper. Om det er behov for ? skjerme en dashboard fra andre brukere i ?usit?, kan man fortsatt bruke sin grafana-organisasjon for det form?let.
Notat
Dersom man _er_ innlogget, m? man bytte organisasjon til ?public? for ? se dashboards som er definert i der.
Notat
Husk ? ikke legge dashboards i public som skal skjermes mot innsyn fra ikke-innloggede brukere.
Notat
Dersom man ikke har tilgang til grafana men ?nsker dette, kan man sende en henvendelse til: usit-gid@usit.uio.no
Grafana for UiO-metrics er p?: https://grafana.uio.no/
Dokumentasjon av grafana finnes p?: http://grafana.org/
4 Sending av metriske data
F?r man kan sende metriske data, trenger vi ?pning p? brannmuren p? carbon-input.uio.no. Man trenger ? opprette en rt-sak med ip adressen til kilde maskinen p? iti/dia k?en: usit-gid@usit.uio.no
4.1 Bash eksempel
PORT=2023
SERVER=carbon-input.uio.no
echo "test.demo.temp 30 `date +%s`" | nc ${SERVER} ${PORT}
4.2 Powershell eksempel
#Set the Graphite carbon server location and port number
$carbonServer = "carbon-input.uio.no"
$carbonServerPort = 2023
#Get Unix epoch Time
$epochTime=[int]((get-date (get-date).ToUniversalTime() -UFormat "%s").split(",")[0])
#Putting some value here
$value = 1000000
$metric = ("test.demo.temp " + $value + " " + $epochTime)
#Stream results to the Carbon server
$socket = New-Object System.Net.Sockets.TCPClient
$socket.connect($carbonServer, $carbonServerPort)
$stream = $socket.GetStream()
$writer = new-object System.IO.StreamWriter($stream) #Write out metric to the stream.
$writer.WriteLine($metric)
$writer.Flush() #Flush and write our metrics.
$writer.Close()
$stream.Close()
4.2 Python eksempel
import socket
import time
timestamp = int(time.time())
sock = socket.socket()
sock.connect("carbon-input.uio.no",2023)
message = "test.demo.temp 30 %d\n" %(timestamp)
sock.sendall(message)
sock.close()
5 Driftsdokumentasjon/tips
5.1 Resizing av whisper-filer
Graphite lagrer inkommende data i et format (whisper). Det er de underliggende whisper-filene som styrer data-retention og aggregering over tid. Whisper-filer blir automatisk opprettet n?r data for en ny m?leverdi sendes til carbon. Filer blir opprettet med retention-/aggration-skjema som er definert i /opt/graphite/conf/storage-schemas.conf
Dersom man ?nsker ? endre skjema i etterkant, kan man bruke verkt?yet /opt/graphite/bin/whisper-resize.py, f.eks. slik:
find $dir_with_whisper_files -type f -name \*.wsp -exec /opt/graphite/bin/whisper-resize.py --nobackup {} 60s:14d 15m:90d 30m:180d 1h:2y \;
Her endres filene til f?lgende oppl?sninger:
- 60 sekunder de siste to ukene (14 dager)
- 15 minutter de siste 90 dager
- 30 minutter de siste 180 dager
- 1 time de siste 2 ?r
Kan gj?res mens carbon-cache.py kj?rer. Eventuelle data i filene blir beholdt etter resizing. Dette gj?res ved at original fil kopieres til fil.bkp og dat overf?res fra denne til nyopprettet fil med annen oppl?sning. Dersom man beholde backup-filen kan opsjonen --nobackup droppes.