Grafana: [Permintaan fitur] Beberapa peringatan per grafik

Kasus penggunaan konkret: Saya telah melengkapi aplikasi saya untuk merekam histogram di Prometheus untuk setiap fungsi utama (mis. di mana panggilan HTTP eksternal atau I/O disk berlangsung) dan ingin memperingatkan ketika salah satu dari ini menjadi lambat.

Saat ini saya harus mendefinisikan grafik dummy untuk ini karena hubungan 1:1 antara grafik dan peringatan. Akan jauh lebih logis untuk menjaga peringatan tetap didefinisikan di tempat yang sama dengan grafik itu sendiri.

Dan Anda tidak dapat mendefinisikannya dalam satu kueri?

Tidak; rangkaian kondisi OR masih mentah, dan satu nama Lansiran tidak dapat dengan jelas mengidentifikasi alasan yang tepat untuk lansiran tersebut. Saya benar-benar tidak ingin mengirim peringatan seperti Some part of service X is failing - insinyur panggilan tidak akan menjadi teman saya...

maka lebih masuk akal untuk memiliki panel terpisah untuk peringatan, jika Anda ingin nama & pesan aturan peringatan terpisah, dll.

Ya, itulah yang saya lakukan saat ini. Apakah ada kemungkinan penerapan beberapa lansiran per grafik dalam waktu dekat sehingga saya dapat beralih dari solusi ini?

itu sangat tidak mungkin

mungkin jika ada permintaan besar untuk itu :)

haha OK - Saya akan melihat apakah saya bisa mengaduk-aduk massa yang marah ;) Serius tho', terima kasih atas kejujurannya.

Ok kita punya massa dua :-) Saya membuat grafik tingkat bahan bakar di beberapa tangki & ingin mengatur peringatan bahan bakar rendah untuk setiap tangki.

dan setiap tangki memiliki ambang batas atau notifikasi yang berbeda?

Tepat. Salah satunya adalah tangki minyak pemanas 285 gal. Saya ingin mengatur peringatan "minyak pemanas rendah" ketika tangki itu berada di bawah 70gals. Yang lainnya adalah tangki propana 500 gal, untuk itu saya menginginkan peringatan "propana rendah" ketika berada di bawah 100 gal. Saya mengatur singlestats untuk masing-masing tetapi peringatan tidak tersedia di singlestat.

Saya memiliki grafik dengan median dan metrik persentil ke-90. Saya ingin mendapatkan peringatan pada masing-masing. Untuk melakukan ini, saya harus membuat satu grafik untuk masing-masing. Kemudian, jika saya ingin peringatan dan peringatan kritis untuk masing-masing, saya harus membuat grafik kedua untuk masing-masing.

Saya memiliki 30 atau 40 layanan untuk dipantau, masing-masing dengan 2 hingga 5 metrik utama. Saya memiliki grafik di mana saya membuat grafik metrik yang sama untuk beberapa pelanggan, dan meskipun saya tidak perlu melakukan lansiran per pelanggan (belum), itu menambah jumlah metrik yang saya inginkan untuk memiliki lansiran. Jumlah pekerjaan untuk membuat lusinan grafik berkembang sangat cepat. Akan sangat berguna di lingkungan produksi saya saat ini (dan di lingkungan produksi saya sebelumnya) untuk memiliki peringatan dan peringatan kritis, dan untuk menampilkan beberapa metrik dalam satu grafik dan peringatan pada mereka.

Saya juga ingin melihat fitur ini. Contoh yang baik adalah satu peringatan jika metrik berada di luar ambang batas dan peringatan lainnya jika data gagal diperbarui. Yaitu, jika nilai terlalu tinggi atau jika nilai gagal dilaporkan. Ini dapat digunakan untuk menunjukkan bahwa apa pun yang melaporkan data telah mengalami masalah yang mencegah komunikasi dengan grafana (atau backend apa pun).

Halo Torkelo!

Saya mendapat beberapa "suka" untuk fitur ini! Akankah kita memasuki realease berikutnya =) ?

@rmsys mungkin di beberapa titik, menyelesaikannya dari perspektif UX & kompleksitas kode (dan kompleksitas UX) akan memakan waktu, itu belum ada di peta jalan apa pun, tapi mungkin tahun depan karena mesin peringatan lebih matang dan desain UX untuk ini berfungsi keluar

Kasus penggunaan lain yang baik untuk beberapa peringatan adalah memiliki ambang tingkat keparahan yang berbeda dengan tindakan yang berbeda. Jika server mulai menunjukkan pelambatan, email mungkin sudah cukup, tetapi jika pelambatan menjadi ekstrem, mungkin ada baiknya melakukan paging ke administrator.

Saya memiliki grafik yang mengembalikan metrik dengan nilai valid dan invalid . Ini akan berguna bagi saya karena saya dapat menggunakan satu grafik yang berisi dua kueri untuk membuat peringatan yang diaktifkan ketika valid terlalu rendah dan invalid terlalu tinggi.

Selain itu, melacak status lansiran yang terpisah tidak selalu disukai (karena pengguna akhir perlu mengetahui detail di balik masing-masing status ) vs hanya mengetahui apakah lansiran dipicu.

Tidak yakin saya mengerti apa yang Anda maksud dengan ini. Bisakah Anda menguraikan?

Bisakah Anda menjelaskan bagaimana beberapa lansiran per grafik akan bekerja dan terlihat? Apa yang akan dikatakan anotasi, dan hati hijau/merah di samping judul panel ditampilkan (jika katakan 2/5 aturan peringatan di mana menembak)?

Apakah Anda ingin berbagi sesuatu di antara aturan peringatan atau akankah mereka benar-benar terisolasi (Selain tinggal di panel grafik yang sama dan mungkin merujuk ke kueri yang sama).

Bagaimana Anda memvisualisasikan ambang ketika Anda memiliki beberapa aturan peringatan? Apakah mereka akan muncul sebagai aturan terpisah di halaman aturan peringatan & panel daftar peringatan? Maka Anda memerlukan cara untuk menavigasi ke contoh aturan tertentu dan bukan hanya ke tab peringatan.

Grafana adalah alat visual dan kami telah memilih untuk mengikat aturan peringatan ke grafik sehingga status aturan peringatan dapat divisualisasikan dengan mudah (melalui metrik, ambang batas & riwayat status peringatan). Saya khawatir setiap grafik dapat mewakili beberapa aturan peringatan akan memperumit ini hingga batas yang sangat besar dan saya tidak yakin tentang perlunya ini.

@rssalerno memiliki dukungan untuk aturan peringatan di panel singlestat tampaknya tidak terkait dengan masalah ini.

@alex-phillips skenario Anda sepertinya dapat diselesaikan dengan membuat aturan peringatan individual lebih fleksibel.

Apakah seseorang memiliki beberapa contoh konkret di mana ini akan bagus? Hanya tidak melihat skenario di mana itu akan berakhir dalam grafik yang membingungkan dengan ambang batas 2-5 yang tidak Anda ketahui terkait dengan metrik dan anotasi riwayat lansiran yang Anda juga tidak tahu dari mana aturan lansiran itu berasal (tanpa mengarahkan kursor).

Bisakah Anda menjelaskan bagaimana beberapa lansiran per grafik akan bekerja dan terlihat? Apa yang akan dikatakan anotasi, dan hati hijau/merah di samping judul panel ditampilkan (jika katakan 2/5 aturan peringatan di mana menembak)?

Saya pikir beberapa aturan peringatan akan dijelaskan satu per satu. Hati mungkin diberi kode warna. Aturan perlu diberi nama untuk membedakan dalam peringatan/panel.

Apakah Anda ingin berbagi sesuatu di antara aturan peringatan atau akankah mereka benar-benar terisolasi (Selain tinggal di panel grafik yang sama dan mungkin merujuk ke kueri yang sama).

Secara umum saya pikir tidak, meskipun saya menduga grup perlu memiliki ambang batas bersama, dan memberi nama jika mereka diterapkan (per https://github.com/grafana/grafana/issues/6557#issuecomment-324363795).

Bagaimana Anda memvisualisasikan ambang ketika Anda memiliki beberapa aturan peringatan? Apakah mereka akan muncul sebagai aturan terpisah di halaman aturan peringatan & panel daftar peringatan? Maka Anda memerlukan cara untuk menavigasi ke contoh aturan tertentu dan bukan hanya ke tab peringatan.

Jika aturan mengambil parameter warna tambahan, ambang batas dapat dirender menggunakan itu, dan dibedakan seperti itu, mungkin juga menginginkan tooltip. Mampu beralih aturan akan berguna, dan param untuk membuat aturan tertentu menangani yang terakhir, saya pikir?

@rssalerno memiliki dukungan untuk aturan peringatan di panel singlestat tampaknya tidak terkait dengan masalah ini.

Saya yakin Anda akan menemukan bahwa dia mengacu pada grafik di bawah ini, meskipun karena dia memiliki panel terpisah untuk setiap tangki, peringatan status tunggal dapat menyelesaikan masalahnya untuk dasbor khusus itu.

Apakah seseorang memiliki beberapa contoh konkret di mana ini akan bagus? Hanya tidak melihat skenario di mana itu akan berakhir dalam grafik yang membingungkan dengan ambang batas 2-5 yang tidak Anda ketahui terkait dengan metrik dan anotasi riwayat lansiran yang Anda juga tidak tahu dari mana aturan lansiran itu berasal (tanpa mengarahkan kursor).

Terutama, saya ingin ini mendukung #6557 dan #6553, dan untuk beberapa ambang batas, mirip dengan @alex-phillips. Misalnya, satu kasus penggunaan yang kami miliki untuk #6557 adalah memberi peringatan secara berbeda untuk lingkungan yang berbeda ( production , beta , dev , dll), dikombinasikan dengan beberapa ambang yang akan memecahkan sebagian besar masalah kita. Jika ada cara yang lebih baik untuk melakukan itu tanpa banyak aturan, itu tidak jelas bagi saya.

@torkelo

Bisakah Anda menjelaskan bagaimana beberapa lansiran per grafik akan bekerja dan terlihat? Apa yang akan dikatakan anotasi, dan hati hijau/merah di samping judul panel ditampilkan (jika katakan 2/5 aturan peringatan di mana menembak)?

Saya suka pendekatan yang disarankan oleh @pdf

Selanjutnya, pendekatan untuk menampilkan anotasi akan sama dengan kasus saat ini, di mana Anda memiliki aturan peringatan dengan > 1 kondisi (masing-masing memiliki ambang batas yang berbeda). Dan hati hijau/merah di samping judul panel akan ditampilkan sebagai merah (jika ada setidaknya satu peringatan yang diaktifkan), mirip dengan skenario saat ini di mana setidaknya satu kondisi aturan peringatan yang dievaluasi ke true). Dan mungkin juga menunjukkan nomor (2/5) bersama dengan hati merah di judul.

Apakah Anda ingin berbagi sesuatu di antara aturan peringatan atau akankah mereka benar-benar terisolasi (Selain tinggal di panel grafik yang sama dan mungkin merujuk ke kueri yang sama).

Dalam sebagian besar kasus penggunaan kami, aturan ini tidak akan membagikan apa pun di antara mereka dan kueri juga berbeda

Bagaimana Anda memvisualisasikan ambang ketika Anda memiliki beberapa aturan peringatan? Apakah mereka akan muncul sebagai aturan terpisah di halaman aturan peringatan & panel daftar peringatan? Maka Anda memerlukan cara untuk menavigasi ke contoh aturan tertentu dan bukan hanya ke tab peringatan.

Mereka akan muncul sebagai aturan terpisah di halaman peringatan. Tab Peringatan, mungkin akan memiliki daftar peringatan yang ditentukan. Benar, kita perlu menyorot/memperluas aturan peringatan khusus pada tab ini, ketika url aturan alret (harus menangkap id atau indeks peringatan) diakses dari notifikasi. Tampaknya mudah dipecahkan.

Di panel daftar peringatan, tidak akan ada perubahan apa pun. Ini menunjukkan semuanya secara terpisah. Secara semantik, setiap peringatan terpisah. Hanya saja itu telah ditempatkan di panel yang sama.

Apakah seseorang memiliki beberapa contoh konkret di mana ini akan bagus? Hanya tidak melihat skenario di mana itu akan berakhir dalam grafik yang membingungkan dengan ambang batas 2-5 yang tidak Anda ketahui terkait dengan metrik dan anotasi riwayat lansiran yang Anda juga tidak tahu dari mana aturan lansiran itu berasal (tanpa mengarahkan kursor).

Mempertimbangkan bahwa banyak orang telah memilih fitur ini, itu pasti akan menjadi fitur yang berguna. Jika kami memiliki dukungan untuk beberapa peringatan, maka saya pikir itu akan tergantung pada persepsi masing-masing pengguna apakah itu membingungkan atau tidak. IMHO, mereka yang menganggapnya membingungkan akan menggunakan pendekatan panel terpisah saat ini untuk setiap grafik dan bagi mereka yang berpikir utilitas/kenyamanan memiliki panel yang sama digunakan untuk visualisasi dan peringatan melebihi kebingungan yang dirasakan, akan menggunakan beberapa cara peringatan . Tentu itu akan sedikit mengubah UX

Di splunk kami memiliki peringatan tinggi/rendah. Jika beberapa peringatan di grafana tersedia, kami hanya akan menggunakan pencarian yang sama, mereka hanya ambang batas yang berbeda terhadap pencarian yang sama.

+1 untuk fitur ini.

+1 untuk ini. Kasus penggunaan kami adalah sebagai berikut: Kami ingin mendefinisikan satu grafik dengan, katakanlah, penggunaan cpu untuk semua server kami. Kemudian pada grafik yang sama kita akan membuat dua metrik tersembunyi, satu untuk penggunaan cpu di server produksi dan satu lagi untuk penggunaan cpu di server non-produksi. Masing-masing metrik tersebut akan memiliki peringatannya sendiri, dengan saluran notifikasi yang berbeda. Kami tidak ingin harus membuat beberapa bagan atau panel atau dasbor untuk mencapai hal ini.

+1 untuk fitur ini.

Datang ke sini membaca beberapa masalah lain mengenai kategori dan tingkat keparahan. Saya setuju semua peringatan harus dapat ditindaklanjuti. Tetapi ada perbedaan antara peringatan "perbaiki hal pertama ini di pagi hari" dan peringatan "panggil konsultan $400/jam secepatnya".

Seperti yang telah disebutkan banyak orang, ini paling umum diselesaikan dengan ambang Peringatan dan Kritis.

Secara teknis ini dapat diimplementasikan dalam banyak cara, label, beberapa peringatan per panel, beberapa ambang batas per peringatan, dll.

Mengenai kebingungan jika kategorisasinya terlalu rumit, pengaturan Peringatan/Kritis cukup menggunakan Merah/Kuning. Merah mengalahkan Kuning.

Untuk pengaturan yang lebih kompleks, opsi lain selain mengarahkan kursor untuk menemukan deret waktu yang menyinggung dapat berupa garis/area/apa pun yang berkedip? Itu bisa menarik perhatian ke deret waktu yang benar dengan mudah.

Saya pikir sebagian besar pengguna akan puas dengan pemisahan Warn/Crit yang cukup sederhana.

Ini adalah keharusan mutlak untuk perangkat lunak peringatan, terutama untuk pemantauan server. Ruang disk, memori, penggunaan cpu, suhu, rata-rata beban.... semua contoh utama di mana seseorang ingin beberapa peringatan dikonfigurasi dengan pesan yang berbeda dengan ambang batas yang berbeda. Ambil ruang disk misalnya. Perlu satu peringatan untuk penggunaan disk lebih dari 70%, yang lain untuk penggunaan disk lebih dari 90%.

Sedikit kasus tepi, tetapi kami menggunakan peringatan untuk memberi tahu kami jika suatu produk tidak terjual dalam beberapa hari. Kami memiliki setiap produk sebagai metrik, yang berarti kami hanya mendapatkan satu lansiran saat salah satu metrik memasuki ambang lansiran. Idealnya kami ingin menerima lansiran jika lansiran tersebut menunjukkan metrik tambahan apa pun yang telah memasuki ambang lansiran juga.

Kami juga menggunakan var templating untuk mengulang grafik untuk setiap produk yang dipilih dengan dua metrik yang dilapis (volume dan margin kotor) pada sumbu y kiri dan kanan. Ini menghilangkan peluang apa pun untuk menggunakan peringatan karena kueri peringatan tidak mengambil variabel daftar $sku untuk IN ($sku) kami.

Untuk mengatasinya, saya mencoba membuat kueri lain B yang hanya menjalankan kueri templat untuk mencari semua skus yang kami minati dan memasukkannya langsung ke kueri peringatan IN (SELECT skus from interested_product_table) . Namun ini mulai mengirimkan peringatan kepada kami untuk setiap grafik untuk semua metrik di setiap grafik yang berarti kami mendapatkan:

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

Misalnya yang cukup spam.

Sepenuhnya setuju bahwa fitur tersebut adalah keharusan dan sangat tidak setuju bahwa SEMUA notifikasi harus dapat ditindaklanjuti.

Contoh paling sederhana adalah Anda mungkin memiliki peringatan yang Anda dapatkan dan Anda perlu melakukan beberapa tindakan sesegera mungkin seperti keesokan paginya sementara ada jenis peringatan lain yang akan membuat Anda bangun bahkan di tengah malam untuk memperbaiki server produksi.

Melemparkan dua sen saya - saya ingin memiliki fitur ini.

Saya bahkan tidak memerlukan hati yang berbeda atau hati dengan warna yang berbeda (merah untuk peringatan apa pun pada grafik tidak masalah), itu adalah pemberitahuan email yang saya inginkan untuk nama yang berbeda.

Silakan tambahkan fitur ini. untuk kasus penggunaan seperti ini,
dari grafik tunggal
jika nilai > X --> kendur
jika Nilai > X+Y --> PD

Kami memiliki kebijakan di sini tentang lansiran yang dapat ditindaklanjuti, di mana lansiran tersebut harus menentukan tindakan yang harus diambil jika memungkinkan. Kami memiliki tindakan berbeda yang harus diambil berdasarkan metrik yang terlalu rendah, atau terlalu tinggi.

Misalnya: CPU RDS terlalu rendah? periksa tumpukan lain di sini untuk mengetahui perilakunya. Terlalu tinggi? Tingkatkan instance.

Seperti yang lain, kami juga ingin memiliki berbagai jenis peringatan di ambang batas yang berbeda.

Mirip dengan @jdblack Saya ingin memiliki tingkat peringatan air yang tinggi dan tingkat darurat air yang tinggi. Saya tahu saya bisa melakukannya dengan dua pertanyaan tetapi tidak seintuitif atau licin.

Saya sedang berpikir untuk menggunakan Grafana sebagai cara untuk memberi sinyal pada sistem penskalaan otomatis. Jika metrik terlalu rendah, kirim webhook dengan pesan untuk memperkecil, jika terlalu tinggi, kirim webhook dengan pesan untuk memperkecil. Tanpa banyak peringatan, saya tidak percaya ini tidak mungkin. Saya juga setuju dengan orang lain di utas bahwa kasus penggunaan untuk "peringatan" lalu ambang "kritis" adalah umum.

Mungkin gagasan untuk menggabungkan lansiran ke grafik harus ditinjau kembali? Mungkin lansiran harus dibuat secara terpisah, dengan grafik pratinjau yang bagus saat membuat lansiran. Pemisahan ini mungkin membuatnya lebih berfungsi saat mengubah metrik grafik, tetapi setidaknya ini akan memiliki lebih banyak fleksibilitas dalam membuat beberapa lansiran.

Saya sudah mencoba menggunakan Grafana + Influx untuk jaringan sensor. Dasbor berfungsi cukup baik, kecuali untuk peringatan. Saya perlu diperingatkan ketika Sensor123 melebihi ambang batas tertentu. Saya tidak perlu bagan untuk itu, hanya peringatan. Juga, saya harus berpotensi memiliki 1000-an sensor. Saya dapat menyiapkan peringatan jika sensor "ada" melebihi ambang batas, tetapi saya perlu tahu yang mana yang/sedang diperingatkan. Saya memiliki pengaturan dasbor dengan variabel templat untuk melihat sensor tertentu, tetapi saya tidak dapat menambahkan peringatan untuk variabel templat. Untuk pengujian, saya hanya menyiapkan beberapa peringatan untuk beberapa sensor di dasbor tambahan yang tidak dilihat oleh siapa pun, tetapi untuk selanjutnya saya memerlukan solusi yang berbeda untuk peringatan.

@torkelo , Mendekati satu tahun sejak komentar resmi tentang ini - hanya ingin tahu apakah ada pembaruan yang dapat dibagikan sekarang karena sistem peringatan telah berada di alam liar selama beberapa waktu?

@MakoSDV Anda harus mempertimbangkan untuk menggunakan kapacitor untuk kasus penggunaan itu.

+1 untuk fitur ini; itu akan sangat berguna juga untuk peringatan dua tingkat (misalnya: sesuatu > X = peringatan kuning, sesuatu > Y = peringatan merah)

+1 untuk membuat peringatan lebih fleksibel

saya memantau grafik suhu di boiler pemanas, ambang batas suhu rendah adalah hal yang sepele dan perlu pergi ke saluran notifikasi yang tidak kritis, tetapi suhu tinggi sangat mendesak dan perlu berdengung melalui saluran yang mendesak. Beberapa aturan peringatan akan sangat masuk akal di sini.

Sangat disayangkan bahwa masalah ini tampaknya diabaikan. Adakah yang tahu bagaimana kami bisa menarik perhatian pengembang?

Sepertinya dari segi UI, akan relatif mudah untuk menerapkan lansiran dengan cara menimpa diterapkan, untuk memungkinkan satu atau lebih lansiran tanpa banyak perubahan UI.

@Gaibhne menulis:

Adakah yang tahu bagaimana kita bisa mendapatkan perhatian pengembang untuk itu?

Membayar untuk dukungan mungkin? Sepertinya belum ada sumber daya yang tersedia untuk kekurangan terkait peringatan yang serius, meskipun mereka tetap menjadi masalah yang dinilai pengguna Github tertinggi selama bertahun-tahun.

+1 untuk permintaan ini.

Kami memiliki penghitung yang disiapkan di aplikasi kami ketika permintaan ke layanan eksternal kami integrasikan dengan waktu habis yang kami buat grafiknya di Grafana.

Jika ada beberapa waktu jeda yang ingin kami ketahui sehingga kami dapat mengejar layanan eksternal tentang hal itu nanti, jika ada banyak waktu tunggu, itu berarti aplikasi kami kemungkinan besar terpengaruh oleh sebagian besar pelanggan, jadi kami perlu merespons dan segera atasi.

+1 untuk ini juga.

Saat ini mencoba menyiapkan dua lansiran terpisah untuk grafik:

1. Pesan kendur untuk data yang mencapai level _warning_
2. Peringatan Pager Duty untuk data yang mencapai level _critical_

Saat ini untuk pemahaman saya, saya harus membuat dua grafik terpisah dari data yang sama untuk mencapai ini. Akan lebih masuk akal bagi saya untuk memiliki beberapa peringatan berbeda yang bekerja pada grafik yang sama.

@torkelo apakah ada pembaruan tentang rencana ini masuk ke 2019?

+1

Kami memiliki dasbor yang memantau layanan mikro yang sama untuk beberapa klien/lingkungan menggunakan variabel untuk beralih di antara lingkungan yang ditampilkan.

Rasa sakit kami saat ini dapat dikurangi jika kami dapat menggunakan variabel dalam judul/teks peringatan sehingga kami dapat mengidentifikasi klien/lingkungan, tetapi dalam jangka panjang kami sangat menginginkan kemampuan untuk membuat peringatan terpisah dengan ambang batas yang berbeda menggunakan grafik yang sama.

Akan lebih bagus bahkan jika diperlukan menggunakan kueri yang berbeda untuk setiap peringatan, dan hanya mengatur kueri agar tidak terlihat di grafik.

Apa yang Anda gambarkan @itonlytakeswon juga tampaknya terkait dengan https://github.com/grafana/grafana/issues/6557 , jadi Anda mungkin ingin melacak yang itu juga :)

Bagaimana ini bukan fitur?

@ jsterling7 menjelaskan kasus penggunaan yang kami inginkan dengan sempurna.

@torkelo Setiap rilis fitur

Baik beberapa peringatan atau mengizinkan nilai tag di judul/isi peringatan di suatu tempat akan menyelesaikan ini untuk penggunaan kami. Kami memiliki satu grafik yang menunjukkan metrik yang diberi tag dengan beberapa sumber independen dan ingin tahu mana yang turun di bawah ambang batas. Saya sekarang sedang membuat 10 grafik terpisah yang saya perlukan untuk menyelesaikan ini, tetapi rasanya seperti fitur yang hilang dan buruk untuk pemeliharaan jangka panjang di pihak saya.

Sepertinya permintaannya tinggi, saya salah satu yang membutuhkan fitur seperti ini. Saya hampir menyukai grafana lalu tiba-tiba batasan ini mematikan saya.

Kasus penggunaan saya mirip dengan yang lain yang dirujuk di sini dan untuk masalah #6557. Kami memiliki beberapa cluster elasticsearch yang dipantau dalam satu dasbor template. Saya ingin memicu peringatan kepada mereka satu per satu dan seperti sekarang saya tidak bisa hanya membuat grafik dengan kueri yang di-hardcode tetapi harus membuat grafik untuk setiap cluster, agar peringatan ini berfungsi ...

+1, ini akan sangat membantu lingkungan kita! Bahkan hanya dua peringatan 'hati' kuning/merah per pengaturan grafik, di mana jika merah dipicu, itu menimpa kuning.

Memberi +1 ini akan bagus, bertanya-tanya betapa sepelenya membiarkan setiap kondisi memiliki pemberitahuan peringatan opsional yang dapat dikonfigurasi dan jika bukan karena kondisi tertentu, itu dapat kembali ke pesan pemberitahuan default ... cara tercepat untuk mewujudkannya kupikir ?

+1 itu akan sangat berguna bagi kami juga. Kami memiliki banyak dasbor dengan templating pada beberapa variabel, akan sangat bagus jika penggantian templat dilakukan pada nama lansiran dan pemberitahuan lansiran.

+1, IMO ini harus ada di setiap sistem pemantauan ... ada banyak situasi ketika Anda perlu mengidentifikasi tingkat keparahan peringatan dan bereaksi sesuai, yang berarti beberapa peringatan dengan ambang batas yang berbeda di dasbor yang sama.

+1 dari saya juga - kaget ini belum ada!

+1

Saya pikir fitur ini berjalan seiring dengan keterbatasan dukungan kueri template.

Saya telah menyiapkan beberapa grafik yang diberi makan prometheus dengan kueri yang memiliki templat, dan mengetikkan label. Saya mengatasi masalah template dengan membuat kueri tak terlihat untuk nilai template.

Saya ingin lansiran terpisah untuk setiap nilai template, tetapi saya terbatas pada satu lansiran dengan pesan+tindakan satu ukuran untuk semua yang umum. Saya dapat menggunakan daftar OR yang panjang untuk mengingatkan semua pertanyaan saya, tetapi ini terasa kasar.

Alternatifnya adalah membuat dasbor terpisah dengan banyak panel yang tidak terlihat oleh siapa pun, hanya sebagai sumber peringatan.

Menambahkan dukungan untuk beberapa lansiran sepertinya berpotensi menjadi langkah pertama dalam mendukung lansiran kueri template.

+1. Ini harus dimiliki!

+1 Ini sangat berguna

@torkelo "maka lebih masuk akal untuk memiliki panel terpisah untuk peringatan, jika Anda ingin nama & pesan aturan peringatan terpisah, dll."

Ini tidak masuk akal. Mengharuskan pengguna untuk memvisualisasikan panel yang sama beberapa kali hanya agar mereka dapat mengirim pesan peringatan non-generik yang berguna bukanlah solusi. Ini adalah peretasan untuk sesuatu yang seharusnya menjadi fitur, dan menambahkan kebisingan yang menurunkan kegunaan produk.

@torkelo "maka lebih masuk akal untuk memiliki panel terpisah untuk peringatan, jika Anda ingin nama & pesan aturan peringatan terpisah, dll."

Ini tidak masuk akal. Mengharuskan pengguna untuk memvisualisasikan panel yang sama beberapa kali hanya agar mereka dapat mengirim pesan peringatan non-generik yang berguna bukanlah solusi. Ini adalah peretasan untuk sesuatu yang seharusnya menjadi fitur, dan menambahkan kebisingan yang menurunkan kegunaan produk.

Tepat. +1 untuk beberapa peringatan per panel

Dalam situasi kami, kami mengukur voltase sel dalam baterai (16 sel per baterai). Kami membuat grafik 16 seri pada satu panel untuk perbandingan dan memiliki panel yang berbeda untuk setiap baterai.

Peringatan tunggal untuk panel (grafik) tidak terlalu membantu. Kami benar-benar membutuhkan kemampuan untuk mengatur setidaknya satu peringatan per sel sehingga email peringatan menunjukkan sel mana yang berada di luar jangkauan dalam hal voltase.

Karena, dalam kasus kami, rentang tegangan yang dapat diterima adalah sama untuk setiap sel, akan sangat bagus jika dapat menentukan batas atas dan bawah serta menghubungkan rentang sel individu dengan batas yang ditentukan.

Saat ini kami harus memprogram 16 x OR pernyataan untuk seri sel, dan (kembali) -menentukan batas untuk setiap sel dalam proses - sulit untuk diatur dan mimpi buruk pemeliharaan untuk dimodifikasi.

Idealnya kita juga harus memprogram peringatan dan kejadian kritis untuk setiap sel pada panel grafik.

Saya pikir sudah saatnya struktur peringatan dimodifikasi untuk mencakup persyaratan yang telah diidentifikasi pengguna. Persyaratan ini biasanya diterapkan dalam sistem SCADA yang juga menghasilkan peringatan. Ini benar-benar hanya mesin logika, bukan?

Ada pembaruan tentang ini? Saya merasa fitur ini harus dimiliki untuk penerapan yang lebih besar. Terutama karena kami ingin memiliki satu grafik misalnya menunjukkan penggunaan penyimpanan, kami ingin peringatan untuk 70%, 80% dll. yang seharusnya tidak menampilkan grafik dalam jumlah besar.

Saya baru saja menemukan ini dan saya sangat terkejut belum ada cara untuk melakukan ini D:

Saya melihat di sini https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 bahwa ini tidak akan diterapkan di masa mendatang dan sepertinya peringatan akan ditarik sepenuhnya dari dasbor.

Bagaimana ini akan memengaruhi model json dasbor? Adakah yang bisa berbicara dengan kapan akan ada lebih banyak berita seputar ini?

Ini adalah fitur yang sangat dibutuhkan. Adakah pembaruan tentang situasi yang akan datang?

+1 untuk beberapa peringatan per panel

+1 untuk fitur ini.

Ini adalah fitur yang sangat dibutuhkan. Adakah pembaruan tentang situasi yang akan datang?

Butuh fitur ini.

3 tahun kemudian.. Seseorang dapat memberi tahu kami mengapa ini tidak diterapkan (walaupun jumlah permintaan)?
Itu karena kendala teknis untuk mengimplementasikannya? Itu ditolak? Ini harus dilakukan?
Seperti yang dikatakan sebelumnya, tampaknya 'fitur dasar'.
Contoh: Saya memiliki dasbor dan seri dengan 200 server, jika saya menambahkan peringatan:
Satu dari 200 server mati: keren, saya menerima peringatan dengan nama
Ups, server baru mati: tidak ada peringatan (atau perlu menyegarkan dasbor atau menunggu pengingat 24 jam setelahnya..)
Ini tidak mungkin untuk menambahkan seperti kotak centang untuk diperiksa sehingga kami dapat diperingatkan oleh baris dalam seri (bukan oleh seri 'penuh')?
Jika seseorang dari dev, tim grafana dapat menjawab untuk umpan balik ...

Maukah Anda mencoba prometheus untuk mengingatkan dan meninggalkan grafana untuk melakukan dasbor?

@beastea Jika Anda harus menyiapkan alat lain hanya untuk membuat Grafana berfungsi, tidak ada gunanya menggunakan Grafana. Kami pindah ke Datadog karena fungsi ini ada di sana dan hanya ada satu alat.

@anne-nelson Anda harus mengatur pengumpul metrik, penyimpanan metrik dan untuk pengaturan yang tepat, mainkan dengan HA di sekitarnya untuk membuat Grafana berfungsi, bukan?
Datadog bukan hanya satu alat, itu hanya menyembunyikannya dari Anda dan melakukan pekerjaan dengan baik, juga, Anda masih dapat menggunakan grafana dengan datadog: https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea Saya tidak yakin alat apa itu, jadi saya rasa kami tidak menggunakannya. Metrik kami dikirim ke Influx, kami hanya akan mengirimkannya ke Datadog, bukan Grafana. Mengapa saya mengirim sesuatu ke Datadog melalui Grafana ketika saya bisa mengirimnya secara langsung? Saya ingin menggunakan alat sesedikit mungkin.

@anne-nelson Anda dapat menerapkan metrik push di aplikasi Anda, tetapi terkadang ini sangat berguna untuk mendorong beberapa metrik sistem juga sehingga Anda dapat mengetahui apa yang terjadi dengan disk Anda dan barang-barang lainnya. Ini yang saya maksud dengan metrics collector, beberapa daemon lokal yang melakukan hal seperti itu, seperti telegraf, collectd atau fasih.
Masuknya dalam pengaturan Anda - adalah hal yang menyimpan metrik dan memberikan kemampuan yang kaya untuk melakukan pencarian melalui grafana sebagai antarmuka web ui ke data mentah yang memberi Anda kesempatan dengan menggunakan beberapa bahasa kueri masuknya internal untuk memanipulasi data Anda.
Dalam hal memiliki Datadog alih-alih Influx, ia bekerja dengan cara yang persis sama. Grafana di sini -adalah ui untuk akses data. Dalam pengaturan umum. Jadi itu tidak melakukan apa pun dengan data Anda, itu hanya menyajikannya dalam grafik. Jadi Anda tetap mengirim mereka langsung.
Jika seperti yang Anda jelaskan, Anda bekerja dengan inlux mengapa Anda tidak dianggap menggunakan kapacitor atau fluks untuk memecahkan masalah yang Anda gambarkan karena mereka menyediakan banyak kemampuan reacher maka grafana dapat menawarkan Anda dan mereka masih dari vendor yang sama dan menyukai lingkungan yang sama. Flux bahkan merupakan bagian dari paket pengiriman masuk.

Ini akan sangat membantu.

@beastea jadi mungkin lebih baik menghapus fitur 'peringatan' di grafana dan memigrasikan orang ke alat lain (untuk menghindari pabrik gaz dari banyak alat)?
Maksud saya, OK, kita bisa menggunakan kapacitor, prometheus, dll. Tapi fitur alert sudah ada di Grafana jadi tidak masuk akal untuk kasus saya.

Btw, apa yang mencegah menambahkan kotak centang ini untuk memiliki peringatan per baris? Mungkin penjelasan dapat membantu untuk memahami.

@beastea Tampaknya sangat aneh bahwa Anda mencoba meyakinkan seseorang untuk tidak menggunakan Grafana.

Seperti yang ditunjukkan anthosz selama peringatan adalah fitur di Grafana, masuk akal untuk mengharapkan kemampuan untuk menambahkan beberapa peringatan ke grafik. Jika menurut Anda kami tidak boleh menggunakan Grafana untuk peringatan, maka Grafana seharusnya tidak memiliki peringatan sebagai fitur. Jelas bahwa banyak orang menginginkan fitur ini, dan banyak produk pesaing sudah menawarkannya. Sejujurnya saya tidak mengerti mengapa ada begitu banyak dorongan untuk ini.

@anne-nelson Saya tidak mencoba meyakinkan siapa pun untuk tidak melakukan apa pun yang ingin mereka lakukan. Saya mencoba memberikan saran untuk melihat ke arah berbeda yang sudah bisa menawarkan solusi kepada Anda hari ini.
Saya tidak mendikte apa yang harus Anda gunakan untuk apa, saya menawarkan alternatif yang bisa memberi Anda solusi hari ini. Saya tidak menolak, saya memberi Anda saran. Jika menurut Anda saran saya tidak membantu, jadi sayang sekali tapi ini dia. Saya minta maaf karena Anda merasa saya mengganggu Anda dan saya terlalu memaksa dengan saran saya.
Selamat bersenang-senang.

@beastea Saya berasumsi karena pembelaan Anda bahwa Anda bekerja untuk Grafana. Fitur ini relevan bagi banyak orang, dan menyarankan produk alternatif pada permintaan fitur tidak membantu dan menggagalkan diskusi ini. Ini bukan stackoverflow.

Bisakah semua orang membuangnya begitu saja? Anda berpotensi mengirim spam ke ratusan orang, ini tidak produktif.

Maaf untuk kebisingan tambahan semua.

@torkelo maukah Anda memberi kami pembaruan tentang permintaan fitur ini? Topik ini telah dibuka selama _tahun_ dan seperti yang Anda lihat masih menarik. Setidaknya mungkin membantu untuk mengurangi pertengkaran dan obrolan yang tidak perlu tentang topik ini untuk mendapatkan semacam jawaban "resmi" tentang apakah ini disertakan atau tidak di peta jalan saat ini. Bersulang.

Yang ini dan #6041 yang serupa sama sekali diabaikan. Kenapa ya.

Bagi kami masuk akal, karena tim operasi kami mendaftarkan integrasi baru di platform kami. Kami secara otomatis mulai mengirimkan metrik ke grafit. Dan hanya satu panel di grafana yang mengawasi semua ini.

Saat beberapa sistem mati, kami hanya mendapatkan peringatan untuk yang pertama. Dan juga tidak terlalu jelas.

Ketika satu turun, dan yang kedua padam juga, peringatan tidak menyala lagi.

Kasus penggunaan yang saya miliki untuk ini adalah untuk mendefinisikan peringatan tingkat pembakaran multi-jendela melalui prometheus dan grafana. Ini adalah praktik standar untuk memiliki lansiran jenis ini untuk pemantauan SLO seperti yang didefinisikan dalam buku pegangan Google SRE di https://landing.google.com/sre/workbook/chapters/alerting-on-slos/

Mutlak harus, tolong tindak lanjuti ini..

Saya juga telah pindah dari Prometheus Alerting ke Grafana Alerting dan saya sangat menantikan ini!

Dapatkah seseorang yang telah bekerja di Grafana sebelumnya membuat daftar tantangan yang diketahui dalam menangani hal ini?

Hai @torkelo , mungkin Anda bisa mencerahkan kami tentang masalah ini!

Mengecewakan melihat 7.x tidak ada peningkatan pada peringatan - saran sebelumnya bahwa peringatan harus dihapus sepenuhnya tidak membuat saya berharap, tetapi jika ini masalahnya, pasti menghapusnya di 7.x pasti sudah logis mengingat skala perombakan?

Akan sangat bagus untuk mendapatkan semacam pembaruan tentang mengapa ini sangat sulit untuk diterapkan, agar kami dapat memahami _mengapa_ masalah ini telah terbuka begitu lama.

@torkelo halo.
Saya memiliki kebutuhan yang sama - beberapa peringatan untuk satu metrik pada satu grafik tetapi dengan beberapa server yang dipantau.
Saya memiliki ~100 server dengan metrik ruang kosong yang ditentukan di partisi '/' (misalnya - karena saya memiliki puluhan metrik tersebut). Dan saya perlu menerima satu pemberitahuan peringatan unik di SETIAP server jika ruang kosong di '/' akan menjadi kurang dari 20%.
Saat ini hal itu tidak akan terjadi, jika, misalnya server2 akan mengeluarkan peringatan, dan saat orang-orang sedang mengerjakan pemecahan masalah, server4 akan mengeluarkan peringatan yang sama - kami tidak akan mendapatkan pemberitahuan. Atau apakah saya kehilangan beberapa fungsi?

Cara perkalian panel per server per metrik bukanlah cara.
Bisakah seseorang tolong lakukan saran untuk saya, bagaimana membuat ini mungkin?
Haruskah saya memutakhirkan Grafana saya (versi saat ini adalah 6.3.5)? Tambahkan beberapa ekstensi? Plugin? Ada yang lain?

Saya berterima kasih dan menghargai semua orang yang dapat memberi saran atau membantu.

@torkelo halo.
Saya memiliki kebutuhan yang sama - beberapa peringatan untuk satu metrik pada satu grafik tetapi dengan beberapa server yang dipantau.
Saya memiliki ~100 server dengan metrik ruang kosong yang ditentukan di partisi '/' (misalnya - karena saya memiliki puluhan metrik tersebut). Dan saya perlu menerima satu pemberitahuan peringatan unik di SETIAP server jika ruang kosong di '/' akan menjadi kurang dari 20%.
Saat ini hal itu tidak akan terjadi, jika, misalnya server2 akan mengeluarkan peringatan, dan saat orang-orang sedang mengerjakan pemecahan masalah, server4 akan mengeluarkan peringatan yang sama - kami tidak akan mendapatkan pemberitahuan. Atau apakah saya kehilangan beberapa fungsi?

Cara perkalian panel per server per metrik bukanlah cara.
Bisakah seseorang tolong lakukan saran untuk saya, bagaimana membuat ini mungkin?
Haruskah saya memutakhirkan Grafana saya (versi saat ini adalah 6.3.5)? Tambahkan beberapa ekstensi? Plugin? Ada yang lain?

Saya berterima kasih dan menghargai semua orang yang dapat memberi saran atau membantu.

Masalah ini dibuka sejak 2017 (Dan jawaban dari @torkelo adalah "lebih masuk akal untuk memiliki panel terpisah untuk peringatan" (sangat bagus untuk membuat panel oleh server/lansiran ketika kami memiliki 600 server) ).

Tampaknya satu-satunya cara adalah bermigrasi dari Grafana ke solusi lain atau membuat pabrik gaz dengan banyak alat untuk dirawat.

@anthosz - terima kasih banyak. Masalahnya adalah fakta lingkungan bukan milik kita tetapi milik pelanggan, jadi itu akan menjadi semacam tugas yang sangat tidak mudah bagi saya untuk bersikeras ini untuk memimpin saya dan seterusnya baginya untuk mengatasi pelanggan "tidak akan membayar untuk ini" .
Namun, setidaknya saya memiliki beberapa fakta yang mengatakan 'tidak ada kemungkinan untuk mengatur pemicu / alarm seperti itu - dengan cara ini'.

Terima kasih lagi.

_join(suara, paduan suara)_
Saya memiliki sensor arus pada sirkuit yang memantau pompa udara, nominal 1,5 Amps dan pompa limbah 10Amp nominal. Pompa udara bekerja 24/7, pompa efluen berjalan sesuai permintaan berdasarkan level tangki. Ketika semuanya baik-baik saja, arus (I) adalah 1,5A saat pompa limbah mati atau 11,5A saat pompa limbah hidup.

Kegagalan umum pertama adalah pompa udara terbakar yang diperingatkan oleh (Imax <0,5A atau Iavg antara 9A hingga 11A) yang mendeteksi tidak ada arus atau pompa limbah berjalan saat pompa udara mati. Ini harus diatasi dalam waktu 48 jam untuk menghindari kegagalan sistem. Data adalah 1 poin per menit, peringatan setelah 90 menit.

Peringatan kedua yang diinginkan pada grafik yang sama adalah (Imax > 14A atau Iavg antara 2A hingga 9A) yang menunjukkan pompa limbah tersumbat atau saluran udara saat harus dipompa. Ini adalah peringatan yang jauh lebih mendesak yang mungkin perlu ditangani dalam waktu 3 jam sehingga peringatan setelah 5 menit akan ideal.

Kedua peringatan berasal dari sensor arus jarak jauh yang sama yang mengirim data melalui LoRa. Beberapa lansiran akan menyederhanakan agar saya tidak harus menduplikasi kueri dasbor untuk sensor yang sama.

@torkelo beberapa grafik sama sekali tidak dapat diskalakan untuk banyak pengguna. Ini sepertinya hal yang sederhana untuk ditambahkan dan saya ingin tahu mengapa kalian tidak mempertimbangkannya?

mungkin jika ada permintaan besar untuk itu :)

Hai @torkelo , apa yang Anda anggap sebagai permintaan besar? 96 komentar dan 250 "suka" di komentar Anda sangat besar? Ini adalah permintaan fitur terbuka ke-8 yang paling banyak dikomentari dan hanya satu permintaan fitur tertutup yang memiliki lebih banyak komentar dari itu. Ini juga merupakan permintaan fitur terbuka ke-3 dengan lebih banyak :+1: reaksi. Apa yang dibutuhkan untuk memasuki peta jalan?

@torkelo Saya mendapat skenario kasus yang sangat sederhana.

Saya memerlukan lansiran yang berbeda jika nilainya di bawah ambang batas, dari lansiran ketika nilainya melampaui ambang (berbeda).

Berikut adalah skenario yang berbeda. Ketika saya memantau jumlah server yang sehat, saya memerlukan peringatan yang berbeda ketika saya kehilangan 1 server (restart yang sah tidak menjadi masalah kecuali dibutuhkan lebih dari 10 menit), dibandingkan kehilangan 5 server.

Berikut adalah skenario lain. Saya ingin menetapkan peringatan yang berbeda jika tingkat peningkatan antrian melebihi ambang batas, dan peringatan yang berbeda jika ukuran antrian itu sendiri melampaui ambang batas.

Dalam hal visualisasi, saya yakin komunitas akan senang dengan solusi apa pun untuk memulai. misalnya hanya memvisualisasikan peringatan pertama (jadi tidak diperlukan perubahan UI). Visualisasikan semua peringatan dengan garis vertikal yang ketika diarahkan memberi tahu Anda peringatan mana yang dipicu. Hanya tampilkan ambang/lansiran saat Anda mengarahkan kursor ke rangkaian tertentu, dll.

Hanya 2 sen saya.

Halo!

Ingin berpadu di sini kami (Spotify) membutuhkan ini juga.

Saat ini kami menjalankan peringatan sumber mesin peringatan kami sendiri dari Grafana, dan peringatan per-deret waktu. Saat ini kami mendorong anotasi peringatan per deret waktu kembali ke grafana.

Jadi, dalam hal UI, deret waktu pertama yang memperingatkan menyebabkan panel/lansiran masuk ke status "Peringatan", dan setiap peringatan berikutnya hanya menumpuk (riwayat status akan menampilkan beberapa pembaruan "untuk" peringatan, dan juga, beberapa perubahan kembali ke "oke")

Kami "membutuhkan" ini karena ini adalah cara kami selalu melakukan peringatan, jadi menjauh dari peringatan per-deret waktu akan menjadi perubahan sosial yang besar, untuk ~10 ribu peringatan. Kami sangat ingin menggunakan dan mengadopsi peringatan asli Grafana dan memperbarui sumber data kami untuk mendukungnya.

Ingin berpadu di sini kami (Spotify) membutuhkan ini juga.

Apakah Anda menggunakan juga perusahaan Grafana? Mungkin bisa membantu/memotivasi developer =)

Kami juga ingin melihat fitur ini, kemampuan untuk memicu beberapa peringatan dari grafik yang sama. Memberikan kemampuan untuk memicu pada status "di bawah" dan juga "di atas", dan memiliki kemungkinan untuk memiliki apa yang secara efektif akan menjadi peringatan kuning sebelum pelanggaran ambang batas yang lebih penting

Saat ini kami menjalankan peringatan sumber mesin peringatan kami sendiri dari Grafana, dan peringatan per-deret waktu. Saat ini kami mendorong anotasi peringatan per deret waktu kembali ke grafana.

@sjoeboo agak di luar topik di sini, tetapi apakah ada yang tersedia untuk umum?

@vbichov belum , kami ingin membuka sumber mesin peringatan, meskipun jangka waktu sedang berubah. saya yakin saya dapat membagikan tambalan yang kami miliki di garpu internal kami (hampir tidak ideal) untuk mengaktifkan pelacakan peringatan per-deret waktu melalui anotasi.

catatan, mesin peringatan, saat ini, khusus untuk TSDB kami (https://github.com/spotify/heroic)

+1 untuk fitur ini. ini adalah sesuatu seperti peringatan/kritis. Kami ingin mendapat peringatan sebelum hidup semakin buruk. Maka kita harus mendapatkan peringatan kritis untuk mengambil tindakan segera.

Saya kagum bahwa ini belum diterapkan setelah 3 tahun permintaan oleh pengguna.

Harus membuat beberapa panel (satu untuk setiap peringatan) akhirnya menyumbat dasbor dan membuat penambahan peringatan baru jauh lebih rumit dari yang seharusnya

Saya selalu bertanya-tanya mengapa ada 1 yang ditampilkan di tab peringatan jika Anda tidak dapat menentukan lebih dari satu peringatan per panel. Di tab kueri, nomor ini juga menunjukkan jumlah kueri yang ditentukan. Jadi saya selalu berpikir bahwa ini akan mungkin dan saya cukup terkejut bahwa ini belum tersedia.

Menarik bahwa ini masih belum dilaksanakan. Saya setuju "hitungan" pada tab peringatan menyesatkan karena membuat orang percaya bahwa mungkin ada banyak. Juga, memiliki panel per aturan peringatan agak konyol, karena itu berarti saya memiliki dasbor "tidak berguna" yang tidak lain adalah panel untuk peringatan. Ini pasti dasbor yang berantakan, tetapi ini adalah satu-satunya cara untuk mengimplementasikannya. Terutama, agar saya dapat memiliki aturan yang berbeda untuk nama dan/atau kombinasi titik akhir notifikasi. Ini rumit untuk sedikitnya.

Apakah ini sudah dilakukan?
Versi Grafana = 4.x

Sekarang versi Grafana masuk ke 7.x dan saya tidak melihat fitur ini

Apakah ini sudah dilakukan?
Versi Grafana = 4.x

Sekarang versi Grafana masuk ke 7.x dan saya tidak melihat fitur ini

Sangat naif😁

+1 untuk fitur ini.
Pada satu metrik saya ingin

1. Peringatan peringatan untuk menunjukkan bahwa suatu komponen tidak berperilaku seperti yang diharapkan dan perlu pemantauan ketat oleh dukungan lini ke-2
2. Peringatan kesalahan untuk menunjukkan komponen gagal dan memicu pemanggilan ke teknik baris ke-3.
   Menduplikasi metrik itu kikuk dan membuat dasbor kami membingungkan untuk pemantauan.

Begitu banyak fitur sederhana yang terus-menerus ditolak oleh grup ini, periksa banyak permintaan fitur lainnya..ini sepertinya sesuatu yang mendasar.

Saya akan memberikan contoh lain.

Saya menjalankan sinologi dan ingin mengingatkannya. Raid Status memiliki nilai normal 1. Namun juga memiliki nilai Degraded 11, dan nilai Crashed 12. Degraded berarti data masih dapat diakses. Hancur berarti kemungkinan besar kehilangan data.

Saya ingin mengirimkan peringatan jika Raid Didegradasi, dan alarm kritis jika Raid Hancur.
Saya memiliki beberapa volume dan kumpulan penyimpanan dan membutuhkan beberapa grafik untuk masing-masing tidak dapat diskalakan.

Ini juga dapat diterapkan pada sesuatu yang sederhana seperti penggunaan ruang disk.
Saya ingin mengirimkan peringatan jika penggunaan disk mencapai 80%, dan alarm kritis jika penggunaan disk mencapai 90%. Melakukan banyak grafik untuk SETIAP disk saya bukanlah permintaan yang masuk akal.

Dan saya tidak mengerti komentar bahwa ini sulit di UI. Anda sudah memiliki sesuatu yang serupa yang merupakan daftar Dasbor. Ketika Anda mengklik tab Alert, itu akan menampilkan daftar Alert Rules dengan nama dengan tombol "Buat Alert baru" di bagian bawah. Setiap aturan peringatan harus memiliki opsi "edit", "nonaktifkan", atau "hapus" di sebelah kanannya. Dengan mengklik lansiran, atau pada tombol edit, itu akan membawa Anda ke halaman edit yang ada yang ditampilkan tetapi untuk aturan lansiran tertentu.

Melakukan banyak grafik untuk SETIAP disk saya bukanlah permintaan yang masuk akal.

Anda dapat menggunakan api untuk mengotomatiskan pembuatan/pembaruan dasbor dan peringatannya. Jika mau, Anda dapat membuat program yang menanyakan prometheus (atau sumber apa pun yang Anda miliki) dengan menjalankan kueri secara berkala agar layanan menemukan target dan secara otomatis membuat peringatan atau target tersebut.

Luar biasa bahwa fitur ini belum diterapkan, dengan umpan balik besar yang dimiliki masalah ini.

Saya menggunakan Grafana sebagai mesin visualisasi & peringatan kami di Teleskop Magellan. Jika saya memiliki beberapa subsistem yang berbagi karakteristik yang pantas untuk semuanya dalam 1 plot, ketika masalah muncul dan salah satu mulai berperilaku buruk, pengguna saya harus mendapatkan peringatan samar dan penggalian yang gagal.

Membuat plot dummy adalah solusi, bukan solusi. Ini tampaknya mendasar!

+1 fitur yang diperlukan

+1

Situasi yang sama persis dengan OP. Fitur dasar yang seharusnya sudah diterapkan.

Bisakah orang berhenti mengirim spam ke masalah utas ini tanpa menambahkan sesuatu yang berharga?.

Gunakan reaksi di atas masalah untuk menunjukkan minat.

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc jauh lebih berguna bagi pengelola untuk menegaskan masalah mana yang "populer" daripada orang yang melakukan spamming semua orang mengirim email ke kotak masuk dan pemberitahuan github dengan informasi yang sudah jelas hanya dengan melihat deskripsi masalah.

Jika ini sangat mendasar, mungkin seseorang dari semua pengeluh yang hanya mengharapkan orang lain melakukan pekerjaan secara gratis untuk mereka harus menerapkan ini sendiri dan membuat permintaan tarik atau mempertahankan garpu mereka sendiri jika pengelola tidak menginginkannya di hulu.

@thomasf "Bisakah orang berhenti mengirim spam ke masalah utas ini tanpa menambahkan sesuatu yang berharga?" - Sama seperti yang Anda lakukan?

Jika pengelola masih berada di utas, komentar baru setidaknya mengingatkan mereka akan hal itu. Pada titik ini tampaknya tidak berguna, tidak mungkin pengelola akan mengimplementasikannya setelah sekian lama dan orang-orang harus benar-benar pindah ke alat yang lebih baik seperti Datadog di mana pengelola benar-benar peduli, tetapi ratusan komentar (terutama ketika mereka memiliki skenario aktual ) memiliki lebih banyak dampak daripada sekadar acungan jempol.

Jika pengelola masih berada di utas, komentar baru setidaknya mengingatkan mereka akan hal itu. Pada titik ini tampaknya tidak berguna, tidak mungkin pengelola akan mengimplementasikannya setelah sekian lama dan orang-orang harus benar-benar pindah ke alat yang lebih baik seperti Datadog di mana pengelola benar-benar peduli, tetapi ratusan komentar (terutama ketika mereka memiliki skenario aktual ) memiliki lebih banyak dampak daripada sekadar acungan jempol.

Atau mungkin pengelola telah berhenti berlangganan pemberitahuan tentang masalah ini karena spam, yang bukan satu-satunya dengan banyak +1/pesan tanpa pembaruan. Tolong jangan bandingkan Grafana dan DataDog (kami adalah pengguna dari keduanya, tidak ada cara untuk kembali ke DataDog)

Cara terbaik untuk mendapatkan yang ini adalah dengan berkontribusi (atau mungkin membayar untuk Grafana Entreprise)

Anda sangat sangat salah. Gratis atau tidak, Anda tidak dapat menempatkan
forum/slack/github/umpan balik saluran dan kemudian mengabaikannya. Jika Anda berpikir bahwa
menempatkan perangkat lunak pada lisensi opensource berarti "tidak ada keluhan" dan "orang
akan mengembangkan fitur Anda secara gratis" sekali lagi Anda sangat salah
kasus saya, saya menjelaskan kepada mereka bahwa dengan fitur ini saya dapat menjual grafana ke sepuluh
pelanggan saya. Mengabaikan saya, itu berarti kesal pada pelanggan. Besar
pindah mungkin mereka melakukan "cukup" uang dan mereka tidak ingin lebih, saya senang
untuk mereka....

Il giorno mer 14 ott 2020 alle ore 15:35 Thomas Frössman <
[email protected]> skrip:

Bisakah orang berhenti mengirim spam ke masalah utas ini tanpa menambahkan apa pun?
nilai?.

Gunakan reaksi di atas masalah untuk menunjukkan minat.

Jika begitu mendasar mungkin seseorang dari semua pengeluh yang hanya mengharapkan
orang lain untuk melakukan pekerjaan secara gratis bagi mereka harus menerapkan ini sendiri
dan membuat permintaan tarik atau mempertahankan garpu mereka sendiri jika
pengelola tidak menginginkannya di hulu.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

Jumlah uang yang bersedia saya keluarkan untuk perangkat lunak _any_ berbanding lurus dengan tingkat layanan pelanggan yang dapat saya antisipasi. Saya akan diberikan untuk investasi saya. Apakah itu produk open source yang menawarkan "dukungan berbayar" atau produk komersial, itu tidak masalah.

Memiliki masalah ini tetap terbuka begitu lama tanpa banyak mengintip dari pengelola proyek sayangnya mengekstrapolasi ke perasaan keraguan yang masuk akal tentang apakah sesuatu akan berbeda dengan menghabiskan uang. Jika Anda mencoba menjual perangkat lunak, mungkin bijaksana untuk mempertimbangkan hal ini.

buat permintaan tarik atau pertahankan garpu mereka sendiri

Bahkan jika ada petunjuk dari pengembang tentang di mana untuk memulai, saya yakin saya tidak sendirian dalam mengatakan saya akan mempertimbangkan ini, terlepas dari apakah saya pikir saya harus atau tidak, hanya karena jumlah nilai yang akan menyediakan. Sayangnya, sepertinya tidak demikian dan saya kurang tertarik untuk mencoba merekayasa balik produk untuk fitur yang tampaknya tidak terlalu dipedulikan oleh pengelola.

Terakhir, kecuali utasnya ditutup/dikunci, saya tidak melihat alasan bagi seseorang untuk tidak mengutarakan pendapatnya. Anda diperbolehkan untuk berhenti berlangganan jika itu tidak cocok untuk Anda. Saya benar-benar menikmati membaca orang-orang yang meratapi absurditas relatif ini. 😁

Peringatan NG (NextGen) yang direncanakan untuk 8 akan mendukung beberapa contoh peringatan dari satu definisi peringatan. Jadi, sesuatu seperti host=* dengan sistem seperti prometheus akan membuat peringatan per host.

Beberapa informasi umum tentang ini dalam konteks statistik tunggal ditambahkan ke https://github.com/grafana/grafana/issues/6983#issuecomment -712915673

Kami masih merancang dan membuat prototipe, tetapi untuk menanggapi beberapa pemikiran awal tentang hal-hal:

Beberapa peringatan per grafik

Definisi lansiran akan menjadi entitas mereka sendiri, sehingga mereka tidak akan terikat ke panel. Dari definisi peringatan dapat menjadi beberapa contoh peringatan. Kemudian panel dapat berlangganan instance atau definisi. Saya membayangkan kita masih menginginkan jalur UX yang bagus dari panel Dasbor untuk membuat peringatan, karena itu adalah aliran yang bagus.

Selain itu, melacak status lansiran yang terpisah tidak selalu disukai (karena pengguna akhir perlu mengetahui detail di balik masing-masing status ) vs hanya mengetahui apakah lansiran dipicu.

Setelah banyak peringatan dari satu definisi diizinkan, maka bagaimana mereka harus dikelompokkan menjadi masalah (karena seseorang bisa mendapatkan banyak peringatan). Saat ini saya melihat dua jalur untuk bagaimana ini akan bekerja dengan Alerting NG:

1. Gunakan alerting NG dengan IRM seperti pagerduty atau alertmanager yang dapat menangani pengelompokan instance alert.
2. Ubah kueri Anda menjadi grup menurut dimensi cakupan yang lebih besar. Jadi misalnya, jika kueri cluster=* alih-alih host=*,cluster=* (atau kelompokkan untuk sql seperti sumber data). Atau, saya bermaksud menambahkan fungsionalitas ke ekspresi sisi server (datang dengan peringatan ng) untuk memungkinkan operasi grup/berdasarkan pivot jika sumber data tidak melakukan ini. Ini akan menjadi kasus ketika tidak menggunakan IRM dan mengirim langsung ke layanan seperti email/slack.

peringatan/kritis

Yang ini lebih rumit. Untuk desain WIP, saya telah menghapusnya sebagai fitur (setidaknya untuk definisi peringatan, mungkin akan memiliki cara untuk menduplikasi definisi peringatan, mengubahnya, dan beberapa cara memberi label/tag dengan tingkat keparahan)

Ini sulit, karena dalam banyak kasus, ini sangat berguna:

• Bagi saya, peringatan/kritis memiliki kegunaan yang jelas: mendekati rusak/patah, atau terdegradasi/rusak.
• Tanpa mereka, banyak penyiapan yang pada akhirnya akan mengulangi cukup banyak peringatan untuk tingkat keparahan yang berbeda.

Jadi mengapa memutuskan untuk tidak memilikinya? Ini menambahkan sedikit kerumitan yang tidak jelas:

• Dengan asumsi Anda ingin mendukung ambang Anda yang berasal dari metrik lain (atau ambang Anda menjadi rentang waktu kueri yang berbeda, bukan nilai), sekarang ada dua kondisi yang harus dijalankan.
• Untuk status instance peringatan, minimal saya ingin mendukung:
  
  
  
  • Tidak diketahui: Sebuah instance menghilang
  
  
  • Kesalahan: Kueri yang akan mengetahui ada masalah tentang instance rusak
  
  
  • Peringatan: Kondisinya benar
  
  
  • Normal. Kondisinya tidak benar
  
  
• Kami juga ingin terus memiliki FOR ekspresi serupa. Saat menambahkan lebih banyak status, mendesain tidak harus mengepakkan baik hasil pemberitahuan yang terlewat atau kebisingan menjadi rumit. Secara umum, mesin negara dari waktu ke waktu sangat rentan terhadap bug dan sulit untuk diperbaiki (cari tindakan TLA / Logika Temporal untuk mempelajari lebih lanjut jika Anda menyukai hal semacam itu). Jadi menambahkan tingkat keparahan meningkatkan ruang keadaan lebih dari yang bisa ditebak. Yang berarti kita lebih cenderung memiliki perilaku yang tidak diinginkan, atau perilaku yang lebih sulit untuk dijadikan model mental.
• Saat ingin berintegrasi dengan sistem atau IRM lain, memiliki gagasan spesifik tentang tingkat keparahan dapat memperumit integrasi.

(setidaknya untuk definisi peringatan, mungkin akan memiliki cara untuk menduplikasi definisi peringatan, mengubahnya, dan beberapa cara memberi label/tag dengan tingkat keparahan

Ini adalah solusi yang dapat diterima untuk diferensiasi kritis/peringatan. Saya lebih dari senang untuk mempertahankan ambang batas yang terpisah. Memiliki ambang batas peringatan/kritis gabungan akan menyenangkan untuk dimiliki, tetapi bukan pemecah masalah.

lalu bagaimana mereka harus dikelompokkan menjadi masalah (karena seseorang bisa mendapatkan banyak peringatan)

Terserah pengguna untuk mengelola volume tiket dan pembuatan alarm mereka sendiri. Jika Anda menyetel alarm, masing-masing alarm harus berupa email atau notifikasi terpisah. Pikirkan seperti ini, jika Anda membuat sistem otomatis untuk menghasilkan tiket berdasarkan pemicu alarm, mengelompokkan beberapa alarm ke dalam satu email, misalnya, akan membuat ini sulit atau hanya menjengkelkan. Lebih lanjut, beberapa alarm muncul menjadi satu email berarti setiap alarm tidak dapat memiliki utas emailnya sendiri, itu perlu dipisahkan secara manual oleh pengguna dan utas baru dimulai. Alih-alih, setiap pemicu alarm harus memiliki notifikasinya sendiri sehingga utas dapat dimuat ke alarm tertentu.

Semoga ini menyederhanakan desain yang mengkhawatirkan karena Anda tidak perlu khawatir tentang pengelompokan. Itu terserah pengguna untuk menangani.