Nipid metrikate töötlemiseks Kapacitoris

Tänapäeval ei küsi tõenäoliselt keegi, miks on oluline koguda teenuste mõõdikute andmeid. Järgmine mõistlik samm on seadistada mõõdikute alerte, mis teavitavad teid mistahes andmete kõrvalekalletest mugavates kanales (meil, Slack, Telegram). Hotellide veebibroneerimisteenus Ostrovok.ru kõik meie teenuste mõõdikud suunatakse InfluxDB-sse ja kuvatakse Grafanas, kus on ka seadistatud põhialert. Selliste ülesannete jaoks nagu "peab midagi arvutama ja selle võrreldama" kasutame Kapacitorit.

Kapacitor on osa TICK-stakist, mis suudab töödelda mõõdikuid InfluxDB-st. Ta suudab ühendada mitmeid mõõtmisi (join), arvutada saadud andmetest midagi kasulikku, kirjutada tulemuse tagasi InfluxDB-sse ning saata alerte Slacki, Telegrami või meilile.

Kogu stack on väga äge ja detailne dokumentatsiooni, kuid alati leidub kasulikke asju, mis ei ole aruannetes selgelt välja toodud. Selles artiklis otsustasin kokku koguda mitmeid selliseid kasulikke, kuid mitte alati ilmseid näpunäiteid (TICKscripti põhisintra on kirjeldatud siit) ja näidata, kuidas neid rakendada meie ühe ülesande näitel.

Lähme!

float & int, arvutusvead

Äärmiselt tavaline probleem, millega saab hakkama castimisega:

var alert_float = 5.0
var alert_int = 10
data|eval(lambda: float("value") > alert_float OR float("value") < float("alert_int"))

default() kasutamine

Kui sildid/väljad ei ole täidetud, tekivad arvutusvead:

|default()
        .tag('status', 'empty')
        .field('value', 0)

fill joinis (inner vs outer)

Vaikimisi loob join punkte, kus andmed puuduvad (inner).
fill('null') korral toimub outer join, mille järel tuleb teha default() ja täita tühjad väärtused:

var data = res1
    |join(res2)
        .as('res1', 'res2')
        .fill('null')
    |default()
        .field('res1.value', 0.0)
        .field('res2.value', 100.0)

Siin on siiski nüanss. Kui ülaltoodud näites on üks seeriatest (res1 või res2) tühi, on ka lõppseeria (data) tühi. Selle teemal on mitu tiketit GitHubis (1633, 1871, 6967) – ootame parandusi ja veidi kannatame.

Tingimuste kasutamine arvutustes (if lambda-s)

|eval(lambda: if("value" > 0, true, false)

Viimased viis minutit pipe'ist ajavahemikul

Näiteks, kui peate võrreldama viimase viie minuti väärtusi eelmise nädalaga. Võite võtta kaks andmepartiid kaht erineva batch'iga või välja võtta osa andmeid suuremast ajavahemikust:

 |where(lambda: duration((unixNano(now()) - unixNano("time")) / 1000, 1u) < 5m)

Viimaste viie minuti alternatiiviks võib olla BarrierNode'i kasutamine, mis katkestab andmed enne määratud aega:

|barrier()
        .period(5m)

Go malle kasutamise näited message'is

Mallid vastavad paketi vormingule text.template, allpool on mõned sagedamini esinevad ülesanded.

if-else

Teeme korda, mitte ei häiri inimesi tekstiga liigse kordamisega:

|alert()
    ...
    .message(
        '{{ if eq .Level "OK" }}Nüüd on kõik korras{{ else }}Pea, kõik on katki{{end}}'
    )

Kaks tähtsust koma järel message'is

Parandame sõnumi loetavust:

|alert()
    ...
    .message(
        'nüüdne väärtus on {{ index .Fields "value" | printf "%0.2f" }}'
    )

Muuttujate lahtimuukimine message'is

Kuvame sõnumis rohkem teavet küsimusele "Miks see kisa teeb?"

var warnAlert = 10
  |alert()
    ...
    .message(
       'Täna väärtus vähem kui ' + string(warnAlert) + '%'
    )

Alerdi unikaalne identifikaator

Oluline asi, kui andmetes on rohkem kui üks grupp, vastasel juhul genereeritakse ainult üks alert:

|alert()
      ...
      .id('{{ index .Tags "myname" }}/{{ index .Tags "myfield" }}')

Kohandatud handler'id

Pikas handler'ite loendis on exec, mis võimaldab käivitada oma skripti edastatud parameetritega (stdin) – puhas looming!

Üks meie kohandustest on väike Python'i skript, et saata teateid Slacki.
Algselt soovisime saata sõnumis pildi Grafanast, mis on kaitstud autentimisega. Hiljem – kirjutada OK eelmise alerdi teema alla, mitte eraldi sõnumina. Veel hiljem – lisada sõnumisse kõige sagedasem viga viimase X minuti jooksul.

Eriline teema on seos teiste teenustega ja kõik tegevused, mis alerdi tõttu algatatakse (ainult juhul, kui teie jälgimine töötab piisavalt hästi).
Näide handleri kirjelduse kohta, kus slack_handler.py on meie enda skript:

topic: slack_graph
id: slack_graph.alert
match: level() != INFO AND changed() == TRUE
kind: exec
options:
  prog: /sbin/slack_handler.py
  args: ["-c", "CHANNELID", "--graph", "--search"]

Kuidas vigade leidmine?

Variant logi väljundiga

|log()
      .level("error")
      .prefix("something")

Vaata (cli): kapacitor -url host-or-ip:9092 logs lvl=error

HTTPOut variant

Kuvab andmeid praeguses pipe'is:

|httpOut('something')

Vaata (get): host-or-ip:9092/kapacitor/v1/tasks/task_name/something

Täitev skeem

• Iga ülesanne tagastab täitmispuu kasulike numbritega vormingus graphviz.
• Võtame ploki dot.
• Kinnita pildile, naudi.

Kust saab veel timestamp'i infl dö vat?

timestamp InfluxDB-s, kui see on tagurpidi

Näiteks seadistame hoiatuse tundide põhjal tehtud päringute summa (groupBy(1h)) ja soovime salvestada juhtunud hoiatuse influxdb-s (et ilusasti näidata probleemide olemasolu graafikul grafanas).

influxDBOut() salvestab timestampi väärtuse alertist, seega salvestatakse punkt graafikus varem/hiljem, kui hoiatuse aeg saabus.

Kui on vajalik täpsus: lahendame selle probleemi kohandatud handler'i kutsumise kaudu, mis salvestab andmed influxdb-s koos praeguse timestamp'iga.

docker, koostamine ja juurutamine

Kapacitor'i käivitamisel saab see laadida ülesandeid, malle ja handler'e kaustast, mis on määratud konfiguraatoris, blokis [load].

Ülesande korrektseks loomiseks on vajalikud järgmised asjad:

1. Failinimi – muutub id/skripti nimeks
2. Tüüp – stream/batch
3. dbrp – märksõna skripti töötamiseks millises andmebaasis + poliitikas (dbrp "supplier"."autogen")

Kui mõnes batch-ülesandes puudub dbrp rida, keeldub kogu teenus käivitumisest ja kirjutab sellest ausalt logisse.

Chronograf'is ei tohi see rida olla, läbi liidese ei aktsepteerita seda ja see annab veateate.

Konteineri koostamise hack: Dockerfile väljub -1-ga, kui on rea //.+dbrp, mis aitab kohe mõista, miks buildi koostamisel tõrge tekkis.

join üks paljudele

Näidisülesanne: tuleb võtta teenuse tööaja 95. percentiil nädalas, võrrelda iga viimase 10 minuti väärtust selle näitajaga.

Ei ole võimalik teha join üks paljudele, last/mean/median rühmade punktide põhjal muudab nodi stream'iks, tagastatakse viga "cannot add child mismatched edges: batch -> stream".

Batch'i tulemust, nagu muutuja lambda väljendis, ei saa samuti kasutada.

On võimalus salvestada esimesest batch'ist vajalikud numbrid faili läbi udf ja laadida see fail läbi sideload.

Mida me sellega lahendasime?

Meil on umbes 100 hotellipakkujat, igal neist võib olla mitu ühendust, nimetame seda kanaliks. Neid kanaleid on umbes 300, iga kanal võib ebaõnnestuda. Kõiki salvestatud mõõdikuid jälgime veatehte määra (requests ja errors).

Miks mitte grafana?

Grafanas seadistatud veateated omavad mitmeid miinuseid. Mõned on kriitilised, mõnedest võib mööda vaadata, sõltuvalt olukorrast.

Grafana ei oska teha arvutusi mõõtmiste vahel + häirete seadistamine, aga meil on vajalik määr (requests-errors)/requests.

Vead näevad välja kohutavad:

Ja vähem kohutavad, kui vaadata edukate päringute kontekstis:

Okei, me saame eelnevalt määrata määr teenuses enne grafanat, ja mõnes olukorras see sobib. Aga mitte meie puhul, sest iga kanali jaoks arvutatakse "normaalne" suhe eraldi ning hoiatuste seadistused toimivad staatiliste väärtuste alusel (otsime silmadega, muudame, kui liiga tihti hoiatustele reageerime).

Need on näiteks "normaalsed" näitajad erinevate kanalite jaoks:

Jätame eelneva punkti tähelepanuta ja eeldame, et kõikide pakkujate "normaalne" olukord on sarnane. Nüüd on kõik hästi, ja saame jätkata grafanas hoiatustega?
Saame, aga ei taha, kuna tuleb valida üks variantidest:
a) teha palju graafikuid igale kanalile eraldi (ja vaeva näha nende hooldamisega)
b) jätta üks graafik koos kõigi kanalitega (ja eksida värviliste joonte ja seadistatud hoiatuste seas)

Kuidas tegime?

Jällegi, dokumentatsioonis on hea algnäide (Calculating rates across joined series), mida saab vaadata või kasutada sarnastes ülesannetes.

Mida lõpuks tegime:

• liitmine kahe seeria vahel mitme tunni jooksul, rühmitamine kanalite põhjal;
• täidame seeriaid rühmade järgi, kui andmeid ei olnud;
• võrdleme viimase 10 minuti mediaani varasemate andmetega;
• karjume, kui midagi avastame;
• salvestame arvutatud määrad ja juhtunud hoiad influxdb-s;
• saadame kasuliku sõnumi slack'i.

Minu arvates suutsime saavutada kõik, mida soovisime saavutada (ja isegi natuke rohkem kohandatud käsitsemistega).

GitHub.com-is saab vaadata näidis kood ja minimaalne skeem (graphviz) saadud skriptist.

Edasi liikuv koodi näidis:

dbrp "supplier"."autogen"
var name = 'requests.rate'
var grafana_dash = 'pczpmYZWU/mydashboard'
var grafana_panel = '26'
var period = 8h
var todayPeriod = 10m
var every = 1m
var warnAlert = 15
var warnReset = 5
var reqQuery = 'SELECT sum("count") AS value FROM "supplier"."autogen"."requests"'
var errQuery = 'SELECT sum("count") AS value FROM "supplier"."autogen"."errors"'

var prevErr = batch
 |query(errQuery)
 .period(period)
 .every(every)
 .groupBy(1m, 'channel', 'supplier')

var prevReq = batch
 |query(reqQuery)
 .period(period)
 .every(every)
 .groupBy(1m, 'channel', 'supplier')

var rates = prevReq
 |join(prevErr)
 .as('req', 'err')
 .tolerance(1m)
 .fill('null')
 // täidame nullidega, kui neid polnud
 |default()
 .field('err.value', 0.0)
 .field('req.value', 0.0)
 // if lambda: arvutame reitingu, ainult kui vigu on olnud
 |eval(lambda: if("err.value" > 0, 100.0 * (float("req.value") - float("err.value")) / float("req.value"), 100.0))
 .as('rate')

// salvestame arvutatud väärtused influxisse
rates
 |influxDBOut()
 .quiet()
 .create()
 .database('kapacitor')
 .retentionPolicy('autogen')
 .measurement('rates')

// valime andmed viimase 10 minuti jooksul, arvutame mediaani
var todayRate = rates
 |where(lambda: duration((unixNano(now()) - unixNano("time")) / 1000, 1u)  warnAlert)
 .warnReset(lambda: ("prev.median" - "today.median") < warnReset)
 .flapping(0.25, 0.5)
 .stateChangesOnly()
 // kogume sõnumisse lingi grafana dashboardi graafikule
 .message(
 '{{ .Level }}: {{ index .Tags "channel" }} veaga / päringute suhe ({{ index .Tags "supplier" }})
{{ if eq .Level "OK" }}Nüüd on kõik korras{{ else }}
'+string(todayPeriod)+' mediaan on {{ index .Fields "today.median" | printf "%0.2f" }}%, eelmise '+string(period)+' puhul on {{ index .Fields "prev.median" | printf "%0.2f" }}%{{ end }}
http://grafana.ostrovok.in/d/'+string(grafana_dash)+'
?var-supplier={{ index .Tags "supplier" }}&var-channel={{ index .Tags "channel" }}&panelId='+string(grafana_panel)+'&fullscreen&tz=UTC0300'
 )
 .id('{{ index .Tags "name" }} / {{ index .Tags "channel" }}')
 .levelTag('level')
 .messageField('message')
 .durationField('duration')
 .topic('slack_graph')

// "today.median" dubleerime kui "value", samuti kirjutame influxisse ülejäänud alerte väljad (keep)
trigger
 |eval(lambda: "today.median")
 .as('value')
 .keep()
 |influxDBOut()
 .quiet()
 .create()
 .database('kapacitor')
 .retentionPolicy('autogen')
 .measurement('alerts')
 .tag('alertName', name)

A millisei?

Kapacitor oskab suurpäraselt tegelema jälgimise ja häiretega, luues arvukalt rühmitusi, tehes täiendavaid arvutusi juba salvestatud mõõdikute põhjal, viies läbi kohandatud toiminguid ja käivitades skripte (udf).

Sisenemislävi pole kuigi kõrge – proovige seda, kui Grafana või muud tööriistad ei rahulda teid täielikult.

Allikas: habr.com