Tricks ສໍາລັບການປະມວນຜົນ metrics ໃນ Kapacitor

ສ່ວນຫຼາຍອາດຈະ, ມື້ນີ້ບໍ່ມີໃຜຖາມວ່າເປັນຫຍັງມັນຈໍາເປັນຕ້ອງເກັບກໍາ metrics ການບໍລິການ. ຂັ້ນຕອນຢ່າງມີເຫດຜົນຕໍ່ໄປແມ່ນການຕັ້ງຄ່າການແຈ້ງເຕືອນສໍາລັບ metrics ທີ່ເກັບກໍາ, ເຊິ່ງຈະແຈ້ງໃຫ້ຊາບກ່ຽວກັບການ deviations ໃນຂໍ້ມູນໃນຊ່ອງທາງທີ່ສະດວກສໍາລັບທ່ານ (mail, Slack, Telegram). ໃນການບໍລິການຈອງໂຮງແຮມອອນໄລນ໌ Ostrovok.ru metrics ທັງຫມົດຂອງການບໍລິການຂອງພວກເຮົາແມ່ນ poured ເຂົ້າໄປໃນ InfluxDB ແລະສະແດງໃນ Grafana, ແລະການເຕືອນໄພພື້ນຖານແມ່ນຍັງ configured ຢູ່ທີ່ນັ້ນ. ສໍາລັບວຽກງານເຊັ່ນ "ທ່ານຈໍາເປັນຕ້ອງຄິດໄລ່ບາງສິ່ງບາງຢ່າງແລະປຽບທຽບກັບມັນ," ພວກເຮົາໃຊ້ Kapacitor.

Kapacitor ແມ່ນສ່ວນຫນຶ່ງຂອງ stack TICK ທີ່ສາມາດປະມວນຜົນ metrics ຈາກ InfluxDB. ມັນສາມາດເຊື່ອມຕໍ່ການວັດແທກຈໍານວນຫນຶ່ງຮ່ວມກັນ (ເຂົ້າຮ່ວມ), ຄິດໄລ່ບາງສິ່ງບາງຢ່າງທີ່ເປັນປະໂຫຍດຈາກຂໍ້ມູນທີ່ໄດ້ຮັບ, ຂຽນຜົນໄດ້ຮັບກັບຄືນໄປບ່ອນ InfluxDB, ສົ່ງການແຈ້ງເຕືອນໄປຫາ Slack / Telegram / mail.

stack ທັງຫມົດແມ່ນເຢັນແລະລາຍລະອຽດ ເອກະສານ, ແຕ່ມັນຈະມີສິ່ງທີ່ເປັນປະໂຫຍດທີ່ບໍ່ໄດ້ລະບຸຢ່າງຊັດເຈນຢູ່ໃນຄູ່ມື. ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະລວບລວມຄໍາແນະນໍາທີ່ເປັນປະໂຫຍດ, ທີ່ບໍ່ຊັດເຈນ ( syntax ພື້ນຖານຂອງ 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)

ຕື່ມ​ຂໍ້​ມູນ​ໃສ່​ການ​ເຂົ້າ​ຮ່ວມ (ພາຍ​ໃນ vs ນອກ​)

ໂດຍຄ່າເລີ່ມຕົ້ນ, ການເຂົ້າຮ່ວມຈະຍົກເລີກຈຸດທີ່ບໍ່ມີຂໍ້ມູນ (ພາຍໃນ).
ເມື່ອຕື່ມ ('null') ການເຂົ້າຮ່ວມພາຍນອກຈະຖືກປະຕິບັດ, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງເຮັດຄ່າເລີ່ມຕົ້ນ () ແລະຕື່ມຂໍ້ມູນໃສ່ໃນຄ່າຫວ່າງເປົ່າ:

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

ຍັງມີ nuance ຢູ່ທີ່ນີ້. ໃນຕົວຢ່າງຂ້າງເທິງ, ຖ້າຊຸດຫນຶ່ງ (res1 ຫຼື res2) ຫວ່າງເປົ່າ, ຊຸດຜົນໄດ້ຮັບ (ຂໍ້ມູນ) ກໍ່ຈະຫວ່າງເປົ່າ. ມີຫຼາຍປີ້ກ່ຽວກັບຫົວຂໍ້ນີ້ໃນ Github (1633, 1871, 6967) – ພວກເຮົາກໍາລັງລໍຖ້າການແກ້ໄຂແລະຄວາມທຸກທໍລະມານເລັກນ້ອຍ.

ການນໍາໃຊ້ເງື່ອນໄຂໃນການຄິດໄລ່ (ຖ້າຢູ່ໃນ lambda)

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

ຫ້ານາທີສຸດທ້າຍຈາກທໍ່ສໍາລັບໄລຍະເວລາ

ຕົວຢ່າງ, ທ່ານຈໍາເປັນຕ້ອງປຽບທຽບຄ່າຂອງຫ້ານາທີສຸດທ້າຍກັບອາທິດທີ່ຜ່ານມາ. ທ່ານ​ສາ​ມາດ​ເອົາ​ສອງ​ຊຸດ​ຂອງ​ຂໍ້​ມູນ​ໃນ​ສອງ​ຊຸດ​ແຍກ​ຕ່າງ​ຫາກ​ຫຼື​ເອົາ​ສ່ວນ​ຫນຶ່ງ​ຂອງ​ຂໍ້​ມູນ​ຈາກ​ໄລ​ຍະ​ເວ​ລາ​ທີ່​ໃຫຍ່​ກວ່າ​:

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

ທາງເລືອກສໍາລັບຫ້ານາທີສຸດທ້າຍແມ່ນການນໍາໃຊ້ BarrierNode, ເຊິ່ງຕັດຂໍ້ມູນກ່ອນເວລາທີ່ກໍານົດໄວ້:

|barrier()
        .period(5m)

ຕົວຢ່າງຂອງການໃຊ້ແມ່ແບບ Go ໃນຂໍ້ຄວາມ

ແມ່ແບບກົງກັບຮູບແບບຈາກຊຸດ text.templateຂ້າງລຸ່ມນີ້ແມ່ນບາງເກມແຂ່ງລົດທີ່ພົບເລື້ອຍໆ.

ຖ້າ - ອື່ນໆ

ພວກ​ເຮົາ​ຈັດ​ວາງ​ສິ່ງ​ທີ່​ເປັນ​ລະ​ບຽບ​ແລະ​ບໍ່​ເຮັດ​ໃຫ້​ຄົນ​ທີ່​ມີ​ຂໍ້​ຄວາມ​ອີກ​ເທື່ອ​ຫນຶ່ງ​:

|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, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດ script ຂອງທ່ານດ້ວຍຕົວກໍານົດການຜ່ານ (stdin) - ຄວາມຄິດສ້າງສັນແລະບໍ່ມີຫຍັງອີກ!

ຫນຶ່ງໃນພາສີຂອງພວກເຮົາແມ່ນສະຄິບ Python ຂະຫນາດນ້ອຍສໍາລັບການສົ່ງການແຈ້ງເຕືອນໃຫ້ slack.
ທໍາອິດ, ພວກເຮົາຕ້ອງການສົ່ງຮູບພາບ grafana ທີ່ມີການປົກປ້ອງອະນຸຍາດໃນຂໍ້ຄວາມ. ຫຼັງຈາກນັ້ນ, ຂຽນ 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")

ສັງເກດເບິ່ງ (cli): kapacitor -url host-or-ip:9092 ບັນທຶກ lvl=error

ທາງເລືອກທີ່ມີ httpOut

ສະແດງຂໍ້ມູນໃນທໍ່ປະຈຸບັນ:

|httpOut('something')

ເບິ່ງ (ໄດ້​ຮັບ): host-or-ip:9092/kapacitor/v1/tasks/task_name/ບາງສິ່ງບາງຢ່າງ

ໂຄງ​ການ​ປະ​ຕິ​ບັດ​

• ແຕ່ລະວຽກງານສົ່ງຄືນຕົ້ນໄມ້ການປະຕິບັດທີ່ມີຕົວເລກທີ່ເປັນປະໂຫຍດໃນຮູບແບບ ເສັ້ນສະແດງ.
• ເອົາບລັອກ ຈຸດ.
• ວາງມັນໃສ່ viewer, ມ່ວນ.

ບ່ອນອື່ນທີ່ທ່ານສາມາດໄດ້ຮັບ rake?

ການສະແຕມເວລາໃນ influxdb ໃນການຂຽນຄືນ

ຕົວຢ່າງ, ພວກເຮົາຕັ້ງການແຈ້ງເຕືອນສໍາລັບຜົນລວມຂອງຄໍາຮ້ອງຂໍຕໍ່ຊົ່ວໂມງ (groupBy(1h)) ແລະຕ້ອງການບັນທຶກການແຈ້ງເຕືອນທີ່ເກີດຂຶ້ນໃນ influxdb (ເພື່ອສະແດງໃຫ້ເຫັນຢ່າງສວຍງາມຂອງຄວາມເປັນຈິງຂອງບັນຫາໃນກາຟໃນ grafana).

influxDBOut() ຈະຂຽນຄ່າເວລາຈາກການແຈ້ງເຕືອນເຖິງເວລາ; ຕາມນັ້ນ, ຈຸດໃນຕາຕະລາງຈະຖືກຂຽນກ່ອນ / ຊ້າກວ່າການແຈ້ງເຕືອນມາຮອດ.

ເມື່ອຄວາມຖືກຕ້ອງແມ່ນຕ້ອງການ: ພວກເຮົາແກ້ໄຂບັນຫານີ້ໂດຍການໂທຫາຕົວຈັດການທີ່ກໍາຫນົດເອງ, ເຊິ່ງຈະຂຽນຂໍ້ມູນໃສ່ influxdb ກັບເວລາປະຈຸບັນ.

docker, ການກໍ່ສ້າງແລະການນໍາໃຊ້

ໃນຕອນເລີ່ມຕົ້ນ, kapacitor ສາມາດໂຫລດຫນ້າວຽກ, ແມ່ແບບແລະຕົວຈັດການຈາກໄດເລກະທໍລີທີ່ລະບຸໄວ້ໃນ config ໃນ [ໂຫຼດ] block.

ເພື່ອສ້າງຫນ້າວຽກຢ່າງຖືກຕ້ອງ, ທ່ານຕ້ອງການສິ່ງຕໍ່ໄປນີ້:

1. ຊື່ໄຟລ໌ – ຂະຫຍາຍເປັນ script id/name
2. ປະເພດ – stream/batch
3. dbrp - ຄໍາສໍາຄັນເພື່ອຊີ້ບອກວ່າຖານຂໍ້ມູນ + ນະໂຍບາຍໃດທີ່ສະຄິບດໍາເນີນການ (dbrp "ຜູ້ສະຫນອງ." "autogen")

ຖ້າບາງວຽກ batch ບໍ່ມີເສັ້ນທີ່ມີ dbrp, ບໍລິການທັງຫມົດຈະປະຕິເສດທີ່ຈະເລີ່ມຕົ້ນແລະຈະຂຽນກ່ຽວກັບມັນຢ່າງຊື່ສັດໃນບັນທຶກ.

ໃນ chronograf, ໃນທາງກົງກັນຂ້າມ, ເສັ້ນນີ້ບໍ່ຄວນມີຢູ່; ມັນບໍ່ໄດ້ຮັບການຍອມຮັບໂດຍຜ່ານການໂຕ້ຕອບແລະສ້າງຂໍ້ຜິດພາດ.

Hack ເມື່ອສ້າງຕູ້ຄອນເທນເນີ: Dockerfile ອອກດ້ວຍ -1 ຖ້າມີເສັ້ນທີ່ມີ //.+dbrp, ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈທັນທີກ່ຽວກັບເຫດຜົນຂອງຄວາມລົ້ມເຫຼວໃນເວລາທີ່ປະກອບການກໍ່ສ້າງ.

ເຂົ້າ​ຮ່ວມ​ຫນຶ່ງ​ກັບ​ຈໍາ​ນວນ​ຫຼາຍ​

ຕົວຢ່າງວຽກງານ: ທ່ານຈໍາເປັນຕ້ອງໃຊ້ເວລາສ່ວນຮ້ອຍທີ 95 ຂອງເວລາປະຕິບັດງານຂອງການບໍລິການສໍາລັບອາທິດ, ປຽບທຽບແຕ່ລະນາທີຂອງ 10 ສຸດທ້າຍດ້ວຍຄ່ານີ້.

ທ່ານບໍ່ສາມາດເຮັດການເຂົ້າຮ່ວມຫນຶ່ງຕໍ່ຫຼາຍ, ສຸດທ້າຍ / ສະເລ່ຍ / ກາງໃນໄລຍະກຸ່ມຂອງຈຸດປ່ຽນ node ເຂົ້າໄປໃນສະຕຣີມ, ຂໍ້ຜິດພາດ "ບໍ່ສາມາດເພີ່ມຂອບທີ່ບໍ່ກົງກັນຂອງເດັກນ້ອຍ: batch -> stream" ຈະຖືກສົ່ງຄືນ.

ຜົນໄດ້ຮັບຂອງ batch, ເປັນຕົວແປໃນການສະແດງ lambda, ຍັງບໍ່ໄດ້ຖືກທົດແທນ.

ມີທາງເລືອກທີ່ຈະບັນທຶກຕົວເລກທີ່ຈໍາເປັນຈາກຊຸດທໍາອິດໄປຫາໄຟລ໌ຜ່ານ udf ແລະໂຫລດໄຟລ໌ນີ້ຜ່ານ sideload.

ພວກເຮົາໄດ້ແກ້ໄຂຫຍັງກັບເລື່ອງນີ້?

ພວກເຮົາມີຜູ້ສະຫນອງໂຮງແຮມປະມານ 100 ຄົນ, ແຕ່ລະຄົນສາມາດເຊື່ອມຕໍ່ຫຼາຍ, ໃຫ້ໂທຫາມັນເປັນຊ່ອງທາງ. ມີປະມານ 300 ຊ່ອງເຫຼົ່ານີ້, ແຕ່ລະຊ່ອງທາງສາມາດລົ້ມລົງໄດ້. ຂອງທຸກ metrics ທີ່ບັນທຶກໄວ້, ພວກເຮົາຈະຕິດຕາມອັດຕາຄວາມຜິດພາດ (ຄໍາຮ້ອງຂໍແລະຄວາມຜິດພາດ).

ເປັນຫຍັງບໍ່ Grafana?

ການແຈ້ງເຕືອນຂໍ້ຜິດພາດທີ່ຖືກຕັ້ງຄ່າໃນ Grafana ມີຂໍ້ເສຍຫຼາຍຢ່າງ. ບາງຄົນແມ່ນສໍາຄັນ, ບາງຄົນສາມາດປິດຕາຂອງເຈົ້າ, ຂຶ້ນກັບສະຖານະການ.

Grafana ບໍ່ຮູ້ວິທີການຄິດໄລ່ລະຫວ່າງການວັດແທກ + ການເຕືອນ, ແຕ່ພວກເຮົາຕ້ອງການອັດຕາ (requests-errors)/requests.

ຄວາມຜິດພາດທີ່ເບິ່ງຄືວ່າບໍ່ດີ:

ແລະຄວາມຊົ່ວຮ້າຍຫນ້ອຍລົງເມື່ອເບິ່ງດ້ວຍການຮ້ອງຂໍທີ່ປະສົບຜົນສໍາເລັດ:

ຕົກລົງ, ພວກເຮົາສາມາດຄິດໄລ່ອັດຕາລ່ວງຫນ້າໃນການບໍລິການກ່ອນ grafana, ແລະໃນບາງກໍລະນີນີ້ຈະເຮັດວຽກ. ແຕ່ບໍ່ແມ່ນຢູ່ໃນພວກເຮົາ, ເພາະວ່າ ... ສໍາລັບແຕ່ລະຊ່ອງທາງອັດຕາສ່ວນຂອງຕົນເອງແມ່ນຖືວ່າ "ປົກກະຕິ", ແລະການແຈ້ງເຕືອນເຮັດວຽກຕາມຄ່າຄົງທີ່ (ພວກເຮົາຊອກຫາພວກມັນດ້ວຍຕາຂອງພວກເຮົາ, ປ່ຽນພວກມັນຖ້າມີການແຈ້ງເຕືອນເລື້ອຍໆ).

ເຫຼົ່ານີ້ແມ່ນຕົວຢ່າງຂອງ "ປົກກະຕິ" ສໍາລັບຊ່ອງທາງຕ່າງໆ:

ພວກເຮົາບໍ່ສົນໃຈຈຸດທີ່ຜ່ານມາແລະສົມມຸດວ່າຮູບພາບ "ປົກກະຕິ" ແມ່ນຄ້າຍຄືກັນສໍາລັບຜູ້ສະຫນອງທັງຫມົດ. ໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ແລະພວກເຮົາສາມາດໄດ້ຮັບໂດຍມີການແຈ້ງເຕືອນໃນ grafana?
ພວກເຮົາສາມາດ, ແຕ່ພວກເຮົາກໍ່ບໍ່ຕ້ອງການ, ເພາະວ່າພວກເຮົາຕ້ອງເລືອກຫນຶ່ງໃນທາງເລືອກ:
ກ) ສ້າງກາຟຫຼາຍອັນສໍາລັບແຕ່ລະຊ່ອງແຍກຕ່າງຫາກ (ແລະເຈັບປວດກັບພວກເຂົາ)
b) ອອກຈາກຕາຕະລາງຫນຶ່ງກັບທຸກຊ່ອງທາງ (ແລະໄດ້ຮັບການສູນເສຍໃນສາຍທີ່ມີສີສັນແລະການແຈ້ງເຕືອນທີ່ກໍາຫນົດເອງ)

ທ່ານເຮັດແນວໃດມັນ?

ອີກເທື່ອ ໜຶ່ງ, ມີຕົວຢ່າງເລີ່ມຕົ້ນທີ່ດີໃນເອກະສານ (ການຄິດໄລ່ອັດຕາໃນທົ່ວຊຸດທີ່ເຂົ້າຮ່ວມ), ສາມາດໄດ້ຮັບການ peeked ຢູ່ຫຼືປະຕິບັດເປັນພື້ນຖານໃນບັນຫາທີ່ຄ້າຍຄືກັນ.

ສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດໃນທີ່ສຸດ:

• ເຂົ້າຮ່ວມສອງຊຸດໃນສອງສາມຊົ່ວໂມງ, ຈັດກຸ່ມໂດຍຊ່ອງທາງ;
• ຕື່ມຂໍ້ມູນໃສ່ໃນຊຸດໂດຍກຸ່ມຖ້າບໍ່ມີຂໍ້ມູນ;
• ປຽບທຽບຄ່າສະເລ່ຍຂອງ 10 ນາທີທີ່ຜ່ານມາກັບຂໍ້ມູນທີ່ຜ່ານມາ;
• ພວກເຮົາຮ້ອງຂຶ້ນຖ້າຫາກວ່າພວກເຮົາຊອກຫາບາງສິ່ງບາງຢ່າງ;
• ພວກເຮົາຂຽນອັດຕາການຄິດໄລ່ແລະການແຈ້ງເຕືອນທີ່ເກີດຂຶ້ນໃນ influxdb;
• ສົ່ງຂໍ້ຄວາມທີ່ເປັນປະໂຫຍດເພື່ອ slack.

ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ພວກເຮົາໄດ້ຈັດການເພື່ອບັນລຸທຸກສິ່ງທີ່ພວກເຮົາຕ້ອງການທີ່ຈະໄດ້ຮັບໃນຕອນທ້າຍ (ແລະແມ້ກະທັ້ງເລັກນ້ອຍຫຼາຍກັບຕົວຈັດການ) ທີ່ສວຍງາມເທົ່າທີ່ເປັນໄປໄດ້.

ທ່ານສາມາດເບິ່ງທີ່ github.com ຕົວຢ່າງລະຫັດ и ວົງຈອນໜ້ອຍທີ່ສຸດ (graphviz) script ຜົນໄດ້ຮັບ.

ຕົວຢ່າງຂອງລະຫັດຜົນໄດ້ຮັບ:

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 ແມ່ນດີເລີດໃນການປະຕິບັດການຕິດຕາມ - ການແຈ້ງເຕືອນທີ່ມີກຸ່ມຂອງກຸ່ມ, ປະຕິບັດການຄິດໄລ່ເພີ່ມເຕີມໂດຍອີງໃສ່ metrics ທີ່ບັນທຶກໄວ້ແລ້ວ, ປະຕິບັດການປະຕິບັດທີ່ກໍາຫນົດເອງແລະແລ່ນສະຄິບ (udf).

ອຸປະສັກໃນການເຂົ້າແມ່ນບໍ່ສູງຫຼາຍ - ລອງມັນຖ້າ grafana ຫຼືເຄື່ອງມືອື່ນໆບໍ່ຕອບສະຫນອງຄວາມປາຖະຫນາຂອງເຈົ້າຢ່າງສົມບູນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com