Zabbix - memperluaskan sempadan makro

Apabila membuat penyelesaian untuk pelanggan, timbul 2 tugasan yang ingin saya selesaikan dengan cantik dan dengan fungsi Zabbix biasa.

Tugasan 1. Menjejaki versi perisian tegar semasa pada penghala Mikrotik.

Tugas itu diselesaikan dengan mudah - dengan menambahkan ejen pada templat HTTP. Ejen menerima versi semasa daripada laman web Mikrotik, dan pencetus membandingkan versi semasa dengan versi semasa dan mengeluarkan amaran sekiranya berlaku percanggahan.

Apabila anda mempunyai 10 penghala, algoritma sedemikian tidak kritikal, tetapi apa yang perlu dilakukan dengan 3000 penghala? Hantar 3000 permintaan ke pelayan? Sudah tentu, skim sedemikian akan berfungsi, tetapi idea 3000 permintaan tidak sesuai dengan saya, saya ingin mencari penyelesaian lain. Di samping itu, masih terdapat kelemahan dalam algoritma sedemikian: pihak lain boleh mengira sejumlah permintaan dari satu IP untuk serangan DoS, mereka hanya boleh melarangnya.

Tugasan 2. Menggunakan sesi kebenaran dalam ejen HTTP yang berbeza.

Apabila ejen perlu menerima maklumat daripada halaman "tertutup" melalui HTTP, kuki kebenaran diperlukan. Untuk melakukan ini, biasanya terdapat borang kebenaran standard dengan pasangan "log masuk / kata laluan" dan menetapkan ID sesi dalam kuki.

Tetapi ada masalah, adalah mustahil untuk mengakses data item lain dari satu item ejen HTTP untuk menggantikan nilai ini dalam Header.

Terdapat juga "skrip Web", ia mempunyai had lain, ia tidak membenarkan anda mendapatkan kandungan untuk analisis dan penjimatan selanjutnya. Anda hanya boleh menyemak kehadiran pembolehubah yang diperlukan pada halaman atau lulus pembolehubah yang diterima sebelum ini antara langkah skrip web.

Selepas memikirkan sedikit tentang tugasan ini, saya memutuskan untuk menggunakan makro yang boleh dilihat dengan sempurna di mana-mana bahagian sistem pemantauan: dalam templat, hos, pencetus atau item. Dan anda boleh mengemas kini makro melalui API antara muka web.

Zabbix mempunyai dokumentasi API yang baik dan terperinci. Untuk pertukaran data melalui api, format data Json digunakan. Butiran boleh didapati di dokumentasi rasmi.

Urutan tindakan untuk mendapatkan data yang kami perlukan dan merekodkannya dalam makro ditunjukkan dalam rajah di bawah.

Langkah 1

Langkah pertama boleh terdiri daripada satu tindakan atau berbilang tindakan. Semua logik utama diletakkan pada langkah pertama, dan 3 langkah terakhir adalah yang utama.

Dalam contoh saya, langkah pertama ialah mendapatkan kuki kebenaran pada PBX untuk tugasan pertama. Untuk tugasan kedua, saya mendapat nombor versi semasa perisian tegar Mikrotik.

URL versi semasa perisian tegar Mikrotik

• upgrade.mikrotik.com/routeros/LATEST.6 - Alamat URL versi Stabil semasa
• upgrade.mikrotik.com/routeros/LATEST.6fix — Alamat URL versi LTS semasa

Alamat ini diakses oleh peralatan Mikrotik itu sendiri apabila versi perisian tegar terkini yang tersedia diterima.

Langkah pertama adalah sepenuhnya individu untuk setiap kes dan logik kerjanya mungkin berbeza. Semuanya bergantung pada tugas anda.

Apabila bekerja dengan skrip web, jejaki kaedah respons yang anda perlukan. Tajuk Respons HTTP atau diri sendiri тело respons tanpa tajuk?
Jika kuki kebenaran diperlukan, kemudian tetapkan kaedah respons Tajuk seperti dalam kes Asterisk.

Jika anda memerlukan data, seperti dalam kes tindak balas pelayan mikrotik, letakkan badan respons tanpa tajuk.

Langkah 2

Mari kita teruskan ke langkah kedua. Mendapatkan sesi kebenaran:

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
        "user": "Admin"
        "password": "zabbix"
    },
    "id": 1,
    "auth": null
}

jsonrpc ialah versi protokol JSON-RPC yang sedang digunakan;
Zabbix melaksanakan JSON-RPC versi 2.0;

• kaedah - kaedah yang dipanggil;
• params - parameter yang diluluskan oleh kaedah;
• id ialah pengecam permintaan sewenang-wenangnya;
• auth - kunci pengesahan pengguna; memandangkan kita belum memilikinya, mari kita tetapkan kepada null.

Untuk bekerja dengan API, saya membuat akaun berasingan dengan hak terhad. Pertama, anda tidak perlu memberikan akses ke tempat yang anda tidak perlu. Dan kedua, sebelum versi 5.0, kata laluan yang ditetapkan melalui makro boleh dibaca. Sehubungan itu, jika anda menggunakan kata laluan pentadbir Zabbix, akaun pentadbir mudah dicuri.

Ini akan menjadi benar terutamanya apabila bekerja dengan API melalui skrip pihak ketiga dan menyimpan bukti kelayakan di sisi.

Sejak versi 5.0 terdapat pilihan untuk menyembunyikan kata laluan yang disimpan dalam makro.

Apabila membuat akaun berasingan untuk mengemas kini data melalui API, pastikan anda menyemak sama ada data yang anda perlukan tersedia melalui antara muka web dan sama ada ia boleh dikemas kini. Saya tidak menyemak, dan kemudian untuk masa yang lama saya tidak dapat memahami mengapa makro yang saya perlukan tidak kelihatan dalam API.

Selepas kami menerima kebenaran dalam API, kami meneruskan untuk mendapatkan senarai makro.

Langkah 3

API tidak membenarkan anda mengemas kini makro hos mengikut nama, anda mesti mendapatkan ID makro terlebih dahulu. Selain itu, untuk mendapatkan senarai makro untuk hos tertentu, anda perlu mengetahui ID hos ini, dan ini adalah permintaan tambahan. Gunakan makro lalai {HOST ID} dalam permintaan tidak dibenarkan. Saya memutuskan untuk memintas sekatan seperti ini:

Saya mencipta makro tempatan dengan ID hos ini. Mengetahui ID hos adalah sangat mudah dari antara muka web.

Respons dengan senarai semua makro pada hos tertentu boleh ditapis mengikut corak:

regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"

Oleh itu, kami mendapat ID makro yang kami perlukan, di mana MIKROTIK_VERSION ialah nama makro yang kami cari. Dalam kes saya, makro dicari MIKROTIK_VERSIONYang telah diberikan kepada tuan rumah.

Permintaan itu sendiri kelihatan seperti ini:

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc":"2.0",
    "method":"usermacro.get",
    "params":{
        "output":"extend",
        "hostids":"{$HOST_ID}"
    },
    "auth":"{sid}",
    "id":1
}

Pembolehubah {sid} diperoleh dalam langkah kedua dan akan digunakan secara berterusan, di mana anda perlu bekerja dengan antara muka API.

LANGKAH 4 Akhir - mengemas kini makro

Sekarang kita tahu ID makro yang perlu dikemas kini, kuki kebenaran atau versi perisian tegar penghala. Anda boleh mengemas kini makro itu sendiri.

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc":"2.0",
    "method":"usermacro.update",
    "params":{
        "hostmacroid":"{hostmacroid}",
        "value":"{mikrotik_version}"
    },
    "auth":"{sid}",
    "id":1
}

{mikrotik_version} ialah nilai yang diperolehi dalam langkah pertama. Dalam contoh saya, versi perisian tegar mikrotik semasa
{hostmacroid} - nilai diperoleh dalam langkah ketiga - id makro yang sedang kami kemas kini.

Penemuan

Pendekatan untuk menyelesaikan masalah dengan fungsi standard adalah lebih rumit dan lebih lama. Terutama jika anda tahu pengaturcaraan dan dengan cepat boleh menambah logik yang diperlukan dalam skrip.

Kelebihan jelas pendekatan ini ialah "mudah alih" penyelesaian antara pelayan yang berbeza.

Bagi saya secara peribadi, pelik bahawa ejen HTTP tidak boleh mengakses data item lain dan menggantikannya dalam badan permintaan atau pengepala [ ZBXNEXT-5993].

Templat siap boleh muat turun di GitHub.

Sumber: www.habr.com