Grafana: membangun sistem peringatan untuk grafana

Saya ingin membantu dengan ini! Saran saya adalah tetap berpegang pada pedoman gaya nagios. Dengan begitu alat tersebut dapat dengan mudah digunakan dengan alat pemantauan lainnya. misalnya Nagios, Zenoss, Icinga, dll.

Hal terbesar tentang fitur ini adalah mendapatkan arsitektur dasar yang benar.

Beberapa pertanyaan yang ingin saya jelajahi
1) Komponen apa yang diperlukan bagaimana menjalankannya (dalam proc di grafana, di luar proc),
2) Bagaimana hal-hal harus dikoordinasikan.
3) Haruskah kita mengabaikan peringatan "dalam aliran", (hanya fokus pada berbasis tarik)

Lebih dalam ke 1)
Saya khawatir membuat server grafana menjadi monolit. Ingin menemukan cara untuk memisahkan grafana-server menjadi layanan yang lebih terisolasi satu sama lain (dan dapat dijalankan baik inproc atau sebagai proses terpisah). Ini adalah semacam rencana dengan abstraksi bus. Pilihan lain adalah membuat komponen peringatan hanya berbicara dengan grafana melalui api HTTP, mungkin membatasi integrasi, tidak yakin.

Saya setuju dengan torkelo. Dalam pengalaman saya dengan proyek lain dengan segala sesuatu yang "terpasang" itu bisa menjadi sangat rumit untuk memecahkan masalah. Saya suka ide layanan yang berjalan secara eksternal, tetapi halaman konfigurasi yang bagus di grafana yang berbicara dengan layanan melalui api HTTP untuk menangani pengelolaan semua peringatan. Juga, untuk penerapan skala besar, ini mungkin akan menjadi persyaratan karena kinerja pada akhirnya akan menurun (setidaknya saya akan memiliki ini sebagai opsi konfigurasi).

apakah kita berintegrasi dengan pengaturan ambang grafik grafana saat ini (yang saat ini hanya untuk, bukan untuk diproses)? jika ekspresinya adalah pemeriksaan ambang, kami dapat secara otomatis menampilkan garis ambang

Saya pikir itu bisa menjadi tempat yang baik untuk memulai. Waspada jika disetel, jangan jika tidak.

Kembali ke nomor 1. Saya pikir jika layanan bosun dapat berjalan secara terpisah tetapi masih memiliki kemampuan untuk sepenuhnya mengkonfigurasi semuanya melalui grafana, menurut saya, itu ideal.

Pertahankan pekerjaan yang luar biasa.

Satu-satunya kekurangan yang saya lihat dengan bosun adalah sumber data yang dapat digunakan. Jika Anda dapat memanfaatkan bahasa untuk mengekspresikan peringatan bosun tetapi juga berintegrasi dengan sumber data yang ada yang dikonfigurasi melalui UI grafana biasa, itu pasti akan ideal.

Mampu mewakili ambang peringatan, ketika Anda dekat dengannya, serta secara otomatis mendorong anotasi ketika mereka dipicu dalam pikiran saya membuat UI panel tunggal yang ideal.

Menantikan pekerjaan yang akan dilakukan di sini!

1. Itu harus menggunakan ambang batas yang ditentukan di Dasbor untuk memperingatkan
   Mari kita tetap sederhana; jika Dasbor menunjukkan warna untuk peringatan, itu harus memperingatkan.
2. Ini mungkin sesuatu di luar proses grafana-server itu sendiri.
   ... Sesuatu yang akan menggunakan sisa api untuk mengikis dasbor dan pengaturannya dan merendernya serta memperingatkan menggunakan perintah eksternal.
3. Tingkat peringatan; hanya sebuah kotak untuk menjatuhkan editor bahwa Dasbor ini harus dipantau; dan harus diperiksa setiap menit. Jika tidak ada data, apakah harus tetap untuk suatu periode apakah masih harus waspada? (kotak centang)

Akhirnya; karena kita lebih bergantung pada Grafana saya akui saya bersedia untuk mengatakan 2. bisa menjadi sesuatu yang saya akan bersedia untuk membayar.

Saya ingin tahu mengapa orang berpikir ini harus dimasukkan ke dalam Grafana sama sekali?
Grafana tidak menerima atau menyimpan data aktual itu tetapi "hanya" memvisualisasikannya. Sistem peringatan apa pun harus didasarkan pada data di penyimpanan metrik.
Jika ini benar-benar terintegrasi ke dalam Grafana saya harap ini dapat dinonaktifkan karena di sini kita sudah menggunakan Icinga untuk memperingatkan sehingga segala jenis peringatan di Grafana hanya akan semakin mengacaukan GUI meskipun tidak digunakan sama sekali.

Benar sekali @dennisjac; Grafana hanya merender sesuatu.

Tetapi karena kami telah memindahkan banyak hal ke sisi server, itu tidak lagi hanya rendering klien; kemungkinan proses pekerja yang dapat memeriksa metrik dan peringatan Anda; kurang sulit.

Data ada dalam database; asalkan ditaburi dengan data yang memberitahunya untuk memeriksa metrik ...

Beberapa orang mungkin setuju atau tidak setuju bahwa kita tidak boleh menyeberangi arus dan membuat Grafana melakukan lebih dari sekadar memvisualisasikannya (kira-kira) tetapi saya bukan mereka.

Saya tidak terlalu menentang fitur untuk orang yang menginginkannya untuk diintegrasikan tetapi saya berharap ini akan menjadi opsional untuk orang yang sudah memiliki sistem pemantauan/pemberitahuan yang tersedia.

Proyek Telegraf baru (pengumpul metrik dari orang-orang influxdb) juga melihat fitur pemantauan/peringatan yang tidak disukai karena alasan yang sama. Saya menguraikan ini di sini:
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

Saya pikir torkelo telah melakukan pekerjaan yang sangat baik dalam memberi kami fitur di Grafana2 yang tidak harus kami aktifkan.

Sejauh influxdb mereka harus menghasilkan uang entah bagaimana; baik dari dukungan influxdb dan layanan profesional atau produk untuk itu.

Yang terakhir terdengar jauh lebih layak

Sudut lain dalam hal ini. Tampaknya ada dukungan yang akan datang untuk elasticsearch sebagai penyimpanan metrik untuk grafana. Bosun sekarang dapat meminta elasticsearch untuk data log.

Apakah masuk akal ketika merancang sistem peringatan untuk memungkinkan peringatan dari data log juga? Mungkin bukan fitur untuk versi pertama, tapi sesuatu yang bisa diimplementasikan nanti.

Saya juga setuju dengan gagasan untuk membagi proses. Minta Grafana antarmuka untuk melihat dan membuat lansiran, minta sesuatu yang lain menangani lansiran. Memiliki bagian peringatan berbasis api juga akan memungkinkan alat lain untuk berinteraksi dengannya.

+1 untuk Peringatan. Di luar penggunaan DevOps, aplikasi yang dibuat untuk pengguna akhir perlu memberikan peringatan yang ditentukan pengguna. Bagus untuk memilikinya di alat visualisasi ...

Memberi +1 ini akan menutup loop - usulan untuk mendapatkan metrik.

+1 Peringatan dari Grafana + Backend Penskalaan Horizontal dari InfluxDB akan menjadikannya standar yang harus dikalahkan untuk Konfigurasi Peringatan Metrik

+1 Saya ingin penskalaan horizontal peringatan pada beberapa simpul grafana.

Akan sangat bagus jika seseorang dapat mengaitkan perilaku seperti "debounce" dengan peringatan. Misalnya, saya ingin mengaktifkan peringatan hanya jika ambang batas yang ditentukan melebihi X selama N menit.

Saya telah melihat ini dengan beberapa alat peringatan, sayangnya kami saat ini menggunakan Seyren yang tampaknya tidak memberikan opsi seperti itu. Kami menggunakan Grafana untuk pengembangan dasbor kami dan berharap untuk menarik peringatan ke Grafana juga. Tetap bekerja dengan baik.

Kami memiliki dua kasus penggunaan:

• tim infrastruktur membuat peringatan melalui alat penyediaan seperti biasa ke dalam tumpukan pemantauan umum (pemeriksaan klaster umum atau pemeriksaan sistem dalam sistem ramah nagios)
• pengembang perangkat lunak membuat metrik aplikasi melalui Grafana

Kami ingin memiliki sistem peringatan terpadu yang menangani peringatan, deteksi tutup, eskalasi, dan kontak. Itu membantu kita merekam dan menghubungkan peristiwa/operasi dalam sumber kebenaran yang sama. Banyak sistem telah memecahkan masalah peringatan. Saya berharap Grafana dapat melakukan lebih baik dalam hal ini dalam jangka panjang, jangka pendek untuk tidak menemukan kembali sistem yang ada akan membantu dalam hal kiriman.

Salah satu saran adalah Grafana dapat menyediakan API untuk mengekstrak definisi pemantauan (status peringatan), pihak ketiga dapat berkontribusi plugin ekspor konfigurasi. Ini akan sangat ideal dalam kasus penggunaan kami mengekspor konfigurasi nagios.

Lebih penting lagi, saya juga ingin melihat beberapa solusi deteksi anomali terintegrasi!

Pada 15 Juli 2015, pukul 17:40, Pierig Le Saux [email protected] menulis:

+1 Saya ingin penskalaan horizontal peringatan pada beberapa simpul grafana.

—
Balas email ini secara langsung atau lihat di GitHub.

Saya setuju dengan @activars. Saya tidak begitu mengerti mengapa solusi dasbor harus menangani peringatan yang merupakan masalah yang kurang lebih diselesaikan oleh banyak alat lain, sebagian besar cukup matang. Lakukan satu hal dan lakukan dengan baik.

IMHO akan lebih masuk akal untuk fokus pada bagian _integrasi_.

Contoh: Tentukan ambang batas warning/crit dinamis dalam grafana (misalnya seperti pada contoh @Dieterbe di atas) dan berikan API (REST?) yang mengembalikan status (normal, warn, crit) dari grafik ini. Seorang nagios, icinga, bosun dll. dapat meminta semua grafik yang diaktifkan "pemantauan" (fitur API lain), beralih melalui masing-masing status dan melakukan peringatan yang diperlukan.

Dalam kasus kami, katalog layanan dan tindakan yang ditentukan adalah bagian yang sulit - layanan mana yang sangat penting bagi bisnis, ke mana harus mengirim email, mengepak, dll. Anda juga tidak perlu khawatir tentang manajemen pengguna / grup di grafana yang sudah dimiliki sebagian besar perusahaan di tempat pusat (AD, LDAP, Crowd dll) dan terintegrasi dengan sistem peringatan.

Kami juga harus mempertimbangkan bahwa tidak seperti solusi dasbor, persyaratan kualitas untuk alat peringatan dapat dianggap jauh lebih tinggi dalam hal keandalan, ketahanan, stabilitas, dll. yang menciptakan upaya (pengujian) yang tidak boleh diremehkan.

Juga bagaimana dengan pemeriksaan terkait non-deret waktu, seperti memanggil layanan web, melakukan ping ke mesin, menjalankan skrip khusus ... apakah Anda juga menginginkannya di grafana? Saya kira adopsi bosun akan memberikan semua ini, tetapi saya tidak begitu akrab dengannya.

Di sisi lain saya dapat membayangkan bagaimana sistem peringatan sederhana akan membuat banyak pengguna senang yang tidak memiliki alternatif yang baik, tetapi ini mungkin dapat diselesaikan dengan beberapa contoh pola integrasi untuk alat peringatan lainnya.

Sebanyak yang saya ingin Grafana untuk menyelesaikan semua masalah saya, saya pikir falkenbt memukul paku di kepala dengan yang satu ini.

API untuk mengekspos data yang disebutkan, beberapa pipa di bosun, dan beberapa pola integrasi dengan platform peringatan umum sangat masuk akal.

Selamat atas pekerjaan baru Anda di raintank @Dieterbe! Saya telah membaca blog Anda untuk sementara waktu dan Anda memiliki beberapa ide yang sangat bagus tentang pemantauan, terutama mengenai metrik dan tempatnya dalam peringatan. Saya yakin Anda akan menemukan cara yang baik untuk menerapkan peringatan di grafana.

Seperti yang mungkin Anda setujui, orang-orang di belakang Bosun cukup banyak melakukan peringatan dengan cara yang benar. Hal yang kurang dari Bosun adalah visualisasinya. Saya ingin melihat Bosun di balik Grafana UI. Menggabungkan dasbor Grafanas dan peringatan bosun di belakang antarmuka yang sama akan menghasilkan solusi pemantauan yang luar biasa dan lengkap.

Juga saya pikir akan memalukan untuk memecah komunitas pemantau open source lebih jauh, ide Anda tentang pemantauan tampaknya sangat sesuai dengan ide orang-orang di belakang Bosun. Jika Anda mau bersatu saya yakin hasilnya akan bagus.

Di tempat saya bekerja, kami menggunakan Elastis untuk log/peristiwa dan baru saja mulai menggunakan InfluxDB untuk metrik. Kami telah menjajaki berbagai solusi untuk pemantauan dan saat ini condong ke Bosun. Kami sudah menggunakan Grafana untuk dashboard, tetapi ingin mengakses semua informasi pemantauan kami melalui antarmuka yang sama, alangkah baiknya jika Grafana bisa menjadi antarmuka itu.

Pertahankan pekerjaan yang bagus, dan semoga berhasil!

Pada garis singgung terkait, kami mendapatkan bagian peringatan yang bekerja dengan mengintegrasikan grafana dengan riemann. Merupakan latihan yang bagus untuk mengenal bagian dalam grafana :).

Ini lebih mudah dengan riemann karena konfigurasinya hanyalah kode clojure. Saya membayangkan integrasi ini akan lebih sulit di Bosun.

Berikut adalah beberapa tangkapan layar saat beraksi

Perubahan pada bagian grafana termasuk menambahkan titik akhir "/alerts" dan "/subscriptions" dan membuatnya berbicara dengan api kecil lain yang berada di atas agar riemann melakukan crud.

Hal yang menyenangkan adalah fakta bahwa perubahan dalam definisi peringatan segera direfleksikan tanpa harus mengirim SIGHUP ke riemann. Jadi mengaktifkan/menonaktifkan, tweak periode waktu untuk perubahan status hanyalah masalah mengubahnya di UI dan membuat perubahan itu menyebar sendiri ke riemann.

Masih belum membandingkan integrasi ini tetapi saya tidak berpikir itu akan seburuk itu. Akan membuat blog tentangnya setelah saya membersihkan kode dan setelah ditayangkan.

Seluruh alasan kami melakukan ini adalah karena orang dapat melanjutkan dan mengatur peringatan dan pemberitahuan ini dari UI yang sangat familiar dan tidak mengganggu kami untuk menulis konfigurasi riemann :).

@sudharsh implementasi Anda terdengar sangat menarik. Apakah Anda berencana melepaskan ini ke alam liar?

banyak ide bagus, terima kasih semuanya.
Terinspirasi oleh beberapa komentar dan proyek https://github.com/pabloa/grafana-alerts @pabloa , kami memutuskan untuk fokus pertama dan terutama pada UI dan UX untuk mengonfigurasi dan mengelola aturan peringatan sebagai bagian dari alur kerja yang sama mengedit dasbor dan panel. Grafana akan menyimpan aturan tersebut di suatu tempat dan menyediakan akses mudah ke sana sehingga skrip atau alat lain dapat mengambil aturan peringatan.
Mungkin melalui file, panggilan API, bagian di konfigurasi dasbor, atau entri dalam database.
(Saya suka gagasan untuk menjadikannya sebagai bagian dari definisi dasbor itu sendiri, sehingga proyek sumber terbuka dapat datang dengan file json dasbor grafana untuk mereka yang akan menyertakan aturan peringatan meskipun tidak harus aktif secara default. di sisi lain memilikinya di database tampaknya lebih kuat)
Apa pun itu, kami ingin menyediakan akses mudah sehingga Anda dapat membuat konfigurasi untuk sistem lain apa pun yang ingin Anda gunakan yang benar-benar menjalankan aturan peringatan dan memproses peristiwa. (dari sini saya akan menyebut ini sebagai "penangan").
Handler seperti itu bisa berupa nagios, atau sensu, atau bosun, alat yang Anda tulis atau lakmus alert scheduler-executor yang merupakan handler yang dapat Anda kompilasi menjadi grafana yang menyediakan integrasi yang bagus dan sederhana yang didukung oleh bosun tapi kami benar-benar ingin pastikan Anda dapat menggunakan sistem apa pun yang Anda inginkan.

Selama penangan Anda mendukung kueri penyimpanan data yang Anda gunakan. kita akan memulai dengan ambang statis sederhana tetapi kemudian juga ingin membuatnya mudah untuk memilih fungsi reduksi, ekspresi boolean antara beberapa kondisi, dll.

@sudharsh itu adalah pendekatan yang sangat bagus. Saya suka bagaimana solusi Anda dapat berbicara langsung ke API jarak jauh, melewati langkah perantara yang dijelaskan di atas (tentu saja ini menyiratkan ini hanya berfungsi untuk 1 backend tertentu yang kami coba hindari), dan itu dapat secara otomatis memuat ulang konfigurasi. (Anda benar, bosun saat ini tidak mendukungnya, mungkin di masa depan. FWIW handler lakmus menangani ini dengan baik dan menggunakan mekanisme evaluasi ekspresi bosun). Saya tidak pernah benar-benar masuk ke riemann banyak. Sebagian besar saya khawatir tentang menambahkan bahasa yang berbeda ke tumpukan sehingga tidak banyak orang mengerti atau dapat men-debug ketika ada yang salah. Tapi saya sangat ingin tahu lebih banyak tentang sistem Anda dan tentang kode CLJ Riemann. (Saya akan senang jika kecurigaan saya salah)

@dennisjac ya itu opsional.
@elvarb ada tiket untuk ES sebagai sumber data . sebenarnya tujuannya adalah jika grafana mendukung rendering data dari sumber data tertentu, grafana juga harus mendukung pembuatan aturan peringatan untuknya. Adapun eksekusi kueri/kueri ini tentu saja tergantung pada penangan apa yang Anda putuskan untuk digunakan. (untuk penangan lakmus, kita akan mulai dengan yang paling populer seperti grafit dan influxdb)
@rsetzer : setuju, itu hal yang baik untuk dapat menentukan berapa lama ambang batas harus dilampaui sebelum kita memicu
@falkenbt : Saya percaya banyak hal dapat diungkapkan sebagai masalah kueri deret waktu (misalnya contoh ping). Tapi Anda benar, beberapa hal tidak benar-benar terkait dengan deret waktu dan itu di luar cakupan untuk apa yang kami coba bangun di sini. Dan saya pikir tidak apa-apa: kami ingin memberikan cara terbaik untuk mengonfigurasi dan mengelola peringatan pada rangkaian waktu dan bertujuan untuk integrasi dengan sistem lain yang mungkin lebih dioptimalkan untuk kasus "skrip misc" (seperti nagios, icinga, sensu, .. .). Adapun masalah seperti keandalan pengiriman, eskalasi dll, Anda dapat mengaitkan layanan seperti pagerduty.
@activars & @falkenbt apakah ini sesuai dengan harapan Anda atau menurut Anda apa yang dapat ditingkatkan secara khusus?
@jemilsson terima kasih! dan begitulah cara saya melihatnya: bosun hebat dalam mengingatkan tetapi tidak pandai visualisasi. Grafana hebat dalam visualisasi dan UX tetapi tidak memiliki peringatan. Saya mencoba untuk mendorong kolaborasi yang akan tumbuh seiring waktu, saya pikir

Adakah yang punya pemikiran tentang konteks seperti apa yang akan dikirim dalam notifikasi seperti email?
Paling tidak, pemberitahuan harus berisi data yang Anda waspadai, tetapi mungkin untuk menyertakan grafik terkait lainnya. Di sini kita dapat menggunakan backend rendering png grafana saat membuat konten notifikasi. Saya juga berpikir untuk memanfaatkan fitur snapshot grafana. seperti saat peringatan dipicu, ambil snapshot dari dasbor tertentu untuk konteks.
dan mungkin snapshot itu (halaman html) dapat dimasukkan dalam email, atau mungkin terlalu banyak data/kompleksitas. juga fitur javascript tidak akan tersedia di klien email (sehingga Anda tidak akan dapat memperbesar grafik dalam email). Mungkin kami dapat menautkan dari email ke snapshot dasbor yang dihosting.

Saya suka pendekatan umum buruh pelabuhan - termasuk baterai, tetapi dapat dilepas. Jadi implementasi peringatan dasar yang dapat ditukar akan menjadi pendekatan yang baik.

influxdb akan didukung untuk peringatan? atau hanya grafit?

Satu hal yang ingin saya lihat adalah gagasan tentang pohon peringatan hierarkis. Ada terlalu banyak aspek yang dipantau dan status siaga yang berdiri sendiri memiliki kardinalitas yang tidak dapat dikelola. Dengan hierarki pohon, saya dapat menentukan semua peringatan tingkat rendah ini yang menggulung ke peringatan tingkat menengah yang menggulung ke tingkat tinggi ......

Dengan demikian, setiap peringatan yang digulung secara otomatis mengasumsikan tingkat keparahan yang tinggi dari semua anak di bawahnya. Dengan cara itu, saya bisa mendapatkan kesan [dan mengelola] kesehatan sistem secara akurat dengan luas permukaan analisis yang jauh lebih rendah.

Ini adalah contoh yang saya pinjam dari dokumen lama yang saya tulis beberapa waktu lalu. Ya, silakan tertawa lepas dengan penggunaan kata "Struts". Ini TUA oke? Ini menyajikan hierarki yang sangat sederhana untuk satu server.

Pada titik tertentu, server mengalami penggunaan CPU 75% yang berkelanjutan, jadi ini membuat peringatan ini menjadi status peringatan: CPU-# --> CPU --> Host/OS --> Sistem

Jika seseorang benar-benar menerapkan dirinya sendiri, seseorang dapat mengawasi seluruh pusat data dengan satu indikator. (ya, tidak juga, tapi ini berfungsi sebagai latihan pemikiran)

Mengapa tidak menggunakan suar grafit ? Saya pikir Anda dapat menggabungkan graphite-beacon yang sangat ringan dengan grafana.

@felixbarny Saya suka terminologi itu. kita mungkin akan mengadopsi kata-kata itu.
@JulienChampseix ya penangan standar akan/akan mendukung influxdb
@nickman itu menarik. itu benar-benar sejalan dengan tujuan akhir yang kami pikirkan, yaitu mampu membuat peringatan tingkat sangat tinggi yang dapat menyertakan / bergantung pada aturan dan informasi peringatan yang lebih halus. bosun sudah melakukan ini, dan dalam jangka panjang kami ingin membuat fungsi ini tersedia melalui antarmuka yang lebih ramah pengguna, tetapi kami harus memulai lebih sederhana dari ini.
@amirhosseinrajabi terlihat seperti proyek yang keren dan saya pikir membuat suar grafit menjadi penangan untuk peringatan yang dikonfigurasi melalui UI grafana akan sangat masuk akal.

@Dieterbe apakah mungkin untuk memperbarui status saat ini? untuk sistem peringatan
untuk mengetahui sistem mana yang kompatibel (grafit/influxdb)?
langganan mana yang tersedia? jenis peringatan apa yang tersedia?
terima kasih atas pembaruan Anda.

kami sedang membuat prototipe UX/UI. jadi kami cukup jauh dari ini yang dapat digunakan.

Hai @Dieterbe

apakah ada pembaruan tentang kemajuan sistem peringatan ??

Akan luar biasa memiliki peringatan di Grafana! Menantikan fitur ini. Ada pembaruan sekarang?

@mattttt dapatkah Anda memberikan pembaruan tentang pekerjaan UX Anda?

Ya, tentu saja. Akan mengunggah beberapa layar/alur pengguna besok.

Kami membutuhkan peringatan: UI untuk definisi aturan, API untuk definisi aturan, dan API untuk pemberitahuan peringatan. Akan menonton utas ini dengan penuh minat. Kami memiliki sistem multi-tenant dan menyukai Grafana UI dan back-end.

Ya, saya juga sangat tertarik dan tidak sabar untuk melihat fitur baru ini!
Terima kasih banyak Mat! ;)

27-08-2015 6:49 GMT+02:00 andyl [email protected] :

Kami membutuhkan peringatan: UI untuk definisi aturan, API untuk definisi aturan, dan API
untuk pemberitahuan peringatan. Akan menonton utas ini dengan penuh minat.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295.

Ada banyak item yang jatuh ke tempatnya secara internal, tetapi saya tidak ingin membiarkan utas ini diabaikan.

Ini salah satu maket panel yang sedang saya kerjakan. Ini menggambarkan kesehatan historis dari waktu ke waktu, menggabungkan status ke dalam tooltip dan menggunakan ambang batas yang ada yang ditentukan dalam konfigurasi panel untuk mengonfigurasi peringatan.

Dalam contoh ini, ini mengingatkan pada satu kueri dengan beberapa seri. Tooltips diperluas untuk menunjukkan status pada waktu hover.

_Beberapa pertanyaan kecil yang belum terselesaikan _: Berapa banyak informasi tentang pemberitahuan peringatan yang harus dimasukkan ke dalam tooltip, jika ada - atau haruskah informasi ini diakses di tempat lain dalam tampilan yang lebih rinci? Saya percaya yang terakhir saat ini, tetapi ada baiknya bertanya dengan keras.

Konfigurasi, layar peringatan, aliran pengguna datang perlahan. Banyak yang akan datang.

@mattttt bagus!

Cintai garis hijau dan merah di bawah grafik!

Itu terkait dengan perhitungan waktu aktif, akan senang dapat melihat itu sebagai angka di suatu tempat. Total untuk semua kueri dan untuk setiap metrik.

Tentang tooltip, apakah Anda berbicara tentang statistik yang muncul saat Anda mengarahkan kursor ke garis?

Sial @mattttt itu terlihat luar biasa. Saya bahkan tidak akan khawatir tentang meletakkan apa pun di tooltip. Garis ambang batas dan bilah kesehatan status peringatan di bagian bawah lebih dari cukup.

Tidak sabar untuk melihat ini setelah selesai!

Saya senang melihat ini berkembang dengan baik!

Saat ini kami menggunakan Grafana+Bosun+OpenTSDB sebagai tumpukan pemantauan & peringatan kami. Saya sangat setuju akan luar biasa memiliki kekuatan Bosun dengan UX Grafana yang hebat.

Berikut adalah contoh di mana UX konfigurasi Grafana lebih baik daripada Bosun:

Konteks

Tumpukan pemantauan kami dibagi antara beberapa tim dan layanan mereka. Serangkaian layanan yang berbeda disebarkan ke cluster/situs yang berbeda berdasarkan spesifikasi proyek. Setiap tim/layanan harus bertanggung jawab atas dasbor/lansirannya sendiri.

Perbandingan

Dengan tim API HTTP Grafana dapat PUT dasbor mereka sendiri saat menggunakan layanan mereka. Bosun saat ini hanya memiliki satu file untuk menyimpan konfigurasi; ini membuat sulit untuk berbagi antara tim yang berbeda dan di proyek yang berbeda.

@mattttt @torkelo @Dieterbe ada ide untuk rilis bagian peringatan (atau rilis beta)?

gema ^. Apakah mereka rilis beta atau alpha untuk ini? Saya sedang meneliti solusi peringatan, tetapi saya ingin memiliki sesuatu yang dibangun di grafana. Saya bisa memberikan banyak umpan balik pengujian.

Fitur peringatan masih beberapa bulan ke depan, kami masih membuat prototipe UI dan memikirkan berbagai cara untuk mengimplementasikannya, tetapi kemajuan akan bergerak lebih cepat dalam 2 bulan ke depan sehingga kami akan tahu lebih banyak.

@mattttt apakah Anda bermaksud membuat warna bilah kesehatan historis dapat dikonfigurasi? Hijau dan merah tidak cocok dengan buta warna ;)

Mengenai peringatan: Saya cukup tertarik dengan bagaimana ini terjadi. Kami telah mengumpulkan dan memvisualisasikan data untuk sementara waktu sekarang, dan peringatan adalah sesuatu yang saat ini kami coba cari tahu. Grafana bisa memiliki tempat yang bagus di sana, terutama karena visualisasinya sudah ada. Apa yang saya heran: seberapa jauh Grafana harus lebih waspada terhadap 'entitas' daripada rangkaian metrik untuk peringatan? Saya dapat membayangkan diri saya ingin secara otomatis mengaktifkan perubahan status visual (ping atau pemeriksaan http gagal) atau secara manual (melakukan pemeliharaan) untuk apa yang dalam kasus saya akan menjadi server, selain peringatan berbasis metrik.

Saya menarik untuk melihat ke mana arah peringatan di Grafana, tetapi bagi Anda yang membutuhkan sesuatu sekarang, ada plugin nagios seperti https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details yang dapat memicu peringatan ketika ambang batas dilewati.

@baaym

Apa yang saya heran: seberapa jauh Grafana harus lebih waspada terhadap 'entitas' daripada rangkaian metrik untuk peringatan? Saya dapat membayangkan diri saya ingin secara otomatis mengaktifkan perubahan status visual (ping atau pemeriksaan http gagal) atau secara manual (melakukan pemeliharaan) untuk apa yang dalam kasus saya akan menjadi server, selain peringatan berbasis metrik.

ini adalah pertanyaan yang bagus dan juga sesuatu yang telah kita bicarakan sedikit.
solusi yang ingin kami lakukan untuk jangka waktu dekat (dan mungkin juga jangka panjang) adalah membuat grafana tidak menyadari konsep tingkat yang lebih tinggi seperti itu. yaitu sebagai pengguna Anda memiliki kekuatan untuk mengatur peringatan pada rangkaian metrik, dan dari aturan peringatan tersebut, hasil peringatan akan dihasilkan (kemungkinan termasuk atribut atau tag dari nama rangkaian) dari mana Anda kemudian dapat membangun entitas apa pun yang Anda inginkan. ini adalah sesuatu yang harus kita pikirkan sedikit lebih banyak, tetapi misalnya

katakanlah Anda mengatur peringatan di sepanjang baris movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn . ini akan memverifikasi ambang batas pada semua server web Anda di kluster yang diberikan, dan menghasilkan peringatan untuk setiap pelanggaran seperti movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! .
mungkin kami dapat memungkinkan Anda untuk mengatakan "bidang pertama adalah nama cluster, yang ke-2 adalah nama host", dll, sehingga peringatan dapat berisi informasi yang lebih baik.
tetapi intinya adalah, _outcome_ yang memperingatkan berisi informasi yang Anda butuhkan untuk mengidentifikasi entitas mana yang mengalami masalah, tetapi itu berada di luar cakupan grafana. Grafana akan lebih menjadi sumber konfigurasi aturan peringatan, dan dasbor grafana dapat dikonfigurasi untuk memuat anotasi dan apa pun yang Anda miliki untuk memvisualisasikan status peringatan, tetapi tidak akan memiliki gagasan tentang konsep tingkat tinggi seperti host atau cluster. Saya pikir ini adalah sesuatu yang bisa ditangani di penangan yang memperingatkan

@Dieterbe

Ada dua jenis masalah pengguna/organisasi saat membangun fitur peringatan:

• Startup seperti, di mana mereka umumnya tidak punya waktu untuk membangun solusi peringatan mereka sendiri. Semuanya akan mengandalkan Grafana untuk waspada pada metrik
• Organisasi teknik yang mapan, mereka memiliki alat peringatan yang sudah ada, peringatan untuk aturan bisnis dibangun berdasarkan sinyal peringatan granular lainnya (Grafana akan menjadi salah satunya).

Grafana harus bekerja dengan praktik operasi mapan yang ada, karena berada di luar siklus mengabaikan tujuan peringatan - memiliki pandangan yang jelas tentang kesehatan entitas kritis bisnis. Peringatan lebih baik dipusatkan untuk memungkinkan membangun keadaan lingkungan yang jelas. Sangat penting untuk mengizinkan pengguna yang kuat menggunakan grafana API (atau solusi lain apa pun) untuk mengekspor aturan peringatan ke sistem lain.

Saat mengatakan operasional, setiap peringatan secara opsional harus berisi bidang dokumentasi/tautan untuk menjelaskan tujuan peringatan & perilaku historis.

@activars saya pikir saya setuju dengan semua itu. dalam pandangan saya, kami mengambil pendekatan yang mendorong memasukkan grafana ke seluruh lingkungan (terutama berkat pemisahan masalah, dengan penangan yang dapat dipasang). apakah menurut Anda desain yang diusulkan dapat ditingkatkan dengan cara apa pun?

Saya pikir @ deebs031 membuat poin bagus yang belum banyak dibahas "aplikasi yang dibangun untuk pengguna akhir perlu memberikan peringatan yang ditentukan pengguna".
IMHO graal adalah pemantauan berbasis metrik layanan mandiri , dalam kasus saya Grafana menjadi ujung depan utama bagi orang-orang yang ingin melihat metrik, masuk akal untuk memungkinkan mereka membuat peringatan untuk diri mereka sendiri dalam hal yang sama - mari kita hadapi itu AWESOME- UI.
Saya pribadi telah melakukan peringatan Sensu berdasarkan metrik tetapi menyediakannya sebagai layanan mandiri benar-benar bukan hal yang mudah dibandingkan dengan betapa mulusnya jika terintegrasi dengan Grafana. Saya juga melihat Cabot karena memiliki kemampuan visualisasi tetapi belum dibangun dengan mempertimbangkan layanan mandiri sehingga tidak dapat menggunakannya apa adanya.
Saya berada di sisi "lakukan satu hal dengan baik" tetapi saya pikir dalam kasus khusus peringatan layanan mandiri berdasarkan metrik yang memasangkan kemampuan dengan lapisan visualisasi metrik sangat masuk akal:

• Pengguna sudah terbiasa dengan UI
• Pengguna diautentikasi sehingga dia dapat membuat peringatan untuk dirinya sendiri atau skema izin apa pun yang memungkinkan otentikasi
• Pengguna dapat melihat grafik yang biasanya cukup berguna saat membuat lansiran berbasis metrik tersebut

slide presentasi grafanacon saya tentang peringatan:
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
mereka agak sulit dipahami tanpa konteks, video tersebut akan online dalam waktu sekitar seminggu, saya akan mempostingnya ketika sudah siap.

kami sekarang telah mulai membuat prototipe cara untuk menerapkan model peringatan/UI/definisi/dll. kami memiliki gagasan yang cukup bagus tentang alur kerja utama, meskipun 1 poin besar yang masih kami coba cari tahu adalah bagaimana integrasi dengan penangan peringatan pihak ketiga seharusnya terlihat.
pemikiran kami saat ini adalah bahwa Anda akan dapat menggunakan grafana untuk menetapkan ambang batas/aturan peringatan/menentukan pemberitahuan dan untuk memvisualisasikan status historis dan terkini dari aturan peringatan.

asumsinya adalah Anda ingin menggunakan perangkat lunak peringatan pilihan Anda (bosun/cabot/sensu/nagios/...)
jadi akan ada alat terpisah yang menanyakan grafana melalui API http-nya untuk mengambil semua aturan peringatan. alat itu kemudian dapat memperbarui konfigurasi bosun/cabot/sensu/nagios/... Anda, sehingga Anda dapat menggunakan perangkat lunak peringatan pilihan Anda untuk menjalankan dan menjalankan peringatan dan mengirimkan pemberitahuan.
tetapi kami ingin dapat memvisualisasikan status saat ini dan historis dengan benar, jadi program peringatan Anda harus dapat memanggil skrip atau webhook atau sesuatu untuk memberi tahu grafana tentang status baru, atau grafana harus menanyakannya. (yang tampaknya menjijikkan, mengingat sebagian besar alat tampaknya tidak memiliki api yang bagus)
ini semua agak rumit tetapi harus dengan cara ini untuk mendukung orang-orang yang penting bagi mereka untuk tetap dapat menggunakan perangkat lunak peringatan pilihan mereka, saat menggunakan grafana untuk mendefinisikan aturan peringatan dan memvisualisasikan keadaan.

Apakah penting bagi Anda untuk dapat menggunakan alat peringatan pilihan Anda saat ini?

hal lain yang ingin kami lakukan, juga menulis sendiri pelaksana peringatan sederhana, yang menanyakan grafana api untuk peringatan, menjadwalkan dan menjalankannya, melakukan pemberitahuan (itu akan mendukung email, slack, pagerduty, skrip khusus, dan mungkin beberapa lainnya) dan memperbarui status di grafana lagi.
akan cukup mudah untuk menulis bagi kami, mudah untuk Anda gunakan dan kami dapat memiliki interoperabilitas yang hebat.

Apakah pelaksana peringatan bawaan (lihat di atas) sesuatu yang menurut Anda cukup untuk menangani semua aturan peringatan yang Anda buat di grafana?

juga apakah Anda ingin dapat menggunakan beberapa penangan peringatan? yang ?

@jaimegago amin ;)

Bagi saya nomor 2 tampaknya lebih baik karena Anda benar-benar dapat meminimalkan jumlah hal yang harus Anda konfigurasikan agar semuanya berfungsi dengan lancar. Dalam pengaturan kami saat ini, kami akan melakukannya.

Begitulah yang dikatakan jika orang lain tidak setuju ;)

Edit cepat: Slide mengagumkan. Jika produk akhir keluar terlihat setengah sebagus itu maka itu luar biasa.

+1
Saya setuju bahwa pengendali notifikasi internal dengan integrasi ini sempurna! untuk kasus penggunaan yang paling umum.

Saya akan senang menjadi Pengujian Beta :) dan slide menjadi luar biasa!

Saya pikir posting terakhir @Dieterbe menjelaskan sedikit, tetapi saya ingin memposting diagram cepat ini untuk memperjelas lebih lanjut.

Peringatan di Grafana sebenarnya ada dua hal, konfigurasi peringatan swalayan (terima kasih @jaimegago , saya sendiri tidak bisa mengatakannya dengan lebih baik) dan pawang itu sendiri.

Kami akan mengirimkan penangan peringatan Grafana, tetapi juga menyediakan kerangka kerja untuk diintegrasikan dengan perangkat lunak peringatan pilihan Anda:

+1 untuk membangun semacam jembatan ke sistem peringatan lain (mungkin kita dapat berpikir untuk menerapkan beberapa sistem plugin peringatan umum :-))

Anda dapat menambahkan Prometheus juga pada bagian "Penangan Peringatan Eksternal". Versi alertmanager Prometheus pertama sedang diproduksi di beberapa perusahaan dan penulisan ulang lengkap saat ini sedang dikerjakan. SoundCloud mungkin menggunakan Grafana untuk mengonfigurasi peringatan, tetapi tentu saja hanya jika manajer peringatan Prometheus digunakan sebagai pengendali peringatan.

@grobie , tangkapan bagus, diperbaiki di komentar asli.

@mattttt @Dieterbe itu bagus! Sepertinya Anda berada di jalur "termasuk baterai tetapi dapat dilepas" yang merupakan yang terbaik dari kedua dunia. Sudahkah Anda memikirkan bagaimana Anda akan meneruskan data otorisasi ke penangan peringatan? Saya sedang memikirkan cerita seperti ini:
Sebagai pengguna Grafana saya ingin diberitahu melalui _email_ dan/atau _pagerduty_ dan/atau _foo_ ketika (beberapa kondisi dibangun melalui UI peringatan Grafana) terjadi.
Pengguna itu seharusnya hanya dapat mengirim peringatan ke sistem notifikasi yang dia otorisasi, ini adalah persyaratan untuk layanan mandiri dan entah bagaimana harus ditangani. Sejak Grafana 2 kami memiliki SQL backend + otentikasi/otorisasi pengguna dengan integrasi LDAP, jadi sepertinya tidak terlalu jauh untuk memiliki kemampuan itu sejak hari pertama peringatan?
Dengan Sensu (yang merupakan alat yang akan saya pasang) melewati target peringatan (misalnya alamat email) melalui handler harus cukup lurus ke depan, tidak bisa mengatakan tentang yang lain.

Halo semua,
Saya senang melihat bahwa kemampuan ini semakin maju, karena saya menyukai pendekatan konfigurasi lansiran swalayan.

Secara pribadi, saya tidak memerlukan penangan peringatan khusus. Saya ingin melihat penangan HTTP POST generik, yang baru saja dipicu segera setelah peringatan dilemparkan. Saya pikir sebagian besar admin dapat dengan cepat membangun sesuatu yang mampu menerima HTTP dan kemudian melakukan apa pun yang perlu mereka lakukan dengannya (mengirimnya ke nagios, riemann, younameit). Jadi saya akan senang dengan penangan HTTP yang mengirimkan semua informasi tentang peringatan sebagai data JSON.

Berbicara tentang peringatan melalui grafana, apakah Anda berencana untuk menambahkan sesuatu seperti deteksi mengepak? Atau apakah ini sesuatu yang harus diperhatikan oleh sistem pemantauan eksternal?

Pertahankan kerja bagus teman-teman!

Bersulang

Saya ingin melihat penangan HTTP POST generik, yang baru saja dipicu segera setelah peringatan dilemparkan. Saya pikir sebagian besar admin dapat dengan cepat membangun sesuatu yang mampu menerima HTTP dan kemudian melakukan apa pun yang mereka perlu lakukan dengannya (mengirimnya ke nagios, riemann, younameit)

jadi jika peringatan menyala (katakanlah "web123 memiliki cpu kritis menganggur!, nilai 1 lebih rendah dari ambang batas 15" ) dan kami melakukan posting http dari data itu, bagaimana Anda menanganinya di nagios? maksud Anda nagios akan menganggapnya sebagai pemeriksaan layanan pasif, dan kemudian nagios akan mengirim pemberitahuan?

Berbicara tentang peringatan melalui grafana, apakah Anda berencana untuk menambahkan sesuatu seperti deteksi mengepak? Atau apakah ini sesuatu yang harus diperhatikan oleh sistem pemantauan eksternal?

ini juga sesuatu yang perlu kita pikirkan lebih lanjut. Ini bisa menjadi berantakan dan jika orang menggunakan sesuatu seperti pagerduty atau flapjack maka mereka dapat menggunakannya untuk menggabungkan peristiwa/menekan duplikat jadi kami mencari apakah kami dapat menghindari penerapannya di grafana handler, meskipun kami mungkin harus melakukannya. Perhatikan juga bahwa karena Anda dapat menyetel lansiran pada ekspresi kueri metrik arbitrer, Anda akan memiliki banyak kekuatan untuk mempertimbangkan data sebelumnya dalam ekspresi aktual, sehingga Anda dapat membuat sinyal yang lebih kuat dalam ekspresi yang tidak sering berubah status.

jadi jika peringatan menyala (katakanlah "web123 memiliki cpu kritis menganggur!, nilai 1 lebih rendah dari ambang batas 15" ) dan kami melakukan posting >http dari data itu, bagaimana Anda menanganinya di nagios? maksud Anda nagios akan menerimanya sebagai> pemeriksaan layanan pasif, dan kemudian nagios akan mengirim pemberitahuan?

Agak. Saya sebenarnya menantikan grafana alerting untuk menyingkirkan nagios. Menggunakan penangan HTTP, Anda perlu mengonfigurasi pemeriksaan pasif untuk nagios agar dapat mengirimkan hasilnya di sana. Tetapi saya ingin memiliki grafana sebagai satu-satunya sumber tempat Anda dapat mengonfigurasi peringatan. Dalam kasus kami, orang yang diizinkan untuk menambahkan peringatan adalah sysadmin sebenarnya yang juga akan mengonfigurasi pemeriksaan di nagios.

Dengan http handler, grafana akan memiliki semua yang kami butuhkan untuk itu: dasbor untuk pemantauan waktu nyata, API, konfigurasi peringatan yang mudah, dan penangan http tempat kami dapat meneruskan peringatan ke sistem pemberitahuan internal kami.

Bersulang

Meskipun saya dapat melihat logika dalam strategi integrasi ini, saya tidak dapat tidak berpikir bahwa ini sedikit berlebihan. Untuk apa yang saya pahami (dan apa yang bisa saya baca di utas), satu-satunya alasan sebagian besar pengguna Grafana tetap menggunakan teknologi peringatan mandiri adalah karena Grafana tidak mengusulkannya. Jadi, tidak akan lebih "lean" untuk fokus terlebih dahulu pada bagian Grafana Alerting, dan mengembangkannya sebagai komponen yang berkomunikasi dengan sisa tumpukan melalui API, sehingga kontributor lain dapat meniru perilaku dan membuat adaptor tertentu nanti?

tl;dr: dengan berfokus pada membangun "baterai" sendiri terlebih dahulu, Grafana akan memiliki sistem peringatan berfitur lengkap, yang nantinya dapat berkembang menjadi layanan untuk integrasi dengan alat peringatan pihak ketiga.

Kekhawatiran kecil, jika ini belum ditangani. Sistem peringatan tradisional tidak berskala dengan baik untuk infrastruktur cloud, karena sumber daya sangat dinamis (disediakan & dihancurkan). Peringatan tentang metrik harus mendukung fitur yang menggoda atau mengelompokkan (dengan pengecualian pengecualian, terkadang beban kerja berbeda). Peringatan bertemplat atau dikelompokkan harus dapat menemukan kumpulan grup baru.

Terima kasih atas pembaruannya! Dalam kasus penggunaan saya, peringatan bawaan di Grafana adalah semua yang saya perlukan saat ini. Saya sudah tidak sabar menunggu Grafana alert.

Seperti yang saya janjikan di IRC, berikut adalah kasus penggunaan kami untuk ini:

Kami memiliki aplikasi Rails lama yang searches our logs untuk patterns dan memiliki
HTTP API untuk menjawab jika pattern telah melewati thresholds dan
dengan demikian memiliki status {OK,WARNING,CRITICAL} .

Threshold dapat berupa:

• status dari CRITICAL jika pattern ada sama sekali.
• bahwa status adalah WARNING jika pattern ditemukan lebih dari X kali
  dan status adalah CRITICAL jika ditemukan lebih dari Y kali.
• jika pattern berumur kurang dari 1 jam maka status adalah OK ,
  kurang dari 3 jam status adalah WARNING dan sebaliknya status adalah
  CRITICAL .

Jika saya memahami fitur ini dengan benar, Grafana akan mendukung penggunaan ini
pola (melalui Logstash dan Elasticsearch tentu saja) ketika fitur ini dan
sumber data Elasticsearch sepenuhnya diimplementasikan?

@Dieterbe @mattttt slide dan mock-up Anda terlihat sangat menakjubkan! Ini benar-benar pengubah permainan.
Bagi saya, handler peringatan Grafana internal akan paling sesuai dengan kebutuhan kita.
Alasan:

• Layanan mandiri - Sangat penting . Pengguna kami mengatakan dengan lantang dan jelas bahwa mereka ingin membuat lansiran sendiri dari ujung ke ujung di dalam Grafana.
• Alur kerja terpadu - Saya ingin meminimalkan bagian yang bergerak, bukan meningkatkannya. Seperti yang ditunjukkan oleh @Dieterbe , penangan peringatan pihak ke-3 akan membutuhkan setidaknya 4 langkah di mana penangan peringatan internal hanya membutuhkan 1 (mungkin 2 jika Anda perlu menentukan metode pemberitahuan untuk setiap ambang? - tidak yakin dari presentasi).
• Integrasi yang ketat dan tidak ada ketergantungan pada infrastruktur peringatan pihak ketiga.

Beberapa kekhawatiran:

• Berapa ambang batas pemeriksaan frekuensi?
• Bagaimana cara menangani frekuensi polling yang terlalu cepat untuk mendapatkan datanya kembali? Masuk, waspada dan antri atau dijatuhkan?
• Untuk penskalaan, khawatir bahwa Grafana mungkin tidak dapat mengikuti banyaknya pemeriksaan, frekuensi yang cepat dan terutama dengan latensi antar sumber data yang mungkin perlu kami tambahkan/skalakan server Grafana untuk mendukung peringatan internal. Saya tahu ini karena kami membutuhkan beberapa instance penangan peringatan pihak ke-3 sekarang. Dalam hal ini, bagaimana kita dapat menetapkan atau mengantri pemeriksaan ambang batas dengan mulus di antara sekelompok server Grafana, terutama jika pemeriksaan berasal dari sumber data yang sama? Dari pengalaman pengguna, saya ingin pengguna membuat ambang batas dengan mulus melalui klaster server Grafana yang seimbang beban tanpa meminta pengguna pergi ke instance Grafana yang "ditugaskan" untuk pemeriksaan tertentu.
• Untuk notifikasi, apakah ini mendukung beberapa jenis arsitektur plugin sehingga notifikasi dapat dengan mudah dikembangkan dan diintegrasikan? Secara umum kita membutuhkan sesuatu yang dapat melakukan HTTP POST. Ini paling umum dengan seperti PagerDuty, xMatters, VictorOps, Opsgenie, dll. Masing-masing memerlukan format yang sedikit berbeda, otentikasi, dll. Seperti yang disebutkan sebelumnya di utas ini, mungkin penangan HTTP POST generik akan bekerja yang akan mengirim ke layanan HTTP khusus yang mampu melakukan apa pun yang Anda inginkan dengannya. Atau, kemampuan skrip khusus juga akan berfungsi.
• Saya berasumsi ambang batas dapat ditetapkan, diambil, dan mendapatkan pelanggaran melalui API? Saya pikir ini akan membantu

Saya pikir itu ideal untuk dapat mengintegrasikan peringatan ke dalam sistem peringatan yang ada. Ada beberapa masalah yang sulit dan jelek seperti deteksi flap seperti yang disebutkan yang telah ditangani dan tampaknya sia-sia untuk menemukan kembali semuanya dari awal. Saya tidak suka melihat ini terkubur di bawah bobot fitur creep.

Tapi saya tidak berpikir ini benar-benar perlu integrasi yang erat ke semua penangan peringatan ini. Api yang baik dan terdokumentasi dengan baik harus memungkinkan orang yang akrab dengan sistem ini untuk berintegrasi dengan sedikit usaha. Jadi slide dengan 'grafana api -> handler' itulah yang terlihat menarik bagi saya.

Scott

Hai semua -- Saya datang terlambat ke diskusi ini, tetapi saya memiliki beberapa keahlian tentang topik ini, dan saya adalah pengembang utama dari salah satu alat yang telah mencoba memecahkan masalah peringatan. Alat kami, StatsAgg sebanding dengan program seperti bosun. StatsAgg bertujuan untuk mencakup peringatan fleksibel, penangguhan peringatan, dan pemberitahuan & cukup matang/stabil pada saat ini (meskipun API belum siap).

Bagaimanapun, beberapa pemikiran tentang masalah peringatan:

• Peringatan oleh metrik individu menyebalkan. Saya bekerja di perusahaan yang mengelola ribuan server, dan harus membuat/mengonfigurasi/mengelola peringatan terpisah untuk setiap rangkaian metrik 'ruang disk kosong%' secara logistik tidak layak. Alat pemantauan perusahaan sering kali mengikat beberapa rangkaian metrik bersama-sama dengan ekspresi reguler (atau hanya ekspresi karakter pengganti). StatsAgg dibangun di atas premis yang sama; beberapa rangkaian metrik diikat menjadi satu, lalu kelompok metrik memiliki pemeriksaan ambang batas peringatan yang dijalankan terhadapnya oleh satu 'lansiran'. Pada skala, kemampuan semacam ini adalah suatu keharusan.
• Jika seseorang menerima pernyataan saya sebelumnya bahwa alat peringatan tidak boleh memperingatkan metrik individual, maka alat tersebut harus memiliki mekanisme untuk dengan cepat mendapatkan daftar metrik yang memenuhi syarat & nilai metrik. Banyak alat mengandalkan penyimpanan data kueri untuk mendapatkan daftar metrik & nilai metrik, dan solusi ini sejujurnya tidak berfungsi dengan baik dalam skala. Logika peringatan, pada dasarnya, perlu sering dijalankan (setiap X detik, atau saat setiap titik data kualifikasi baru masuk). Penyimpanan data (grafit, opentsdb, influxdb, dll) tidak dibuat untuk menangani kueri konstan 'beri saya daftar metrik saat ini yang sesuai dengan pola ini' dan 'tunjukkan nilai X terakhir untuk metrik Y ini'. Mereka juga tidak memiliki bahasa API/kueri yang sesuai, atau mereka tidak dapat menangani beban. Untuk lebih jelasnya, saya berbicara tentang skala menjalankan logika peringatan terhadap 10.000 seri metrik ketika ada 10.000.000 seri metrik yang tersedia di datastore. Ini bukan kasus penggunaan semua orang, tetapi ini milik perusahaan saya.
• Saya telah menemukan bahwa mengatasi masalah melalui pemrosesan aliran adalah satu-satunya cara yang layak untuk mengatasi masalah yang diangkat oleh poin-poin terakhir saya. Itu sebabnya StatsAgg dibangun untuk duduk di depan datastore. Logika peringatan dapat berjalan melawan metrik tanpa menyentuh penyimpanan data, dan metrik hanya melewati penyimpanan data. Konsep utama dari pendekatan ini adalah bahwa 1) peringatan yang baru dibuat tidak dapat/tidak akan menggunakan nilai metrik lama/yang diarsipkan untuk evaluasi peringatan 2) jika program pemrosesan aliran (ex- StatsAgg) mogok, maka titik data tidak berhasil ke dalam penyimpanan data 3) nilai metrik yang diperlukan untuk evaluasi peringatan disimpan dalam memori, yang dapat menjadi masalah stabilitas server. 4) program pemrosesan aliran harus dapat mendekonstruksi & merekonstruksi metrik yang masuk (yang tidak dibuat mudah oleh InfluxDB selama setahun terakhir ...). Bahkan dengan kesombongan ini, solusi ini telah bekerja sangat baik untuk perusahaan saya, dan dalam skala yang sangat besar. Terkadang kami memiliki 200.000+ seri metrik langsung, rata-rata 30k+ metrik masuk/dtk, ratusan peringatan yang mengevaluasi ribuan seri metrik, dan server yang menjalankan StatsAgg yang nyaris tidak berkeringat. Sementara itu, datastore tidak ditanyai sama sekali.

Itu adalah hal-hal utama yang ingin saya sebutkan. Ada banyak aspek penting lainnya untuk disiagakan juga (pemberitahuan, penangguhan, dll), tetapi solusi tersebut mudah diterapkan setelah arsitektur masalah inti terpecahkan. Saya menyadari bahwa skala kebutuhan kita tidak sama dengan rata-rata pengguna, tetapi semoga Anda semua dapat menghargai perspektif ini.

Saya ingin menyarankan peluncuran dengan penangan notifikasi yang dapat mengirim data ke Alerta: https://github.com/guardian/alerta

Alerta memiliki REST API yang sangat waras untuk menerima notifikasi.

Saya lebih suka implementasi lean grafana saja!
Saya pikir ini layak untuk dievaluasi kembali setelah semua orang memiliki pengalaman dengan fitur ini di Grafana UX yang fantastis.

Akan ada banyak kasus kompleks dan/atau sistem backend khusus yang ingin diintegrasikan oleh orang-orang. Anda dapat melihat banyak di utas ini, kebanyakan open source, tetapi ada begitu banyak produk komersial di luar sana juga! Jangan repot-repot dengan penangan individu - itu akan menjadi tikus utuh dan Anda akan selalu dalam mode penangkapan

Saya sangat menyarankan untuk menerapkan hanya dua jenis penangan. Salah satunya pasti HTTP POST, itu akan menjadi alat yang paling serbaguna dan fleksibel. Yang lainnya adalah skrip khusus, sehingga pengguna dapat menerapkan integrasi dengan alat pilihan khusus mereka. Model plugin tidak buruk, tetapi memaksa untuk menggunakan bahasa plugin tertentu yang membatasi. Skrip eksternal lebih baik - selama Anda meneruskan ke skrip semua detail skrip dapat ditulis dalam bahasa apa pun - skrip shell, Python, dll.

Saya bersama @007reader

Saya setuju. Selama metode integrasi umum disediakan, implementasi kustom dapat berupa proyek atau penerapan yang terpisah.

Misalnya, rilis CloudWatch baru-baru ini layak, namun saya ingin menjadikannya sebagai proyek terpisah hanya dengan menyinkronkan metrik yang dipilih ke penyimpanan alternatif. Ini akan memberi kami retensi penuh, bukan hanya data 2 minggu.

Hai semuanya,
video presentasi grafanacon saya sedang online!
ada di https://www.youtube.com/watch?v=C_H2ew8e5OM
saya pikir itu akan menjernihkan banyak, meskipun seperti yang Anda lihat. spesifikasi integrasi masih harus diketahui dan juga merupakan topik yang ingin didiskusikan banyak orang. (walaupun waktu terbatas dan saya meminta orang-orang untuk melanjutkan percakapan di sini sehingga semua orang dapat berpartisipasi)

@simmel ya persis. Anda akan menggunakan kueri ES dan menetapkan aturan tentang itu.
@activars pengelompokan ulang dan penemuan, saya pikir banyak dari itu akan bergantung pada sumber data Anda, tetapi persyaratan paling umum harus ditangani jika Anda menggunakan sesuatu seperti grafit atau ES yang saya tahu sangat pandai "menemukan otomatis" metrik/seri yang sebelumnya tidak terlihat /documents yang cocok dengan ekspresi yang diberikan (dengan wildcard) untuk grafit atau kueri (untuk ES). tidak yakin tentang sumber lain. komentar Anda tentang perlunya menerapkan pengecualian pada aturan adalah yang lebih rumit, kami mungkin perlu mengatasinya di beberapa titik, tetapi saya pikir itu bisa menunggu sampai semuanya lebih jelas dan lebih tenang. mungkin kita bisa menghindari kebutuhan itu entah bagaimana.
@mgravlin frekuensi akan menjadi pengaturan dalam aturan, berurusan dengan sumber data yang terlalu lambat, belum yakin. tapi jangan lakukan itu ;-). juga tergantung pawang. penyebaran skala harus dimungkinkan, juga dengan penangan yang disertakan jadi cukup yakin kita akan melihatnya. tapi mungkin bukan prioritas untuk rilis pertama. ya, plugin notifikasi akan menjadi kunci dan kami akan memastikan Anda dapat menggunakan apa yang Anda inginkan/butuhkan. re api : iya :)
@sknolin jika saya mengerti dengan benar, dalam pandangan Anda, grafana akan melakukan penjadwalan peringatan, eksekusi, memicu kait pemberitahuan dll, bahkan ketika menggunakan sistem lain seperti nagios/bosun. lalu apa sebenarnya peran dari sistem eksternal (nagios/bosun/...) . ini sepertinya juga mirip dengan apa yang dibicarakan @Crapworks .
@jds86930 StatsAgg terlihat cukup menarik. Saya pikir di sini juga integrasi dengan grafana akan masuk akal. Saya pikir pemrosesan aliran adalah pendekatan yang valid yang memiliki tempat sebagai alternatif untuk kueri berulang. tetapi yang terakhir hanya lebih sederhana untuk memulai dan lebih sederhana secara umum saya pikir. Tapi keduanya harus didukung. Jadi ya di grafana Anda akan dapat mengatur pola/kueri yang cocok dengan spektrum data, dan berpotensi mencakup seri/data baru saat ditayangkan. dalam pandangan kami, Anda hanya akan memanfaatkan fungsionalitas apa pun yang dimiliki sumber data Anda (misalnya grafit cukup bagus dalam hal ini dengan wildcard, ekspresi glob dll, dan data kaya elasticsearch dan model kueri), atau jika seseorang akan menggunakan grafana+StatsAgg mereka bisa cukup gunakan StatsAgg untuk menyelesaikannya. Apakah Anda mengatakan grafana sendiri harus melakukan sesuatu yang spesifik di sini? Saya pikir jika sumber data Anda tidak cukup cepat, selesaikan masalah sumber data. dapatkan sesuatu yang lebih cepat, yang memiliki caching untuk metadata metrik, mungkin server memori di depan atau pemrosesan aliran. tapi bagaimanapun juga sejauh menyangkut Grafana, tidak banyak perubahan yang bisa saya pikirkan?
@blysik ya terlihat menarik. begitu banyak alat peringatan di luar sana yang harus kita integrasikan dengan :) untuk memperjelas, apakah Anda menyukai gagasan mengelola aturan peringatan dan memvisualisasikannya di grafana seperti yang disajikan sejauh ini, tetapi Anda ingin menggunakan alerta untuk mengurus pemberitahuan ? akan alerta menjadi tempat utama di mana Anda pergi melihat keadaan peringatan Anda (yang sepertinya hal yang wajar untuk dilakukan), tetapi ingin memastikan saya sepenuhnya memahami bagaimana Anda melihat integrasi.

@007reader , @shanielh , @activars hanya untuk memperjelas, integrasi ini melalui posting atau skrip HTTP generik, apa yang akan menjadi tujuannya. untuk memberi tahu sistem eksternal "ada aturan baru, ini kueri, ambang batas, frekuensi, dll. Sekarang silakan jalankan" ? atau akankah grafana menjadi hal yang menjalankan aturan dan kemudian memperbarui sistem eksternal dengan status baru?

@blysik ya terlihat menarik. begitu banyak alat peringatan di luar sana yang harus kita integrasikan dengan :) untuk memperjelas, apakah Anda menyukai gagasan mengelola aturan peringatan dan memvisualisasikannya di grafana seperti yang disajikan sejauh ini, tetapi Anda ingin menggunakan alerta untuk mengurus pemberitahuan ? akan alerta menjadi tempat utama di mana Anda pergi melihat keadaan peringatan Anda (yang sepertinya hal yang wajar untuk dilakukan), tetapi ingin memastikan saya sepenuhnya memahami bagaimana Anda melihat integrasi.

Benar. Alerta akan menjadi pusat notifikasi kami. Segala macam hal mengirimkan peringatan ke dalamnya. Misalnya: Skrip khusus, Cabot, Zenoss, vCenter, dan mungkin Grafana. Itu memberi ops satu tempat untuk melihat semua peringatan. Dan kemudian itu adalah satu-satunya tempat yang mengarahkan notifikasi ke teknisi panggilan.

@sknolin https://github.com/sknolin jika saya mengerti dengan benar, di Anda
lihat, grafana akan melakukan penjadwalan peringatan, eksekusi, pemicu
kait pemberitahuan dll, bahkan ketika menggunakan sistem lain seperti
nagios/bosun. lalu apa sebenarnya peran sistem eksternal
(nagios/bosun/...). ini sepertinya juga mirip dengan apa yang @Crapworks
https://github.com/Crapworks bicarakan.

Saya kira saya tidak menjelaskan dengan baik. Bukan itu yang saya inginkan, bukan grafana
melakukan semua hal itu. @Crapworks (itu menyenangkan untuk mengetik) berbicara pasif
pemeriksaan layanan, saya hanya menggunakan polling aktif.

Jadi yang saya inginkan hanyalah api tempat saya dapat membaca status peringatan grafana.
Sistem eksternal melakukan segalanya.

Itu tidak berarti jika itu tidak berkembang menjadi jenderal yang hebat
alat peringatan saya tidak akan menggunakannya. Hanya apa yang akan saya lakukan sekarang.

Scott

@sknolin

Jadi yang saya inginkan hanyalah api tempat saya dapat membaca status peringatan grafana.

bagaimana status itu diperbarui di grafana? proses apa yang akan mengeksekusi peringatan dan memperbarui status di grafana?

Setiap kali disurvei, grafana memperbarui status peringatan, dengan semacam interval caching untuk menangani beberapa sistem yang melakukan polling.

Saya melihat titik bahwa ini masih membutuhkan grafana untuk melakukan logika untuk peringatan dan menyajikannya. Jadi memikirkannya, tidak, saya tidak perlu peringatan apa pun.

Saya rasa saya dapat melakukan peringatan apa pun yang diperlukan jika saya dapat mengambil nilai metrik saat ini pada panel grafik. Misalnya, di mana kita memperoleh nilai dari jumlah beberapa metrik penghitung dan membuat grafiknya, akan lebih baik jika kita melakukan polling untuk nilai saat ini dengan sistem pemantauan. Mungkin itu benar-benar bisa dilakukan sekarang dan saya hanya bersikap tumpul.

Scott

@Dieterbe Yang terakhir :

grafana menjadi hal yang mengeksekusi aturan dan kemudian memperbarui sistem eksternal dengan status baru

@Dieterbe Saya setuju bahwa polling sumber data (Graphite, OpenTSDB, dll) menggunakan sintaks kueri asli sumber data adalah yang paling sederhana/termudah & mungkin cara tercepat untuk mendapatkan beberapa bentuk peringatan asli ke Grafana. Bagi banyak orang, solusi semacam ini akan memenuhi kebutuhan mereka, dan saya pikir ini adalah solusi terbaik untuk implementasi awal Grafana (menurut saya). Poin utama saya adalah bahwa ada batas untuk konfigurasi & kinerja peringatan yang akan sulit diatasi dengan model 'polling the datasource'.

Dalam hal arah yang dapat ditempuh Grafana untuk solusi peringatan jangka panjang, saya dapat melihat beberapa opsi:

• Bekerja sama dengan pengelola datastore untuk membangun API yang dibuat dengan tujuan lebih cepat/lebih baik untuk kasus penggunaan peringatan. Saya tidak menyukai opsi ini karena banyak dari proyek tersebut bergerak dengan kecepatan yang lebih lambat (berbulan-bulan hingga bertahun-tahun) & mereka mungkin tidak menerima sebagian/semua permintaan peningkatan. Mereka mungkin juga ingin membuat kode dalam bahasa asli datastore mereka, yang tidak selalu merupakan bahasa cepat (ex- Graphite in python).
• Bangun lapisan pemrosesan aliran/caching untuk setiap penyimpanan data sebagai proyek tangki hujan yang terpisah. Saya pikir ini pada akhirnya akan memiliki hasil yang lebih baik daripada mencoba membujuk berbagai pengelola datastore untuk membangun solusi untuk proyek mereka. Ini juga akan memungkinkan Anda untuk terus memperluas pekerjaan yang sudah Anda lakukan (menggunakan mekanisme kueri penyimpanan data yang ada). Anda bahkan dapat membuat API kustom Anda sendiri ke dalam lapisan pemrosesan aliran/caching yang dapat menyederhanakan sintaks kueri Grafana ke penyimpanan data.
• Tetap dengan solusi asli yang sedang Anda upayakan & buat itu bekerja dengan baik. Alat pihak ke-3 seperti StatsAgg, bosun, dll akan ada untuk kasus penggunaan yang lebih menuntut/khusus/kompleks. Memiliki Grafana terintegrasi dengan alat-alat ini pasti akan menjadi manfaat tambahan bagi pengguna, tetapi akan menambah kompleksitas non-sepele untuk Grafana. Yang mengatakan, sepertinya Anda mungkin akhirnya melakukan ini (saya sedang melihat 'Alerting Backends' pada slide 35 presentasi Anda sekarang). Saya pribadi terbuka untuk menerapkan serangkaian API yang ramah-Grafana di StatsAgg; kita hanya perlu mencari tahu apa itu API & mendapatkan beberapa dokumentasi protokol API yang dirancang. Jangan ragu untuk mengirim pesan/email kepada saya jika Anda ingin mendiskusikan semua itu.

Halo semua,

@Dieterbe Saya baru saja menonton presentasi Anda dan hal-hal terlihat luar biasa. Saya sangat menghargai bahwa Anda mencoba membangun sistem peringatan dengan cara yang "benar", menggunakan banyak masukan dari komunitas! Terima kasih!

Saya juga ingin membuat poin saya sedikit lebih jelas, karena saya pikir itu tidak jelas apa yang saya coba katakan. Saya _JANGAN_ meminta grafana untuk mengetahui sistem pemantauan lain seperti Nagios, Icinga, Bosun, dll. Saya sebenarnya hanya membutuhkan ini:

• Antarmuka pengguna yang luar biasa yang Anda pamerkan dalam presentasi Anda atau apa pun yang terlihat saat sudah selesai sepenuhnya
• Handler HTTP POST generik (seperti yang disarankan beberapa orang lain di sini juga) yang sepenuhnya dapat dikonfigurasi (saya akan memberi Anda contoh nanti)

Alur peristiwa yang saya pikirkan:

• Anda memvisualisasikan data Anda di grafana
• Anda menambahkan ambang batas untuk memperingatkan di grafana
• Segera setelah ambang batas terlampaui, pengendali HTTP POST dipicu
• Sejak saat itu, pekerjaan grafana selesai

Seperti yang disebutkan @mgravlin dan @007reader , sebagian besar layanan pemberitahuan dan peringatan menggunakan HTTP POST, yang memerlukan berbagai jenis data. Jadi hal paling umum yang dapat saya pikirkan, adalah membiarkan pengguna menentukan data dan header POST mereka, sehingga Anda dapat memberi makan beberapa sistem dengan satu penangan, menggunakan templat yang berbeda. Contoh kode semu:

"notificator": {
    "httppost": {
        "data": {
            "host": "$hostname",
            "alert": "$alertname",
            "state": "$state"
        },
        "header": {
            "content-type": "application/json"
        }
    }
}

Memberikan variabel yang cukup kepada pengguna untuk digunakan di sini, akan cukup kuat untuk memberi makan banyak backend.

Dan lagi, dengan handler semacam itu, setiap sysadmin dengan beberapa pengetahuan pengkodean dapat membangun penerima posting http sendiri dan mengubah cara dia suka, misalnya, memberi umpan backend yang tidak mengerti posting http.

Karena ini tidak memiliki kewarganegaraan, ini juga diperkecil. Cukup tempatkan penyeimbang beban di depan backend/api/apa pun dan Anda siap melakukannya.

Setidaknya, ini akan menyelesaikan sebagian besar/hampir semua masalah saya;)

Bersulang

Terima kasih telah membangun fitur ini. Apakah ada perkiraan tanggal rilis untuk itu?

kata torkelo SEKITAR 3 bulan di IRC.
Jika saya memahaminya dengan benar, itu perkiraan yang sangat kasar dan harus diperlakukan seperti itu.

Saya senang dengan kemampuan untuk melakukan alerting dengan grafana. Saya pikir ini adalah satu-satunya fitur yang membuat grafana tidak menjadi alat pemantauan terbaik.

Jika Anda memiliki rilis alfa/beta awal, saya ingin menguji & memberikan umpan balik awal dengan data produksi.

++

aku 2 lol

+1

Seg, 16 de nov de 2015 21:03, Jing Dong [email protected]
escreveu:

Jika Anda memiliki rilis alfa/beta awal, saya ingin menguji & memberi lebih awal
umpan balik dengan data produksi.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
Jika Anda memiliki rilis alfa/beta awal, saya ingin menguji & memberikan umpan balik awal dengan data produksi.

+1 saya 2

21-11-2015 14:44 GMT-02:00 pemberitahuan [email protected] :

+1
Jika Anda memiliki rilis alfa/beta awal, saya ingin menguji & memberi lebih awal
umpan balik dengan data produksi.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279.

+1

bagus untuk melihat semua +1 tetapi FWIW mereka tidak terlalu dibutuhkan. kita sudah tahu bahwa ini adalah fitur baru yang paling ditunggu-tunggu, dan begitu kita memiliki kemajuan yang nyata, kode akan muncul di cabang terpisah yang dapat dimainkan oleh siapa saja. BTW kami juga membawa lebih banyak orang untuk bekerja penuh waktu di grafana jadi pantau terus semuanya :)

Ya tolong, ada 484 orang "menonton" masalah ini. Setiap kali Anda memberi "+1", 484 orang mendapatkan notifikasi email. Cukup berlangganan pemberitahuan dan itu akan menjadi indikasi minat Anda terhadap masalah ini.

+1 >; P

Pada Senin, 30-11-2015 pukul 10:33:52 -0800, Vadim Chekan menulis:

Ya tolong, ada 484 orang "menonton" masalah ini. Setiap kali Anda memberi "+1", 484 orang mendapatkan notifikasi email.

Maaf, saya tahu kalian bekerja sangat keras untuk ini. Apakah ada garis waktu untuk rilis pertama?

Saya akan sangat senang jika dapat mengonfigurasi metrik dan ambang peringatan (baik melalui antarmuka web atau API) dan cronjob/daemon Grafana yang memeriksa metrik ini dan melakukan HTTP POST dengan JSON atau menjalankan skrip dengan JSON di stdout. Akan _sangat_ mudah bagi individu untuk menulis skrip python sederhana yang meneruskan informasi ini ke Pagerduty, Slack, IRC, SMS, email, atau apa pun.

Sementara saya akan sangat menghargai kenyamanannya, saya tidak berpikir itu tugas Grafana untuk berintegrasi erat dengan alat pihak ketiga, dan lebih suka melihat implementasi minimalis lebih cepat daripada yang disempurnakan nanti.

Saya sangat setuju dengan @anlutro . Harap berikan sesuatu yang sederhana untuk memulai. Hal yang paling menarik bagi saya adalah memungkinkan orang-orang untuk mengatur sendiri alert sederhana (self-service). Grafana tidak boleh mencoba mengganti solusi peringatan/peningkatan yang ada.

Saya setuju dengan @anlutro juga. Tetapi alih-alih hanya menyediakan api sederhana, mintalah bagian peringatan yang dapat menangani plugin khusus yang berinteraksi dengan api. Dengan begitu paket dasar dapat mencakup email, pagerduty dan beberapa lainnya kemudian komunitas dapat menambahkannya sesuai kebutuhan. Mirip dengan bagaimana plugin Logstash ditangani sekarang.

+1

Ada berita tentang sistem peringatan? Ada perkiraan?

+1

+1
Layak untuk disebutkan mekanisme hit dan histeresis bekerja pada peringatan yang dikumpulkan sebagai konsep yang perlu dipertimbangkan.

Pernahkah Anda memikirkan fitur peringatan lanjutan seperti deteksi anomali, deteksi korelasi, deteksi akar penyebab, dll?

+1. Peringatan sebagai subsistem plugin - ini akan menjadi solusi paling fleksibel. Tidak perlu menambahkan begitu banyak fitur di dalam grafana jika ada banyak proyek yang dapat melakukan ini dengan lebih baik di backend.

@Dieterbe @torkelo Akan sangat bagus untuk memiliki "dugaan" yang sangat kasar tentang ini. Secara pribadi saya telah bertahan karena peringatan layanan mandiri berbasis metrik adalah fitur yang sangat dibutuhkan dalam kasus saya dan saya yakin Grafana adalah ujung depan pengguna yang tepat untuk itu. Masalahnya adalah, sekarang sudah 6 bulan dan belum ada pembaruan ETA atau bahkan komentar dari salah satu dari Anda cukup lama jadi saya mulai memiliki pemikiran kontra produktif "Saya hanya harus meretas sesuatu". ..Jika saya bisa tahu apakah itu akan menjadi 6 bulan lagi versus beberapa minggu lagi, saya bisa membuat keputusan yang jauh lebih baik.

Terima kasih!

+1
Pada 18 Jan 2016 21:54, "Jaime Gago" [email protected] menulis:

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo Akan sangat menyenangkan untuk memiliki yang sangat kasar
"tebakan" tentang ini. Secara pribadi saya telah bertahan sejak metrik
peringatan layanan mandiri berbasis adalah fitur yang sangat dibutuhkan dalam kasus saya dan saya
yakin Grafana adalah ujung depan pengguna yang tepat untuk itu. Masalahnya, sekarang
sudah 6 bulan dan belum ada pembaruan ETA atau bahkan komentar dari salah satu
Anda cukup lama jadi saya mulai memiliki "Saya hanya harus
meretas sesuatu" melawan pikiran produktif ... Jika saya bisa tahu apakah itu
akan menjadi 6 bulan lagi versus beberapa minggu lagi saya bisa menghasilkan banyak
keputusan yang lebih baik.

Terima kasih!

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684.

+1

+1

@jaimegago sangat menyesal karena tidak memperbarui di sini tentang kemajuan kami atau kurangnya kemajuan dalam masalah ini. Kami pikir kami akan punya waktu untuk dihabiskan untuk ini tetapi selalu berakhir didorong karena sesuatu dengan prioritas lebih tinggi menghalangi.

Kembali pada bulan September saya mulai mengerjakan dukungan sumber data Elasticsearch yang menjadi dasar untuk rilis 2.5 yang berfokus pada sumber data, setelah itu masalah berperingkat teratas di Grafana sejak v1 adalah panel tabel, dan terutama setelah dukungan Elasticsearch saya merasakan rilis kecil dengan tabel panel lebih penting daripada waspada sehingga menjadi dasar untuk 2.6.

Akhir-akhir ini kami memiliki banyak pengguna dan perusahaan yang ingin lebih berintegrasi dengan Grafana yang telah mendorong kami untuk berupaya meningkatkan api dan kemampuan plugin, yang mengakibatkan penundaan lain untuk masalah ini. Saya benar-benar menyesal bahwa kami telah mengomunikasikan hal ini dengan sangat buruk. Kami selalu memiliki ambisi untuk memulai SEGERA, tetapi SEGERA didorong lagi dan lagi :(

Tapi ada harapan! Kami telah memperluas tim fokus Grafana penuh waktu, pada bulan Desember @bergquist bergabung dan pada bulan Februari kami akan mendapatkan penguatan sekali lagi. Saya tidak dapat menawarkan ETA tetapi ini masih merupakan masalah prioritas tinggi dan kami ingin memulai secepatnya. Kami ingin fitur ini menjadi fitur utama untuk Grafana 3.0.

@torkelo Terima kasih atas pembaruannya; Saya tidak bisa mengatakan saya bahagia, tapi setidaknya baru kita tahu di mana kita berdiri.

Satu pertanyaan yang tersisa adalah apakah 2.x akan mendapatkan lebih banyak rilis poin atau apakah 3.x akan menjadi rilis berikutnya. ;)

@RichiH mengenai rilis poin lain, tidak yakin tetapi kemungkinan rilis poin lain sebelum 3.0 akan dirilis pada bulan Februari.

@torkelo Terima kasih banyak telah meluangkan waktu untuk memberikan pembaruan terperinci.

mungkin ini sudah ada di roadmap, jika belum, harap pertimbangkan untuk menambahkan "POST" pada notifikasi.
Jadi kami dapat mengirimkan peringatan ke sistem yang berbeda untuk memprosesnya, seperti kafak

+1 untuk notifikasi SNMP!

+1 Saya pikir ini adalah fitur terbesar yang hilang dari Grafana untuk menjadikannya alat pemantauan yang layak (dan terbaik di kelasnya) untuk produksi.

+1

Adakah admin (@Dieterbe?) yang tersedia untuk mengunci komentar tentang masalah ini dari non-kolaborator? Jadi kita hanya akan mendapatkan konten menarik pada peningkatan fitur, dan bukan +1 yang tidak berguna itu...

Jika Anda tidak mengetahui fitur ini, berikut adalah tautan ke dokumen ad hoc GitHub .

Terima kasih :hati:

@Mayeu eh, sebagai salah satu "non-kolaborator" yang telah berkontribusi dengan lebih dari +1 untuk masalah ini dan di tempat lain saya tidak berpikir mengunci masalah ini untuk kolaborator adalah cara untuk pergi. Cukup buat filter cerdas di email Anda ;-).

Saya juga berpikir +1 memenuhi tujuan, menunjukkan jumlah dan penyebaran minat untuk ini (dan di tempat lain).
Apa yang hilang, mungkin, adalah tombol +1 di UI yang akan mengisi peran yang sama, tetapi tanpa semua pemberitahuan ke semua pelanggan.. jadi permintaan fitur untuk @github.

Kami menyimpang dari topik dan ini adalah pertama & terakhir saya akan menulis tentang ini.

Siapa pun yang tertarik dengan masalah ini harus berlangganan di kanan atas; itu akan memberi Anda informasi dan Anda tidak akan mengirim email ke semua orang.

Mengenai sistem pemungutan suara untuk mencegah akumulasi +1, lihat https://github.com/dear-github/dear-github - 27 hari basi dan tidak ada reaksi dari GitHub.

+1

Ada berita tentang ini?

Saya rasa belum ada berita tentang masalah ini. Tetapi hal yang baik tentang rilis Grafana berikutnya adalah:

Grafana akan mampu memberikan aplikasi/plugin khusus. Kemudian kita dapat menulis plugin/aplikasi peringatan kustom kita sendiri dan mengimpornya ke Grafana. Menulis aplikasi/plugin kecil ini akan menjadi kemenangan cepat sambil menunggu fitur peringatan besar.

Saya menyukai gagasan untuk mengonfigurasi peringatan di tempat yang sama dengan visualisasi. Momen luar biasa di https://www.youtube.com/watch?v=C_H2ew8e5OM tetapi apakah ada tanggal kapan akan dirilis?

videonya bagus, terima kasih!

beberapa umpan balik.

saya senang dengan gagasan ambang linier sederhana, dan kueri khusus lanjutan

pemberi tahu yang paling membantu:

• exec - bisa menggunakan sesuatu seperti ssh atau sendmail
• webhook - pengguna dapat membuat webcgi untuk mengambil web-hook untuk melakukan sesuatu...
• email - jalankan email sederhana dengan json dump dari data notifikasi.
• plugin... tidak terlalu dibutuhkan

api untuk menarik status peringatan... terasa seperti ide yang buruk,
namun api untuk menarik konfigurasi peringatan dalam format json dasar bisa jadi bagus.
dump json ini dapat diubah menjadi sesuatu yang mungkin berguna untuk diubah oleh sistem lain.

Tidak yakin apakah ini disukai atau tidak.. Tidak dapat menemukan tautan donasi di mana pun tetapi kontribusi seperti apa yang diperlukan untuk memasukkan ini ke v3 pada akhir bulan.. Kami benar-benar dapat menggunakan fitur ini tetapi sumber daya kami ATM terikat

+1

+1

Ini adalah fitur yang sangat dibutuhkan bagi kami di sini di Work Market.

Apakah fitur peringatan diluncurkan?

Tidak
Pada Kamis, 25 Februari 2016 pukul 23:13 kskaran94 [email protected] menulis:

Apakah fitur peringatan diluncurkan?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056.

Apakah aman untuk mengasumsikan fitur peringatan akan dirilis di musim panas?

_ketegangan meningkat_
Pada 26 Februari 2016 10:23, "Ian Ha" [email protected] menulis:

Apakah aman untuk mengasumsikan fitur peringatan akan dirilis di
musim panas?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869.

ada berita tentang ini?

+1

+1 akan menyenangkan untuk memilikinya, orang sudah menunggu sepanjang tahun atau bahkan lebih.

:+1: Saya menyukainya. Terima kasih atas video dan presentasinya, @Dieterbe. Apakah tersedia untuk pengujian/pengadopsi awal?

@torkelo Anda mengumumkan

Kami ingin fitur ini menjadi fitur utama untuk Grafana 3.0

Tetapi melihat changelog cabang 3.0 yang belum dirilis (1) tidak disebutkan tentang peringatan, haruskah saya mulai menangis atau apakah rencana masih memiliki fitur Alerting 3.0?

(1) https://github.com/grafana/grafana/blob/master/CHANGELOG.md

Kami membuat keputusan untuk mengembangkan sistem plugin untuk grafana 3 sehingga kami dapat merilis grafana 3, dan kemudian mulai bekerja pada peringatan, alih-alih menunda grafana 3.

@Dieterbe Tidak bisa mengatakan saya senang, tapi itu masuk akal. Tindak lanjut yang jelas adalah jika ada ETA-ish untuk memperingatkan; dan jika itu adalah fitur yang dikonfirmasi dan berkomitmen untuk 3.1.

Juga, sebagai solusi, http://alerta.io/ melakukan bagian dari apa yang saya ingin Grafana lakukan; orang yang menunggu fitur ini mungkin ingin mencobanya.

Apakah ada spek untuk plugin? Mungkin bagus untuk membangun sesuatu di
komunitas untuk menangani peringatan bertepatan dengan rilis versi 3?

beth
Pada 16 Mar 2016 8:44 pagi, "Richard Hartmann" [email protected]
menulis:

@Dieterbe https://github.com/Dieterbe Tidak bisa mengatakan saya senang, tapi itu
masuk akal. Tindak lanjut yang jelas adalah jika ada sesuatu yang ETA-ish untuk
memperingatkan; dan jika itu adalah fitur yang dikonfirmasi dan berkomitmen untuk 3.1.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe Saya pikir itu juga akan menyenangkan untuk memiliki kemampuan untuk membuat pemberitahuan di sisi klien. Misalnya pesan suara di monitor publik dengan dashboard, jadi Anda tidak perlu melihat dashboard untuk mengetahui bahwa ada beberapa masalah. Seperti peringatan suara Zabbix. Untuk tujuan ini saya menulis kode JavaScript sederhana yang memindai dasbor tertentu dan jika ada masalah, itu akan memberi tahu saya menggunakan Web Speech API . Untuk saat ini bekerja sangat baik untuk saya.

Bagaimana dengan menggunakan kapacitor sebagai backend untuk peringatan, scripting lauguage mereka sederhana dan sangat kuat? Atau bagaimana dengan dukungan untuk beberapa backend peringatan, dan memiliki abstraksi atas itu.

Sekarang 3.0 sudah keluar, saya sangat senang semoga ada alert di grafana. Peringatan akan menjadikan grafana alat utama.

Hai @Dieterbe ,

Seperti yang saya lihat dari versi ini https://github.com/raintank/grafana (yang Anda katakan memiliki paket peringatan), repo sekarang tidak digunakan lagi dan dikatakan semua pengembangan baru sedang berlangsung di https://github. com/raintank/worldping-api. Itu membuat saya bertanya-tanya apakah fitur peringatan ini masih dikembangkan atau telah direncanakan dan diubah untuk hal lain (seperti worldPing yang tidak terlihat seperti yang telah kita diskusikan di sini).

Hai @minhdanh , tujuannya selalu untuk menambahkan peringatan "dengan benar" ke dalam grafana, bukan hanya sebagai peretasan di fork khusus raintank, yang merupakan repo yang Anda maksud (dan itu hanya mencakup domain yang sangat sempit, meskipun mungkin masuk akal untuk menggunakan kembali beberapa kode itu setelah kami mulai mengerjakan penjadwal/pelaksana, yang dimiliki repo itu). Oleh karena itu, kami bekerja keras untuk membuat grafana begitu dapat dipasang untuk rilis grafana 3 yang akan datang. (dan sebagai hasilnya, memungkinkan kami untuk memindahkan kebutuhan kami sendiri ke dalam aplikasi mandiri, yang merupakan worldping-api yang Anda maksud).
Menjadi sangat jelas bahwa sebagai langkah pertama kita hanya perlu membangun UI untuk mengelola aturan dari dalam dasbor dan panel grafana Anda dan mengeksposnya melalui semacam api, sehingga plugin dapat menggunakannya untuk menjalankannya. Ini akan menjadi cara tercepat untuk mendapatkan peringatan. "baterai termasuk penjadwal/pelaksana" kemudian akan datang kemudian dan dapat menggunakan kembali beberapa kode yang Anda rujuk.

bagaimanapun, pertama-tama kita akan melakukan manajemen UI di grafana dan mengekspos aturan melalui API, dan kita akan mengambilnya dari sana.

Terima kasih @dieterbe.

Seperti biasa, ada pertanyaan tentang garis waktu yang kasar, meskipun itu hanya "tidak"
sebelum X".

Saya mengerti betapa menjengkelkannya pertanyaan ini sehingga ungkapan dalam
bagian kedua. Saya harap Anda mengerti betapa frustrasinya menunggu di sisi lain
sisi pagar bisa.

Richard

Dikirim melalui ponsel; maafkan saya singkat.

Halo semua,

saya harap tidak apa-apa bagi raintank untuk mengatakannya di sini, tetapi kami baru-baru ini memesan hampir satu bulan jam pengkodean khusus oleh raintank untuk bekerja pada peringatan. Jadi mengapa ini tidak akan menghasilkan fitur peringatan akhir dulu, kita akan melihat sesuatu segera muncul untuk meletakkan dasar untuk peringatan di grafana. Jika perusahaan lain akan mengikuti pendekatan kami atau juga individu yang menginvestasikan sejumlah uang ke dalam masalah ini, itu akan lebih mempercepat pemikiran dan prioritas.

@flyersa , terima kasih banyak atas kontribusinya! Bagaimana kita bisa meletakkan uang tunai juga?

Jon

Halo semua,

Saya tahu banyak yang menginginkan fitur ini, dan dengan senang hati saya melaporkan bahwa tim telah mulai mengerjakannya. Kami menjelaskan alasan keterlambatan kami di blog pengumuman Grafana 3.0 beta

Kami akan merilis peringatan dalam dua fase. Fase pertama akan memungkinkan pengguna untuk menentukan peringatan dan ambang batas mereka dalam UI Grafana. Grafana juga akan mengekspos definisi peringatan ini melalui API HTTP ke penjadwal pihak ketiga dan backend peringatan. Pada fase kedua, kami akan menyediakan layanan backend untuk menggunakan dan bertindak berdasarkan definisi ini, untuk solusi yang sepenuhnya terintegrasi.

Kami berharap bahwa fase pertama dirilis dalam hitungan minggu.

Kami mencoba menyeimbangkan profitabilitas dengan kecepatan, dan kami SANGAT menghargai dukungan komersial dari pelanggan kami seperti @flyersa. Jika orang lain ingin mendukung pengembangan fitur ini dan Grafana secara umum, harap pertimbangkan untuk membeli paket dukungan . Ini akan membantu kami mengembangkan perangkat lunak hebat yang 100% open source.

Kami akan bekerja sama dengan semua pelanggan yang didukung saat kami meluncurkan fitur tersebut, dan memastikannya memenuhi kebutuhan mereka dengan baik.

-raj dutt | ceo/pendiri | tangki hujan

Hai @nopzor1200 ,

Terima kasih atas pembaruan Anda. Apakah Anda memiliki perkiraan kapan peringatan akan tersedia?

Jelas, tidak mungkin untuk berkomitmen pada tanggal tertentu, tetapi kerangka waktu akan sangat dihargai (minggu, bulan, dll).

10x!

Hai guys, sangat bersemangat untuk ini. Inilah cara saya membayangkan untuk menggunakan ini, jika seseorang dapat memeriksa bahwa itu adalah pola standar/yang didukung, saya akan menghargainya.

• Setiap host yang ingin saya pantau memancarkan "Cek". Sebuah "Cek" terdiri dari:
  
  
  
  • nama host
  
  
  • stempel waktu
  
  
  • Negara, yang berupa 0=OK, 1=WARN atau 2=CRITICAL
  
  
• Pemeriksaan ini dapat berasal dari berbagai sumber arbitrer (skrip shell + cron, statsd/collectd, cek Nagios, dll.) dan akan diakumulasikan di Elasticsearch. Pemeriksaan yang sama mungkin memiliki konfigurasi yang berbeda pada host yang berbeda, tetapi ini akan buram untuk Grafana.
• Saya akan mengonfigurasi Grafana terhubung ke Elasticsearch dan untuk memperingatkan ketika ada cek yang datang dari Host mana pun yang memiliki nilai Status >= 1.
• Jika host baru bergabung dengan cluster, tidak ada konfigurasi yang diperlukan di Grafana; Grafana hanya akan melihat titik data apa pun dalam status 1 atau 2 terlepas dari mana asalnya.
• Jika sebuah host mati tiba-tiba dan berhenti mengirimkan cek, kita perlu mendeteksi ini. Untuk menangani ini, ketika sebuah host dijalankan, ia akan mendaftarkan cek master sebagai status "ON", dan nilainya hanya akan menjadi "OFF" ketika dihentikan secara normal. Dengan cara ini saya dapat mencari host "ON" yang belum mengeluarkan cek dalam X detik terakhir.
• Secara umum saya tidak akan menggunakan peringatan berbasis ambang batas pada data deret waktu di Graphana. Dengan kata lain, saya tidak akan melakukan "memeriksa apakah CPU Usage > 80%" dalam Grafana itu sendiri, melainkan, Grafana akan menerima cek "CPU Usage State" (0 / 1 / 2) dan waspada dalam 1 atau 2 status.

Hai @johnnyshields ,

Itu terlihat cukup bagus, tetapi alih-alih "0=OK, 1=WARN atau 2=CRITICAL" mengapa tidak menggunakan definisi level standar? Yang digunakan oleh syslog adalah standar de facto untuk hal-hal ini:

• Nilai -> Keparahan
• 0 -> Darurat
• 1 -> Peringatan
• 2 -> Kritis
• 3 -> Kesalahan
• 4 -> Peringatan
• 5 -> Pemberitahuan
• 6 -> Informasi
• 7 -> Debug

Dan memiliki konfigurasi (global?) untuk memberi tahu grafana level mana yang harus dipertimbangkan sebagai ambang batas peringatan.

Mengingat ini, saya akan menambahkan perubahan berikut ke posting Anda:

• waspada ketika ada cek yang datang dari host mana pun memiliki nilai Status >= CONFIGURABLE_ALERT_LEVEL.
• Grafana hanya akan melihat titik data apa pun dalam status >= CONFIGURABLE_ALERT_LEVEL terlepas dari mana asalnya
• Grafana akan menerima tingkat pemeriksaan dan peringatan "CPU Usage State" jika dikonfigurasi dengan benar.

@brunorey terima kasih, masuk akal!

Level dan status log adalah dua hal yang berbeda. Anda dapat memiliki pesan log 6-Informasi, tetapi bagaimana sesuatu dapat berada dalam status 6-Informasi?

Status OK, WARN, dan CRITICAL baik-baik saja, dan mungkin terlalu baik bagi mereka yang hanya peduli pada OK dan CRITICAL. Menambahkan lebih banyak status menambah kebingungan kecuali artinya dipahami secara universal, dan saya sarankan membatasi pada 3.

Mengenai hanya peringatan pada "status CPU >= WARN" vs. "CPU > 80%", saya menyampaikan bahwa beberapa orang ingin mempertahankan status 3-tingkat mereka dalam DB deret waktu sehingga mereka dapat melihat bagaimana status berubah dari waktu ke waktu. Orang-orang itu akan waspada berdasarkan data deret waktu negara bagian mereka. Orang lain akan ingin mengingatkan nilai CPU mentah yang lebih dari 80%. Intinya, memperingatkan data deret waktu adalah satu-satunya hal yang diperlukan.

Alasan saya memilih jatah status log integer daripada menggunakan data deret waktu secara langsung adalah karena saya ingin dapat mengontrol apa yang dianggap sebagai peringatan pada setiap node.

Misalnya, server pekerja secara rutin memiliki CPU mendekati 100%, dan itu bukan masalah -- saya ingin mereka menembakkan kecepatan penuh pada semua inti. Tetapi server web tidak boleh memiliki CPU di atas 20%. Jadi jika saya membuat CPU generik > 80% akan terlalu tinggi untuk web dan terlalu rendah untuk pekerja. (Ini hanya satu kasus).

@johnnyshields Saya tidak mengerti mengapa Anda tidak menggunakan peringatan berbasis ambang batas pada data deret waktu, IMO di situlah nilai (hanya?) yang sangat kuat untuk menambahkan peringatan ke grafana/grafit. Hal-hal gaya "cek" Anda terdengar lebih cocok untuk sesuatu yang sederhana seperti monit - apakah saya melewatkan sesuatu di sini?

Seperti yang dijelaskan di atas, saya memiliki banyak server dengan peran yang berbeda dan ambang batas yang berbeda per server. Pada akhirnya ini adalah pertanyaan apakah ambang batas ditentukan dalam Grafana atau di server itu sendiri, saya pikir server lebih mudah dalam kasus saya.

Selain itu, beberapa pemeriksaan adalah "ya atau tidak", misalnya apakah proses X berjalan, apakah ping ke port Y merespons, dll.

Dipahami. Terkadang menentukan status ini sederhana (>80%), dan terkadang rumit. Ketika kompleks, beberapa kode akan menentukan level dan mengirim level ke database TS. Itu adalah praktik umum, di mana data diubah menjadi informasi. Maksud saya adalah, tidak ada perbedaan dari rasa waspada.

Jika Anda memerlukan aturan yang rumit untuk lansiran Anda, jangan buat aturan ke dalam mesin lansiran, buat aturan ke dalam pipa TS untuk membuat data TS baru, dan lansirankan itu.

Sederhanakan sistem peringatan. Sembunyikan kerumitan di saluran TS.

Manfaat membuat data TS baru dalam pipeline vs. sistem peringatan berbasis aturan adalah membuat peringatan tetap visual dan sederhana untuk orang-orang yang mengatur dan mendapatkan peringatan. Ada visualisasi yang dapat dikirim melalui email atau sms yang menunjukkan hanya hal yang diperingatkan - bahkan jika itu adalah bagan keadaan sederhana di mana mereka melihat keadaan berubah dari WARN ke CRITICAL 20 menit yang lalu.

Saya pikir jika Anda ingin mengontrol apa yang dianggap layak waspada berdasarkan per-Host/peran, Anda sebaiknya menambahkan logika ke apa yang dianggap PERINGATAN dan apa yang dianggap CRIT karena Anda menambahkan 8 lapisan perincian ke tingkat keparahan peringatan.

Hampir semua sistem peringatan modern lainnya tampaknya telah berkumpul pada OK/WARN/CRIT, dan meskipun mungkin sebagian untuk menginginkan kompatibilitas dengan cek Nagios, saya pikir ide untuk membuatnya tetap sederhana lebih penting. Jika Grafana melakukan hal yang sama, integrasi dengan layanan alerting/monitoring lainnya akan lebih mudah. Misalnya, dalam kasus saya, saya mungkin akan memberi peringatan Grafana ke Sensu, yang kemudian akan mengirimkan email, pesan kendur, atau apa pun. Sensu hanya memiliki OK/WARN/CRIT sehingga perincian lagi akan sia-sia.

Setuju tingkat peringatan log tampaknya over-engineering. OK, Peringatkan, Crit mungkin melakukan pekerjaan untuk sebagian besar kasus.

Pada ambang batas peringatan, saya ingin dapat melakukan peringatan berbasis standar deviasi. Mereka paling berguna dalam praktik imo.

Pada 12 Mei 2016, pukul 08:49, RWhar [email protected] menulis:

@johnnyshields Saya tidak mengerti mengapa Anda tidak menggunakan peringatan berbasis ambang batas pada data deret waktu, IMO di situlah nilai (hanya?) yang sangat kuat untuk menambahkan peringatan ke grafana/grafit. Hal-hal gaya "cek" Anda terdengar lebih cocok untuk sesuatu yang sederhana seperti monit - apakah saya melewatkan sesuatu di sini?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub

Secara pribadi saya telah menantikan peringatan menggunakan data TS yang ada dimasukkan ke dalam grafit sebagai input, terutama menggabungkan statistik dari metrik aplikasi dari (melalui StatsD) dalam rentang waktu yang ditentukan.

Juga, akan lebih baik untuk memiliki opsi di mana peringatan dapat dipicu pada ambang batas dan interval tertentu melewati ambang batas - misalnya mengatur ambang peringatan "rpl_delay" 200 int 50 - akan menyebabkan peringatan pada 200, 250, 300 dll tanpa perlu secara manual menentukan tingkat ambang batas tambahan.

@johnnyshields Saya tidak mendapatkan perbedaan antara 1=PERINGATAN atau 2=KRITIS. Peringatan dipicu atau tidak dipicu. Anda berada di atas 80% atau tidak di atas 80%. Jadi saya hanya melihat dua status 0 dan 1.
Akan lebih baik juga jika Anda memiliki peringatan yang lebih cerdas di mana Anda dapat mendeteksi bahwa Anda telah berada di atas 80% selama 5 menit berturut-turut sehingga Anda tidak diperingatkan tentang lonjakan sementara. Bahkan yang lebih maju adalah hal-hal seperti ambang batas, di mana misalnya Anda memantau lalu lintas situs web Anda, dan Anda mendapatkan jumlah lalu lintas X dan perlahan-lahan meningkat katakanlah 1% per bulan, tetapi tiba-tiba Anda mendapatkan lonjakan lalu lintas 10% di jam. Anda juga ingin dapat memantau sebaliknya, dari penurunan lalu lintas yang tiba-tiba. Sesuatu yang mirip dengan https://github.com/etsy/skyline karena Skyline tidak berfungsi.

Teman-teman, posting saya di sini bukan tentang jumlah status peringatan yang tepat untuk digunakan - saya bertanya secara lebih umum "akankah Grafana akan mendukung status yang disebutkan sebagai kasus penggunaan peringatan?"

Karena ada ketidaksepakatan pada jumlah optimal (Nagios menggunakan 3, syslog menggunakan 7, beberapa orang menyukai 2, dll.) Grafana harus mendukung jumlah status yang berubah-ubah.

Hanya menyatakan kembali apa yang saya katakan sebelumnya bahwa saya percaya bahwa seharusnya hanya ada dua status untuk setiap peringatan yang dipicu 1 atau tidak dipicu 0. Jika Anda ingin tahu apakah Anda mendekati ambang batas, buatlah ambang tambahan untuk nilai yang lebih rendah.

Alasan untuk WARN vs. CRITICAL adalah bahwa tindakan yang Anda lakukan berbeda. Satu kelompok orang dan tindakan umumnya diberitahukan di WARN, dan kelompok lain / tindakan berbeda di CRITICAL.

Itu perbedaan yang cukup berharga, bahwa saya tidak ingin pergi dengan sistem 0-1.

@lorenwest jika Anda ingin pemeriksaan berbeda untuk ambang batas yang berbeda, buat ambang tambahan untuk grup terpisah itu.
jadi setiap ambang batas adalah 0 atau 1.
Misalnya alasan lain Anda ingin menyiapkan peringatan dengan cara ini adalah ketika Anda menginginkan E-Mail ketika ambang batasnya lebih besar dari 70% tetapi halaman ketika Anda lebih dari 80%. Sama seperti bagaimana Anda ingin kelompok terpisah. PERINGATAN vs KRITIS memiliki terlalu banyak ambiguitas.

@doanerock itu masuk akal. Mengizinkan jumlah peringatan yang berubah-ubah pada salah satu metrik atau peristiwa TS memungkinkan fleksibilitas tertinggi. Itu menyederhanakan definisi peringatan dengan tidak memiliki banyak tindakan untuk beberapa level.

jadi:

• metrik dapat memiliki jumlah status yang berubah-ubah (termasuk nilai desimal/deret waktu)
• metrik dapat memiliki beberapa tindakan peringatan yang dilampirkan ke metrik yang sama
• setiap peringatan adalah boolean benar atau salah -- baik dipicu atau tidak dipicu.

untuk memberikan contoh:

• Saya memiliki metrik tertentu dengan nilai 0 = OK, 1 = WARN, 2 = CRITICAL
• Saya mengonfigurasi 3 peringatan:
  
  
  
  • jika nilai = 1, tunjukkan bendera kuning di dasbor saya
  
  
  • jika nilai = 2, tunjukkan bendera merah di dasbor saya
  
  
  • jika nilai >= 1, kirimi saya email
  
  

Halo semua,

Saya tidak tahu apakah ini tempat yang tepat untuk bertanya tentang topik ini, tetapi saya akan mencoba cara apa pun terkait modul peringatan Grafana yang akan datang.
Di organisasi kami, kami memiliki semua sensor peringatan keamanan yang memberi makan Logstash/Elasticsearch untuk acara dan kami menggunakan Yelp/elastaler untuk mengeksekusi peringatan dengan pola tertentu dengan kriteria berikut:

"Match where there are X events in Y time" (frequency type)
"Match when the rate of events increases or decreases" (spike type)
"Match when a certain field matches a blacklist/whitelist" (blacklist and whitelist type)
"Match on any event matching a given filter" (any type)
"Match when a field has two different values within some time" (change type)

Selain itu ketika kriteria peringatan terdeteksi, kami mengeksekusi skrip python eksternal dengan argumen yang meneruskan argumen dari Elastalert ke skrip dengan informasi seperti bidang IP sumber/tujuan, bidang stempel waktu dan peristiwa, dan sistem NAC kami menangani dari sana.

Sekarang melihat modul Grafana Upcoming Alerting dan dengan Elasticsearch sebagai sumber data, saya bertanya-tanya apakah modul Grafan Alerting akan dapat bekerja sama seperti Elastalert dan akhirnya diganti dengan informasi yang diberikan di atas?
Mohon saran

Terima kasih

Saya tahu tim grafana sedang bekerja keras dalam hal ini, dan utas ini panjang tetapi saya ingin menunjukkan bahwa Kapasitor baru saja menggabungkan fitur yang akan sangat memudahkan pengembangan aplikasi konfigurasi peringatan frontend: influxdata/kapasitor#577

Sejauh yang saya pahami, tujuan di sisi Grafana adalah membuat backend peringatan dapat dicolokkan (sama seperti bagaimana Grafana mendukung beberapa toko TSDB) tetapi saya ingin menyebutkan dengan harapan bahwa Kapacitor mendapat dukungan kelas satu ketika fungsi peringatan Grafana dirilis. Sepertinya sangat cocok, seperti halnya InfluxDB + Grafana.

@thom-nic terima kasih atas tipnya Kapasitor persis seperti yang saya cari...

Riemann juga hebat dan sangat kuat. telegraf -> riemann (peringatan) -> influxdb <- grafana

Kami membuat kemajuan di cabang alerting_definitions.

Kami sekarang memiliki model aturan peringatan sederhana yang dapat Anda tentukan di UI dan melalui HTTP api. Anda dapat mengambil aturan, perubahan aturan, status aturan melalui HTTP api. Penjadwalan aturan peringatan sederhana dan eksekusi kueri dan eksekusi aturan juga mulai menyatu.

Satu hal yang menjadi tanda tanya besar bagi saya sekarang adalah jika model lansiran saat ini terlalu sederhana dan buntu. Maksud saya, memperluas model aturan peringatan di masa mendatang akan memerlukan perubahan ekstensif.

Model aturan saat ini:

description
query: #A  (referencing a query in the metrics tab)
aggregation: avg
timerange:  3600   (seconds from now to look back when fetching data)
frequency: 60  (how often to execute alert rule query and evaluation rule)
critLevel: 80
warnLevel: 50

Model penyimpanan ini diwakili di UI dan di tabel database sebenarnya. Ketakutan saya adalah bahwa model aturan sederhana ini tidak memanfaatkan data deret waktu dengan cukup baik. Anda tidak dapat menentukan ambang dinamis (di mana ambang itu sendiri adalah hasil dari kueri). Tentu saja ini
dapat ditambahkan kemudian, tetapi akan membutuhkan model aturan dan mesin eksekusi yang sangat berbeda.

Jadi ide saya adalah menghapus model sederhana ini dan menghasilkan model baru yang lebih kompleks dan dinamis yang nantinya dapat mendukung banyak kueri untuk rentang waktu yang berbeda.

Kueri Sederhana:

"alert": {
   "name": "CPU usage last 5min above 90%",
   "frequency": "1m",      
   "expr": "query(#A, 5m, now, avg)",
   "operator": ">",
   "critLevel": 90,
  },

// sekarang ke peringatan yang menggunakan ambang dinamis berdasarkan nilai yang diteruskan

"alert": {
   "name": "CPU usage last 5m is 20% higher compared to last 24hours avg",
   "frequency": "1m",
   "expr": "query(#A, 5m, now, avg) => percentDiff() => query(#A, 1d, now, avg)",
   "operator": ">",
   "critLevel": 20,
  },

Sekarang Anda mungkin mempertanyakan ini dengan menyatakan bahwa kami menciptakan kembali Graphite di sini, dan ekspresi seperti ini harus ditangani oleh TSDB. Tetapi tidak ada TSDB yang mendukung penghitungan dengan kueri untuk rentang waktu yang berbeda (timeShift hanya menggeser rentang waktu yang sama). Beberapa masalah dengan ambang dinamis adalah bagaimana memvisualisasikannya. Itu juga dapat membuat aturan peringatan lebih terpisah dari apa yang sebenarnya divisualisasikan di panel.

Saya tidak yakin bagaimana seharusnya tampilan GAL (Grafana Alerting Language). Haruskah itu hanya rantai ekspresi di mana setiap bagian dapat berupa kueri yang mengembalikan satu atau beberapa seri (setiap seri digabungkan ke satu titik), dan kemudian fungsi pengurangan atau persen opsional yang dapat dibandingkan dengan kueri lain. Seluruh ekspresi menghasilkan nilai yang kemudian dapat digunakan dengan operator dan tingkat kritik/peringatan untuk mendapatkan status peringatan.

Atau haruskah ekspresi berisi operator dan level?

Opsi lain akan menggunakan bahasa pemrograman lengkap dan melakukan:

expr: "
let last5mAvg = query(#A, 5m, now, avg)
let last24hAvg = query(#A, 1d, now, avg)

return percentDiff(last5minAvg, last24Avg)
"

@torkelo :

1. apakah Anda merancang ini sebagai komponen yang berdiri sendiri? Pada akhirnya Anda sedang membangun prosesor sinyal yang mirip dengan Kapasitor untuk Influxdb ** yang dengan sendirinya memancarkan sinyal (0 = "ok", 1 = "peringatkan", 2 = "crit"). apakah mungkin mengirim sinyal ini ke tempat lain selain Grafana, misalnya A) ke Nagios, atau B) menyalurkannya kembali ke DB?
2. demikian pula, apakah grafana memiliki opsi untuk tidak menggunakan mesin sinyal Anda di atas, melainkan menerima sinyal 0/1/2 dari sumber pihak ketiga seperti plugin Nagios, yang sudah banyak tersedia di alam liar?

** = diberikan Kapicator menggunakan pemrosesan aliran deret waktu sedangkan Anda adalah mesin berbasis polling, tetapi tetap memancarkan sinyal.

Terima kasih sudah meminta masukan.

Pendapat saya adalah menjaga agar peringatan grafana tetap sederhana, dan ukuran terbaik untuk kesederhanaan adalah visualisasi. Jika Anda tidak dapat memvisualisasikan lansiran sebagai garis pada grafik TS yang ada, itu terlalu rumit.

Serahkan kerumitan pada grafik TS. Jika lansiran memiliki kebutuhan yang lebih besar, buat kumpulan data TS lain berdasarkan kebutuhan tersebut, dan tempatkan lansiran pada grafik data tersebut.

Jika Anda hanya memiliki satu prinsip panduan, itu memerlukan visualisasi peringatan yang sederhana.

Masalah lainnya adalah "berapa banyak peringatan yang harus saya konfigurasi"? Topik ini telah dibahas di utas ini, dan saya berpendapat bahwa segera setelah Anda mulai menempatkan beberapa peringatan menjadi satu peringatan (peringatan, kesalahan, peringatan tinggi, kesalahan rendah, dll), Anda mulai kehilangan fleksibilitas. Peringatan dan kesalahan adalah hal yang berbeda - mereka memiliki tingkat yang berbeda, orang yang berbeda peduli tentang mereka, dan mereka memiliki metode pemberitahuan yang berbeda.

Buat lansiran tetap sederhana, dan biarkan orang memasukkan beberapa lansiran ke dalam grafik.

Saya pikir #3677 (Transformasi Umum pada Hasil Kueri Deret Waktu) akan sangat berguna di sini. Dengan fungsi independen TSDB tersebut, Anda dapat membuat "grafik peringatan" yang kompleks di mana Anda dapat menggunakan ambang batas nilai tetap sederhana untuk peringatan, kritik, dll.

Model aturan peringatan sederhana akan menjadi semua yang dibutuhkan saat itu. Kompleksitas ini kemudian "tersembunyi" dalam pembuatan dan kombinasi grafik.

Saya semua untuk tetap sederhana. Saya bukan dev, saya lebih ringan-touch-dev-ops, dan saya ingin dapat menyerahkan platform Grafana/Graphite saya kepada tim admin saya untuk dikelola. Karena itu, maka pembuat peringatan yang mirip dengan yang sudah ada akan jauh lebih mudah. Tidak terlalu repot jika memperkenalkan banyak instruksi baru selama aturan masih dapat dibangun dengan cara yang sama seperti kueri untuk grafik saat ini, itu akan mudah untuk dipahami.

tl; dr bahasa yang sama sekali baru mungkin berlebihan dan terlalu rumit. Membangun aturan dengan mouse=baik.

Singkat membangun bahasa baru, saya berasumsi ini sebagian besar akan menjadi antarmuka untuk platform peringatan yang ada seperti Kapacitor, Reimann & Bosun, mirip dengan bagaimana Grafana menyediakan antarmuka untuk menulis kueri InfluxDB. misalnya angkat berat dilakukan oleh sistem peringatan pihak ketiga dan Grafana menyediakan UI. Mungkin bukan itu masalahnya?

IIRC, Grafana ingin menggunakan cara "termasuk baterai, tetapi dapat dilepas". Yaitu harus bekerja mandiri dengan mesin peringatan yang disertakan tetapi juga harus dapat dipasang ke platform yang ada.

Saya akan mengatakan itu perlu datang dengan beberapa metode bawaan - email (menyediakan Host SMTP) dan WebAPI/Webhook. Kemudian sisanya bisa datang dengan plugin, seperti integrasi ke PagerDuty.

@felixbarny dapatkah Anda menjelaskan apa yang Anda maksud dengan pluggable ke platform yang ada? Tentu saja notifikasi peringatan akan terintegrasi dengan banyak alat peringatan yang ada. Tetapi untuk sistem lain untuk menangani penjadwalan dan eksekusi aturan peringatan bisa jadi rumit, itu mungkin, cukup baca aturan dari Grafana HTTP API. Tapi itu akan membutuhkan banyak kode untuk menangani penjadwalan dan eksekusi aturan. Tapi tentu saja kami akan memberikan opsi untuk hanya mendefinisikan aturan di Grafana, dan agar sistem lain terus membaca aturan dan menjalankannya

@GriffReborn Anda berpikir pada tingkat yang berbeda. Backend peringatan yang ada yang saya sebutkan _sudah_ mendukung output seperti SMTP, PagerDuty, dll:
https://docs.influxdata.com/kapasitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

Produk-produk ini _sudah_ melakukan peringatan yang kompleks dan dinamis dengan baik. Apa yang tidak mereka miliki adalah antarmuka visual yang bagus untuk mengonfigurasi dan mengelola lansiran, mengidentifikasi secara visual lansiran mana yang aktif, dll. Yang ingin saya miliki adalah UI frontend yang pada dasarnya mendorong konfigurasi ke misalnya peringatan Anda (didukung Grafana) sistem pilihan yang kemudian benar-benar melakukan semua pekerjaan.

@thom-nic saya setuju. Fokus utama harus membangun dasbor peringatan yang dapat menggunakan umpan info peringatan yang ada ("agnostik umpan"). Membuat mesin pemroses sinyal ringan yang disponsori Grafana (idealnya sebagai mesin mandiri) harus menjadi perhatian kedua.

@johnnyshields membuat panel baru yang menampilkan info dari backend peringatan yang ada mudah dilakukan siapa saja yang ingin melakukannya. Apa yang kami coba lakukan adalah mempermudah pengguna Grafana untuk menentukan aturan peringatan pada kueri metrik mereka yang mereka tentukan di panel grafik / singlestat. Kemudian miliki mesin peringatan di backend grafana yang menjadwalkan dan mengeksekusi dan mengevaluasi aturan-aturan itu, memperbarui status peringatan, memicu pemberitahuan, dll.

Saya juga berpikir model sederhana harus cukup dan juga akan menghasilkan fitur yang telah lama ditunggu-tunggu sesegera mungkin. Sama sekali grafana adalah untuk metrik, peringatan dasar harus cukup.

@torkelo sejujurnya, saya tidak terlalu akrab dengan platform peringatan seperti bosun dan saya tidak tahu bagaimana integrasi yang tepat dapat terlihat secara spesifik. Saya mengacu pada hal-hal yang dikatakan @Dieterbe , misalnya dalam presentasi Grafanacon-nya: http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny, itulah yang kami rencanakan juga. Untuk memiliki API untuk backend peringatan lainnya untuk digunakan untuk membaca aturan yang ditentukan di Grafana. Tapi kami tidak akan menyediakan jembatan yang membaca aturan peringatan dari Grafana dan menerjemahkannya ke mesin eksekusi aturan lain.

Jadi satu ide yang kita miliki sekarang adalah mendefinisikan aturan sederhana seperti ini

Tetapi juga dapat memiliki ambang dinamis dan membandingkan dengan kueri lain atau kueri yang sama tetapi rentang waktu dan agregasi yang berbeda.

Permintaan "perkiraan" kompleks lainnya. Di mana kueri digunakan untuk mendapatkan garis tren, lalu ramalkan ke depan dalam waktu dan waspadai itu.

Sepertinya yang terbaik dari kedua dunia. Cintai ide itu! Apakah fungsi 'Evaluate Against' merupakan bagian dari Grafana atau khusus untuk TSDB?

@felixbarny mereka adalah bagian dari model aturan peringatan Grafana dan akan diproses oleh mesin evaluasi aturan peringatan Grafana.

Apakah Anda dapat melampirkan beberapa aturan ke satu grafik? Saya suka kesederhanaan tingkat peringatan/kritis dalam satu aturan, dan beberapa grafik memiliki ambang batas tinggi dan rendah yang akan memerlukan beberapa tingkat dalam satu peringatan, atau beberapa peringatan pada satu grafik.

Dan meskipun saya menyukai fungsionalitas aturan yang kompleks, ini semua dapat dicapai dengan membuat grafik yang berbeda dan memperingatkan grafik tersebut dengan aturan sederhana. Manfaat menjaga kompleksitas dari sistem peringatan adalah riwayat keadaan yang menyebabkan aturan untuk diaktifkan disimpan di TSDB.

Ini memungkinkan Anda memvisualisasikan lansiran sebagai garis horizontal sederhana pada grafik, dan melihat bagaimana aturan itu akan (atau memang) diaktifkan dari waktu ke waktu.

Itu terus mengingatkan sederhana untuk rata-rata orang, cukup kompleks untuk semua orang, dan dapat diakses oleh mereka yang memahami hal-hal secara visual.

@lorenwest ya, kami akan menjaga semuanya tetap sederhana dan dan hanya mengizinkan satu aturan peringatan per panel. Tetapi aturan dapat menggunakan kueri yang mengembalikan banyak rangkaian, yang pada dasarnya akan membagi aturan menjadi beberapa (sehingga Anda dapat memiliki satu aturan yang akan memeriksa setiap server, jika kueri mengembalikan rangkaian per server).

Dan meskipun saya menyukai fungsionalitas aturan yang kompleks, ini semua dapat dicapai dengan membuat grafik yang berbeda dan memperingatkan grafik tersebut dengan aturan sederhana.

Tidak yakin apa yang Anda maksud di sini. Grafik lain sama sekali tidak memecahkan skenario di mana Anda ingin mengingatkan pada kueri dibandingkan dengan dirinya sendiri selama rentang waktu yang berbeda, dibandingkan dengan kueri lain seluruhnya (mungkin kueri lain adalah sumber data lain yang mengambil ambang batas dinamis dari database). Skenario itu tidak dapat diselesaikan di TSDB atau hanya dengan membagi aturan menjadi dua aturan di dua panel terpisah.

Tetapi tujuan utamanya adalah untuk memecahkan kasus sederhana dan membuatnya mudah dan intuitif tetapi kami juga ingin, setidaknya nanti, mendukung beberapa aturan peringatan yang lebih kompleks yang benar-benar memanfaatkan fakta bahwa Anda berurusan dengan data TSDB dan juga fakta bahwa kueri yang berbeda dapat menargetkan sumber data yang berbeda

saya pikir poin yang dibuat @lorenwest adalah bahwa dengan aturan peringatan menjadi ambang batas sederhana, aturan diterapkan pada data yang divisualisasikan dalam grafik. Jadi jika Anda melapisi ambang batas, Anda dapat dengan jelas melihat di mana di masa lalu peringatan akan dipicu berdasarkan ambang batas saat ini

Dengan model peringatan yang lebih kompleks, tidak ada lagi indikator yang terlihat di mana ambang batas akan menghasilkan peringatan.

Berpegang pada model sederhana, Anda dapat mencapai banyak persyaratan pemantauan yang kompleks asalkan sumber data menyediakan kemampuan. Untuk "perubahan persen dibandingkan dengan", Anda dapat membuat kueri grafit (grafik berbeda) yang membandingkan hari ini dengan hari sebelumnya, dan kemudian menetapkan ambang batas sederhana untuk itu. Ini tentu saja merupakan proses yang jauh lebih rumit untuk membuat peringatan, tetapi itu berhasil.

Senang kita berada di halaman yang sama @torkelo. Ini sesuai dengan deskripsi di posting asli.

Saya tidak suka membuat platform peringatan yang sama sekali baru untuk dikaitkan dengan Grafana. Apa yang saya harapkan dari peringatan Grafana adalah sesuatu untuk menggantikan NewRelic, tetapi dengan kekuatan luar biasa yang dibawa Grafana. Mampu memicu peringatan (apakah email, API apa pun) ketika salah satu grafik saya mencapai ambang ... itu EMAS. Hal-hal yang mengubah hidup.

Bahkan peringatan ambang batas sederhana akan menjadi solusi sederhana yang bagus.

Jika Anda mengikuti aturan yang satu ini, Anda akan menjadi emas:

Jangan pernah izinkan lansiran yang tidak dapat divisualisasikan dengan overlay pada panel.

Jika Anda tidak dapat memvisualisasikannya, itu terlalu rumit. Buat bagan yang mewujudkan kompleksitas ini, dan waspadai bagan itu. Ini memaksa kami untuk membangun visualisasi yang mewujudkan kompleksitas itu (hal yang baik) sambil tetap memudahkan pembuat peringatan (dan konsumen) untuk melihat apa yang mereka hadapi.

@woodsaj Saya setuju bahwa kami ingin mendorong hubungan antara apa yang Anda waspadai dan apa yang Anda lihat, itu bukanlah sesuatu yang pernah kami diskusikan untuk ditinggalkan. Apa yang mencoba untuk melakukan brainstorming adalah seberapa jauh ambang batas statis permintaan tunggal, apakah mereka cukup baik untuk v2 dari Grafana Alerting atau v3? Dan untuk memicu diskusi tentang batasan apa dalam jenis aturan peringatan yang dimungkinkan dengan kueri tunggal dan ambang batas statis.

Saat ini TSDB sangat tidak fleksibel dalam jenis kueri bersarang apa yang dapat Anda lakukan (misalnya, bandingkan serangkaian dengan dirinya sendiri). Grafit adalah satu-satunya yang mendukung kueri bersarang. Tetapi bahkan Graphite tidak dapat membandingkan dua kueri yang menargetkan jendela waktu yang berbeda (pergeseran waktu hanya menggeser jendela yang sama, tetapi bukan jendela waktu berukuran berbeda). Tetapi semakin saya memikirkan hal ini, semakin saya setuju bahwa sebagian besar dari ini dapat diselesaikan dalam kueri TSDB mengingat itu cukup kuat.

Alasan utama untuk mengangkat diskusi ini adalah untuk melakukan brainstorming bagaimana memodelkan aturan, apa saja komponen yang membentuk aturan, abstraksi apa yang dikandungnya (kueri, jendela waktu, agregasi, level, dll). Bagaimana kami dapat mendukung ambang dinamis di v2 atau lebih banyak kueri lansiran kaya fitur yang memperkirakan tren di masa mendatang. Bagaimana model dan mesin evaluasi aturan perlu diubah?

Sehubungan dengan "Harus memperingatkan peta ke panel" - Saya pikir itu mungkin opsi yang berguna tetapi akan menjadi kendala desain yang buruk, bahkan untuk v1.0.

Saya pikir salah satu aspek peringatan yang lebih rumit adalah ruang lingkup, dan begitu Anda mulai berbicara tentang visualisasi, maka masalahnya menjadi jelas.

Saya menganggap ruang lingkup sebagai area permukaan/kedalaman sistem yang dicakup oleh peringatan sebagai ruang lingkup. Jadi misalnya, lansiran Anda mungkin tercakup:

• Layanan (metrik aplikasi)
• Seluruh cluster yang membentuk layanan
• Node individu dalam sebuah cluster
• Host / proses dalam sebuah cluster
• Subsistem proses / aplikasi (metrik middleware)
• Subsistem host (yaitu disk, cpu) (metrik sistem)

Saya tidak percaya ada jawaban tunggal yang "benar" pada lapisan mana yang harus diwaspadai. Kadang-kadang tergantung pada tim, pentingnya layanan, infrastruktur umum (yaitu cloud vs hardware, cluster vs monolith), dll... Jadi mengingat cakupan berlapis, hierarki peringatan sepertinya bagus. Tetapi saya tidak berpikir mendefinisikan hierarki itu secara umum dapat dipertahankan. Ini adalah banyak pekerjaan, perubahan, dan sering ada hubungan yang tidak menghasilkan pohon cantik dalam sistem dunia nyata. Agresi buku SRE Google:

"""
Google SRE hanya mengalami keberhasilan terbatas dengan hierarki ketergantungan yang kompleks. Kami jarang menggunakan aturan seperti, "Jika saya tahu database lambat, waspada untuk database lambat; jika tidak, waspada untuk situs web yang umumnya lambat." Aturan yang bergantung pada ketergantungan biasanya berkaitan dengan bagian yang sangat stabil dari sistem kami, seperti sistem kami untuk menguras lalu lintas pengguna dari pusat data. Misalnya, "Jika pusat data terkuras, maka jangan beri tahu saya tentang latensinya" adalah salah satu aturan peringatan pusat data yang umum. Beberapa tim di Google mempertahankan hierarki ketergantungan yang kompleks karena infrastruktur kami memiliki tingkat pemfaktoran ulang berkelanjutan yang stabil.
"""

Juga terkait dengan ruang lingkup adalah jenis peringatan (yaitu mengirim email vs mencatatnya / tampilkan di dasbor untuk ditangani seseorang ketika mereka melakukan putaran pagi mereka)

Jadi untuk Grafana, lansiran saya mungkin dipetakan ke:

• Sebuah Panel
• Sekelompok Panel
• Sebuah Dasbor
• Sekelompok Dasbor (yang saya bayangkan akan memiliki perincian)

Terkadang saya ingin lansiran tersebut mengirim pemberitahuan, di lain waktu saya ingin mereka hanya menjadi indikator visual di suatu tempat di Grafana di salah satu cakupan (yaitu ambang batas, atau perubahan status sebagai penanda anotasi). Ini akan berbeda untuk perusahaan yang berbeda dan bahkan kelompok/layanan yang berbeda dalam suatu perusahaan.

@kylebrandt seluruh ide dengan peringatan di Grafana adalah untuk mengikatnya ke panel dan visualisasi. Di mana Anda dapat memiliki grafik dan panel yang memvisualisasikan metrik dengan cakupan yang berbeda (seperti Layanan, kluster, host individual) dan dengan itu Anda dapat memberi peringatan pada tingkat atau cakupan apa pun.

Tidak melihat bagaimana menautkan lansiran ke panel dan sesuatu yang dapat divisualisasikan akan berhenti menentukan lansiran di tingkat yang berbeda. Dan tentu saja Anda akan menentukan setiap peringatan pemberitahuan apa yang harus digunakan.

@torkelo Keputusan untuk waspada akan selalu bermuara pada bool (benar/salah). Mungkin ada level yang berbeda (peringatan, kritik, dll ...) atau bahkan logika fuzzy tetapi pada akhirnya itu adalah keputusan boolean. Membuat grafik bool itu sendiri dalam satu panel tidak akan selalu membantu.

Jadi, $metric > $threshold adalah peringatan paling dasar, dan tentu saja mengembalikan nilai metrik yang melebihi ambang batas. Itu cocok dengan panel (visualisasikan metrik dan visualisasikan ambang batas dalam panel). Namun, untuk menghilangkan kebisingan peringatan, ruang lingkup dan kondisi cenderung tumbuh lebih dari itu di sebagian besar kasus (ketika kami mulai mengerjakan Bosun, saya pikir kasus ini akan menjadi minoritas, ternyata tidak terlalu jika Anda mau mengontrol kebisingan). Jadi Anda mungkin mengatakan sesuatu seperti:

Waspada jika:

• CPU di atas 80% selama X menit
• Pekerjaan A tidak berjalan (yang kami tahu untuk menaikkan CPU dan kami tidak peduli) dan Pekerjaan A tidak berjalan selama lebih dari satu jam
• Dieter telah memiliki lebih dari 3 cangkir starbucks dalam 24 jam terakhir ( karena ketika dia memiliki lebih banyak dia melakukan hal-hal konyol yang meningkatkan CPU dan kami tidak ingin memperingatkannya)

Jadi untuk memvisualisasikan peringatan saja (Benar / Salah) ketika ada beberapa kondisi tidak begitu berguna. Kita perlu memvisualisasikan setiap kondisi (dan bahkan mungkin beberapa lagi untuk info pendukung).

Membuat semua kondisi tersebut menjadi metrik baru tidak terlalu membantu visualisasi saat ini karena itu hanya Benar/Salah dan apa yang benar-benar perlu Anda lihat adalah semua info yang mendasarinya. Jadi apa yang kami miliki alih-alih memvisualisasikan metrik+ambang batas adalah memvisualisasikan metrik + ambang batas yang dapat berada pada skala yang berbeda.

Jadi dalam hal ini, ya, Alert _can_ memetakan ke satu panel, tetapi tergantung pada visualisasi dan peringatan, ada banyak kasus di mana itu tidak benar-benar diinginkan. Saya ingin panel untuk setiap item boolean yang membentuk peringatan, untuk melihat mana yang tersandung - tetapi untuk menghindari kelelahan peringatan, saya hanya ingin satu pemberitahuan untuk kombinasi semua kondisi.

tampaknya semacam penggabung peringatan dengan logika Boolean sederhana mungkin membuat ini mudah.

alert1:
  select: CPU is above 80% for X minutes
  output: null
alert2:
  select: Job A is not running
  output: null
alert3:
  select: Job A has being running for more than an hour
  output: send alert
alert4:
  select: Dieter has had more than 3 cups of starbucks in the last 24 hours
  output: null

(alert joiner does simple true/false logic and perhaps can graph it.)
alert5:
  database: alerts
  select: alert1 & alert2 &!alert4
  output: send alert

@torkelo Saya menarik cabang alerting_definitions dari Github dan membangunnya sesuai dengan instruksi. Tapi sayangnya saya tidak bisa melihat tab "Alerting" (disajikan di atas) di panel Graph.
Selain itu saya menemukan "peringatan: diaktifkan = salah" dalam "Pengaturan server" dari "Administrasi Server". Apakah itu memengaruhi fitur peringatan? Apakah ada flag build atau runtime yang harus saya gunakan?
tolong saran.

Saya sudah mencoba dengan kode terbaru (ebada26b85d8410142c2942ef7ba78b17e88313c), mengaktifkan peringatan dan mendapatkan UI.

Tapi punya banyak kesalahan

EROR[06-17|14:38:23] Failed to extract alerts from dashboard  logger=alerting.extractor error="missing query.query"
EROR[06-17|14:38:23] Failed to save alerts                    logger=context userId=1 orgId=1 uname=admin error="Failed to extract alerts from dashboard"

Saya mencoba dengan sumber data InfluxDB, dalam mode proyy dan langsung.

Apakah itu sesuatu yang diharapkan?

Ya, itu belum siap untuk diuji.

Baiklah senang mengetahuinya.

Saya akan melacak pembaruan dari waktu ke waktu.
Mungkin lebih baik menunggu cabang ini digabung di master sehingga cukup siap digunakan?

ya, kami berharap untuk menggabungkannya untuk menguasai mungkin pertengahan Juli ada sekitar

Apakah Anda memiliki pembaruan kemajuan tentang ini?
Apakah Anda masih akan memukul pertengahan Juli?
Memiliki fitur ini dalam produksi ASAP akan sangat membantu!

Bahkan versi ringan dengan peringatan seperti email saja akan sangat bagus!
Pembaruan pada kemajuan Anda akan sangat bagus (saya harus memilih antara menerapkan sistem peringatan khusus atau mengandalkan Grafana, dan saya pasti lebih suka opsi ke-2!).
Terima kasih kawan

Musim dingin telah tiba, begitu juga dengan waspada :)

Pada Selasa, 12 Juli 2016 pukul 01:41, c-val [email protected] menulis:

Bahkan versi ringan dengan peringatan seperti email saja akan sangat bagus!
Pembaruan tentang kemajuan Anda akan sangat bagus (saya harus memilih antara
menerapkan sistem peringatan khusus atau mengandalkan Grafana, dan saya pasti
lebih suka opsi ke-2!).
Terima kasih kawan

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390
atau matikan utasnya
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

Deepak

Saya akan menganggap ini sebagai "persyaratan bisnis" dan akan menyarankan agar dievaluasi pada tingkat "arsitektur perusahaan". Dengan menerapkan _beberapa_ praktik dan pola yang digunakan untuk Arsitektur Perangkat Lunak Perusahaan, Anda akan dapat mengomunikasikan ide-ide Anda melalui pemodelan gesit yang pada gilirannya mendorong kualitas pemahaman yang lebih tinggi baik bagi pemangku kepentingan maupun tim pengembangan.

Sebelum kita dapat mulai berbicara tentang saus rahasia teknologi dan arsitektur, kita harus menyetujui setidaknya hal-hal berikut:

1. Kami memikirkan fitur kami dalam hal "Manajemen Proses Bisnis (BPM)"; dan
2. Kami menggunakan "Bahasa Pemodelan Proses Bisnis (BPML)" sehingga kami dapat mulai memodelkan persyaratan & implementasi di tempat yang sama dengan UML.
3. Kami mendefinisikan arsitektur kami dengan disiplin tingkat perusahaan.

Sekarang bagian yang menyenangkan! Memiliki pengalaman yang luas dengan pemantauan pada skala global, saya menyarankan agar kita mempertimbangkan hal-hal berikut:

• Tinggalkan grafana saja, itu adalah lapisan presentasi ! Jika Anda ingin menambahkan alur kerja untuk pemodelan & penetapan aturan untuk menghasilkan peringatan, tidak apa-apa, tetapi biarkan saja. Lagi pula, itu sebabnya panel dan plugin diimplementasikan bukan?
• Tinggalkan data di tempat yang ditakdirkan. Metrik yang menelepon ke rumah harus diperlakukan sebagai warga negara kelas satu dan menyimpan nilainya secara terus-menerus adalah prioritas TOP. Apakah itu dalam cache, documentdb, tsdb, atau server sql, tidak masalah. Toleransi kesalahan tersirat .. dengan "pilihan teknologi" yang tepat dibuat untuk arsitektur tentu saja).
• Untuk membuat kami menyiapkan ketersediaan + skalabilitas, kami perlu menggunakan kerangka kerja yang tepat yang dirancang khusus untuk ini: memenuhi Arsitektur Berorientasi Layanan ("SOA"). Pada tingkat yang sangat tinggi kita dapat menggunakan protokol antrian pesan untuk mengirim dan menerima peristiwa & pesan melalui protokol "AMQP". Lupakan REST & HTTP... untuk saat ini. Menggunakan server antrian pesan seperti RabbitMQ atau ZeroMQ, kami memiliki saluran komunikasi terdistribusi, toleran terhadap kesalahan, sangat tersedia, yang dapat digunakan oleh penerbit/pengirim data dan pekerja/penerima untuk memprosesnya. Ini adalah "bus layanan perusahaan". (Lihat dek slide ini menjelaskan ZeroMQ).
• Gunakan bahasa kueri yang dibuat khusus untuk model data komposit yang berbeda dan tidak tertaut. Dengan menggunakan "Graph Database" dan antarmuka kueri " SparQL ":

SPARQL memungkinkan pengguna untuk menulis kueri terhadap apa yang secara longgar dapat disebut data "nilai kunci" atau, lebih khusus lagi, data yang mengikuti spesifikasi RDF dari W3C. Seluruh database dengan demikian merupakan satu set tiga kali lipat "subjek-predikat-objek". Ini analog dengan penggunaan beberapa basis data NoSQL dari istilah "nilai-kunci dokumen", seperti MongoDB.
[..]
SPARQL dengan demikian menyediakan satu set lengkap operasi kueri analitik seperti GABUNG, Urut, Agregat untuk data yang skemanya secara intrinsik merupakan bagian dari data daripada memerlukan definisi skema terpisah. Informasi skema (ontologi) sering diberikan secara eksternal, untuk memungkinkan kumpulan data yang berbeda digabungkan dengan cara yang tidak ambigu. Selain itu, SPARQL menyediakan sintaks traversal grafik khusus untuk data yang dapat dianggap sebagai grafik dan ara.
..
https://en.wikipedia.org/wiki/SPARQL

Ingat, apa yang telah diberikan Grafana kepada kita yang tidak pernah dilakukan Nagios bermuara pada satu titik kegagalan: kurangnya skalabilitas. Grafana "cepat" seperti yang Anda katakan tetapi Anda tidak memperhitungkan fakta bahwa Anda hanya menyimpan dan memproses data deret waktu -- bukan juga lapisan metadata ! Kami membutuhkan semantik SparQL dan kekuatan Elasticache + mesin basis data grafik.

Ini mungkin terdengar rumit .. yang dapat dengan mudah menjadi jauh lebih kompleks daripada dua halaman ini, tetapi saya menyelamatkan Anda dari kekerasan bertahun-tahun, coba-coba dan menghilangkan kebisingan (yaitu: ada 30 pola desain untuk arsitektur perusahaan, 12 untuk uml, dll., kita hanya perlu berbicara tentang 3 untuk dapat menghentikan ini -- untuk saat ini)

Ini seharusnya membuat persneling berputar.. Saya perlu tidur (menarik sepanjang malam) dan saya akan mengerjakan Bagian 2. Jangan ragu untuk ping saya @appsoa di skype atau yomateo di IRC.

Beberapa suguhan sementara:

• Contoh arsitektur referensi yang saya buat menggunakan SOA .
• Microsoft Azure Service Fabric: Bangun dan operasikan aplikasi terdistribusi yang selalu aktif, skalabel.

@talbaror Idealnya Anda akan menangkap pesan log NAC menggunakan agen seperti dengan firewall PIX dan mengirimnya keluar/diputar ulang melalui rsyslogd atau protokol apa pun yang digunakan server pemrosesan acara.

Jika Anda tidak memiliki pengaturan layanan pemrosesan peristiwa, Anda dapat menggunakan pemrosesan aturan Snort - Network Intrusion Detector . Ping saya jika Anda butuh bantuan .. Saya menghabiskan 4 tahun di perusahaan keamanan sebagai layanan ;)

Bisakah Anda mengintegrasikan deteksi anomali seperti banshee ?
Dengan penanda visual dan peringatan.

@torkelo tolong beri kami mark-to-market di timeline untuk pengiriman ini?

@johnnyshields Saya sedang mengerjakan ini sekarang setiap hari. Ini hal yang rumit dan benar-benar ingin mendapatkan dasar-dasar yang benar sehingga sistem peringatan dapat berkembang dan menjadi lebih kaya di masa depan. Model saat ini yang saya kerjakan terlihat sangat bagus, akan memposting pembaruan minggu depan pada model aturan peringatan berbasis kondisi baru.

Berharap untuk menggabungkannya menjadi master dan membuatnya tersedia (di belakang sakelar fitur) dalam waktu 2 minggu jika semuanya berjalan lancar. Kami belum memiliki tanggal pasti untuk versi Grafana berikutnya, baik rilis 3.2 di bulan september atau rilis 4.0 yang lebih besar di akhir Oktober.

@torkelo Semoga kami mendapat peringatan sesegera mungkin. Menunggu itu.
Menggunakan grafana untuk kubernetes.

Untuk orang lain yang sudah memiliki statsd/graphite/grafana dan hanya menunggu Sistem Peringatan Grafana siap untuk melakukan peringatan pertama, saya menemukan alternatif yang bagus untuk digunakan sementara itu, Seyren: https://github.com /scobal/seyren

Ini terintegrasi dengan mudah dengan PagerDuty dan Anda cukup menyalin target grafik yang sudah Anda miliki di dasbor grafana Anda untuk memperingatkan menentukan ambang peringatan dan kesalahan.

Sepertinya tim telah membuat kemajuan besar pada fitur peringatan. Saya percaya pada filosofi "melakukan hanya satu hal tetapi melakukannya dengan baik". Tidak terlalu yakin apakah menempatkan seluruh logika peringatan di dalam Grafana adalah ide terbaik. Bagaimanapun, saya baru saja menulis node kecil js daemon "flapjack-grafana-receiver' untuk memposting acara grafana ke flapjack. Saya mungkin akan membukanya. Ada yang tertarik?

https://github.com/Charles546/flapjack-grafana-receiver

Pembaruan kemajuan!

Setidaknya satu orang telah bekerja penuh waktu untuk memperingatkan sejak April, kemajuannya tidak secepat yang kami inginkan karena banyak penulisan ulang. Meskipun kami menargetkan fitur lansiran dasar untuk versi awal, kami merasa penting untuk mendapatkan model aturan lansiran dasar dengan benar sehingga kami dapat memperluas definisi aturan lansiran dan mesin evaluasi aturan lansiran di rilis mendatang tanpa perombakan besar-besaran.

Tujuan memulai dengan peringatan yang sangat sederhana telah membawa kita ke jalan buntu yang tidak terasa benar dan membutuhkan beberapa penulisan ulang besar. Tapi kami sekarang kembali ke jalur dan membuat kemajuan yang baik pada model aturan berbasis kondisi yang membuat kami jauh lebih bahagia.

Definisi aturan

Model aturan lansiran baru terdiri dari satu atau beberapa ketentuan. Kondisi dapat dari berbagai jenis. Saat ini hanya ada jenis kueri. Tapi nanti kita bisa menambahkan Ketentuan seperti Time of day , atau Day of week , atau yang lebih menarik lagi Other alert (sehingga Anda dapat menyertakan status aturan peringatan lain sebagai ketentuan).

Kondisi kueri terdiri dari kueri dan rentang waktu, peredam yang akan mengambil semua titik data yang dikembalikan untuk setiap rangkaian kueri yang dikembalikan dan menguranginya menjadi satu nilai untuk digunakan dalam perbandingan ambang batas. Peredam juga bisa di masa depan menjadi "perkiraan" yang melakukan regresi linier pada data dan memperkirakan nilai masa depan.

Bagian evaluasi dari kondisi kueri dapat lebih besar dari, kurang dari, di antara, dll. Anda akan dapat menyeret pegangan dalam grafik untuk menetapkan ambang batas.

Model berbasis kondisi menyediakan banyak kemungkinan menarik untuk membuat aturan peringatan lebih kuat di masa mendatang tanpa perombakan total mesin, juga kondisi kueri memiliki komponen yang dapat dicolokkan yang memungkinkan ekstensi (peredam dengan params, dan evaluator dengan params).

Pemberitahuan

Minggu yang berlalu ini kami telah mengerjakan notifikasi dan semuanya mulai menyatu!

Kami memiliki, email, webhook, dan jenis pemberitahuan kendur. Notifikasi kendur terlihat cukup bagus :)

Ingin membantu?

Anda sudah dapat menguji & memberikan umpan balik, kode tersebut tinggal di cabang peringatan, dan Anda juga perlu mengaktifkannya di file konfigurasi dengan.

[alerting]
enabled = true

Gabung untuk menguasai

Kami sangat dekat untuk menggabungkan ini untuk menguasai dan melanjutkan pekerjaan di sana. Saya berharap untuk melakukan ini sebelum liburan musim panas saya (baru saja pergi 1 minggu) tetapi masih ada beberapa perubahan skema SQL kecil yang ingin saya lakukan sebelum bergabung ke master. Gabung ke master AKAN terjadi pada 19 Agustus, saya janji :) Setelah itu, peringatan akan ada di versi terbaru 4.0 nightly, jadi akan mudah bagi Anda untuk menguji & melaporkan bug dan umpan balik.

Apa yang tersisa?

Ada sejumlah fitur yang hilang yang kami inginkan untuk rilis beta.

• Lebih banyak reduksi & kemampuan untuk mengganti peredam (hanya rata-rata sekarang)
• Notifikasi email terlihat seperti omong kosong
• Skema penguncian untuk webhook
• Desain untuk halaman daftar peringatan
• Lihat riwayat peringatan
• Lihat riwayat peringatan sebagai anotasi pada grafik
• Penjadwal peringatan & stabilitas mesin
• Peningkatan penjadwal peringatan untuk menyebarkan beban (sehingga peringatan tidak dieksekusi pada saat yang sama)
• Pengelompokan penjadwal peringatan

Saya benar-benar minta maaf karena fitur ini memakan waktu lama.

@torkelo harap memiliki kemampuan untuk menempatkan mesin dalam mode pemeliharaan untuk jangka waktu tertentu dalam versi beta.

@torkelo Terima kasih atas pembaruannya. Dari apa yang saya lihat, ini diarahkan untuk memiliki peringatan di dalam Grafana. Apakah Anda masih mengikuti kursus modular yang dijelaskan di https://github.com/grafana/grafana/issues/2209#issuecomment -149351263 ?

Juga terima kasih kepada siapa pun elf tersembunyi yang mengerjakan ini. Saya curiga @Dieterbe , tapi saya tidak tahu.

@RichiH kami tidak yakin bagaimana itu akan berhasil, kami telah mencoba mencari cara untuk melakukan sistem seperti di komentar itu tetapi tidak yakin bagaimana cara kerjanya. Kami sekarang fokus pada pengalaman peringatan yang kuat dan siap pakai yang dapat menjadi lebih baik dari waktu ke waktu. Pengguna dengan pengendali peringatan yang ada berpotensi menonaktifkan pelaksana peringatan di Grafana dan meminta Grafana mengirim peringatan yang perlu dievaluasi ke sistem lain. Akan membutuhkan banyak pekerjaan pada sistem pihak ketiga untuk mengimplementasikan integrasi itu.

@torkelo Pikiran saya sejalan, itulah sebabnya saya memutuskan untuk bertanya.

Secara pribadi, saya peduli dengan peringatan Prometheus, tetapi akan menghargai integrasi visual yang bagus dengan Grafana. Saya tidak terlalu peduli di mana saya mendefinisikan aturan selama aturan itu disimpan dan dijalankan oleh Prometheus.

@bergquist Saat Anda akan berada di promcon, duduk dan berbicara tentang kemungkinan pendekatan mungkin masuk akal. Jika Anda mau, saya akan menyodok pengembang Prometheus tentang waktu yang paling cocok. Mungkin ada atau mungkin tidak ada waktu tenang untuk duduk pada malam sebelum dan/atau setelah pembersihan; Saya dapat memberi tahu Anda jika Anda mau.

Halo @torkelo - ini terlihat bagus.

Saya baru saja menarik cabang Anda dan ketika saya menguji alarm untuk ElasticSearch saya mendapatkan kesalahan

firing false
timeMs 0.225ms
error tsdb.HandleRequest() error Could not find executor for data source type elasticsearch

...apakah ini berarti ElasticSearch belum support :cry:

ps dalam output proses saya mendapatkan ini:

EROR[08-04|09:15:00] Alert Rule Result Error                  logger=alerting.engine ruleId=1 error="tsdb.HandleRequest() error Could not find executor for data source type elasticsearch" retry=nil LOG15_ERROR="Normalized odd number of arguments by adding nil"

@Workshop2 kami hanya mendukung grafit untuk peringatan sejauh ini tetapi kami akan mendukung Elasticsearch pada akhirnya :) Saya akan menambahkan pesan kesalahan yang lebih baik untuk ini.

Bagaimana sistem peringatan akan berperilaku jika kueri tidak mengembalikan data? Apakah ini akan memicu peringatan secara default?
Juga, peredam count akan keren yang hanya mengembalikan jumlah titik data yang dikembalikan oleh kueri.

@bergquist Saya pikir peringatan akan transparan sehubungan dengan sumber data yang digunakan. Berapa lama sebelum kami dapat memulai pratinjau / pengujian fitur peringatan selain sumber data grafit? (Saya menyadari 'berapa lama ...' pertanyaan tidak ada yang suka, maaf)

@RichiH Salah satu opsi adalah membuat aplikasi grafana seperti bosun. https://grafana.net/plugins/bosun-app Tapi itu tidak memungkinkan penggunaan kembali kueri/dasbor dengan cara yang sederhana. Mari kita bicarakan lebih lanjut di promcon. Berharap untuk bertemu dengan Anda! :)

Tidak ada dukungan influxdb awalnya juga?

saya tidak tahu ikatan spesifiknya dengan grafit :( Kami juga menggunakan influx dan
pencarian elastis ;)

Pada Senin, 8 Agustus 2016 pukul 14:18, elvarb [email protected] menulis:

Tidak ada dukungan influxdb awalnya juga?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

Enrico Kern

Insinyur Sistem Utama

glispa GmbH
Sonnenburger Straße 73
10437 Berlin, Jerman

telp: +49 30 5557130-17
faks: +49 30 5557130-50
skype: flyersaenrico. [email protected]

---

Sitz Berlin, AG Charlottenburg HRB 114678B

Hanya awalnya, kami kemungkinan akan menambahkan Prometheus sebelum rilis. Mungkin juga InfluxDB atau Elasticsearch, karena penjadwalan dan eksekusi peringatan sedang berlangsung di backend, kode permintaan dan respons telah ditulis dari awal (di Go), kode plugin sumber data frontend (ditulis dalam js) tidak dapat digunakan kembali.

Kami menggunakan influx, saya pikir kami dapat mengabaikan integrasi grafana dan menggunakan Kapacitor dengan front-end web sederhana untuk membuat dan mengelola lansiran.

+1 Peringatan + InfluxDB.

Pada Senin, 8 Agustus 2016 pukul 06:01, Thom Nichols [email protected]
menulis:

Kami menggunakan influx, saya pikir kami dapat mengabaikan integrasi dan penggunaan grafana
Kapasitor dengan front-end web sederhana untuk membuat dan mengelola peringatan.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

Deepak

Sangat disayangkan bahwa pekerjaan yang kami lakukan untuk membangun plugin sumber data hanya berguna untuk klien.

Mempertimbangkan pekerjaan jangka pendek dan jangka panjang yang mendukung peringatan untuk sumber data yang berbeda, membangun arsitektur plugin go dll, bukankah jumlah pekerjaan yang hampir sama (jika tidak kurang) untuk membangun server peringatan di NodeJS, sehingga bisa menggunakan yang sudah ada plugin sumber data?

Selain pendapat tentang go vs. nodejs, hal ini dapat secara signifikan mengurangi duplikasi kode untuk memberi tahu sumber data yang berbeda.

Dan jika Anda benar-benar tidak menyukai node, saya yakin ada mekanisme callout untuk memuat dan mengeksekusi JS.

+1 Peringatan untuk ElasticSearch

Hai, kami telah menunggu sistem peringatan untuk... OpenTSDB! Bisakah kita
berharap untuk mendapatkannya untuk OpenTSDB segera? (Mungkin kapan?)

Terima kasih banyak untuk tim!

08-08-2016 17:28 GMT+02:00 Slava Vishnyakov [email protected] :

+1 Peringatan untuk ElasticSearch

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

+1 Peringatan untuk ElasticSearch
Apakah itu memiliki kemungkinan untuk menjalankan skrip saat waspada?

Apakah kalian sudah memiliki cabang peringatan di gambar buruh pelabuhan?

1. Apakah kueri peringatan hanya berfungsi untuk kueri "A"? Apakah ini kode keras?
2. Kapan kita bisa mengharapkan versi peringatan yang berfungsi penuh? (19 masih menjadi target)
3. Kapan kami dapat mengharapkan Elasticsearch berfungsi dengan peringatan?

Sunting:

1. Dapatkah saya menambahkan lebih dari satu aturan alarm per grafik?
2. Dapatkah saya menambahkan beberapa informasi tentang alarm ke pesan HTTP? (dasbor/grafik/observed_query/alarm_config/alarm_query/threshold/warn_or_crit/value/observed_timeframe/time_of_occurence)

@DEvil0000

1) Anda dapat mengubah kueri apa pun yang Anda miliki di tab metrik.
2) Sepenuhnya bekerja, tergantung pada apa yang Anda maksud. Kami berencana untuk menggabungkannya menjadi master minggu ini. Kemudian orang-orang dapat mulai menguji build malam dan memberikan umpan balik. Rilis alfa dalam 2-3 minggu, rilis beta & stabil tergantung pada umpan balik dan seberapa cepat itu bisa menjadi stabil
3) Elasticsearch rumit, membutuhkan banyak kode untuk meminta dan mengurai respons ke dalam deret waktu, jadi kemungkinan akan datang setelah dukungan untuk Prometheus dan InfluxDB ditambahkan

@torkelo
Saya baru mengenal elasticsearch, grafana, dan go lang. Dan saya pikir Anda sudah mencari klien tetapi apakah Anda pernah melihatnya?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
Lib itu mungkin mengurangi upaya.

Juga terima kasih kepada siapa pun elf tersembunyi yang mengerjakan ini. Saya curiga @Dieterbe , tapi saya tidak tahu.

Peringatan sekarang terutama @torkelo dan @bergquist (dan @mattttt ). Saya telah mengalihkan fokus ke backend grafit kami yang akan datang, https://github.com/raintank/metrictank

Saya sangat senang melihat fitur ini membuat kemajuan. Akan senang memiliki dukungan untuk OpenTSDB karena solusi peringatan lainnya (Bosun) tidak akan cukup ramah pengguna untuk penggunaan reguler di sini.

Saya berharap untuk melihat alarm di versi resmi berikutnya dan memberi penghargaan kepada para programmer yang telah bekerja keras untuk membuat kode.

Saya berharap untuk melihat alarm di versi resmi berikutnya dan memberi penghargaan kepada para programmer yang telah bekerja keras untuk membuat kode.

@superbool maaf tidak bisa membaca ini dan terjemahan google tidak terlalu membantu

Gabung ke master AKAN terjadi pada 19 Agustus, saya janji :)

@torkelo hehe lain kali saya bertaruh Apakah ada tanggal baru?

Bisakah kami mengharapkan peringatan untuk OpenTSDB dijadwalkan? Kami mungkin menemukan
(sederhana) pendirian untuk mendorong dev.

22-08-2016 10:05 GMT+02:00 A. Binzxxxxxx [email protected] :

Saya berharap untuk melihat alarm di versi resmi berikutnya dan memberi penghargaan kepada para programmer yang telah bekerja keras untuk membuat kode.

@superbool https://github.com/superbool maaf tidak bisa membaca ini dan
terjemahan google tidak terlalu membantu

Gabung ke master AKAN terjadi pada 19 Agustus, saya janji :)

@torkelo https://github.com/torkelo hehe lain kali saya bertaruh
tanggal baru?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -241340597,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@DEvil0000 Berharap untuk melihat fitur peringatan akan dapat diterbitkan dalam versi Grafana stabil berikutnya, dan saya ingin memberikan penghargaan yang tinggi kepada semua orang yang mengembangkan alat ini.
Maaf, bahasa Inggris saya tidak terlalu baik, harap Anda dapat memahami kata-kata saya

@DEvil0000 Rencananya adalah untuk bergabung Jumat lalu tetapi karena beberapa acara yang tidak direncanakan ( https://twitter.com/torkelo/status/766514688997732352 ) kami harus menundanya sedikit :) Kami masih memiliki beberapa hal kecil yang harus dilakukan.

@torkelo Selamat!
@bergquist @torkelo Saya perlu memperingatkan dengan elastis sebelum Oktober (alpha akan baik-baik saja untuk saya). Bisakah saya membantu kalian menerapkannya? Anda hanya perlu memberi saya beberapa informasi untuk memiliki titik awal;)

Cabang peringatan sekarang telah digabungkan menjadi master. :angkat_tangan:

Kami menghargai semua umpan balik yang kami terima dari masalah ini. Terima kasih untuk kalian semua !
Untuk diskusi dan umpan balik di masa mendatang, harap posting di masalah peringatan yang sesuai atau buat yang baru. Ini membantu kami mengatur dan memprioritaskan pekerjaan kami di masa depan. Saya menutup tiket ini demi tiket yang baru. Tapi jangan ragu untuk melanjutkan diskusi dalam masalah ini.

Jadi apa selanjutnya?

• Rilis alfa (dokumen dan posting blog)
• Kumpulkan umpan balik dari komunitas.
• Terus kerjakan masalah yang tersisa
• Rilis Grafana 4.0 dengan peringatan.

Cobalah?

• Anda harus mengaktifkan peringatan di konfigurasi .
• Anda sekarang dapat menemukan peringatan di menu samping.
• Anda dapat menambahkan lansiran dengan membuka panel grafik dan memilih tab lansiran.
• Gunakan tombol _Uji lansiran_ untuk memverifikasi lansiran Anda.
• Untuk menyimpan lansiran Anda hanya perlu menyimpan dasbor.
• Siapkan notifikasi di /alerting/notifications agar diberi tahu tentang pengaktifan peringatan.
• Tambahkan pemberi tahu ke lansiran di tab lansiran.

Keterbatasan saat ini

• Sejauh ini kami hanya mendukung grafit.
• Untuk rilis ini hanya panel grafik yang mendukung peringatan.

Contoh dasbor

Anda dapat menemukan dasbor contoh di folder contoh.
Dasbor contoh didasarkan pada data dari penulis data grafit palsu kami. Anda dapat memulai grafit dan penulis data palsu dari file komposisi buruh pelabuhan kami.

cd docker/
./create_docker_compose.sh graphite
docker-compose up

Ini seharusnya hanya dianggap sebagai panduan kasar dan kami akan menambahkan lebih banyak dokumentasi tentang peringatan di minggu-minggu berikutnya.

Selamat mengingatkan! :koktail: :tada:

@bergquist Selamat.

Apakah ada masalah yang dapat kami ikuti tentang masa depan fitur ini?

@Workshop2 https://github.com/grafana/grafana/issues/5858

Hanya ada "DAN" dan bukan "ATAU" di Alert Conditions untuk menambahkan "di atas" ATAU "di bawah" di satu Panel atau adakah cara lain untuk mendukung ini?

Saya pikir ada opsi "ada di luar jangkauan"/"ada dalam jangkauan". Tapi saya juga ingin melihat "atau".

Halo semua! Terima kasih banyak atas kontribusi Anda dalam fungsi yang bermanfaat ini.

Ini sangat menarik bagi saya, tetapi dalam banyak kasus saya memerlukan "ATAU" dalam Kondisi Peringatan karena tidak ada kemungkinan untuk membuat lebih dari satu peringatan dalam satu gragh.

Saya pikir tanpa "ATAU" itu saya tidak akan dapat membuat lansiran untuk grafik semacam ini:

Ada ide? Apakah Anda berencana untuk menambahkan opsi "ATAU"?

BR

@jmgonzalezp ya, kami berharap dapat mendukung OR juga (belum yakin tentang pencampuran AND dan OR)

Kami memiliki 2 keputusan desain yang tersisa untuk mengingatkan bahwa kami akan menyukai beberapa umpan balik tentang (Kategori, dan Tingkat Keparahan/Negara).

Inilah masalah dengan pemikiran kami saat ini dan akan sangat menghargai umpan balik Anda.
https://github.com/grafana/grafana/issues/6007

Halo semua! Terima kasih untuk fitur hebat ini di grafana!

Saya punya pertanyaan tentang sistem peringatan ini. Saat ini, kami menggunakan grup penskalaan otomatis di AWS untuk menerapkan grafana, apakah itu menjadi masalah jika saya menjalankan grafana di beberapa mesin? Masalah yang saya maksud adalah, apakah akan ada beberapa peringatan yang sama dari beberapa mesin grafana? Atau grafana sudah menangani itu?

@torkelo Saya punya pertanyaan yang sama dengan @akurniawan. Mari kita pertimbangkan pengaturan ini: 1 Load balancer, 3 instance Grafana di belakang load balancer, 1 Mysql DB yang dibagikan oleh ketiga instance. Bagaimana server Grafana menangani peringatan dalam jenis pengaturan ini? Haruskah kita mengaktifkan peringatan hanya pada 1 contoh saja atau Grafana melacak peringatan sehingga beberapa node tidak memeriksa dan mengirim peringatan yang sama?

@utkarshcmu @akurniawan alerting di dalam grafana belum support HA. Rencana kami adalah menambahkan dukungan ke peringatan partisi antar server di masa mendatang.

@bergquist Terima kasih atas jawabannya. :)

@bergquist Adakah ETA kapan dukungan InfluxDB akan ditambahkan untuk ini?

@thisisjaid dilihat dari https://github.com/grafana/grafana/milestone/40 ini seharusnya ada di sini pada tanggal 10.

@Dieterbe Adakah ETA untuk memperingatkan dukungan untuk OpenTSDB?

@sofixa Terima kasih, seharusnya melihat peta jalan sendiri, kasus tidak RTFMing. Tetap dihargai.

@Dieterbe Adakah ETA untuk memperingatkan dukungan untuk OpenTSDB?

saya tidak bekerja pada peringatan lagi. mungkin @torkelo atau @bergquist bisa menjawab.

@torkelo @bergquist

Setiap ETA untuk memperingatkan dukungan untuk OpenTSDB

@LoaderMick @naveen-tirupattur Peringatan OpenTSDB ditambahkan ke Grafana, harus menjadi bagian dari rilis berikutnya. Juga, peringatan untuk OpenTSDB berfungsi di build malam.

Adakah ETA untuk memperingatkan dukungan untuk influxDB dan prometheus juga?

Peringatan @nnsaln untuk kedua sumber data sudah ada di cabang master.

Sepertinya saya tidak bisa membuat peringatan bekerja dengan OpenTSDB dengan (Grafana v4.0.0-pre1 (komit: 578507a)). Saya menguji sistem email (berfungsi) tetapi peringatan tidak menyala bahkan ketika saya memiliki ambang yang sangat rendah. Apakah ada cara untuk menjalankan kueri secara manual dan melihat data yang ditariknya?

Grafana v4.0.0-pre1 (komit: 9b28bf2)
kesalahan tsdb.HandleRequest() kesalahan Influxdb mengembalikan kode status kode status tidak valid: 400 Permintaan Buruk

@torkelo
Bisakah 'pemberitahuan peringatan webhook' memposting metrik peringatan, json, atau jenis formulir?

Hai teman-teman, apakah Grafana akan mendukung peringatan untuk kueri menggunakan variabel templat atau apakah ada rilis target untuk ini?

Semua, silakan coba 4.0 beta; jika ada sesuatu yang hilang, buka masalah baru.

Richard

Dikirim melalui ponsel; maafkan saya singkat.

Saya sudah mencoba 4.0 beta, tetapi saya masih mendapatkan kesalahan ini
kesalahan tsdb.HandleRequest() kesalahan Influxdb mengembalikan kode status kode status tidak valid: 400 Permintaan Buruk

Saya tidak dapat menyimpan pemberitahuan peringatan - kirim ke, setelah saya simpan, baris kirim ke menjadi kosong lagi

@nnsaln Anda seharusnya mengisi target notifikasi di sana, bukan alamat email. Buka menu samping grafana dan arahkan kursor ke opsi menu Peringatan, lalu tekan opsi menu Notifikasi. Di sana Anda dapat mengatur target notifikasi yang dapat Anda gunakan dari aturan peringatan Anda.

Apakah ada rencana untuk mendukung variabel template bersama dengan alerting ? saya bersedia
memahami setiap grafik yang dihasilkan oleh (atau set) variabel template sesuai
ke grafik yang berbeda dan karenanya menghasilkan peringatan terhadap nilai statis adalah
tidak benar.

Pada Mon, 5 Desember 2016 di 02:06, Tomas Barton [email protected]
menulis:

@nnsaln https://github.com/nnsaln Anda harus mengisi notifikasi
target di sana, bukan alamat email. Buka menu samping grafana dan arahkan kursor ke atas
opsi menu Peringatan, lalu tekan opsi menu Pemberitahuan. Di sana
Anda dapat mengatur target notifikasi yang dapat Anda gunakan dari aturan peringatan Anda.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

--
Deepak

Tidak, saat ini tidak ada dukungan untuk melakukan ini. Mungkin di masa depan yang jauh tapi

99% dasbor menggunakan variabel template. Mereka dirancang dengan template
variabel untuk menghindari masalah "ledakan dasbor".

Pada Senin, 5 Des 2016 pukul 20:20, Torkel degaard [email protected]
menulis:

Tidak, saat ini tidak ada dukungan untuk melakukan ini. Mungkin di masa depan yang jauh tapi

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

--
Deepak

Ya, tetapi dasbor eksplorasi umum tidak sama dengan desain dasbor untuk aturan peringatan.

Sejauh ini belum ada proposal bagaimana mendukung variabel template dengan cara yang intuitif/dapat dimengerti. Apa yang harus dilakukan kueri peringatan dengan variabel? Interpolasi dengan nilai variabel tersimpan saat ini, dengan semua? Haruskah itu memperlakukan setiap nilai sebagai aturan terpisah dan mempertahankan status untuk setiap dll. Variabel templat yang mendukung membuka sekaleng worm untuk kompleksitas dan perilaku yang berpotensi membingungkan. mungkin e menambahkan suatu hari jika seseorang datang dengan cara yang sederhana dan dapat dimengerti.

Sementara itu tidak ada yang menghentikan Anda untuk membuat dasbor peringatan terpisah.
Peringatan adalah hal baru dan tambahan besar untuk grafana. Ini akan berkembang dalam waktu,
tetapi dalam waktu singkat itu diterapkan itu menambah nilai besar untuk grafana,
dan terima kasih kepada semua kontributor untuk itu!

Am 06.12.2016 11:14 nachm. schrieb "Torkel degaard" <
[email protected]>:

Ya, tetapi dasbor eksplorasi umum tidak sama dengan dasbor
desain untuk aturan peringatan.

Sejauh ini belum ada usulan bagaimana mendukung variabel template
dengan cara yang intuitif/dapat dimengerti. Apa yang harus mengingatkan kueri dengan variabel
melakukan? Interpolasi dengan nilai variabel tersimpan saat ini, dengan semua? Haruskah?
perlakukan setiap nilai sebagai aturan terpisah dan pertahankan status untuk setiap dll. Mendukung
variabel templating membuka sekaleng worm untuk kompleksitas dan berpotensi
perilaku yang membingungkan. mungkin e menambahkan suatu hari jika seseorang datang dengan
cara yang sederhana dan mudah dipahami.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 Torkel.

Itu membuat peringatan cukup rumit.

Pada Selasa, 6 Des 2016 pukul 14:14, Torkel degaard [email protected]
menulis:

Ya, tetapi dasbor eksplorasi umum tidak sama dengan dasbor
desain untuk aturan peringatan.

Sejauh ini belum ada usulan bagaimana mendukung variabel template
dengan cara yang intuitif/dapat dimengerti. Apa yang harus mengingatkan kueri dengan variabel
melakukan? Interpolasi dengan nilai variabel tersimpan saat ini, dengan semua? Haruskah?
perlakukan setiap nilai sebagai aturan terpisah dan pertahankan status untuk setiap dll. Mendukung
variabel templating membuka sekaleng worm untuk kompleksitas dan berpotensi
perilaku yang membingungkan. mungkin e menambahkan suatu hari jika seseorang datang dengan
cara yang sederhana dan mudah dipahami.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

--
Deepak

@bergquist tentang komentar ini

waspada dalam grafana belum mendukung HA. Rencana kami adalah menambahkan dukungan ke peringatan partisi antar server di masa mendatang

Apakah ada tiket untuk melacak kemajuan? Setiap cabang untuk berkontribusi?

Dan terima kasih banyak untuk pekerjaan yang bagus!

Lelaki yg tdk terpelajar,

<3 granat.

Saya hanya mencoba berbagi pemikiran seputar peringatan dengan template
dasbor.

Pada Jumat, 9 Des 2016 pukul 02:53, Dmitry Zhukov [email protected]
menulis:

@bergquist https://github.com/bergquist mengenai komentar ini

waspada dalam grafana belum mendukung HA. Rencana kami adalah untuk menambahkan
dukungan untuk peringatan partisi antar server di masa mendatang

Apakah ada tiket untuk melacak kemajuan? Setiap cabang untuk berkontribusi?

Dan terima kasih banyak untuk pekerjaan yang bagus!

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

--
Deepak

@torkelo @Dieterbe Luar biasa akhirnya memiliki peringatan yang terpasang di Grafana! Apa cara yang disarankan (jika ada) untuk membuat lansiran secara terprogram?

@jaimegago untuk membuat lansiran secara terprogram menggunakan api dasbor, lansiran disimpan bersama dengan panel & dasbor.

@torkelo Bagaimana dengan target notifikasi (misalnya membuat email notifikasi baru melalui API)?

edit: Menjawab sendiri di sini, saya menemukan titik akhir api/alert-notifications. Saya pikir itu hanya perlu didokumentasikan

Tentu saja ada http api untuk itu, cukup buka halaman notifikasi peringatan, tambahkan notifikasi dan periksa panggilan http api yang dibuat grafana

@torkelo , Apakah ada api yang dapat digunakan untuk membuat lansiran (bukan membuat pemberitahuan lansiran) secara terprogram

@CCWeiZ Alerts adalah bagian dari dasbor json. Jadi Anda hanya bisa membuat dashboard yang berisi alert bukan alert saja.

Anda dapat membaca lebih lanjut tentang api dasbor di http://docs.grafana.org/http_api/dashboard/

apakah ini tersedia: Saya ingin menyiapkan peringatan jika nilainya dibandingkan dengan 3 hari yang lalu, nilainya tidak meningkat. (kata permintaan, jika sekarang nilai - 3 hari yang lalu permintaan < 100, maka kami katakan tidak ada banyak permintaan.). Bagaimana cara melakukannya?