ხრიკები მეტრიკის დამუშავებისთვის Capacitor-ში

სავარაუდოდ, დღეს არავინ კითხულობს, რატომ არის საჭირო სერვისის მეტრიკის შეგროვება. შემდეგი ლოგიკური ნაბიჯი არის შეგროვებული მეტრიკის გაფრთხილების დაყენება, რომელიც შეგატყობინებთ თქვენთვის მოსახერხებელ არხებში (ფოსტა, Slack, Telegram) მონაცემებში რაიმე გადახრის შესახებ. სასტუმროს ონლაინ დაჯავშნის სერვისში Ostrovok.ru ჩვენი სერვისების ყველა მეტრიკა შეედინება InfluxDB-ში და ნაჩვენებია Grafana-ში და ძირითადი გაფრთხილება ასევე კონფიგურირებულია იქ. ისეთი ამოცანებისთვის, როგორიცაა „თქვენ უნდა გამოთვალოთ რაღაც და შეადაროთ მას“, ჩვენ ვიყენებთ Kapacitor-ს.

Capacitor არის TICK სტეკის ნაწილი, რომელსაც შეუძლია მეტრიკის დამუშავება InfluxDB-დან. მას შეუძლია დააკავშიროს რამდენიმე გაზომვა ერთად (შეუერთდეს), გამოთვალოს რაიმე სასარგებლო მიღებული მონაცემებიდან, დაწეროს შედეგი InfluxDB-ში, გაგზავნოს გაფრთხილება Slack/Telegram/mail-ზე.

მთელი დასტა მაგარი და დეტალურია დოკუმენტაცია, მაგრამ ყოველთვის იქნება სასარგებლო რამ, რაც ცალსახად არ არის მითითებული სახელმძღვანელოებში. ამ სტატიაში გადავწყვიტე შემეგროვებინა მრავალი ასეთი სასარგებლო, არა აშკარა რჩევა (აღწერილია TICKscipt-ის ძირითადი სინტაქსი აქ) და აჩვენეთ, თუ როგორ შეიძლება მათი გამოყენება ჩვენი ერთ-ერთი პრობლემის გადაჭრის მაგალითის გამოყენებით.

მოდით წავიდეთ!

float & int, გაანგარიშების შეცდომები

აბსოლუტურად სტანდარტული პრობლემა, მოგვარებული კასტების საშუალებით:

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

ნაგულისხმევი () გამოყენება

თუ ტეგი/ველი არ არის შევსებული, წარმოიქმნება გაანგარიშების შეცდომები:

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

შეერთების შევსება (შიდა და გარე)

ნაგულისხმევად, შეერთება გააუქმებს წერტილებს, სადაც მონაცემები არ არის (შიდა).
Fill('null')-ით შესრულდება გარე შეერთება, რის შემდეგაც თქვენ უნდა გააკეთოთ ნაგულისხმევი() და შეავსოთ ცარიელი მნიშვნელობები:

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

აქ ჯერ კიდევ არის ნიუანსი. ზემოთ მოცემულ მაგალითში, თუ ერთ-ერთი სერია (res1 ან res2) ცარიელია, შედეგად მიღებული სერია (მონაცემები) ასევე ცარიელი იქნება. ამ თემაზე რამდენიმე ბილეთია Github-ზე (1633, 1871, 6967) – ველოდებით გამოსწორებას და ცოტა ტანჯვას.

პირობების გამოყენება გამოთვლებში (თუ ლამბდაში)

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

ბოლო ხუთი წუთი მილსადენიდან იმ პერიოდისთვის

მაგალითად, თქვენ უნდა შეადაროთ ბოლო ხუთი წუთის მნიშვნელობები წინა კვირას. შეგიძლიათ აიღოთ მონაცემების ორი პარტია ორ ცალკეულ პარტიაში ან ამოიღოთ მონაცემების ნაწილი უფრო დიდი პერიოდიდან:

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

ბოლო ხუთი წუთის ალტერნატივა იქნება BarrierNode-ის გამოყენება, რომელიც წყვეტს მონაცემებს მითითებულ დრომდე:

|barrier()
        .period(5m)

Go შაბლონების გამოყენების მაგალითები შეტყობინებაში

შაბლონები შეესაბამება ფორმატს პაკეტიდან ტექსტი.თარგიქვემოთ მოცემულია რამდენიმე ხშირად ნაცნობი თავსატეხი.

თუ კიდევ

ჩვენ წესრიგში ვაყენებთ საკითხებს და არ ვაქცევთ ადამიანებს ტექსტით კიდევ ერთხელ:

|alert()
    ...
    .message(
        '{{ if eq .Level "OK" }}It is ok now{{ else }}Chief, everything is broken{{end}}'
    )

ორი ციფრი ათწილადის შემდეგ შეტყობინებაში

შეტყობინების წაკითხვის გაუმჯობესება:

|alert()
    ...
    .message(
        'now value is {{ index .Fields "value" | printf "%0.2f" }}'
    )

ცვლადების გაფართოება შეტყობინებაში

ჩვენ ვაჩვენებთ დამატებით ინფორმაციას შეტყობინებაში, რათა ვუპასუხოთ კითხვას „რატომ ყვირის“?

var warnAlert = 10
  |alert()
    ...
    .message(
       'Today value less then '+string(warnAlert)+'%'
    )

გაფრთხილების უნიკალური იდენტიფიკატორი

ეს აუცილებელია, როდესაც მონაცემებში არის ერთზე მეტი ჯგუფი, წინააღმდეგ შემთხვევაში მხოლოდ ერთი გაფრთხილება იქნება გენერირებული:

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

მორგებული დამმუშავებლის

დამმუშავებლების დიდ სიაში შედის exec, რომელიც საშუალებას გაძლევთ შეასრულოთ თქვენი სკრიპტი გავლილი პარამეტრებით (stdin) - კრეატიულობა და მეტი არაფერი!

ჩვენი ერთ-ერთი ჩვეულებაა პითონის პატარა სკრიპტი Slack-ისთვის შეტყობინებების გაგზავნისთვის.
თავდაპირველად, გვინდოდა გამოგვეგზავნა ავტორიზაციით დაცული გრაპანის სურათი შეტყობინებაში. ამის შემდეგ, ჩაწერეთ OK თემაში იმავე ჯგუფის წინა გაფრთხილებაში და არა ცალკე მესიჯად. ცოტა მოგვიანებით - დაამატეთ შეტყობინებას ყველაზე გავრცელებული შეცდომა ბოლო X წუთში.

ცალკე თემაა კომუნიკაცია სხვა სერვისებთან და ნებისმიერი ქმედება, რომელიც ინიცირებულია გაფრთხილებით (მხოლოდ იმ შემთხვევაში, თუ თქვენი მონიტორინგი საკმარისად მუშაობს).
დამმუშავებლის აღწერილობის მაგალითი, სადაც slack_handler.py არის ჩვენი თვითდაწერილი სკრიპტი:

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"]

როგორ გავასწოროთ ხარვეზები?

ვარიანტი ჟურნალის გამოყვანით

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

Watch (cli): capacitor -url მასპინძელი ან IP:9092 ჟურნალი lvl=შეცდომა

ვარიანტი httpOut-ით

აჩვენებს მონაცემებს მიმდინარე მილსადენში:

|httpOut('something')

უყურე (მიიღე): მასპინძელი ან IP:9092/kapacitor/v1/tasks/task_name/something

შესრულების სქემა

• თითოეული დავალება აბრუნებს შესრულების ხეს ფორმატში გამოსადეგი რიცხვებით გრაფივი.
• აიღეთ ბლოკი dot.
• ჩასვით მაყურებელში, ისიამოვნეთ.

კიდევ სად შეიძლება საკომისიო შოვნა?

დროის ანაბეჭდი influxdb-ში ჩაწერაზე

მაგალითად, ჩვენ დავაყენეთ გაფრთხილება საათში მოთხოვნების ჯამისთვის (groupBy(1h)) და გვინდა ჩავწეროთ გაფრთხილება, რომელიც მოხდა influxdb-ში (გრაფანაში გრაფიკზე პრობლემის ფაქტის ლამაზად ჩვენების მიზნით).

influxDBOut() დაწერს დროის მნიშვნელობას გაფრთხილებიდან დროის ნიშნულამდე; შესაბამისად, ჩარტზე წერტილი დაიწერება ადრე/გვიან, ვიდრე გაფრთხილება მოვიდა.

როდესაც საჭიროა სიზუსტე: ჩვენ ვმუშაობთ ამ პრობლემის მოგვარებაზე მორგებული დამმუშავებლის გამოძახებით, რომელიც ჩაწერს მონაცემებს influxdb-ში მიმდინარე დროის ნიშნულით.

დოკერი, აშენება და განლაგება

გაშვებისას, capacitor-ს შეუძლია ჩაიტვირთოს ამოცანები, შაბლონები და დამმუშავებლები დირექტორიადან, რომელიც მითითებულია კონფიგურაციაში [load] ბლოკში.

დავალების სწორად შესაქმნელად დაგჭირდებათ შემდეგი რამ:

1. ფაილის სახელი – გაფართოვდა სკრიპტის ID/სახელად
2. ტიპი - ნაკადი / პარტია
3. dbrp – საკვანძო სიტყვა, რომელიც მიუთითებს, რომელ მონაცემთა ბაზაში + პოლიტიკაში მუშაობს სკრიპტი (dbrp „მომწოდებელი“ „ავტოგენი“)

თუ ზოგიერთი ჯგუფის ამოცანა არ შეიცავს ხაზს dbrp-ით, მთელი სერვისი უარს იტყვის დაწყებაზე და გულახდილად დაწერს ამის შესახებ ჟურნალში.

ქრონოგრაფში, პირიქით, ეს ხაზი არ უნდა არსებობდეს, ის არ მიიღება ინტერფეისის საშუალებით და წარმოქმნის შეცდომას.

ჰაკი კონტეინერის აგებისას: Dockerfile გამოდის -1-ით, თუ არის ხაზები //.+dbrp, რაც საშუალებას მოგცემთ დაუყოვნებლივ გაიგოთ წარუმატებლობის მიზეზი build-ის აწყობისას.

შეუერთდი ერთს ბევრს

დავალების მაგალითი: თქვენ უნდა აიღოთ სერვისის მუშაობის დროის 95-ე პროცენტი ერთი კვირის განმავლობაში, შეადარეთ ბოლო 10 წუთი ამ მნიშვნელობას.

თქვენ არ შეგიძლიათ შეერთება ერთიდან ბევრზე, ბოლო/საშუალო/მედიანი პუნქტების ჯგუფზე აქცევს კვანძს ნაკადად, დაბრუნდება შეცდომა „ვერ დავამატებ ბავშვის შეუსაბამო კიდეებს: პარტია -> ნაკადი“.

ჯგუფის შედეგი, როგორც ცვლადი ლამბდა გამოხატულებაში, ასევე არ არის ჩანაცვლებული.

არსებობს შესაძლებლობა შეინახოთ საჭირო ნომრები პირველი პარტიიდან ფაილში udf-ის საშუალებით და ჩატვირთოთ ეს ფაილი sideload-ის საშუალებით.

რა გადავწყვიტეთ ამით?

ჩვენ გვყავს 100-მდე სასტუმროს მომწოდებელი, თითოეულ მათგანს შეიძლება ჰქონდეს რამდენიმე კავშირი, მოდით ამას არხი ვუწოდოთ. დაახლოებით 300 ასეთი არხია, თითოეული არხი შეიძლება ჩამოვარდეს. ყველა ჩაწერილი მეტრიკიდან ჩვენ დავაკვირდებით შეცდომის სიხშირეს (მოთხოვნებს და შეცდომებს).

რატომ არა გრანა?

Grafana-ში კონფიგურირებულ შეცდომის სიგნალებს რამდენიმე უარყოფითი მხარე აქვს. ზოგიერთი კრიტიკულია, ზოგზე შეგიძლიათ თვალები დახუჭოთ, სიტუაციიდან გამომდინარე.

გრაფანამ არ იცის როგორ გამოთვალოს გაზომვებს შორის + გაფრთხილება, მაგრამ ჩვენ გვჭირდება მაჩვენებელი (მოთხოვნები-შეცდომები)/მოთხოვნები.

შეცდომები საზიზღრად გამოიყურება:

და ნაკლები ბოროტება, როდესაც განიხილება წარმატებული მოთხოვნებით:

კარგი, ჩვენ შეგვიძლია წინასწარ გამოვთვალოთ ტარიფი სერვისში გრაპანამდე და ზოგიერთ შემთხვევაში ეს იმუშავებს. მაგრამ არა ჩვენში, რადგან... თითოეული არხისთვის საკუთარი თანაფარდობა ითვლება "ნორმალურად" და სიგნალიზაცია მუშაობს სტატიკური მნიშვნელობების მიხედვით (ჩვენ ვეძებთ მათ ჩვენი თვალით, ვცვლით მათ, თუ ხშირია გაფრთხილებები).

ეს არის მაგალითები "ნორმალური" სხვადასხვა არხისთვის:

ჩვენ უგულებელყოფთ წინა პუნქტს და ვვარაუდობთ, რომ "ნორმალური" სურათი მსგავსია ყველა მომწოდებლისთვის. ახლა ყველაფერი კარგადაა და შეგვიძლია გრაფანაში გაფრთხილებებით გავუმკლავდეთ?
ჩვენ შეგვიძლია, მაგრამ ნამდვილად არ გვინდა, რადგან უნდა ავირჩიოთ ერთ-ერთი ვარიანტი:
ა) გააკეთეთ ბევრი გრაფიკი თითოეული არხისთვის ცალკე (და მტკივნეულად ახლდით მათ)
ბ) დატოვეთ ერთი სქემა ყველა არხთან (და დაიკარგეთ ფერად ხაზებსა და მორგებულ სიგნალებში)

Როგორ გააკეთე?

კიდევ ერთხელ, არის კარგი საწყისი მაგალითი დოკუმენტაციაში (ტარიფების გამოთვლა შეერთებულ სერიებში), შეიძლება გამოიყურებოდეს ან მივიღოთ საფუძვლად მსგავს პრობლემებში.

რა გავაკეთეთ ბოლოს:

• შეუერთდი ორ სერიას რამდენიმე საათში, არხების მიხედვით დაჯგუფება;
• შეავსეთ სერიები ჯგუფის მიხედვით, თუ მონაცემები არ იყო;
• შეადარეთ ბოლო 10 წუთის მედიანა წინა მონაცემებთან;
• ვყვირით, თუ რამეს ვიპოვით;
• ჩვენ ვწერთ გამოთვლილ ტარიფებს და სიგნალებს, რომლებიც მოხდა influxdb-ში;
• გაუგზავნეთ სასარგებლო შეტყობინება slack-ს.

ჩემი აზრით, ჩვენ შევძელით რაც შეიძლება ლამაზად მივაღწიოთ ყველაფერს, რისი მიღწევაც გვინდოდა ბოლოს (და კიდევ ცოტა მეტი საბაჟო დამმუშავებლებით).

შეგიძლიათ ნახოთ github.com კოდის მაგალითი и მინიმალური წრე (გრაფიზი) შედეგად მიღებული სკრიპტი.

შედეგად მიღებული კოდის მაგალითი:

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')
    // заполняем значения нулями, если их не было
    |default()
        .field('err.value', 0.0)
        .field('req.value', 0.0)
    // if в lambda: считаем рейт, только если ошибки были
    |eval(lambda: if("err.value" > 0, 100.0 * (float("req.value") - float("err.value")) / float("req.value"), 100.0))
        .as('rate')

// записываем посчитанные значения в инфлюкс
rates
    |influxDBOut()
        .quiet()
        .create()
        .database('kapacitor')
        .retentionPolicy('autogen')
        .measurement('rates')

// выбираем данные за последние 10 минут, считаем медиану
var todayRate = rates
    |where(lambda: duration((unixNano(now()) - unixNano("time")) / 1000, 1u) < todayPeriod)
    |median('rate')
        .as('median')

var prevRate = rates
    |median('rate')
        .as('median')

var joined = todayRate
    |join(prevRate)
        .as('today', 'prev')
    |httpOut('join')

var trigger = joined
    |alert()
        .warn(lambda: ("prev.median" - "today.median") > warnAlert)
        .warnReset(lambda: ("prev.median" - "today.median") < warnReset)
        .flapping(0.25, 0.5)
        .stateChangesOnly()
        // собираем в message ссылку на график дашборда графаны
        .message(
            '{{ .Level }}: {{ index .Tags "channel" }} err/req ratio ({{ index .Tags "supplier" }})
{{ if eq .Level "OK" }}It is ok now{{ else }}
'+string(todayPeriod)+' median is {{ index .Fields "today.median" | printf "%0.2f" }}%, by previous '+string(period)+' is {{ 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=UTC%2B03%3A00'
        )
        .id('{{ index .Tags "name" }}/{{ index .Tags "channel" }}')
        .levelTag('level')
        .messageField('message')
        .durationField('duration')
        .topic('slack_graph')

// "today.median" дублируем как "value", также пишем в инфлюкс остальные филды алерта (keep)
trigger
    |eval(lambda: "today.median")
        .as('value')
        .keep()
    |influxDBOut()
        .quiet()
        .create()
        .database('kapacitor')
        .retentionPolicy('autogen')
        .measurement('alerts')
        .tag('alertName', name)

რა არის დასკვნა?

Kapacitor შესანიშნავად ახორციელებს მონიტორინგ-გაფრთხილებებს დაჯგუფების თაიგულთან ერთად, ახორციელებს დამატებით გამოთვლებს უკვე ჩაწერილი მეტრიკის საფუძველზე, ახორციელებს პერსონალურ მოქმედებებს და აწარმოებს სკრიპტებს (udf).

შესვლის ბარიერი არ არის ძალიან მაღალი - სცადეთ, თუ გრანა ან სხვა ხელსაწყოები სრულად არ დააკმაყოფილებს თქვენს სურვილებს.

წყარო: www.habr.com