Semua orang menyukai peringatan.
Tentu saja, jauh lebih baik untuk diberitahu ketika sesuatu telah terjadi (atau telah diperbaiki) daripada duduk dan melihat grafik dan mencari anomali.
Dan banyak alat telah diciptakan untuk ini. Alertmanager dari ekosistem Prometheus dan vmalert dari grup produk VictoriaMetrics. Pemberitahuan dan peringatan Zabbix di Grafana. Skrip yang ditulis sendiri di bot bash dan Telegram yang secara berkala menarik beberapa URL dan memberi tahu Anda jika ada sesuatu yang salah. Banyak hal.
Kami, di perusahaan kami, juga menggunakan solusi yang berbeda hingga kami menemui kompleksitasnya, atau, lebih tepatnya, ketidakmungkinan membuat peringatan gabungan yang kompleks. Apa yang kami inginkan dan apa yang akhirnya kami lakukan berada di bawah batas. TLDR: Ini adalah bagaimana proyek open source muncul
Untuk waktu yang cukup lama kami hidup dengan baik dengan peringatan yang dikonfigurasi di Grafana. Ya, ini bukan cara terbaik. Selalu disarankan untuk menggunakan beberapa solusi khusus, seperti Alertmanager. Dan kami juga berupaya untuk bergerak lebih dari sekali. Dan kemudian, sedikit demi sedikit, kami menginginkan lebih.
Katakanlah kapan grafik tertentu turun/naik sebesar XX% dan bertahan selama N menit dibandingkan periode M jam sebelumnya? Tampaknya Anda dapat mencoba menerapkannya dengan Grafana atau Alertmanager, tetapi itu tidak mudah. (Atau mungkin itu tidak mungkin, saya tidak akan mengatakannya sekarang)
Segalanya menjadi lebih rumit ketika keputusan peringatan harus dibuat berdasarkan data dari berbagai sumber. Contoh langsung:
Kami memeriksa data dari dua database Clickhouse, lalu membandingkannya dengan beberapa data dari Postgres, dan memutuskan peringatan. Memberi isyarat atau membatalkan
Kami telah mengumpulkan cukup banyak keinginan serupa untuk memikirkan keputusan kami. Dan kemudian kami mencoba menyusun daftar pertama persyaratan/kemampuan layanan ini, yang belum dibuat.
-
mengakses sumber data yang berbeda. Misalnya Prometheus, Clickhouse, Postgres
-
kirim peringatan ke berbagai saluran - telegram, slack, dll.
-
dalam proses berpikir, menjadi jelas bahwa saya tidak menginginkan deskripsi deklaratif, tetapi kemampuan menulis skrip
-
menjalankan skrip sesuai jadwal
-
pembaruan skrip yang mudah tanpa memulai ulang layanan
-
kemampuan untuk memperluas fungsionalitas tanpa membangun kembali layanan dari kode sumber
Daftar ini hanyalah perkiraan dan kemungkinan besar tidak terlalu akurat. Beberapa poin berubah, ada pula yang mati. Semuanya seperti biasa.
Sebenarnya dari sinilah sejarah Balerter dimulai.
Saya akan mencoba menjelaskan secara singkat apa yang terjadi pada akhirnya dan cara kerjanya. (Ya tentu saja ini bukan akhir. Ada banyak rencana pengembangan produk. Saya akan berhenti di hari ini saja)
Bagaimana cara kerjanya?
Anda menulis skrip di Lua di mana Anda secara eksplisit mengirim permintaan (ke Prometheus, Clickhouse, dll.). Anda menerima jawaban dan entah bagaimana memproses serta membandingkannya. Kemudian nyalakan/matikan semacam peringatan. Balerter sendiri akan mengirimkan notifikasi ke channel yang telah Anda konfigurasi (Email, telegram, slack, dll). Skrip dijalankan pada interval tertentu. Dan... secara umum, itu saja)
Yang terbaik adalah menunjukkannya dengan sebuah 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 terjadi di sini:
-
kami menunjukkan bahwa skrip ini harus dijalankan setiap 10 detik
-
tunjukkan nama skrip (untuk API, untuk ditampilkan di log, untuk digunakan dalam pengujian)
-
sambungkan modul untuk mengeluarkan log
-
sambungkan modul untuk mengakses clickhouse dengan nama
ch1(koneksi itu sendiri dikonfigurasi di konfigurasi) -
kirim permintaan ke clickhouse
-
jika terjadi kesalahan, kami menampilkan pesan di log dan keluar
-
bandingkan hasil query dengan konstanta (dalam contoh langsung, kita bisa mendapatkan nilai ini, misalnya, dari database Postgres)
-
mengaktifkan atau menonaktifkan peringatan dengan ID
rps-min-limit -
Anda akan menerima pemberitahuan jika status peringatan telah berubah
Contohnya cukup sederhana dan mudah dimengerti. Namun, tentu saja, skrip dalam kehidupan nyata bisa sangat panjang dan rumit. Sangat mudah untuk menjadi bingung dan membuat kesalahan.
Oleh karena itu, keinginan logis telah matang - untuk dapat menulis tes untuk skrip Anda. Dan di versi v0.4.0 ini muncul.
Skrip pengujian
Contoh tes skrip kita dari 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')Selangkah demi selangkah:
-
menunjukkan nama skrip yang tesnya ditulis
-
nama pengujian (untuk log)
-
menghubungkan modul pengujian
-
kami mengatakan hasil apa yang harus dikembalikan untuk permintaan khusus ke clickhouse
ch1 -
kami memeriksa apakah peringatan (kesalahan) rps-min-limit dengan pesan yang ditentukan telah dipanggil
-
periksa apakah peringatan rps-min-limit tidak dinonaktifkan (berhasil)
Apa lagi yang bisa dilakukan Balerter?
Saya akan mencoba menyentuh yang paling penting, menurut saya, keterampilan Balerter. Anda dapat melihat semuanya secara detail di situs resminya
-
menerima data dari
-
rumah klik
-
postgres
-
mysql
-
prometheus
-
loki
-
-
mengirim pemberitahuan ke saluran
-
kendur
-
Telegram
-
syslog
-
notify (pemberitahuan UI di komputer Anda)
-
e-mail
-
perselisihan
-
-
buat grafik berdasarkan data Anda, unggah gambar ke penyimpanan yang kompatibel dengan S3 dan lampirkan ke notifikasi ()
-
memungkinkan Anda bertukar data antar skrip - penyimpanan Kunci/Nilai global
-
tulis perpustakaan Anda sendiri di Lua dan gunakan dalam skrip (secara default, perpustakaan lua disediakan untuk bekerja dengan json, csv)
-
mengirim permintaan HTTP dari skrip Anda (dan menerima tanggapan, tentu saja)
-
menyediakan API (belum berfungsi seperti yang kita inginkan)
-
mengekspor metrik dalam format Prometheus
Apa lagi yang ingin Anda lakukan?
Sudah jelas bahwa pengguna dan kami menginginkan kemampuan untuk mengontrol peluncuran skrip menggunakan sintaksis cron. Ini akan dilakukan sebelum versi v1.0.0
Saya ingin mendukung lebih banyak sumber data dan saluran pengiriman notifikasi. Misalnya seseorang pasti akan merindukan MongoDB. Pencarian Elastis untuk beberapa. Kirim SMS dan/atau lakukan panggilan ke ponsel Anda. Kami ingin dapat menerima skrip tidak hanya dari file, tetapi juga, misalnya, dari database. Pada akhirnya, kami menginginkan situs web yang lebih ramah pengguna dan dokumentasi proyek yang lebih baik.
Ada yang selalu melewatkan sesuatu) Di sini kami mengandalkan permintaan masyarakat untuk menentukan prioritas dengan benar. Dan untuk membantu masyarakat mewujudkan semuanya
Sebagai kesimpulan
Kita gunakan Saya sudah memilikinya cukup lama sekarang. Lusinan naskah menjaga ketenangan pikiran kita. Saya harap pekerjaan ini bermanfaat bagi orang lain.
Dan selamat datang dengan Masalah dan PR Anda.
Sumber: www.habr.com