Pendahuluan
Setiap orang yang menggunakan sistem pemantauan Zabbix dan memantau perkembangannya tahu bahwa dengan rilis Zabbix 3.4 kami memiliki fitur hebat - Item Tergantung (item data dependen), yang sudah ada
posting blog
terkait di Zabbix. Namun, dalam bentuk di mana ia diperkenalkan pada 3.4, menggunakannya "sepenuhnya" bermasalah karena fakta bahwa makro LLD tidak didukung untuk digunakan dalam aturan preprocessing (
ZBXNEXT-4109 ), serta sebagai "induk" Hanya satu yang dibuat oleh aturan LLD itu sendiri (
ZBXNEXT-4200 ) yang dapat dipilih dari item data. Singkatnya, saya harus melakukan semuanya persis seperti yang dijelaskan dalam tautan di atas - untuk bekerja dengan tangan Anda, yang, dengan sejumlah besar metrik, menyebabkan banyak ketidaknyamanan. Namun, dengan rilis Zabbix 4.0alpha9, semuanya telah berubah.
Sedikit sejarah
Bagi saya, fungsi yang dijelaskan itu penting karena fakta bahwa perusahaan kami menggunakan beberapa sistem penyimpanan dari HP, yaitu HP MSA 2040/2050, metrik yang dihapus oleh permintaan ke XML API mereka menggunakan
skrip Python .
Pada awalnya, ketika tugasnya adalah memantau peralatan yang ditunjuk dan sebuah opsi ditemukan menggunakan API, ternyata dalam kasus yang paling sederhana, untuk mengetahui, katakanlah, status kesehatan satu komponen sistem penyimpanan, perlu membuat dua pertanyaan:
- Token otentikasi permintaan (kunci sesi);
- Permintaan itu sendiri, mengembalikan informasi tentang komponen.
Sekarang bayangkan penyimpanan terdiri dari 24 disk (atau mungkin lebih), dua catu daya, sepasang pengontrol, kipas, beberapa kumpulan disk, dll. - kami mengalikan semua ini dengan 2 dan mendapatkan lebih dari 50 elemen data, yang sama dengan jumlah permintaan yang sama untuk API pada setiap menit memeriksa. Jika Anda mencoba menggunakan cara ini, API dengan cepat "meletakkan", dan setelah semua kita hanya berbicara tentang meminta "kesehatan" dari komponen, tidak memperhitungkan metrik lain yang mungkin dan menarik - suhu, jam berjalan untuk hard drive, kecepatan kipas, dll.
Keputusan pertama yang saya buat untuk menurunkan API, bahkan sebelum rilis Zabbix versi 3.4, adalah membuat cache untuk token yang diterima, yang nilainya ditulis ke file dan disimpan selama N-menit. Ini memungkinkan untuk mengurangi jumlah panggilan ke API tepat dua kali, namun, situasinya tidak banyak berubah - sulit untuk mendapatkan sesuatu selain kondisi kesehatan. Sekitar waktu ini, saya mengunjungi Zabbix Moscow Meetup 2017, yang diselenggarakan oleh Badoo, di mana saya belajar tentang fungsionalitas item data dependen yang disebutkan di atas.
Skrip dimodifikasi untuk memberikan objek JSON terperinci yang berisi informasi yang menarik bagi kami tentang berbagai komponen repositori dan hasilnya mulai terlihat seperti ini, bukan string tunggal atau nilai numerik:
{"1.1":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27267"},"1.2":{"health":"OK","health-num":"0","error":"0","temperature":"23","power-on-hours":"27266"},"1.3":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27336"}, ... }
Ini adalah contoh dengan data yang diberikan pada semua disk penyimpanan. Untuk komponen lain, gambarnya serupa - kuncinya adalah ID komponen, dan nilainya adalah objek JSON yang berisi metrik yang diperlukan.
Semuanya baik-baik saja, tetapi nuansa yang dijelaskan di awal artikel dengan cepat muncul - semua metrik dependen harus dibuat dan diperbarui secara manual, yang agak menyakitkan (sekitar 300 metrik per sistem penyimpanan ditambah pemicu dan grafik). LLD bisa menyelamatkan kita, tetapi di sini, ketika membuat prototipe, itu tidak memungkinkan kita untuk menentukan yang tidak dibuat oleh aturan itu sendiri sebagai item induk, dan menjatuhkan hack kotor dengan membuat item fiktif melalui LLD dan mengganti itemid dalam database dengan yang diinginkan Server Zabbix. Permintaan fitur yang disebutkan dengan cepat muncul di pelacak bug Zabbix, yang menunjukkan bahwa fungsi ini penting tidak hanya bagi saya.
Karena semua operasi persiapan pada bagian saya selesai, saya memutuskan untuk mentolerir dan tidak menghasilkan solusi sementara, seperti pembuatan template yang dinamis, dan hanya menunggu penutupan ZBXNEXT yang ditunjukkan pada awal artikel dan baru-baru ini selesai.
Bagaimana kelihatannya sekarang
Untuk mendemonstrasikan fitur-fitur baru Zabbix, kami mengambil:
- Penyimpanan HPE MSA 2040 tersedia melalui HTTP / HTTPS;
- Server Zabbix 4.0alpha9 diinstal dari repositori resmi pada CentOS 7.5.1804;
- Sebuah skrip yang ditulis dengan Python versi ketiga dan memberi kami kemampuan untuk mendeteksi komponen penyimpanan (LLD) dan mengembalikan data dalam format JSON untuk diuraikan di sisi server Zabbix menggunakan JSON Path.
Elemen data induk akan menjadi "pemeriksaan eksternal" yang memanggil skrip dengan argumen yang diperlukan dan menyimpan data yang diterima sebagai teks.
Persiapan
Skrip Python diinstal sesuai dengan
dokumentasi dan memiliki pustaka "permintaan" dalam dependensi Python. Jika Anda memiliki distribusi berbasis RHEL, Anda dapat menginstalnya menggunakan pengelola paket yum:
[root@zabbix]
Atau menggunakan pip:
[root@zabbix]
Anda dapat menguji skrip dari shell dengan meminta, misalnya, data LLD tentang disk:
[root@zabbix]
Penyiapan host
Pertama, Anda perlu membuat elemen data induk yang akan berisi semua metrik yang kami butuhkan. Sebagai contoh, buat elemen seperti itu untuk disk fisik:
Nama - tentukan secara sewenang-wenang;
Jenis - verifikasi eksternal;
Kuncinya adalah memanggil skrip dengan parameter yang diperlukan (lihat
dokumentasi skrip di GitHub);
Jenis informasi - teks;
Interval pembaruan - contoh menggunakan makro kustom {$ UPDATE} yang diperluas ke nilai "1m";
Masa penyimpanan riwayat adalah satu hari. Saya pikir menyimpan elemen data induk tidak masuk akal lagi.
Periksa data terbaru untuk elemen yang dibuat:
JSON datang, maka semuanya dilakukan dengan benar.
Selanjutnya akan menyiapkan aturan penemuan yang akan menemukan semua komponen yang tersedia untuk memantau dan membuat item dan pemicu yang tergantung. Melanjutkan contoh dengan disk fisik, akan terlihat seperti ini:
Setelah membuat aturan LLD, Anda perlu membuat prototipe item data. Mari kita buat prototipe seperti itu, menggunakan data suhu sebagai contoh:
Nama - tentukan secara sewenang-wenang;
Jenis tergantung. Sebagai elemen data induk, pilih elemen yang sesuai yang sebelumnya dibuat;
Key - kami akan menunjukkan imajinasi, tetapi kami harus memperhitungkan bahwa setiap kunci harus unik, oleh karena itu kami akan menyertakan makro LLD di dalamnya;
Jenis informasi - dalam hal ini numerik;
Periode penyimpanan histori - dalam contoh, ini adalah makro kustom, ditunjukkan dengan kebijaksanaan Anda;
Periode penyimpanan tren , sekali lagi, makro kustom;
Saya juga menambahkan prototipe dari "Aplikasi" - Anda dapat dengan mudah mengikat metrik yang terkait dengan satu komponen ke dalamnya.
Pada tab "Pra-pemrosesan", buat langkah dari tipe "JSON Path" dengan aturan yang mengambil pembacaan suhu:
Ekspresi langkahnya terlihat seperti ini:
$['{#DISK.ID}']['temperature']Harap dicatat bahwa sekarang Anda dapat menggunakan makro LLD dalam ekspresi, yang tidak hanya sangat menyederhanakan pekerjaan kami, tetapi juga membuatnya sangat mudah untuk melakukan hal-hal seperti itu (Anda akan dikirim ke API Zabbix sebelumnya).
Selanjutnya, dengan analogi dengan suhu, buat prototipe elemen data yang tersisa:
Pada tahap ini, Anda dapat memeriksa hasilnya dengan masuk ke "Data Terbaru" pada host. Jika semuanya sesuai dengan Anda di sana, kami terus bekerja lebih jauh. Saya berakhir dengan gambar berikut:
Kami sedang menunggu cache konfigurasi diperbarui atau mendorongnya secara manual untuk memperbarui:
[root@zabbix]
Setelah itu, Anda dapat menggunakan "trik" keren versi 4.0 - tombol "Periksa sekarang" untuk menjalankan aturan LLD yang dibuat:
Saya mendapat hasil sebagai berikut:
Kesimpulan
Akibatnya, dengan hanya sembilan permintaan ke XML API, kami dapat memperoleh lebih dari tiga ratus metrik dari satu node jaringan, menghabiskan waktu minimum untuknya dan mendapatkan fleksibilitas maksimum. LLD akan memberi kita kemampuan untuk secara otomatis mendeteksi komponen baru atau memperbarui yang lama.
Terima kasih telah membaca, tautan ke materi yang digunakan, dan juga ke template saat ini untuk HPE MSA P2000G3 / 2040/2050 dapat ditemukan di bawah.
Ngomong-ngomong, dalam versi 4.0 tipe cek baru juga diperkenalkan - agen HTTP, yang, ditambah dengan preprocessing dan XML Path, berpotensi menyelamatkan kita dari penggunaan skrip eksternal - Anda hanya perlu menyelesaikan masalah mendapatkan token otentikasi, yang masih perlu diperbarui secara berkala. Salah satu opsi yang saya lihat adalah penggunaan makro global dengan token ini, yang dapat diperbarui melalui Zabbix API oleh crown, incl. orang yang tertarik dapat mengembangkan ide ini. =)
SkripTemplate Berbagi ZabbixItem Data yang TergantungJalan jsonZabbix 4.0alpha9