[Pemantauan Nightingale] Pengurusan penggera, bagus!

Pemantauan adalah kaedah, membimbangkan adalah cara, dan penyelesaian adalah tujuannya.

Tetapi adakah anda pernah mengalami kekeliruan seperti ini? Saya telah mengumpulkan banyak penunjuk, tetapi saya tidak tahu penunjuk mana yang harus menjana penggera, mahupun cara menghantar penggera ini kepada pasukan atau individu yang sepadan, mahupun cara meningkatkan penggera.

Apabila saya menggunakan Prometheus+Altermanager sebelum ini, saya membuat kumpulan DingTalk untuk setiap pasukan, kemudian menambah sekumpulan tag, memadankan tag yang berbeza dan menghantarnya ke kumpulan yang berbeza Jika saya ingin memaklumkan Peningkatan sering dilakukan peningkatan ambang, tetapi sukar untuk menaik taraf penggera yang sama mengikut masa.

Tetapi pengurusan peraturan penggera Nightingale tidaklah begitu rumit (mereka melakukan perkara yang rumit untuk anda), dan ia juga sangat elegan. Saya pertama kali bertemu Nightingale dalam ​​"[Pemantauan Nightingale], dan ia masih kuat!" 》​​ Disebut: Grafana lebih baik dalam memantau pengurusan panel, dan N9e lebih baik dalam mengurus peraturan penggera.

Hari ini, mari kita lihat cara Nightingale bermain.

Peraturan Penggera

Tentera dan kuda belum bergerak, makanan dan rumput didahulukan.

Untuk alert, kita mesti tahu dulu apa keperluan kita, iaitu kita mesti faham indicator mana yang perlu di alert.

Sebagai contoh, pada peringkat sistem, kita perlu mempertimbangkan CPU, memori, cakera, IO dan penunjuk lain pada tahap aplikasi, kita perlu mempertimbangkan ketepuan aplikasi, kadar kegagalan, kelewatan, dll.; peringkat perniagaan, kita perlu mempertimbangkan Pertimbangkan berapa kali transaksi ini gagal, di mana ia gagal, dsb.

Pada tahap yang berbeza, penunjuk pemantauan dan strategi penggera yang dipertimbangkan akan berbeza.

Peraturan penggera Nightingale dibahagikan kepada peraturan terbina dalam dan peraturan tersuai.

Peraturan terbina dalam direka bentuk untuk menurunkan ambang untuk digunakan oleh semua orang dan menyediakan set peraturan universal kepada semua orang. Kandungan utama adalah seperti berikut:

Peraturan penggera terbina dalam tidak akan berkuat kuasa melainkan anda memasukkannya ke dalam peraturan anda. Jika anda menyukai peraturan tertentu, anda boleh mengklonkannya ke dalam peraturan aktif. Contohnya, saya mengklonkan peraturan penggera TIME_WAIT Linux ke dalam kumpulan perniagaan lalai.

Kemudian pergi ke gambaran keseluruhan peraturan penggera dan anda akan melihat bahawa peraturan penggera baharu telah ditambahkan pada kumpulan perniagaan lalai.

Selepas melihat ini, adakah anda mempunyai sebarang inspirasi dalam fikiran anda?

Kami boleh membuat berbilang kumpulan perniagaan mengikut situasi sebenar, dan kemudian bolehkah kami mengurus peraturan penggera yang melibatkan berbilang kumpulan perniagaan secara berasingan?

Dengan mengandaikan kita mempunyai dua pasukan, pejabat hadapan dan pejabat tengah, kita boleh mengklasifikasikan penunjuk secara berasingan.

Peraturan yang diimport secara lalai tidak berkesan pada dasarnya dan memerlukan beberapa konfigurasi tambahan.

Klik pada nama peraturan penggera untuk memasuki halaman konfigurasi.

Kami boleh menyesuaikan keadaan penggera, sumber data, tahap penggera dan konfigurasi lain. Maklumat yang kami konfigurasikan di atas diringkaskan seperti berikut:

• Sumber data penggera ialah local_prometheus, yang menunjukkan kumpulan penggera anda berasal.
• Syarat penggera ialah penggera hanya akan dicetuskan apabila jumlah bilangan TIME_WAIT melebihi 20000.
• Tahap penggera ialah Tahap 2, iaitu tahap penting umum.
• Kekerapan pelaksanaan adalah sekali setiap 15 saat Jika peraturan penggera masih dipenuhi selama 60 saat secara berterusan, penggera akan dicetuskan

Langkah seterusnya ialah konfigurasi tambahan, seperti berikut. :

Konfigurasi berkesan digunakan untuk mengkonfigurasi tempoh masa dan kumpulan perniagaan di mana peraturan penggera akan berkuat kuasa. Konfigurasi pemberitahuan adalah untuk mengkonfigurasi medium pemberitahuan, iaitu, jika penggera berlaku, melalui saluran mana ia harus dihantar ke tempat mana.

Walau bagaimanapun, konfigurasi tambahan boleh dibuat dalam konfigurasi pemberitahuan:

• Pemberitahuan Mulakan pemulihan, iaitu, jika penggera dipulihkan, orang yang bertanggungjawab juga akan dimaklumkan melalui saluran ini.
• Kumpulan penerima penggera, juga dikenali sebagai kumpulan perniagaan.
• Masa pemerhatian, apabila penggera dipulihkan, perhatikan tempoh masa yang diperlukan untuk menghantar pemberitahuan pemulihan kepada kumpulan perniagaan. Penggera yang tidak menentu yang boleh dielakkan seperti penggera dan pemulihan.
• Pemberitahuan ulang, iaitu, dalam tempoh masa ini, jika penggera belum diselesaikan, ia akan dihantar semula. Sudah tentu, peningkatan penggera tidak terlibat di sini lagi.

Selepas melihat ini, adakah anda mempunyai sedikit pemahaman tentang pengurusan peraturan penggera biasa?

Selain mengklon peraturan penggera terbina dalam, kami juga boleh menyesuaikan peraturan penggera, tetapi konfigurasi keseluruhan adalah sama seperti di atas.

Penggera Sekat

Secara amnya, penggera yang disekat bukanlah penggera yang sangat penting.

Dalam keadaan apakah penggera akan disekat?

Sebagai contoh, apabila kami menerbitkan aplikasi, kami pasti akan menghadapi masalah Pada masa ini, kami boleh membuat beberapa peraturan penyekatan terlebih dahulu untuk mengelakkan daripada menjana mesej penggera.

Peraturan pelindung juga dibahagikan dengan komponen perniagaan. Kami boleh menambah peraturan baharu seperti berikut untuk membuat peraturan menyekat penggera pusat mesej.

Dengan cara ini, dalam tetingkap masa tetap, maklumat penggera tidak akan dihantar lagi.

Sesetengah pelajar mungkin ingin berkata, adakah agak menyusahkan untuk menambahnya satu persatu?

Jika penggera aktif telah dijana, ia boleh disekat dengan satu klik.

Jika ia adalah penggera sejarah, ia juga boleh disekat dengan satu klik.

Bagaimana dengan selain itu?

Jika anda ingin menyekat apa-apa, cuma tambah sendiri!

Naik taraf penggera

Apakah yang perlu saya lakukan jika penggera tidak diproses dalam tempoh masa?

Sama ada ia bukan amaran penting - padamkan peraturan dan biarkan ia tidak berguna.

Sama ada penggera yang tidak dapat diselesaikan - tingkatkan penggera itu dan beritahu lebih ramai orang tentangnya.

Dalam Nightingale, peningkatan penggera boleh dilaksanakan dalam peraturan langganan.

Sebagai contoh, konfigurasi kami adalah seperti berikut:

Jika peristiwa penggera server=notis tidak diselesaikan dalam masa 1 jam, kami akan menaik taraf penggera tahap ke tahap satu , dan menghantar maklumat penggera kepada kumpulan peringkat lebih tinggi.

Peraturan di sini juga boleh dikelaskan dan diuruskan oleh pasukan perniagaan.

Selain itu, ia juga menyediakan penggera aktif dan penggera sejarah Anda boleh menyemak maklumat penggera semasa dan rekod penggera sejarah.

Penyembuhan diri penggera

Semakin lama anda bekerja dalam operasi dan penyelenggaraan, anda sebenarnya akan mendapati bahawa pemprosesan banyak perkara boleh dilakukan secara berulang-ulang dilakukan melalui skrip automatik Pemprosesan bukan sahaja dapat meningkatkan kecekapan kerja, tetapi juga mengurangkan risiko operasi manusia pada tahap tertentu.

Nightingale menyediakan fungsi penyembuhan diri penggera. Walaupun fungsinya bagus, jangan tamak.

Apabila berurusan dengan penggera, anda mesti terlebih dahulu mengetahui sebab sebenar di sebaliknya, supaya anda dapat menyelesaikan masalah tersebut. Jadi untuk penyembuhan diri penggera, anda mesti faham bahawa risiko operasi automatik yang anda lakukan adalah sangat rendah dan anda telah mencubanya berkali-kali. Jangan gunakan operasi cd /opt/aaa;rm -rf ./.

Dalam Nightingale, gunakan templat ibex untuk melaksanakan penyembuhan diri penggera. Pada masa ini, bahagian ibex-server perlu digunakan dengan sendirinya, dan bahagian ibex-agent telah disepadukan ke dalam Categraf.

Deploy ibex-server

Pergi ke https://github.com/flashcatcloud/ibex/releases untuk memuat turun pakej binari selepas memuat turun, terdapat perkara berikut fail:

# ll
total 21536
drwxr-xr-x 3 root root 4096 Apr 19 10:44 etc
-rwxr-xr-x 1 root root 16105472 Nov 152021 ibex
-rw------- 1 root root5931963 Jun32022 ibex-1.0.0.tar.gz
drwxr-xr-x 2 root root 4096 Nov 152021 sql

Pangkalan data import:

mysql -uroot -p <sql/ibex.sql

Kemudian ubah suai fail konfigurasi /etc/server.conf, terutamanya mengubah suai konfigurasi pangkalan data.

Akhirnya mulakan pelayan:

nohup ./ibex server &> server.log &

Konfigurasikan klien

Dalam konfigurasi sistem​->konfigurasi pemberitahuan​- >Alamat pelayan yang sepadan dengan konfigurasi modul penyembuhan diri penggera:

Uji penyembuhan diri

Kemudian pergi ke penyembuhan diri penggera​- >Tambahkan skrip pada skrip penyembuhan diri seperti berikut:

Simpan dan keluar, klik untuk membuat tugasan:

Jika konfigurasi di dalam tidak perlu diubah suai atau selepas mengubah suai konfigurasi yang sepadan, pilih untuk melaksanakan serta-merta:

Di titik ini, apa yang anda fikir Adakah ia baik?

Bagaimanapun, saya tidak berjaya Pada ketika ini saya perlu mengadu tentang modul ini:

• Adakah terdapat sebarang prasyarat untuk penggunaan ibex-server?
• Adakah terdapat sebarang prasyarat untuk ibex-agent (categraf)?
• Pelaksanaan skrip penyembuhan diri gagal, dan tiada log kegagalan khusus pada klien atau pelayan.
• Cara meletakkan entri konfigurasi penyembuhan diri penggera N9e Versi V6 ke dalam modul pemberitahuan mesej? Pelik
• Dokumen rasmi modul ini agak terlalu mudah

Jadi, saya tidak berjaya di sini, bahagian hadapan membuang masa tamat.

Tiada log di bahagian belakang.

Ringkasan

Pada masa ini, Nightingale secara relatifnya boleh melengkapkan pengurusan peraturan penggera, pengedaran saluran penggera dan penindasan serta peningkatan daripada mesej penggera Selain itu, FlashDuty boleh mengakses penggera kluster yang berbeza, yang cukup untuk kebanyakan perusahaan.

Hanya semasa menguji penyembuhan diri penggera, saya gagal mengujinya dengan jayanya. Ia sepatutnya berkaitan dengan persekitaran saya:

• Modul keseluruhan N9e digunakan pada K8 menggunakan Helm
• Sisi pelayan ibex digunakan secara langsung pada hos dalam bentuk binari.

Walau bagaimanapun, punca khusus belum diketahui dan terdapat terlalu sedikit maklumat penyelesaian masalah yang tersedia.

Atas ialah kandungan terperinci [Pemantauan Nightingale] Pengurusan penggera, bagus!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!