Kerja mudah dengan makluman yang kompleks. Atau sejarah Balerter

Semua orang suka makluman.

Sudah tentu, adalah lebih baik untuk dimaklumkan apabila sesuatu telah berlaku (atau telah diperbaiki) daripada duduk dan melihat graf dan mencari anomali.

Dan banyak alat telah dicipta untuk ini. Alertmanager daripada ekosistem Prometheus dan vmalert daripada kumpulan produk VictoriaMetrics. Pemberitahuan dan makluman Zabbix dalam Grafana. Skrip tulisan sendiri dalam bot bash dan Telegram yang secara berkala mengeluarkan beberapa URL dan memberitahu anda jika ada sesuatu yang tidak kena. Banyak segalanya.

Kami, dalam syarikat kami, juga menggunakan penyelesaian yang berbeza sehingga kami menghadapi kerumitan, atau, sebaliknya, kemustahilan untuk mencipta makluman komposit yang kompleks. Apa yang kami mahu dan akhirnya kami lakukan adalah di bawah pemotongan. TLDR: Ini adalah bagaimana projek sumber terbuka muncul Balerter

Untuk masa yang agak lama kami hidup dengan baik dengan makluman yang dikonfigurasikan dalam Grafana. Ya, ini bukan cara terbaik. Ia sentiasa disyorkan untuk menggunakan beberapa penyelesaian khusus, seperti Alertmanager. Dan kami juga melihat ke arah bergerak lebih daripada sekali. Dan kemudian, sedikit demi sedikit, kami mahu lebih.

Katakan apabila carta tertentu telah jatuh/meningkat sebanyak XX% dan telah berada di sana selama N minit berbanding tempoh M jam sebelumnya? Nampaknya anda boleh cuba melaksanakannya dengan Grafana atau Alertmanager, tetapi ia tidak begitu mudah. (Atau mungkin ia tidak mungkin, saya tidak akan katakan sekarang)

Perkara menjadi lebih rumit apabila keputusan amaran mesti dibuat berdasarkan data daripada sumber yang berbeza. Contoh langsung:

Kami menyemak data daripada dua pangkalan data Clickhouse, kemudian membandingkannya dengan beberapa data daripada Postgres, dan memutuskan makluman. Isyarat atau batalkan

Kami telah mengumpulkan cukup banyak keinginan yang sama untuk kami memikirkan keputusan kami. Dan kemudian kami cuba menyusun senarai pertama keperluan/keupayaan perkhidmatan ini, yang masih belum dibuat.

• mengakses sumber data yang berbeza. Contohnya, Prometheus, Clickhouse, Postgres

• hantar makluman ke pelbagai saluran - telegram, slack, dll.

• dalam proses berfikir, menjadi jelas bahawa saya tidak mahu penerangan perisytiharan, tetapi keupayaan untuk menulis skrip

• menjalankan skrip mengikut jadual

• kemas kini skrip yang mudah tanpa memulakan semula perkhidmatan

• keupayaan untuk mengembangkan fungsi tanpa membina semula perkhidmatan daripada kod sumber

Senarai ini adalah anggaran dan kemungkinan besar tidak begitu tepat. Beberapa mata berubah, ada yang mati. Semuanya seperti biasa.

Sebenarnya, beginilah sejarah Balerter bermula.

Saya akan cuba menerangkan secara ringkas apa yang berlaku pada akhirnya dan cara ia berfungsi. (Ya, sudah tentu, ini bukan penamat. Terdapat banyak rancangan untuk pembangunan produk. Saya hanya berhenti hari ini)

Bagaimana ia berfungsi?

Anda menulis skrip dalam Lua di mana anda menghantar permintaan secara eksplisit (kepada Prometheus, Clickhouse, dsb.). Anda menerima jawapan dan entah bagaimana memproses dan membandingkannya. Kemudian hidupkan/matikan beberapa jenis amaran. Balerter sendiri akan menghantar pemberitahuan kepada saluran yang telah anda konfigurasikan (E-mel, telegram, slack, dll.). Skrip dilaksanakan pada selang waktu tertentu. Dan... secara umum, itu sahaja)

Adalah lebih baik untuk menunjukkan dengan contoh:

-- @interval 10s
-- @name script1

local minRequestsRPS = 100

local log = require("log")
local ch1 = require("datasource.clickhouse.ch1")

local res, err = ch1.query("SELECT sum(requests) AS rps FROM some_table WHERE date = now()")
if err ~= nil then
    log.error("clickhouse 'ch1' query error: " .. err)
    return
end

local resultRPS = res[1].rps

if resultRPS < minResultRPS then
    alert.error("rps-min-limit", "Requests RPS are very small: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Requests RPS ok")
end 

Apa yang berlaku di sini:

• kami menunjukkan bahawa skrip ini perlu dilaksanakan setiap 10 saat

• nyatakan nama skrip (untuk API, untuk paparan dalam log, untuk digunakan dalam ujian)

• sambungkan modul untuk mengeluarkan log

• sambungkan modul untuk mengakses rumah klik dengan nama ch1 (sambungan itu sendiri dikonfigurasikan dalam konfigurasi)

• hantar permintaan ke clickhouse

• sekiranya berlaku ralat, kami memaparkan mesej dalam log dan keluar

• bandingkan hasil pertanyaan dengan pemalar (dalam contoh langsung, kita boleh mendapatkan nilai ini, contohnya, daripada pangkalan data Postgres)

• dayakan atau lumpuhkan makluman dengan ID rps-min-limit

• anda akan menerima pemberitahuan jika status makluman telah berubah

Contoh yang agak mudah dan boleh difahami. Walau bagaimanapun, sudah tentu, dalam skrip kehidupan sebenar boleh menjadi agak panjang dan kompleks. Mudah keliru dan melakukan kesilapan.

Oleh itu, keinginan logik telah matang - untuk dapat menulis ujian untuk skrip anda. Dan dalam versi v0.4.0 ini muncul.

Menguji skrip

Contoh ujian untuk skrip kami daripada contoh di atas:

-- @test script1
-- @name script1-test

test = require('test')

local resp = {
    {
        rps = 10
    }
} 

test.datasource('clickhouse.ch1').on('query', 'SELECT sum(requests) AS rps FROM some_table WHERE date = now()').response(resp)

test.alert().assertCalled('error', 'rps-min-limit', 'Requests RPS are very small: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')

Langkah-langkahnya:

• nyatakan nama skrip yang ujian itu ditulis

• nama ujian (untuk log)

• sambungkan modul ujian

• kami menyatakan hasil yang perlu dikembalikan untuk permintaan khusus kepada rumah klik ch1

• kami menyemak bahawa amaran (ralat) rps-min-had dengan mesej yang ditentukan telah dipanggil

• semak bahawa amaran had rps-min-limit tidak dilumpuhkan (berjaya)

Apa lagi yang boleh Balerter lakukan?

Saya akan cuba menyentuh yang paling penting, pada pendapat saya, kemahiran Balerter. Anda boleh melihat segala-galanya secara terperinci di laman web rasmi https://balerter.com

• menerima data daripada

  • clickhouse

  • postgres

  • mysql

  • prometheus

  • loki

• menghantar pemberitahuan ke saluran

  • kekurangan

  • telegram

  • syslog

  • maklumkan (pemberitahuan UI pada komputer anda)

  • e-mel

  • perpecahan

• bina graf berdasarkan data anda, muat naik imej ke storan serasi S3 dan lampirkan pada pemberitahuan (Contoh dengan gambar)

• membolehkan anda menukar data antara skrip - storan Kunci/Nilai global

• tulis perpustakaan anda sendiri dalam Lua dan gunakannya dalam skrip (secara lalai, perpustakaan lua dibekalkan untuk bekerja dengan json, csv)

• hantar permintaan HTTP daripada skrip anda (dan terima respons, sudah tentu)

• menyediakan API (belum berfungsi seperti yang kami mahu)

• eksport metrik dalam format Prometheus

Apa lagi yang anda mahu lakukan?

Sudah jelas bahawa pengguna dan kami mahukan keupayaan untuk mengawal pelancaran skrip menggunakan sintaks cron. Ini akan dilakukan sebelum versi v1.0.0

Saya ingin menyokong lebih banyak sumber data dan saluran penghantaran pemberitahuan. Sebagai contoh, seseorang pasti akan merindui MongoDB. Anjal Carian untuk beberapa. Hantar SMS dan/atau buat panggilan ke telefon mudah alih anda. Kami mahu dapat menerima skrip bukan sahaja daripada fail, tetapi juga, sebagai contoh, daripada pangkalan data. Akhirnya, kami mahukan tapak web yang lebih mesra pengguna dan dokumentasi yang lebih baik untuk projek itu.

Seseorang sentiasa kehilangan sesuatu) Di sini kami bergantung pada permintaan komuniti untuk menetapkan keutamaan dengan betul. Dan untuk membantu masyarakat untuk merealisasikan segala-galanya

Kesimpulannya

Kami guna Balerter Saya telah mengalaminya sejak sekian lama. Puluhan skrip menjaga ketenangan fikiran kita. Saya berharap kerja ini akan berguna kepada orang lain.

Dan selamat datang dengan Isu dan PR anda.

Sumber: www.habr.com