ល្បិចសម្រាប់ដំណើរការម៉ែត្រនៅក្នុង Kapacitor

ភាគច្រើនទំនងជាថ្ងៃនេះគ្មាននរណាម្នាក់សួរថាហេតុអ្វីបានជាវាចាំបាច់ដើម្បីប្រមូលរង្វាស់សេវាកម្ម។ ជំហានឡូជីខលបន្ទាប់គឺត្រូវរៀបចំការដាស់តឿនសម្រាប់ម៉ែត្រដែលប្រមូលបាន ដែលនឹងជូនដំណឹងអំពីគម្លាតណាមួយនៅក្នុងទិន្នន័យនៅក្នុងបណ្តាញដែលងាយស្រួលសម្រាប់អ្នក (សំបុត្រ, Slack, Telegram)។ នៅក្នុងសេវាកម្មកក់សណ្ឋាគារតាមអ៊ីនធឺណិត Ostrovok.ru ម៉ែត្រទាំងអស់នៃសេវាកម្មរបស់យើងត្រូវបានចាក់ចូលទៅក្នុង InfluxDB ហើយបង្ហាញនៅក្នុង Grafana ហើយការជូនដំណឹងជាមូលដ្ឋានក៏ត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅទីនោះផងដែរ។ សម្រាប់កិច្ចការដូចជា "អ្នកត្រូវគណនាអ្វីមួយ ហើយប្រៀបធៀបជាមួយវា" យើងប្រើ Kapacitor ។

Kapacitor គឺជាផ្នែកមួយនៃជង់ 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)

បំពេញការចូលរួម (ខាងក្នុងទល់នឹងខាងក្រៅ)

តាមលំនាំដើម ការចូលរួមនឹងបោះបង់ចំណុចដែលមិនមានទិន្នន័យ (ខាងក្នុង)។
ជាមួយនឹងការបំពេញ('null') ការភ្ជាប់ខាងក្រៅនឹងត្រូវបានអនុវត្ត បន្ទាប់ពីនោះអ្នកត្រូវធ្វើ default() ហើយបំពេញតម្លៃទទេ៖

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) - យើងកំពុងរង់ចាំការជួសជុល និងរងទុក្ខបន្តិចបន្តួច។

ការប្រើប្រាស់លក្ខខណ្ឌក្នុងការគណនា (ប្រសិនបើនៅក្នុង lambda)

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

ប្រាំនាទីចុងក្រោយពីបំពង់បង្ហូរប្រេងសម្រាប់រយៈពេលនេះ។

ឧទាហរណ៍ អ្នកត្រូវប្រៀបធៀបតម្លៃនៃប្រាំនាទីចុងក្រោយជាមួយនឹងសប្តាហ៍មុន។ អ្នកអាចយកទិន្នន័យពីរជាបាច់ពីរដាច់ដោយឡែកពីគ្នា ឬទាញយកផ្នែកនៃទិន្នន័យពីរយៈពេលធំជាងនេះ៖

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

ជម្រើសសម្រាប់ XNUMX នាទីចុងក្រោយគឺត្រូវប្រើ 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) - ការច្នៃប្រឌិតនិងគ្មានអ្វីទៀតទេ!

ទំនៀមទម្លាប់មួយរបស់យើងគឺស្គ្រីប Python តូចមួយសម្រាប់ផ្ញើការជូនដំណឹងទៅ slack ។
ដំបូង​ឡើយ យើង​ចង់​ផ្ញើ​រូបភាព Grafana ដែល​មាន​ការ​អនុញ្ញាត​ក្នុង​សារ។ បន្ទាប់មក សរសេរ យល់ព្រម នៅក្នុងខ្សែស្រឡាយ ទៅកាន់ការជូនដំណឹងពីមុនពីក្រុមដូចគ្នា ហើយមិនមែនជាសារដាច់ដោយឡែកនោះទេ។ បន្តិចក្រោយមក - បន្ថែមទៅសារនូវកំហុសទូទៅបំផុតនៅក្នុង 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")

មើល (cli): kapacitor -url host-or-ip: 9092 កំណត់ហេតុ lvl=error

ជម្រើសជាមួយ httpOut

បង្ហាញទិន្នន័យនៅក្នុងបំពង់បង្ហូរបច្ចុប្បន្ន៖

|httpOut('something')

មើល (ទទួលបាន): host-or-ip៖9092/kapacitor/v1/tasks/task_name/អ្វីមួយ

គ្រោងការណ៍ប្រតិបត្តិ

• កិច្ចការនីមួយៗត្រឡប់មែកធាងប្រតិបត្តិដែលមានលេខមានប្រយោជន៍ក្នុងទម្រង់ ក្រាហ្វិច.
• យកប្លុកមួយ។ ចំណុច.
• បិទភ្ជាប់វាទៅក្នុងកម្មវិធីមើល រីករាយ.

តើអ្នកអាចទទួលបានតុងរួចនៅឯណា?

ត្រាពេលវេលានៅក្នុង influxdb នៅលើការសរសេរឡើងវិញ

ឧទាហរណ៍ យើងរៀបចំការជូនដំណឹងសម្រាប់ផលបូកនៃសំណើក្នុងមួយម៉ោង (groupBy(1h)) ហើយចង់កត់ត្រាការដាស់តឿនដែលបានកើតឡើងនៅក្នុង influxdb (ដើម្បីបង្ហាញយ៉ាងស្អាតនូវការពិតនៃបញ្ហានៅលើក្រាហ្វក្នុង grafana)។

influxDBOut() នឹង​សរសេរ​តម្លៃ​ពេលវេលា​ពី​ការ​ជូន​ដំណឹង​ទៅ​កាន់​ពេលវេលា​ អាស្រ័យហេតុនេះ ចំណុច​នៅលើ​គំនូសតាង​នឹង​ត្រូវ​បាន​សរសេរ​មុន/ក្រោយ​ជាង​ការ​ជូន​ដំណឹង​មកដល់។

នៅពេលដែលភាពត្រឹមត្រូវត្រូវបានទាមទារ៖ យើងដោះស្រាយបញ្ហានេះដោយហៅទូរស័ព្ទទៅអ្នកដោះស្រាយផ្ទាល់ខ្លួន ដែលនឹងសរសេរទិន្នន័យទៅ influxdb ជាមួយនឹងត្រាពេលវេលាបច្ចុប្បន្ន។

docker សាងសង់ និងដាក់ពង្រាយ

នៅពេលចាប់ផ្តើម kapacitor អាចផ្ទុកភារកិច្ច គំរូ និងអ្នកដោះស្រាយពីថតដែលបានបញ្ជាក់នៅក្នុងការកំណត់នៅក្នុងប្លុក [ផ្ទុក] ។

ដើម្បី​បង្កើត​កិច្ចការ​បាន​ត្រឹមត្រូវ អ្នក​ត្រូវ​ការ​របស់​ដូច​ខាង​ក្រោម៖

1. ឈ្មោះឯកសារ - ពង្រីកទៅជាលេខសម្គាល់ស្គ្រីប/ឈ្មោះ
2. ប្រភេទ - ស្ទ្រីម / បាច់
3. dbrp - ពាក្យគន្លឹះដើម្បីបង្ហាញពីមូលដ្ឋានទិន្នន័យ + គោលការណ៍ដែលស្គ្រីបដំណើរការ (dbrp "អ្នកផ្គត់ផ្គង់។ ""autogen")

ប្រសិនបើកិច្ចការបាច់មួយចំនួនមិនមានបន្ទាត់ជាមួយ dbrp នោះសេវាកម្មទាំងមូលនឹងបដិសេធមិនចាប់ផ្តើម ហើយនឹងសរសេរអំពីវាដោយស្មោះត្រង់នៅក្នុងកំណត់ហេតុ។

នៅក្នុង chronograf ផ្ទុយទៅវិញ បន្ទាត់នេះមិនគួរមានទេ វាមិនត្រូវបានទទួលយកតាមរយៈចំណុចប្រទាក់ និងបង្កើតកំហុសមួយ។

Hack នៅពេលសាងសង់កុងតឺន័រ៖ Dockerfile ចេញជាមួយ -1 ប្រសិនបើមានបន្ទាត់ជាមួយ //.+dbrp ដែលនឹងអនុញ្ញាតឱ្យអ្នកយល់ភ្លាមៗអំពីហេតុផលសម្រាប់ការបរាជ័យនៅពេលដំឡើងការស្ថាបនា។

ចូលរួមពីមួយទៅច្រើន។

ឧទាហរណ៍កិច្ចការ៖ អ្នកត្រូវយកភាគរយទី 95 នៃពេលវេលាប្រតិបត្តិការរបស់សេវាកម្មសម្រាប់មួយសប្តាហ៍ ប្រៀបធៀបរាល់នាទីនៃ 10 ចុងក្រោយជាមួយនឹងតម្លៃនេះ។

អ្នក​មិន​អាច​ធ្វើ​ការ​ចូល​រួម​មួយ​ទល់​នឹង​ច្រើន​ទេ ចុង​ក្រោយ/មធ្យម/មធ្យម​លើ​ក្រុម​នៃ​ចំណុច​ប្រែ​ក្លាយ​ថ្នាំង​ទៅ​ជា​ស្ទ្រីម កំហុស "មិន​អាច​បន្ថែម​គែម​មិន​ត្រូវ​គ្នា​របស់​កុមារ៖ បាច់ -> ស្ទ្រីម" នឹង​ត្រូវ​បាន​ត្រឡប់​មក​វិញ។

លទ្ធផលនៃបាច់មួយ ជាអថេរនៅក្នុងកន្សោម lambda ក៏មិនត្រូវបានជំនួសដែរ។

មានជម្រើសមួយដើម្បីរក្សាទុកលេខចាំបាច់ពីបាច់ទីមួយទៅឯកសារតាមរយៈ udf ហើយផ្ទុកឯកសារនេះតាមរយៈ sideload ។

តើយើងបានដោះស្រាយអ្វីជាមួយរឿងនេះ?

យើង​មាន​អ្នក​ផ្គត់ផ្គង់​សណ្ឋាគារ​ប្រហែល 100 ដែល​ពួកគេ​ម្នាក់ៗ​អាច​មាន​ការ​តភ្ជាប់​គ្នា​ជាច្រើន​។​ សូម​ហៅ​វា​ថា​ឆានែល។ មានបណ្តាញប្រហែល 300 នៃបណ្តាញទាំងនេះ ឆានែលនីមួយៗអាចធ្លាក់ចុះ។ ក្នុងចំណោមរង្វាស់ដែលបានកត់ត្រាទាំងអស់ យើងនឹងត្រួតពិនិត្យអត្រាកំហុស (សំណើ និងកំហុស)។

ហេតុអ្វីមិន Grafana?

ការជូនដំណឹងអំពីកំហុសដែលបានកំណត់រចនាសម្ព័ន្ធនៅក្នុង Grafana មានគុណវិបត្តិជាច្រើន។ ខ្លះរិះគន់ ខ្លះបិទភ្នែកទៅ អាស្រ័យលើស្ថានភាព។

Grafana មិនដឹងពីរបៀបគណនារវាងការវាស់វែង + ការជូនដំណឹងទេ ប៉ុន្តែយើងត្រូវការអត្រា (requests-errors)/requests។

កំហុសមើលទៅអាក្រក់៖

និង​អាក្រក់​តិច​នៅ​ពេល​បាន​មើល​ជា​មួយ​នឹង​សំណើ​ដែល​ទទួល​បាន​ជោគជ័យ​:

មិនអីទេ យើងអាចគណនាអត្រាការប្រាក់ជាមុននៅក្នុងសេវាកម្មមុន Grafana ហើយក្នុងករណីខ្លះវានឹងដំណើរការ។ ប៉ុន្តែមិនមែននៅក្នុងរបស់យើងទេព្រោះ ... សម្រាប់ឆានែលនីមួយៗ សមាមាត្រផ្ទាល់ខ្លួនរបស់វាត្រូវបានចាត់ទុកថា "ធម្មតា" ហើយការជូនដំណឹងដំណើរការដោយយោងតាមតម្លៃឋិតិវន្ត (យើងរកមើលពួកវាដោយភ្នែករបស់យើង ផ្លាស់ប្តូរពួកវាប្រសិនបើមានការជូនដំណឹងញឹកញាប់)។

ទាំងនេះគឺជាឧទាហរណ៍នៃ "ធម្មតា" សម្រាប់ប៉ុស្តិ៍ផ្សេងៗគ្នា៖

យើងមិនអើពើចំណុចមុន ហើយសន្មតថារូបភាព "ធម្មតា" គឺស្រដៀងគ្នាសម្រាប់អ្នកផ្គត់ផ្គង់ទាំងអស់។ ឥឡូវនេះអ្វីគ្រប់យ៉ាងគឺល្អ ហើយយើងអាចទទួលបានដោយការដាស់តឿននៅក្នុង 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)។

របាំងសម្រាប់ការចូលគឺមិនខ្ពស់ខ្លាំងណាស់ - សាកល្បងវាប្រសិនបើ grafana ឬឧបករណ៍ផ្សេងទៀតមិនបំពេញបំណងប្រាថ្នារបស់អ្នកទាំងស្រុង។

ប្រភព: www.habr.com