Grafana: Dukungan peringatan untuk kueri menggunakan variabel template

+1

1. Apa bedanya dibandingkan dengan hanya menggunakan semua?

+1
Akan menyenangkan untuk dapat menambahkan peringatan di server dengan waktu hidup yang rendah (penskalaan otomatis AWS), mendaftar otomatis server di grafana mudah dengan templating tetapi sedih tidak dapat menempatkan peringatan pada mereka

@bergquist tidak praktis menggunakan semua misalnya ketika Anda memiliki lebih dari selusin host.

Jika misalnya hanya sedikit dari mereka yang gagal, (katakanlah 5), akan sangat berguna untuk menerima email untuk setiap peringatan yang gagal. Cara ini juga lebih mudah untuk diintegrasikan dengan alat lain yang pada umumnya mengharapkan satu peringatan per metrik.

Pendekatan saat ini (menggunakan semua) cukup rapi meskipun ketika ada lebih sedikit contoh atau ketika Anda memperingatkan di tingkat layanan (mis. # pekerjaan dalam antrian).

apa yang dikatakan @calind , saya punya beberapa variabel $host yang berfungsi baik dengan influxDB tetapi tidak dengan peringatan

+1 juga.

Hanya sebuah pemikiran, karena Anda dapat membuat kueri dengan variabel template, bukankah Anda hanya dapat melakukan kueri yang sama dengan metrik peringatan dan mungkin mengulangi hasil untuk melihat mana yang memenuhi kriteria peringatan?

@NotSoCleverLogin Itu mungkin. Tetapi apakah Anda ingin mengubah perilaku aturan peringatan berdasarkan nilai template apa yang dipilih?

Menggunakan opsi semua untuk template adalah satu-satunya cara yang masuk akal bagi saya.

+1

Saya memiliki pengaturan lingkungan X dengan komponen yang sama di setiap lingkungan. Kami saat ini menggunakan prometheus untuk mengingatkan misalnya penggunaan cpu/penggunaan disk dll. Di sana kami menentukan peringatan untuk kueri, dan ketika peringatan dipicu, itu hanya akan menyatakan dari lingkungan mana peringatan itu dipicu.

Jika kita melakukan ini dengan variabel Semua, itu akan berhasil sampai batas tertentu. Tetapi, dengan menggunakan contoh @calind , tangkapan layar akan diisi dengan tren semua CPU dari semua lingkungan saya, dan bukan hanya lingkungan tempat saya ingin diberi tahu tentang masalah tersebut. Grafik akan (atau dapat) dikaburkan dengan informasi dari lingkungan lain. Dalam beberapa skenario, mungkin menarik untuk membandingkan cpu di lingkungan lain, tetapi tidak ada jaminan bahwa apa yang terjadi di lingkungan pengujian terjadi di lingkungan produksi kami, dll.

Kami juga sedang mencari cara untuk membuat dasbor yang dapat digunakan oleh operasi, menampilkan anotasi untuk peringatan di dasbor ikhtisar "standar". Mengingat bahwa kami menggunakan variabel template 'env' untuk jenis dasbor ini, sebenarnya tidak mungkin bagi kami untuk melakukannya dengan cara penerapannya sekarang. Saya harus secara manual (setidaknya sampai batas tertentu) menghasilkan dasbor "bayangan" tempat peringatan dipicu (yang membuat saya kehilangan anotasi di dasbor ikhtisar).

Hal lain yang menurut saya variabel templat dapat membantu Anda lakukan adalah merutekan peringatan (jika Anda memilih untuk mengimplementasikan fitur seperti itu) ke sumber yang berbeda (beberapa ke operasi jika dalam produksi, ke qa/pengembang jika dalam lingkungan pengujian, dll).

+1 untuk mendukung lansiran pada kueri bertemplat.

@bergquist , beberapa dasbor tidak memiliki opsi _Semua_. Misalnya metrik sistem dengan mengumpulkan (https://grafana.net/dashboards/24). Memiliki opsi _All_ tentu saja tidak praktis untuk katakanlah 10 atau lebih server. Itu sebabnya perlu untuk beralih melalui variabel template.

Mengizinkan penggunaan Semua adalah awal yang baik dan disambut baik.

Di Prometheus, kueri perlu ditulis dengan cara yang berbeda untuk mengizinkan Semua:

some.metric{hostname=~"$Hostname"}

Perhatikan tilde ekstra di sana, memungkinkan pencarian ekspresi reguler (dan wildcard di Semua).

Saya belum membandingkan kemungkinan dampak kinerja dari kueri langsung ke kueri pencarian regex, tetapi setidaknya untuk saat ini tampaknya akan menyelesaikan masalah kami.

+1

+1

tidak yakin bagaimana itu harus diterapkan, hanya tahu itu diperlukan ..

+1
Kami menggunakan Prometheus sebagai Sumber Data untuk memantau Infrastruktur Kubernetes kami untuk menghadapi Cluster K8S On-Prem dan Cluster AWS K8S kami.
Semua dasbor kami menggunakan Variabel Template untuk Sumber Data ($Environment), $Instance/Node, $Namespace, dan $Pod.
Karena cara Struktur Kueri Prometheus; semua kueri memiliki Variabel Template; yang mencegah Aturan Peringatan mengizinkan untuk menyimpan.
Saya ingin melihat Kueri Variabel Template ditambahkan ke peringatan.

+1

+1
Kami menggunakan dasbor templating untuk lingkungan multi-server yang merupakan cara logis (dan banyak orang menggunakan), Jadi kami tidak dapat menggunakan peringatan dengan grafana sekarang. Satu-satunya cara adalah memiliki dasbor non-templat terpisah atau peringatan pengaturan dengan prometheus itu sendiri yang tidak mudah.

mungkin jika ada opsi atau cara sederhana untuk menyimpan/mengekspor dasbor dengan variabel templat yang didukung/dirender sebelumnya ke semua bidang... ini mungkin akan menjadi titik tengah yang baik sampai solusi lain ditemukan.

+1 untuk mendukung lansiran pada kueri bertemplat. Saat ini kami menggunakan templating di semua dasbor kami sehingga tidak dapat memanfaatkan fitur yang sangat keren ini.

+1, kami memiliki banyak dasbor bertemplat, dan kami tidak dapat menggunakan peringatan untuk saat ini, kami harus menghapus duplikat dasbor untuk memiliki lansiran, dan kami kehilangan kekuatan templating

+1, Hampir semua dasbor kami menggunakan variabel template (dan variabel template bersarang).

Kami ingin dapat mengatur lansiran pada panel berulang untuk mendapatkan lansiran individual per grup variabel template jika diperlukan. Plus ini berarti bahwa peringatan itu dinamis dan tidak super manual seperti sekarang.

BAHAYA: Variabel dalam teori akan bagus untuk dimiliki, tetapi kita perlu ingat bahwa jika seseorang masuk ke dasbor Anda dan mengubah nilai dan menyimpannya, peringatan yang dihasilkan akan terpengaruh. Tidak tahu apakah itu perilaku ok atau tidak, akan rumit.

+1

Saat bekerja dengan grafana rasanya templating didorong di mana-mana dan rasanya salah untuk membuat kumpulan grafik tambahan yang tidak menggunakan variabel hanya untuk menggunakan fitur peringatan...

+1 untuk mendukung lansiran pada kueri bertemplat.
juga, kami menemukan bahwa ketika kami menggunakan nama aturan Cina atau judul bahasa Cina, kami menerima email yang tidak normal dengan aturan yang dipicu. Misalnya, kami mengharapkan “ alert(getTimeTrend) waspada” tetapi menerima "ä¸ªè‚¡åˆ†æ—¶çº¿æŽ¥å £è¯·æ±‚æ—¶é—´( getTimeTrend) alert", mungkin rangkaian karakternya salah.

+1 untuk mengimplementasikan templated vars di alert

+1

+1 akan mendapatkan tambahan yang bagus

+1

+1 untuk mengimplementasikan templated vars di alert

+1

+1 menantikannya

+1

+1

+1

+1

Tolong berhenti menulis +1 !
Setiap orang yang telah berlangganan edisi ini akan mendapatkan email...

Ada fitur github hanya untuk menghilangkan komentar +1 itu:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick Ada tautan di email tempat Anda dapat menonaktifkan utas dan tidak menerima email apa pun. Tetapi saya mengerti bahwa Anda mungkin hanya ingin mendapatkan pemberitahuan ketika fitur tersebut selesai, tetapi saya juga ingin masalah ini diperbaiki sehingga mudah-mudahan akan segera diselesaikan :)

Kemajuan besar dalam memperingatkan secara keseluruhan.
Untuk variabel templat dalam peringatan, saya juga melewatkannya. +1 :D

=
Selain itu, mungkin ada bug dalam cara Grafana mendeteksi apakah metrik yang digunakan di query menggunakan variabel template.

Saat Anda memiliki rangkaian yang menggunakan variabel template secara tidak langsung, Grafana tidak menghentikan Anda untuk menambahkan rangkaian tersebut sebagai peringatan. Peringatan itu jelas tidak berfungsi dengan benar.

Lihat #K (menggunakan #D, yang menggunakan #A dan #A menggunakan templ. var):

Saya masih bisa memilihnya:

Template di mana-mana, yang berarti tidak memberi tahu di mana pun.
Tidak yakin bagaimana peringatan telah diterapkan, tetapi untuk grafik sederhana, kueri "diterjemahkan", variabel templat diganti dengan nilai, sebelum melakukan panggilan ke sumber data, bukan? Jadi mengapa tidak dalam kasus ini? Bagaimanapun, seperti yang dikatakan sebelumnya, memiliki hampir semua kueri menggunakan variabel templat, peringatan sepenuhnya untuk saya. Tolong, bisakah Anda menerapkannya sehingga kami tidak perlu memindahkan alert ke luar Grafana? Terima kasih banyak!

Saya pikir kita harus menyadari bahwa peringatan dengan templating bukanlah hal yang sepele dan saya pikir opsi SEMUA adalah cara yang harus dilakukan karena kita tidak ingin peringatan kita berubah ketika seseorang menggunakan dasbor.
Tapi grafana masih harus membuat peringatan baru jika kueri template mengembalikan hasil baru... yang sering terjadi tanpa suara saat kami menskalakan aplikasi kami.
Ini menyebabkan lebih banyak masalah jika Anda menggunakan InfluxDB karena banyak dari kita yang menggunakan tag/nilai tag, dan tidak ada filter waktu untuk mereka... jadi grafana akan membuat peringatan untuk semua layanan yang pernah ada di host mana pun.. .

+1

Hanya mengizinkan untuk menentukan sumber data dalam peringatan akan baik-baik saja bagi saya. Itu tidak akan merusak logika apa pun, dan saya dapat menentukan setidaknya lingkungan produksi dan pementasan yang harus diperhatikan.

SEMUA adalah pilihan, tentu saja. Lebih fleksibel adalah pengenalan variabel template dalam kueri dan membiarkan pengguna mengatur nilai dalam konfigurasi kondisi peringatan. Saya kira yang terbaik, tetapi rumit, adalah memiliki beberapa peringatan (dengan cara yang sama ada beberapa kueri) sehingga peringatan yang berbeda dapat disiapkan untuk nilai variabel templat yang berbeda dalam kueri. Ini akan memungkinkan administrator untuk mengatur kondisi peringatan yang berbeda untuk host yang berbeda misalnya.

Beberapa profil peringatan akan bagus, tetapi untuk lulus awal, hanya menyediakan pemilih template yang sama seperti yang tersedia di dasbor di panel peringatan akan memecahkan banyak masalah.

Saya juga berpikir harus ada sakelar untuk setiap variabel untuk menggabungkan hasil untuk variabel itu menjadi satu notifikasi, ini mungkin hanya diaktifkan untuk vars templat yang mengaktifkan multi-pilih. Ini menyediakan metode sederhana namun efektif untuk mengontrol verbositas notifikasi - Anda mungkin ingin memberi tahu hanya sekali untuk beberapa metrik terkait, tetapi memberi tahu untuk setiap host jika ada metrik yang gagal. Atau, Anda mungkin ingin memberi tahu hanya sekali untuk metrik yang gagal, tidak peduli berapa banyak host yang terpengaruh.

apakah kami memiliki target pencapaian untuk bug ini?

Saya memiliki beberapa masalah dengan peringatan pada kueri yang rumit dan kueri variabel templat. Saya telah menemukan solusi mudah, yang mungkin tidak cantik, tetapi ini berfungsi untuk kasus penggunaan saya.
Itu hanya mengekstrak kueri setelah Anda membuatnya, jadi tidak ada variabel templat dan referensi #ROW apa pun. Ini bisa menjadi jelas bagi Anda, tidak ada ilmu roket, tetapi bagi saya itu adalah pengubah hidup.

Yang saya lakukan adalah menyiapkan kueri:

lalu ekstrak menggunakan alat pengembang Chrome (salin nilai parameter target):

Letakkan di baris lain (alihkan ke mode edit beralih terlebih dahulu):

Siapkan peringatan:

Voila!

@siteshbehera Ini bukan bug. Ini adalah permintaan fitur.

Tapi tidak. Kami tidak memiliki tonggak untuk ini saat ini.

plugin grafana kecerdasan buatan harus disertakan dalam komit untuk fitur ini.

Menunggu template di Alerts juga +1

Saya juga sangat mendukung apa yang disediakan calind sebagai kemungkinan implementasi di pos pembuka. Tampaknya cocok dengan berapa banyak (termasuk saya) yang menggunakan dasbor templat - di mana Anda memiliki satu dasbor, tetapi alihkan/batasi beberapa variabel untuk melihat hal-hal tertentu secara manual. Saya pikir contoh variabel "server" mungkin yang paling pas. Di sana, variabel template (tanpa _all_-value) akan menjadi sesuatu yang mirip dengan "_tab_" di dasbor saya - saya dapat beralih di antara variabel tersebut untuk melihat kumpulan data yang berbeda. Maka mudah untuk mengasumsikan bahwa, saat menyiapkan peringatan, peringatan akan ada untuk setiap kemungkinan "_tab_" secara terpisah.

Menunggu untuk mendukung template di Alerts +1

Sebagai pengguna Librato sebelumnya di mana peringatan sebagian mampu membuat templat ini, saya ingin berpadu dengan solusi parsial yang sama. Di Librato, setiap metrik dilengkapi dengan variabel 'sumber', dan peringatan pada grafik akan secara otomatis menjadi per sumber.

Saya pikir solusi yang setara akan memenuhi kebutuhan yang diangkat di sini. Saat membuat lansiran, Anda harus dapat memilih satu nilai template sebagai 'sumber' dan sumber ini disebutkan dalam lansiran, semua yang lain disetel ke 'semua'. Solusi ini setidaknya menghindari masalah kombinatorik yang Anda dapatkan jika mengizinkan penggunaan beberapa variabel templat.

Saya sendiri baru saja mengatur grafik maks atau min yang tidak terlihat pada data yang saya minati dan melakukan peringatan padanya, tidak sekuat tetapi masih merupakan solusi yang berfungsi sampai masalah ini teratasi.

Hai, saya pasti mencari fitur ini karena, dengan sebagian besar kasus sebelumnya, semua dasbor saya menggunakan kueri templat untuk mendukung banyak lingkungan (setidaknya).

Apakah ada tempat di mana peta jalan grafana sedang dilacak? Atau cara apa pun yang dapat kita lihat apakah fitur (seperti ini) akan diterapkan di masa mendatang (hampir atau tidak begitu dekat) tanpa menyodok pengelola di github? :)

Luar biasa sangat menantikan yang satu ini

+1

+1

Kami masih tidak yakin bagaimana melakukan ini.

Saya pikir menggunakan kembali variabel templat yang dipilih untuk peringatan akan berbahaya karena orang dapat memilih untuk melihat hanya satu opsi dan kemudian lupa untuk mengubah kembali ke All atau sesuatu yang lebih luas. Saya tidak akan merasa aman dengan perilaku seperti itu. Aturan peringatan harus sangat mudah dipahami dan dipikirkan. Aturan eksplisit > aturan ajaib.

Salah satu solusi untuk masalah ini adalah memiliki dua nilai untuk setiap variabel template. Satu untuk visualisasi di dasbor dan satu lagi untuk peringatan. Ini akan memungkinkan untuk selalu memiliki opsi yang lebih luas dalam mengingatkan dan tetap memilih hanya beberapa opsi dalam grafik. Menghubungkan nilai-nilai itu harus dimungkinkan tetapi bukan perilaku default.

Itu solusi bagaimana setiap fitur akan cukup besar dan kompleks.

Saya punya dua proposal untuk solusi.

1. Proposal jangka pendek adalah menambahkan opsi peringatan sehingga dalam garph yang diberikan (yang dikirim melalui email) hanya metrik yang memperingatkan yang ditampilkan. Ini akan mengatasi kekacauan saat grafik peringatan berisi lusinan metrik.

2. Solusi jangka panjang adalah dengan melakukan iterasi melalui variabel template, sehingga Anda memiliki peringatan yang berbeda untuk setiap kombinasi nilai template.

Seperti yang saya sebutkan kembali pada bulan November. Untuk pengguna prometheus hanya menggunakan 'Semua' sebagai nilai variabel sudah cukup jika kueri ditulis dengan benar ( some.metric{hostname=~"$Hostname"} ).

Seharusnya mungkin juga sangat mudah diimplementasikan.

@bergquist Saya pikir opsi 2 sedang menuju ke arah yang benar (implementasi sebagian dari apa yang saya sarankan di https://github.com/grafana/grafana/issues/6557#issuecomment-272588490), sepertinya tidak terlalu rumit, karena kode untuk menangani pemilihan var template sudah ada untuk dasbor, dan tidak perlu menduplikasi konfigurasi var, cukup pilih. Saya rasa saya tidak akan repot-repot menghubungkan pemilihan dasbor ke peringatan di lintasan pertama di fitur ini.

saya menyelesaikannya dengan membuat kueri metrik baru hanya untuk peringatan, tanpa variabel templat dan menonaktifkannya (untuk mengecualikannya dari grafik) di Grafana versi v4.1.1.

+1 untuk mengimplementasikan templated vars di alert

+1 untuk mengimplementasikan templated vars di alert

Apakah ini memengaruhi _semua_ versi Grafana? Atau apakah ini fitur yang tersedia sebelumnya? Ini adalah semacam pemecah kesepakatan bagi saya dan tidak keberatan menginstal versi sebelumnya.

Peringatan @alejandroandreu telah ditambahkan di versi 4, tidak pernah berfungsi dengan templating.

+1 untuk mengimplementasikan templated vars di alert

Saya ingin dapat memilih/memasukkan kombinasi yang harus dievaluasi oleh peringatan, karena beberapa lingkungan yang saya jalankan bukan lingkungan produksi, Ada dua cara untuk menerapkan ini, Yang pertama lebih eksplisit, yang kedua adalah lebih mudah untuk dikonfigurasi.

Masukkan semua kombinasi yang diinginkan secara manual

• Konfigurasi ini harus ditampilkan di panel konfigurasi Alert

Misalnya, Jika saya memiliki 3 variabel template : cloud , region dan type , saya akan mengisi tabel yang terlihat seperti ini:

| awan | wilayah | ketik |
|-------|------------|------|
| aws | kita-timur-1 | prod |
| aws | kami-barat-1 | prod |
| biru | AS Tengah | prod |

Tabel harus memiliki baris tambahan untuk menyisipkan baris baru dan tombol hapus untuk setiap baris.

Masukkan nilai yang mungkin dan Grafana akan menghitung Produk Cartesian

• Catatan: Konfigurasi ini dapat dimasukkan di panel konfigurasi variabel template

| awan | wilayah | ketik |
|-------|------------|------|
| aws | kita-timur-1 | prod |
| biru | kami-barat-1 | |
| | AS Tengah | |

Kombinasi yang akan dibuat untuk input ini adalah :

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

Tetapi Grafana dapat menangani situasi ini dengan "memasukkan" variabel pertama ( cloud ), dan kemudian memfilter nilai yang tersedia dari variabel kedua ( region ) hingga menemukan semua kemungkinan kombinasi (catatan - itu harus dilakukan secara iteratif untuk semua variabel). Ini dimungkinkan ketika orang menggunakan kueri dalam tag seperti ini:

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

Dan dalam hal ini, kombinasi yang dihasilkan akan baik-baik saja (yang sama dengan tabel pada opsi pertama):

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

Saya harap saran saya akan membantu.

Kami memiliki masalah ini (sumber data OpenTSDB) dalam konteks yang sedikit berbeda - jika Anda menggunakan template var untuk memilih interval downsample dalam metrik, kueri peringatan gagal dengan kesalahan 400. Saya memahami kesulitan dalam menerapkan solusi umum tetapi kami harus merekayasa ulang berbagai dasbor yang ada untuk mengaktifkan peringatan.

@dbcook terdengar seperti masalah berbeda yang mungkin harus Anda ajukan masalah terpisah.

Templating benar-benar fitur yang luar biasa, dan begitu juga peringatan. Sebaiknya kita membuat mereka bekerja sama dengan lancar daripada solusi yang canggung.

@tomekit Terima kasih atas solusinya, itu memang terlihat menjanjikan sementara kami menunggu implementasi yang sebenarnya. Namun saya tidak dapat menemukan tempat untuk mengekstrak kueri menggunakan alat pengembang Chrome dan karenanya saya tidak dapat menyalin nilai parameter target untuk kueri baru. Saya telah mencoba "Periksa Elemen" tetapi saya kesulitan menemukan "Nama" atau "Header" atau "Data Formulir" yang telah Anda tunjukkan pada tangkapan layar.

Bisakah Anda menggambarkan langkah-langkah untuk melakukan itu? Bantuan Anda akan sangat dihargai!

Terima kasih

@mathurj Ini adalah Jaringan -> tab XHR. Apakah itu membantu sekarang?

Kemudian klik pada permintaan "render".

Terima kasih @tomekit Saya dapat melihat halaman ini sekarang namun saya tidak dapat melihat permintaan apa pun yang bernama "render". Namun ada permintaan lain tentang kueri yang saya jalankan, tetapi tidak memiliki parameter "target".

Adakah petunjuk tentang cara melakukan permintaan "render"?

@mathurj Saya mendapatkan permintaan "render", setelah melihat salah satu grafik di dasbor saya dan mengklik segarkan (pojok kanan atas).

Mencobanya, masih tidak ada permintaan "render" untuk saya :( Dan tidak ada paremeter "target" juga. Terima kasih atas bantuan Anda @tomekit . Sepertinya saya harus menunggu implementasi yang sebenarnya, yang mungkin terlihat agak lama itu. @bergquist @torkelo ?

oke bekerja dengan
some.metric{hostname=\~"$Hostname"}
dalam kueri itu sendiri baik-baik saja,
tapi ini sumber data saya yang merupakan template di sini ...

lingkungan=\~"$lingkungan"
sepertinya tidak berhasil ... cara apa pun agar ini berhasil, apakah saya melewatkan sesuatu? atau haruskah saya menyingkirkan templatnya :kecewa:

+2

fitur ini sangat berguna saat menggunakan prometheus sebagai sumber data!

Saya membutuhkan ini juga, untuk alasan yang sama seperti yang disebutkan di atas. Saya berharap ini berfungsi sebagai untuk setiap loop di seluruh koleksi yang ditentukan oleh templat.

Kami membutuhkan ini!!! :) 👍

Secara pribadi saya mendukung fitur ini juga. Kami menguji lebih dari satu sistem dengan serangkaian uji beban yang menghasilkan metrik penundaan. Alih-alih memiliki satu dasbor, kami menggunakan variabel untuk beralih di antara sumber data yang menyimpan data untuk berbagai sistem agar hanya perlu memelihara satu papan dan bukan membuat skrip.
Oleh karena itu, dukungan untuk template dalam peringatan akan sangat dihargai.

+1
kami juga membutuhkan ini

+1
kami juga membutuhkan ini

+1
kami juga membutuhkan ini

Bolehkah saya bertanya mengapa ada begitu banyak orang yang "mengecilkan" balasan +1 itu??

@skygragon pada dasarnya adalah spam yang tidak berguna ketika opsi untuk memberi +1 pada pos asli ada. Cukup klik ikon jempol ke atas di postingan pertama.

Variabel template dan peringatan adalah 2 fitur terbaik dari Grafana.
Sedih melihat mereka saling eksklusif meskipun ......

+1

@bergquist, bisakah tim Anda membahas ini lagi dan semoga membuat pencapaian ini? Ini adalah fitur yang paling banyak diminta selama hampir 2 tahun sekarang dan saya yakin beberapa pengguna akan senang mendapatkan fitur ini.

Belum ada solusi bagus yang diusulkan dan kami masih yakin ini adalah ide yang buruk karena menggabungkan dua fitur yang memiliki tujuan berbeda. Variabel templating digunakan untuk dasbor & eksplorasi dinamis. Aturan alert sudah bisa dibuat dinamis dengan query regex/wilcard. Menggabungkan keduanya sepertinya ide yang buruk, setidaknya dengan cara yang bisa dimengerti & diprediksi.

Ada beberapa alasan bagus untuk mendukungnya dalam beberapa cara terbatas tetapi tidak yakin itu akan sepadan dengan kompleksitas ekstrem yang akan ditambahkan dan biaya pengembangan. Tapi kami terbuka untuk ide, saran & PR.

Masalahnya adalah saya memiliki beberapa server yang saya pantau DAN mereka dibuat secara dinamis melalui Amazon, jadi pada waktu tertentu saya tidak tahu berapa banyak server yang aktif.

Saya memiliki grafik templat yang menunjukkan CPU untuk setiap server (misalnya), jadi saya juga ingin memberi tahu di sana.

Tetapi Anda mengatakan saya dapat mencapai hal yang sama dengan menggunakan wildcard?

@yesman85 tentu saja, tergantung pada toko deret waktu Anda. tetapi sebagian besar mendukung beberapa bentuk sintaks kueri glob/regex untuk menargetkan beberapa metrik yang mengikuti pola penamaan.

@torkelo Saya percaya ini adalah pertama kalinya posisi ini dinyatakan secara publik. Saya pikir mungkin ada beberapa kesalahpahaman di sini - Saya tidak percaya pengguna ingin nilai templat yang dipilih untuk keluaran dasbor memengaruhi peringatan, tetapi sebaliknya memiliki pilihan templat yang sama tersedia saat mengonfigurasi peringatan.

Saran implementasi yang relevan dari utas ini:
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641 (opsi 2)

Juga, masalah terkait:
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

Keterbatasan ini telah menghentikan kami untuk dapat menggunakan Grafana untuk memperingatkan dalam kemarahan, karena satu-satunya cara untuk melakukannya saat ini adalah dengan menambahkan sekelompok kueri tersembunyi yang terpisah untuk peringatan, atau untuk membuat dasbor terpisah untuk peringatan vs tampilan . Kedua opsi tersebut merupakan mimpi buruk pemeliharaan, dan justru membatasi potensi besar yang dimiliki Grafana untuk memudahkan konfigurasi pemantauan dan interpretasi oleh pengguna.

Saya pikir saran saya di atas yang terinspirasi oleh peringatan berbasis sumber Libratos memberikan solusi yang terbatas, dapat dimengerti, dan dapat diprediksi yang tampaknya mencakup hampir semua masalah yang disebutkan di atas.

Dalam grafana itu akan diterjemahkan menjadi dapat menggunakan satu dan hanya satu variabel template untuk peringatan dan setiap nilai dalam variabel itu akan menghasilkan peringatannya sendiri. Anda juga dapat menambahkan regex di atasnya untuk memfilter masuk/keluar yang mana Anda ingin membuat lansiran.

@pdf Saya setuju bahwa https://github.com/grafana/grafana/issues/6041 adalah batasan besar, yang pasti ingin kami perbaiki tetapi tidak terkait dengan masalah ini. Sangat buruk bahwa kami belum memperbaikinya. Saya setuju, kami sedikit kekurangan staf di sisi peringatan beberapa bulan terakhir, tetapi itu akan segera berubah!

@danhallin yang tidak sama, sepertinya itu akan diterjemahkan ke kueri di Grafana yang menargetkan banyak seri menggunakan ekspresi wildcard atau glob dalam kueri Anda atau hanya memfilter pada set tag terbatas? Aturan peringatan Librato didefinisikan secara terpisah dari dasbor, bukan begitu, jadi bagaimana cara menerjemahkannya ke fitur pemfilteran data di seluruh dasbor?

cara untuk melakukannya semacam itu bekerja saat ini adalah dengan menambahkan sekelompok kueri tersembunyi yang terpisah untuk memperingatkan, yang merupakan mimpi buruk pemeliharaan

Pahami bahwa mencampurkan aturan peringatan dalam grafik template Anda seperti itu adalah mimpi buruk. Tapi berpikir mendukung variabel template dalam peringatan bisa menjadi mimpi buruk yang lebih besar. Mungkin pertanyaan bodoh, tetapi bisakah Anda tidak membuat dasbor & grafik yang berfokus pada peringatan? dan meninggalkan dasbor dengan banyak variabel template untuk eksplorasi dan pemecahan masalah? Saya tahu mungkin ada banyak kasus di mana mereka akan serupa sehingga terasa seperti pekerjaan yang digandakan :( Masalah dengan aturan peringatan dalam konteks dasbor dengan beberapa variabel templat adalah bagaimana seharusnya bekerja & dapat dimengerti, dan bagaimana itu bisa diimplementasikan sama sekali.

Katakanlah satu kueri menggunakan 2 variabel templat, $A, dan $B, masing-masing memiliki 50 nilai. Apakah ini akan menghasilkan evaluasi aturan peringatan 2500 kali? Maksud saya jika variabelnya adalah "nilai tunggal", yaitu kueri dibuat hanya berfungsi jika $A dan $B memiliki nilai tunggal maka kita harus melakukan itu. Bukan show stopper mungkin, kami harus menjelaskan hanya variabel multi nilai yang didukung. Mungkin ada lebih banyak batasan & detail bermasalah yang akan membuat fitur ini sangat sulit untuk diterapkan & digunakan & dipahami

Tetapi saya tidak 100% menentangnya, saya pikir mungkin ada cara untuk melakukannya dengan cara yang terbatas (seperti hanya mendukung satu .)
variabel bernilai banyak). Ada juga kasus penggunaan memiliki beberapa sumber data dan dapat menargetkan variabel sumber data dalam aturan peringatan Anda untuk menggunakan kembali aturan peringatan tersebut di banyak pusat data/lingkungan (yang memiliki TSDB terpisah) yang kasus penggunaan harus diselesaikan menggunakan variabel template sumber data sebagai kueri metrik dengan karakter pengganti tidak dapat menyelesaikannya.

tetapi bisakah Anda tidak membuat dasbor & grafik yang berfokus pada peringatan? dan meninggalkan dasbor dengan banyak variabel template untuk eksplorasi dan pemecahan masalah? Saya tahu mungkin ada banyak kasus di mana mereka akan serupa sehingga terasa seperti pekerjaan yang digandakan :(

Saya benar-benar mengedit komentar saya untuk merujuk opsi ini (dan menambahkan beberapa masalah titik nyeri terkait peringatan lainnya). Seperti yang telah Anda identifikasi, ini berarti mengalikan pembuatan dasbor/panel (dan pemeliharaan, jika semua kueri tersebut memerlukan pembaruan) dengan jumlah variasi template yang ingin Anda waspadai, dan juga memisahkan anotasi peringatan dari lokasinya. paling berguna di - dasbor berpola dengan anotasi peringatan bisa sangat berguna untuk membuat korelasi, tetapi tidak terlalu berguna jika Anda harus mencoba dan menjelajahi beberapa tab browser dan mencoba menyelaraskan semuanya.

Katakanlah satu kueri menggunakan 2 variabel templat, $A, dan $B, masing-masing memiliki 50 nilai. Apakah ini akan menghasilkan evaluasi aturan peringatan 2500 kali? Maksud saya jika variabelnya adalah "nilai tunggal", yaitu kueri dibuat hanya berfungsi jika $A dan $B memiliki nilai tunggal maka kita harus melakukan itu. Bukan show stopper mungkin, kami harus menjelaskan hanya variabel multi nilai yang didukung. Mungkin ada lebih banyak batasan & detail bermasalah yang akan membuat fitur ini sangat sulit untuk diterapkan & digunakan & dipahami

Ada dua masalah terpisah di sini saya pikir. Satu _is_ (saya percaya) terkait erat dengan #6041, di mana mungkin ada keinginan untuk mengevaluasi kondisi peringatan secara individual per seri/nilai template (toggle agregat yang saya sebutkan dalam komentar sebelumnya). Jika kita mengesampingkannya untuk saat ini, saya yakin cara ideal untuk menyelesaikan sebagian besar masalah ini adalah dengan mengizinkan beberapa konfigurasi peringatan per panel, dan lakukan interpolasi variabel dengan cara yang persis sama seperti untuk keluaran dasbor: izinkan pengguna untuk memilih satu- atau nilai template multinilai saat mengonfigurasi kueri peringatan; kueri akan dieksekusi sekali per konfigurasi peringatan, dengan nilai yang dipilih terisi; dan hasilnya akan ditafsirkan dengan cara yang sama persis seperti saat ini. Kecuali jika saya salah memahami sesuatu, saya tidak melihat ini sebagai peningkatan kompleksitas yang signifikan, dan seharusnya cukup ramah pengguna.

Kemampuan untuk memilih nilai template untuk membatasi cakupan peringatan akan tetap berguna tanpa beberapa konfigurasi peringatan (jika membantu mengembangkan fungsi ini dalam urutan itu), tetapi akan lebih bernilai secara eksponensial dengan beberapa konfigurasi.

Ada juga kasus penggunaan memiliki beberapa sumber data dan dapat menargetkan variabel sumber data dalam aturan peringatan Anda untuk menggunakan kembali aturan peringatan tersebut di banyak pusat data/lingkungan (yang memiliki TSDB terpisah) yang kasus penggunaan harus diselesaikan menggunakan variabel template sumber data sebagai kueri metrik dengan karakter pengganti tidak dapat menyelesaikannya.

Beberapa konfigurasi/kueri peringatan per panel akan menyediakan metode untuk menangani beberapa TSDB, dan satu opsi mungkin mengizinkan pengelompokan kueri peringatan, sehingga transisi status terjadi berdasarkan hasil semua kueri dalam grup (mirip dengan cara kerja saat ini untuk seri). Sepertinya tidak terlalu rumit.

Ini jelas merupakan kebutuhan yang populer.. Sekarang untuk mencapai Peringatan kami harus pindah
jauh dari Grafana dan buat solusi khusus kami menggunakan Graphite's Render
Data mentah API .. Saya tidak berpikir mendukung Lansiran dalam dinamis / templated
data setidaknya kompleks menggunakan Graphite..

Satu pemikiran lagi adalah,. Mengapa Grafana memiliki bagian Peringatan adalah bagian dari dasbor
config jika ini dianggap kompleks. Anda dapat memindahkannya untuk memisahkan
Tampilan peringatan di mana pengguna dapat memasukkan/mengonfigurasi kueri dinamis mereka,
interval, kondisi evaluasi di sana.. Mungkin ini bisa berarti kita
tidak memiliki dasbor duplikat.. Masuk akal?

BR,
Wiswa..

Pada 23-Agustus-2017 8:01, "Peter Fern" [email protected] menulis:

tetapi bisakah Anda tidak membuat dasbor & grafik yang berfokus pada peringatan?
dan tinggalkan dasbor dengan banyak variabel template untuk dijelajahi dan
penyelesaian masalah? Saya tahu mungkin ada banyak kasus di mana mereka akan
mirip jadi terasa seperti pekerjaan duplikat :(

Saya benar-benar mengedit komentar saya untuk merujuk opsi ini (dan menambahkan beberapa
dari masalah titik nyeri terkait peringatan lainnya). Seperti yang telah Anda identifikasi,
ini berarti melipatgandakan pembuatan dasbor/panel (dan pemeliharaan, jika semua
kueri tersebut memerlukan pembaruan) dengan jumlah variasi templat yang Anda inginkan
untuk mengingatkan, dan juga memisahkan anotasi peringatan dari lokasi
mereka mungkin paling berguna di - dasbor berpola dengan anotasi peringatan
bisa sangat berguna untuk membuat korelasi, tetapi tidak begitu banyak jika Anda harus
coba dan jelajahi di beberapa tab browser dan coba sejajarkan.

Katakanlah satu kueri menggunakan 2 variabel templat, $A, dan $B, masing-masing memiliki 50
nilai-nilai. Apakah ini akan menghasilkan evaluasi aturan peringatan 2500 kali? maksudku
jika variabelnya adalah "nilai tunggal", yaitu kueri dibuat hanya untuk berfungsi
jika $A dan $B memiliki nilai tunggal maka kita harus melakukan itu. Bukan pertunjukan
stopper mungkin, kita harus menjelaskan hanya variabel multi nilai yang
didukung. Mungkin ada lebih banyak batasan & detail bermasalah
yang akan membuat fitur ini sangat sulit untuk diterapkan & digunakan & dipahami

Ada dua masalah terpisah di sini saya pikir. Salah satunya adalah (saya percaya) erat
terkait dengan #6041 https://github.com/grafana/grafana/issues/6041 , di
bahwa mungkin ada keinginan untuk mengevaluasi kondisi waspada secara individual
nilai seri/templat (toggle agregat yang saya sebutkan sebelumnya
komentar). Jika kita mengesampingkannya untuk saat ini, saya percaya cara yang ideal untuk menyelesaikannya
sebagian besar masalah ini adalah mengizinkan beberapa konfigurasi peringatan per panel, dan
lakukan interpolasi variabel dengan cara yang persis sama seperti untuk dasbor
output - memungkinkan pengguna untuk memilih nilai template tunggal atau multinilai ketika
mengonfigurasi kueri peringatan; kueri akan dieksekusi sekali per peringatan
config, dengan nilai yang dipilih terisi; dan hasilnya akan menjadi
ditafsirkan dengan cara yang persis sama seperti saat ini. Kecuali aku terlalu
salah paham tentang sesuatu, saya tidak melihat ini sebagai peningkatan yang signifikan dalam
kompleksitas, dan harus cukup ramah pengguna.

Kemampuan untuk memilih nilai template untuk membatasi cakupan peringatan akan
masih berguna tanpa beberapa konfigurasi peringatan (jika itu membantu untuk mengembangkan
fungsi ini dalam urutan itu), tetapi akan menjadi lebih berharga secara eksponensial
dengan beberapa konfigurasi.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin yang tidak sama, sepertinya itu akan diterjemahkan ke kueri di Grafana yang menargetkan banyak seri menggunakan ekspresi wildcard atau glob dalam kueri Anda atau hanya memfilter pada set tag terbatas? Aturan peringatan Librato didefinisikan secara terpisah dari dasbor, bukan begitu, jadi bagaimana cara menerjemahkannya ke fitur pemfilteran data di seluruh dasbor?

Saya melihat sekarang bahwa apa yang saya diskusikan pada dasarnya adalah salinan dari: https://github.com/grafana/grafana/issues/6041

Saya mendukung permintaan fitur itu untuk yang ini.

Kami memutar server secara teratur dan kami memiliki dasbor templat yang mengukur hal-hal umum di semua host (mem, hd, cpu, dll). Membuat dasbor "peringatan" yang memiliki grafik untuk setiap kombinasi yang mungkin terlalu membosankan, banyak dari peringatan yang diinginkan dapat digeneralisasikan di semua host. AFAIKT masalah ini meminta cara untuk memungkinkan kasus penggunaan ini dan tidak akan diselesaikan di #6041. Kecuali aku kehilangan sesuatu.

Membuat grafik & peringatan untuk setiap kombinasi bukanlah yang kami usulkan, hanya saja permintaan peringatan Anda menggunakan wildcard atau regex sehingga mencakup semua host dll. Kemudian Anda memiliki satu peringatan dan grafik yang dapat disetel untuk peringatan dan tidak bersaing dengan persyaratan untuk pemecahan masalah & pemfilteran dinamis.

Untuk kasus penggunaan kami, kami memiliki sejumlah (berpotensi) instans sementara yang menyediakan pemrosesan peristiwa secara waktu nyata - kami perlu diperingatkan jika metrik yang dihasilkan aplikasi tertentu turun ke 0. Namun, jika instans dihapus atau dihentikan, mereka akan tetap memiliki metrik bernama terkait dengan mereka yang muncul dalam pencarian wildcard langsung yang mengarah ke peringatan palsu.

Atasi ini dengan menggunakan variabel multi-nilai templat (diatur ke Semua) yang dihasilkan dari "Sumber Data JSON Sederhana" yang berisi sumber kebenaran untuk instance apa yang harus dijalankan - semuanya bekerja dengan sempurna. Sayangnya, segera setelah saya mencoba mengaktifkan peringatan, saya diarahkan ke permintaan fitur ini :)

Tidak yakin seberapa unik kasus penggunaan khusus kami, tetapi saya tidak yakin ada cara lain untuk memperingatkan ini tanpa menggunakan templating - untuk saat ini, kami perlu terus memperingatkan masalah ini di luar Grafana (yang memalukan - kami pengguna Grafana yang sangat berat!)

+1

Jadi satu kasus di mana kami tidak memiliki masalah ini adalah di mana variabel template adalah tipe konstan. Misalnya, kami memiliki beberapa dasbor yang mengandalkan variabel konstan untuk membatasi data di dasbor itu ke sumber daya tertentu (alasan kami tidak menggunakan variabel multinilai adalah karena setiap dasbor cukup berbeda untuk membenarkan penyiapan yang berbeda tetapi cukup dekat untuk membenarkan dasbor "templat"). Setidaknya dalam kasus ini (variabel konstan) tidak ada yang perlu diubah tentang perilaku peringatan saat ini.

Ada berita tentang topik ini?

Hai,

Apakah ada harapan untuk mendapatkan fitur ini? saya hanya ingin tahu bagaimana sistem lain memiliki fitur ini karena mereka juga harus menggunakan semacam templating karena ketika kami menginstal agen, itu secara otomatis muncul di portal dan peringatan juga dapat diatur untuk itu. (Ini adalah pengalaman saya dengan New Relic).

@vishwanathh saya menyukai pendekatan memiliki bagian terpisah untuk memperingatkan (jika rumit untuk memilikinya di panel grafik) di mana kami dapat memasukkan pertanyaan kami hanya untuk memperingatkan. karena dengan cara ini pengguna kami tidak akan melihat panel placeholder (digunakan untuk mengingatkan).

Maaf untuk kebisingan ekstra, tetapi ini akan menjadi fitur yang sangat bagus untuk dimiliki di Grafana.

+1, fitur yang sangat sangat penting!

Selain itu, jika mengizinkan saya memodifikasi ekspresi kueri metrik prometheus untuk menghapus variabel template, ini sama sekali tidak layak. Jadi, menurut saya fitur ini paling penting bagi prometheus+grafana untuk berproduksi!

Bagaimanapun, tolong tim dapat mempertimbangkan prioritas, terima kasih!

Dengan 5.0 menuju keluar pintu segera, saya ingin melihat beberapa fokus signifikan yang diberikan peringatan selama seri rilis berikutnya. Melihat reaksi Github, kekurangan terkait peringatan tampaknya paling diminati oleh pengguna.

Saya tahu ada keengganan untuk menangani hal-hal ini karena masalah kompleksitas UI/UX, namun saya tidak yakin kekhawatiran ini perlu dibenarkan. Adakah yang dapat kami lakukan sebagai pengguna yang dapat membantu perencanaan/desain atau untuk memajukan masalah ini, selain permintaan tarik dengan kode aktual?

@torkelo Ini telah membantu saya untuk mengatur peringatan untuk semua host saya menggunakan tag dan sekarang setiap grafik peringatan saya berisi beberapa seri yang dibentuk oleh kombinasi tag. Semuanya tampak bekerja dengan baik. Tetapi melalui dokumen dan masalah lain saya menyadari bahwa jika salah satu seri dalam grafik telah mengambil status waspada maka peringatan untuk seri lain tidak akan dipicu jika mereka juga melewati batas.

Itu lagi-lagi menjadi batasan.

Terima kasih.

Ada berita tentang fitur ini?

Apa upaya kontributor baru untuk menambahkan fitur ini?

+1

Harap izinkan variabel template digunakan untuk Notifikasi Lansiran.
+1

+1

Kami berharap dapat diselesaikan.

+1

Saya tidak ingin mengalahkan kuda mati di sini, tetapi kami memiliki masalah yang sama, dan saya ingin memberikan beberapa konteks mengapa proposal yang ada tidak berhasil dalam semua keadaan. Saya juga memiliki beberapa ide untuk solusi, tetapi mengapa kami membutuhkan _beberapa fitur_ untuk membantu membuat solusi tersebut cukup.

Untuk semua skenario di bawah, kami menggunakan variabel template tunggal: $env

"Mengapa tidak membuat dasbor peringatan saja?"

Kami ingin mengingatkan pada beberapa lingkungan yang berbeda, bukan hanya produksi. Jadi sekarang kita harus memiliki metrik yang sama di _setidaknya_ 3 tempat berbeda (dasbor pemecahan masalah dengan semua metrik, bukan hanya metrik yang kita waspadai; dasbor peringatan prod; dasbor peringatan integrasi). Ini bisa keluar dari tangan cukup cepat, dan rentan terhadap kesalahan pengguna.

Sama pentingnya, ini membatalkan banyak keuntungan dari anotasi otomatis dari peringatan. Jika saya harus bolak-balik dari dasbor eksplorasi ke dasbor peringatan saya untuk melihat anotasi kapan suatu acara dimulai dan kapan berakhir, itu akan sangat membosankan.

Solusi yang Dicoba

Apa yang telah kami lakukan untuk mencoba menyiasatinya adalah kami telah menambahkan metrik duplikat _khusus untuk peringatan_ ke dasbor kami. Jadi, jika ada metrik yang ingin kami waspadai, kami membuka panel dan menambahkan metrik eksplisit untuk lansiran tersebut (dan menyembunyikannya).

Daftar seri kami untuk panel tertentu yang perlu diwaspadai akan terlihat seperti:

Dengan seri non-templat ditandai sebagai tersembunyi. Kemudian di tab peringatan, kami menetapkan ambang batas untuk seri _ini_, bukan seri variabel.

Masalah dengan solusi ini

Ini tidak bekerja dengan baik. Sebagai contoh:

Seperti yang Anda lihat, panel Alerts tidak mengizinkan kita untuk menentukan _which environment_ yang sedang diwaspadai -- jadi kita harus menelusuri lansiran tersebut untuk mengetahui lingkungan mana yang diblokir saat ini. Namun, perbaikan mudah untuk ini mungkin hanya memungkinkan deskripsi menjadi sama verbosenya dengan panel Alert History yang menunjukkan transisi status:

Ini setidaknya agak membantu, tetapi bahkan di panel ini tidak ada indikasi peringatan mana yang telah kembali ke Healthy (deskripsi dari tangkapan layar di atas berasal dari alias yang kami atur pada seri jika ada yang bertanya-tanya bagaimana caranya untuk setidaknya mendapatkan sebanyak itu untuk muncul).

Hal-hal yang akan membantu sampai tiket khusus ini diselesaikan

• Izinkan opsi untuk menampilkan alias seri alih-alih deskripsi yang diketik untuk peringatan (dengan cara ini alias setidaknya dapat menentukan $variable yang diperingatkan)
• Izinkan transisi status kembali ke sehat untuk juga menampilkan alias seri (dalam tangkapan layar Riwayat di atas)
• Izinkan nilai legenda untuk peringatan aktif (menggunakan alias seri yang saya asumsikan) untuk panel tertentu

Hal-hal yang saya tidak yakin bagaimana cara memperbaikinya

Anotasi pada grafik yang memiliki peringatan yang dikonfigurasi untuk beberapa lingkungan/variabel:

Dengan ini, kami tidak dapat mengetahui lansiran mana yang diaktifkan tanpa masuk ke panel. Saran legenda dapat membantu memperjelas hal ini, tetapi tidak banyak membantu anotasi jika $env yang benar tidak dipilih (pada gambar di atas, int memperingatkan, tetapi prod adalah variabel yang dipilih di dasbor, jadi kami menampilkan anotasi dari peringatan int di atas grafik menggunakan prod .

+1

tambah satu :)

Harap berhenti memberi +1 pada masalah ini. Ini menghasilkan email spam yang tidak perlu. Kemampuan untuk menambahkan reaksi ke komentar masalah github telah ada untuk sementara waktu sekarang, dan lebih dari 429 orang telah menemukan cara menyukai komentar awal alih-alih mengirim spam ke semua orang yang berlangganan.

Harap kami benar-benar membutuhkan fitur ini, kami ingin menggunakan templating, tetapi dalam kasus kami yang paling penting adalah memiliki sistem peringatan yang jelas. Jadi untuk mengatasinya, kami menghindari templating di dasbor kami... ini berantakan.

Saya setuju dan fitur ini akan sangat membantu kami !!!!

+1 tolong

kita membutuhkan ini

+1 tolong. Ini benar-benar dibutuhkan.

@bergquist @torkelo bisakah kami mengunci masalah ini untuk menghentikan +1 spam?