Grafana: Memantau Grafana

++

: +1:

pastikan url kesehatan tidak menghasilkan sesi

: +1:

+1, ini akan sangat berguna untuk menjalankan grafana di belakang loadbalancer, loadbalancer akan memanggil / health HTTP untuk memverifikasi apakah grafana mengembalikan HTTP 200 OK.

Saya telah mengumpulkan sesuatu yang sangat sederhana, tetapi saya tidak terlalu senang dengannya saat ini.

Jika ada yang ingin melihat status vs master saat ini: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

Ini mengembalikan sesuatu seperti:

{"current_timestamp":"2016-06-04T18:43:49+01:00","database_ok":true,"session_ok":true,"version":{"built":1464981754,"commit":"v3.0.4+158-g7cbaf06-dirty","version":"3.1.0"}}

Pemeriksaan database saya awalnya mengembalikan beberapa statistik, tetapi saya sudah memotongnya. Saya dapat mengalihkan kueri ke sesuatu yang lebih sederhana seperti "pilih 1" dan memeriksa apakah tidak ada kesalahan. Tidak yakin apakah itu sepadan.

Pemeriksaan sesi saya juga tidak terlalu senang. Tampaknya tidak mudah untuk menguji tanpa menjalankan uji server macaron dan memulihkan () dari kepanikan yang akan dilontarkannya saat memulai penyedia sesi, atau memodifikasi macaron / sesi untuk menambahkan fitur uji ke masing-masing penyedia. Seperti sekarang ini menjengkelkan mengembalikan header Set-Cookie, yang tidak terlalu saya inginkan. Saya akan menghargai beberapa masukan untuk mengambil ini dari seseorang yang lebih berpengalaman dengan macaron 😞

Memeriksa sumber data tampaknya tidak terlalu masuk akal untuk mencoba melalui ini mengingat bagaimana grafana ditulis. Mungkin lebih masuk akal untuk ditambahkan ke sistem pemantauan reguler Anda.

Saya menghadapi masalah yang sama dan sebagai solusinya, saya menggunakan panggilan API dari penyeimbang beban dengan kunci API otentikasi khusus. Saya menggunakan HAProxy, yang memiliki beberapa fitur "tersembunyi" yang berguna untuk menyetel tajuk HTTP kustom di option httpchk :

option httpchk GET /api/org HTTP/1.0\r\nAccept:\ application/json\r\nContent-Type:\ application/json\r\nAuthorization:\ Bearer\ your_api_key\r\n

(Saya perlu menggunakan HTTP / 1.0 daripada 1.1, karena yang terakhir memerlukan pengaturan header Host dan saya tidak bisa mendapatkannya secara dinamis di konfigurasi HAProxy).

/api/org tampaknya merupakan permintaan paling sederhana dengan sedikit overhead dan mengembalikan HTTP 200, yang persis seperti yang dibutuhkan penyeimbang beban - dan tidak membuat sesi baru.

Ada kemajuan atau PR tentang masalah ini?

+1

Saya akan membagi ini menjadi titik akhir / liveness dan / readiness yang terpisah seperti praktik terbaik di kubernetes. / liveness hanya menunjukkan apakah grafana itu sendiri aktif dan berjalan, / kesiapan menunjukkan apakah ia siap menerima lalu lintas dan akan memeriksa apakah ketergantungannya dapat dijangkau.

Dalam kubernetes, titik akhir liveness akan diperiksa dan ketika gagal beberapa kali untuk merespons dengan 200 ok, kontainer akan dimatikan dan diganti dengan yang baru. Titik akhir kesiapan digunakan untuk menjadikan wadah bagian dari layanan dan mengirimkan lalu lintas ke arahnya. Seperti menambahkan dan menghapusnya dari penyeimbang beban.

+1

bagaimana dengan menambahkan titik akhir Prometheus / metrik?

+1

Untuk siapa pun yang membutuhkan pemeriksaan kesehatan pada beberapa layanan seperti Amazon ECS:
Gunakan retasan ini: Jalur /public/img/grafana_icon.svg , Kode HTTP: 200.

+1

Sementara itu jika Anda hanya mencari HTTP code: 200 , maka cukup gunakan /login . Rekan saya dan saya baru saja menerapkan Grafana ke cluster Kubernetes dan menggunakan titik akhir itu berfungsi dengan baik untuk probe keaktifan / kesiapan. Juga berfungsi untuk penyeimbang beban Google Compute Engine.

Pikirkan semua orang tahu bagaimana menyiratkan ini secara teknis, tetapi intinya adalah untuk secara eksplisit mendukung pemantauan kesehatan layanan termasuk ketergantungan eksternal.

dikirim dari iPhone saya

Pada 5 Desember 2016, pada 16:09, Hunter Satterwhite [email protected] menulis:

Jika Anda mencari kode HTTP sederhana: 200, cukup gunakan / login. Rekan saya dan saya baru saja menerapkan Grafana ke cluster Kubernetes dan menggunakan titik akhir itu berfungsi dengan baik untuk probe keaktifan / kesiapan. Juga berfungsi untuk penyeimbang beban Google Compute Engine.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Saya ingin menambahkan kasus penggunaan khusus kami: kami memerlukan titik akhir HTTP sederhana untuk memeriksa apakah pengguna dapat masuk dan menampilkan grafik. Saya tahu bahwa kita dapat menggunakan sumber daya statis dan titik akhir seperti /login untuk mengatasi tidak adanya ini, tetapi kita benar-benar membutuhkan sesuatu yang memeriksa bahwa internal Grafana berjalan seperti yang diharapkan. Kami tidak perlu pemeriksaan status untuk mengambil data dari sumber data, karena kami memiliki health check terpisah untuk itu.

+1 untuk ini.

Pada hari Senin, 5 Desember 2016 pukul 23.51, Philip Wernersbach <
[email protected]> menulis:

Saya ingin menambahkan kasus penggunaan khusus kami: kami memerlukan titik akhir HTTP sederhana untuk
memeriksa apakah pengguna dapat masuk dan menampilkan grafik. Saya tahu bahwa kita bisa menggunakan
sumber daya statis dan titik akhir seperti / login untuk mengatasi ketidakhadiran
ini, tapi kami benar-benar membutuhkan sesuatu yang memeriksa Grafana itu
internal berjalan seperti yang diharapkan. Kami tidak perlu pemeriksaan status
untuk mengambil data dari sumber data, karena kami memiliki health check terpisah
untuk itu.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

-

[image: TransLoc_logos_gear-blue_600x600.png]

Hunter Satterwhite

Pimpinan Build & Operations Engineer, TransLoc

Seluler: 252.762.5177 | http://transloc.com http://www.transloc.com/

[image: social media icons-03.png] https://www.facebook.com/TransLoc/ [image:
social media icons-04.png] https://www.linkedin.com/company/transloc [image:
social media icons-02.png] http://www.twitter.com/transloc [image: social
ikon media-01.png] http://www.instagram.com/transloc_inc

Jadi saat ini ada di titik akhir 4.0 a / api / metrik dengan beberapa metrik internal.

Tetapi masalah meminta sesuatu seperti ini

{ "date_sources_ok": True, "database_ok": True, "authorization_ok": True, "grafana_version": "2.5.1" }

Akan lebih baik dengan penjelasan yang lebih rinci untuk apa yang diharapkan di sini. Haruskah panggilan kesehatan API melakukan pemeriksaan langsung dengan semua sumber data di semua organisasi? haruskah itu dilakukan dengan cepat saat panggilan / health api dibuat?
Apa artinya otorisasi oke?

@torkelo akan membuang ide tetapi pastinya berpikir / kesehatan harus memungkinkan grafana-server serta plugin yang diinstal untuk mendaftarkan hal-hal sewenang-wenang untuk dilaporkan:

{
    "ok": false,
    "items": [
        "datasources": {
            "ok": true,
        },
        "database": {
            "ok": false,
            "msg": "Cannot communicate ###.###.###.###/XXXXXXX"
        },
        ...
    ]
}

Secara default, health check melakukan pemeriksaan langsung untuk semua hal saat endpoint dipanggil. Jika orang ingin memisahkan health check ke hal-hal tertentu, Anda dapat melakukan sesuatu seperti yang dilakukan elasticsearch untuk kesehatan cluster . Ketika sesuatu adalah layanan eksternal (otorisasi, database, dll), maka uji konektivitas dilakukan seminimal mungkin dan pemeriksaan kewarasan lainnya yang wajar untuk hal tersebut (misalnya PILIH 1 untuk database, uji ikatan LDAP untuk otorisasi, dll).

Memiliki keluaran seperti ini akan memungkinkan pemeriksaan pemantauan untuk memeriksa masalah secara holistik sambil menemukan masalah tertentu dan keluaran yang sesuai.

+1

@torkelo maaf atas jawaban yang tertunda baru saja melihat pertanyaan Anda.

TL; DR
@andyfeller Melakukan pekerjaan dengan baik dalam komentarnya dan itu cukup banyak yang ada dalam pikiran saya

Titik akhir (atau titik akhir) yang digunakan untuk memantau Grafana harus menjawab 2 pertanyaan dengan detail:
A) Apakah instance Grafana ini sudah siap dan siap?
B) Apakah instance Grafana ini berjalan seperti yang diharapkan sesuai dengan maksud konfigurasinya?

"maksud konfigurasi" adalah kuncinya di sini, yang saya maksud dengan maksud adalah bahwa ketika misalnya admin menambahkan sebagai sumber data, dia mengharapkannya tersedia terlepas dari apakah konfigurasi yang disimpan sudah benar atau tidak. Jadi, jika sumber data yang dikonfigurasi tidak tersedia untuk Grafana, titik akhir pemantauan harus mengatakan demikian dan mengapa, dengan cara yang sama tombol "uji" yang sangat berguna berfungsi.

Ini membantu saya berpikir dalam hal pesawat lepas landas, pertama saya perlu tahu pesawat telah selesai lepas landas dan sudah di udara, lalu saya perlu tahu pesawat itu terbang menuju tujuannya seperti yang diharapkan (mari kita tidak membahas apa " mencapai ketinggian kapal pesiar "berarti ;-))

Ini bisa dibandingkan dengan / live / ready yang ditunjukkan orang lain atau / health (1) / state (2) dari model Elasticsearch atau / health dan / info Sensu (3).
IMHO satu titik akhir sudah cukup, tetapi melihat 2 titik akhir di sebagian besar alat modern adalah _kinda_ berubah pikiran; katakan saja saya belum diyakinkan karena saya pikir B adalah bagian dari A jadi saya akan membuat JSON kembali mencerminkan bahwa alih-alih memiliki 2 titik akhir. Kemudian suatu hari ketika Grafana dapat dikelompokkan, "/ cluster_state" dapat ditambahkan.

Sekarang mengenai detail dari setiap jawaban, berikut adalah pemikiran -tidak lengkap- saya:
Detail A:

• Status (misalnya merah / kuning / hijau)
• Komentar status (mis. "Semua baik-baik saja" / "Tidak dapat memulai komponen Foo" / "Memulai")
• Versi (misalnya v4.1.1-1)

B detail:

• Status DB (misalnya merah / kuning / hijau)
• Detail DB (misalnya "tidak dapat terhubung, autentikasi buruk", atau koneksi ok ke mySQL v4.1 di xxx.yyy. Zzz : 3306 , versi skema v34132, ya skema SQL harus diversi (4))
• Otentikasi / Otorisasi (misalnya koneksi LDAP ke xx.xx.xx: 389 ok)
• Sumber data (misalnya Sumber Data 1, Jenis Grafit, status Merah, komentar status "kegagalan auth, Sumber Data 2, jenis Elasticsearch, status Hijau, komentar status" semua baik ")

Masih banyak lagi yang bisa dilakukan di B, itulah sebabnya memecah pemantauan menjadi 2 titik akhir mungkin lebih masuk akal, meh.

Mengenai bagaimana melakukan apa yang terjadi ketika titik akhir sedang dipertanyakan (dengan cepat, API, dll), saya akan tunduk pada siapa yang akhirnya menerapkan.

Beberapa - jelas? - nasihat:

• Berhati-hatilah dengan sumber daya yang digunakan untuk mengumpulkan data pemantauan dan sangat "protektif" dengan kode instrumentasi, bantu admin Grafana menghindari "pemantauan saya terhadap Grafana menurunkan Grafana" atau "Grafana telah melambat sebesar X% sejak saya mulai memantaunya" situasi .

• Pastikan seperti yang Anda bisa pada data pemantauan yang disediakan, keletihan waspada adalah wabah

(1) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html
(2) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html
(3) https://sensuapp.org/docs/0.23/api/health-and-info-api.html#the -info-api-endpoint
(4) https://blog.codinghorror.com/get-your-database-under-version-control/

Jadi 4.2.0 baru saja keluar dan masih belum ada cara untuk menyelidiki layanan ini? (pikirkan cluster k8s)

@torkelo Saya pikir @dynek ada benarnya, ini bukan opsional lagi. Baik itu bagian baru dalam dokumen yang didedikasikan untuk "cara memantau Grafana" di mana apa yang dapat dilakukan hari ini dengan instrumentasi yang ada (misalnya halaman admin atau metrik leverage) didokumentasikan atau API khusus yang lengkap seperti dalam proposal ini, kami memerlukan sesuatu kemarin .
Tolong jangan salah paham, saya tidak bermaksud memberi tahu Anda apa yang harus menjadi prioritas, Hanya saja itu adalah penjualan yang sulit untuk aplikasi menjadi "Enterprise Ready" tanpa bagian khusus untuk memantaunya.

+1

Menambahkan titik akhir http sederhana untuk memeriksa kesehatan grafana:

GET /api/health 
{
  "commit": "349f3eb",
  "database": "ok",
  "version": "4.1.0"
}

Jika database (mysql / postgres / sqlite3) tidak dapat dijangkau, ia akan mengembalikan "gagal" di bidang database . Grafana tetap akan menjawab dengan kode status 200. Tidak yakin apa yang benar dalam kasus itu.

Hal terpenting tentang titik akhir ini adalah bahwa itu tidak akan pernah menyebabkan sesi dibuat (Sesuatu yang mungkin dilakukan oleh panggilan api lain jika Anda tidak memanggilnya dengan kunci api atau autentikasi dasar).

Bukankah lebih baik untuk kembali dengan kode status 503 ketika database tidak dapat dijangkau?

Kubernetes menggunakan:

Kode apa pun yang lebih besar dari atau sama dengan 200 dan kurang dari 400 menunjukkan keberhasilan. Kode lain menunjukkan kegagalan.

Ya, saya pikir kode status 503 ketika status db gagal adalah yang terbaik, akan diperbarui

Angka 503 berarti titik akhir /api/health paling baik hanya digunakan untuk cek readiness di Kubernetes. Jika pemeriksaan ini digunakan untuk liveness masalah database akan menyebabkan semua pod terbunuh. Apakah ada parameter kueri untuk mengabaikan pemeriksaan database?

@JorritSalverda Anda mungkin bisa menggunakan tcpSocket check in livenessProbe

/metrics tidak akan membuat sesi atau mengeluarkan permintaan db.

kami biasanya memiliki pemeriksaan kesiapan yang agresif dan pemeriksaan kehidupan yang santai, 1 detik, 1 gagal untuk kesiapan, sementara itu 60 detik 10 gagal 1 berhasil untuk kehidupan, ini memungkinkan untuk pengubahan rute yang responsif ketika ada masalah, tetapi pada saat yang sama jika pemulihan diri mungkin, mencegah pod restart yang tidak perlu. Tetapi masalah DB yang terus-menerus akan menyebabkan restart yang mungkin benar-benar membantu jika itu karena beberapa status kontainer yang buruk.