🧒🏼 🔟 🎷 Bagaimana kami memperbarui Zabbix 🧒🏽 🖕🏻 💷

gambar

Mengapa kita mencintai Prometheus ? Dia memiliki konfigurasi - dia melihat dan semuanya jelas, program melakukan apa yang diperintahkan padanya. Anda dapat mengotomatiskan pengaturan pemantauan, menyimpannya dalam VCS, dan meninjau perintah. Terbatas MR Anda, pipeline bekerja, konfigurasi baru diterapkan ke prometheus. Secara umum, IaC dalam semua kemuliaan.

Berbicara tentang prometheus. Apakah Anda menggunakannya untuk infrastruktur besi Anda? Jadi kami tidak menggunakan.

Seperti banyak orang yang telah memantau untuk waktu yang lama dan yang memiliki perangkat keras "telanjang", kami menggunakan Zabbix , yang terletak di perangkat keras itu. Sayangnya, saat ini, Zabbix dan IaC adalah hal yang tidak terkait. Zabbix dapat dikonfigurasi secara manual atau melalui API.

Latar belakang

Pada Oktober 2018, Zabbix-4.0 dirilis - cabang LTS baru. Dan pada pertengahan Maret, kami mulai merencanakan untuk memutakhirkan pemasangan versi 3.4 ke instalasi kami.

Hampir tidak ada masalah khusus dengan 3.4:

Terkadang beberapa LLD tidak berfungsi di suatu tempat dan Impossible terjadi, yang tidak jelas cara melakukan debug pada versi yang tidak didukung oleh pengembang
Memori penarik HTTP terus mengalir - sebagai akibatnya sistem yang dikonfigurasi dengan cermat memakukan pemantauan dan memulainya lagi. Masalahnya ditutupi oleh jumlah memori server yang layak. Masalahnya sudah diketahui, didokumentasikan .

Dan di 4.0 ada fitur menarik seperti HTTP-item asli dan periode layanan tidak untuk seluruh host.

Dan di mana itu terlihat, duduk di versi pemantauan yang tidak relevan, bahkan pada LTS? Kita harus tetap up to date.

Selain itu, ketika merencanakan pembaruan, ditemukan detail yang menarik: kemajuan tidak berhenti, Anda dapat mengambil mobil yang lebih cepat dengan harga lebih murah. Dan sepanjang jalan, saya menemukan cara untuk menghemat layanan hoster yang sudah tidak perlu di beberapa proyek rekan. Seperti yang mereka katakan, kami berhasil memasukinya.

Pembaruan Dahi

Tidak ada yang rumit dalam memperbarui zabbix sekarang. Pesan server, konfigurasikan, gabungkan salinan basis data. Masukkan paket pemantauan dan tunjukkan kepada mereka basisnya, jalankan zabbiks - dan dia akan memperbarui semuanya untuk Anda, gulung semua migrasi. Ya, Anda mungkin tahu betapa mudahnya upgrade Zabbix.

Secara total, migrasi basis data memakan waktu sekitar 15 menit, dan bahkan tanpa banyak penyalahgunaan. Dan semuanya tampak baik-baik saja. Hah? Bagaimanapun caranya! Terlepas dari kenyataan bahwa IP server baru tidak terdaftar dalam daftar putih agen, dan mengumpulkan data hanya dari beberapa host pengujian, Impossible masih terjadi di sana.

Untuk memuji pengembang Zabbix, saya harus mengatakan, mereka menepati janji mereka - versi 4.2 didukung pada waktu itu. Setelah berbicara dalam pelacak proyek, kami menemukan bahwa alasan untuk hal yang mustahil adalah karena tidak sesuai dengan struktur yang diharapkan dari salah satu tabel database.

Keraguan samar merayap masuk. Akan berguna untuk mengingat bahwa secara historis tabel database Zabbix “paling tebal” telah dipartisi. Pertama-tama, untuk alasan kinerja, untuk menutupi entah bagaimana kalus zabbix favorit Anda - menghapus data historis di RDBMS . Kami membandingkan struktur semua tabel secara berurutan dalam database yang baru diperbarui dan kontrol - yang dibuat oleh server sendiri dari awal. Ketakutan itu dikonfirmasi. Selain kurangnya beberapa konstanta dalam database, dalam banyak tabel, banyak kolom digital dari tipe yang salah.

Faktanya, kami tidak memiliki skema dasar yang didukung oleh pengembang, tetapi "garpu" kami sendiri. Tipe lain dari data kolom adalah, berpotensi:

biaya penyimpanan metrik lainnya
akurasi angka yang berbeda
kecepatan pengambilan sampel / perekaman yang berbeda dari metrik

Pikirkan yang lebih baik? Itu diragukan. Menurut pengalaman sebelumnya dengan dukungan teknis dan pengembang zabbix, mereka dapat menyesuaikan DBMS.

Dan tipe data kolom ini mungkin, tetapi sulit dan lama untuk berubah. Dan tidak mungkin tanpa pemantauan downtime yang lama. Tanpa jaminan kesuksesan, tanpa dukungan dari pengembang di masa depan. Perlu cara lain.

Dan Zabbix memilikinya. Karena pada bulan April 2019, zabbix-4.2 akan keluar

Pendekatan kedua untuk proyektil

Fitur utama 4.2 bagi kami adalah dukungan untuk mempartisi di luar kotak menggunakan TimescaleDB . Setelah berbicara dengan perwakilan Zabbix dan membiasakan diri dengan hasil pengujian dukungan teknis untuk fitur ini ( terjemahan pada hub), kami memutuskan untuk menguji instalasi dengan timescaledb dan, berdasarkan hasil, membuat keputusan tentang transisi. Lebih khusus: untuk beberapa waktu, semua data pemantauan akan ditulis secara paralel dengan versi lama dan baru. Dan kemudian kita tinggal mengganti entri DNS.

Tentu saja, pendekatan ini tidak memungkinkan Anda untuk menyimpan data dan tren historis - database baru diisi dari awal. Tetapi apakah mereka benar-benar dibutuhkan? Sejarah hanya penting di sini dan sekarang, ia akan terakumulasi dengan cukup cepat lagi (lihat prometheus yang sama). Hanya utilitas tren yang tidak diragukan untuk perencanaan kapasitas yang tersisa. Bagaimanapun, arsip dengan data yang sudah dikumpulkan tetap ada bersama kami (melihat ke depan - itu berguna untuk beberapa klien). Fitur lain dari dukungan timescaledb di zabbix adalah periode penyimpanan histori / tren individu tidak lagi valid.

Kami memiliki klien yang bersikeras penyimpanan "kekal" semua data yang dikumpulkan di semua biaya. Kami dapat menawarkan mereka untuk mempertimbangkan instalasi / dukungan dari instalasi pemantauan terpisah dengan pengaturan khusus. Tugas utama kami adalah memastikan operasi proyek / server klien yang stabil dengan tetap menjaga biaya layanan yang dapat diterima, yang mencakup pemantauan juga.

Secara total, langkah-langkah berikut akan diperlukan untuk migrasi:

Instal dan konfigurasikan instalasi pemantauan kedua
Dapatkan semuanya sama seperti pada instalasi pertama
Beralih!

Kedengarannya mudah, bukan? Memang, yang pertama tidak terlalu sulit, karena selama pendekatan sebelumnya kami menulis peran untuk menginstal server zabbix, cukup dengan mengunggah konfigurasi saja. Item ketiga juga terlihat sederhana - alihkan DNS dan semua agen zabbiks, proksi, klien API, dan pengguna langsung ke versi baru. Tetapi bagaimana membuat poin kedua?

Awalnya kami mencoba pendekatan naif. Diimpor dari pemantauan saat ini beberapa templat yang paling umum digunakan. Menggunakan skrip yang sudah ditulis untuk bekerja dengan API, kami memulai proyek yang sama dalam pemantauan baru seperti yang saat ini, mendorong pengeditan melalui sistem SCM , menambahkan IP mesin baru ke filter paket dan ke arahan agen Server / ServerActive . Bahkan berhasil - banyak host mulai mendaftar dalam dua pemantauan sekaligus, yang baru menetapkan templat dan mulai mengumpulkan data secara paralel dengan yang sekarang.

Sayangnya, ini justru pendekatan naif terhadap migrasi, hanya cocok untuk tes. Beban yang dihasilkan (dalam nvps ) tidak dapat dibandingkan dengan instalasi saat ini, lebih rendah dengan urutan besarnya. Itu bisa dimengerti. Dalam kasus kami, pemantauan secara harfiah merupakan tahun-tahun kerja banyak orang dan skrip, intisari pengalaman dalam mengoperasikan proyek-proyek yang heterogen.

Sebagai contoh, bagaimana dengan pengguna secara manual dan kata sandi mereka, yang dihasilkan secara acak saat membuat proyek, template pemantauan tergantung pada host (dengan nilai-nilai makro kustom mereka), item yang dibuat secara manual, layar kompleks, grafik, dasbor, periode layanan, proxy? Semua ini dan banyak lagi yang perlu ditransfer untuk kelancaran migrasi.

Untungnya, zabbix memiliki fungsi bawaan untuk mengekspor / mengimpor objek - juga tersedia melalui API. Sayangnya, itu mencakup tidak lebih dari setengah dari semua fasilitas yang ada. Dan kode untuk menggunakannya juga perlu ditulis. Secara umum, Anda tidak bisa hanya mengambil dan mengimpor konfigurasi satu zabbik ke yang lain.

Atau mungkinkah?

Di sini otak membantu mengingat tugas dari simpanan bahwa akan lebih baik untuk mengatur penyimpanan sejarah konfigurasi pemantauan dengan cara eksternal. Sayangnya, ini adalah titik sakit Zabbix. Dengan merujuk pada artikel di hub dan repositori dengan kode. Namun ada nuansa:

kode tidak mengekspor semua objek pemantauan ke file YAML yang dapat dibaca manusia (khususnya, tidak semua yang kita butuhkan)
kode tidak mendukung mengimpor objek

Untungnya, ada orang yang tahu sedikit bahasa proyek (python) dan memiliki pengalaman dengan Zabbix API. Satu-satunya bisnis adalah mengimpor objek dari dump YAML yang sudah jadi. Untuk berapa lama, singkat, tetapi setelah tiga minggu bekerja dan satu setengah ratus komit, garpu cukup cocok untuk tujuan kita. Sebenarnya, demi presentasinya, seluruh artikel ditulis:

https://github.com/centosadmin/zabbix-review-export-import

Apa yang telah dilakukan:

Dukungan tambahan untuk banyak objek baru
Format ekspor YAML dari sebagian besar objek yang ada telah diubah sehingga mereka dapat diimpor
Menambahkan kemampuan untuk mengimpor sebagian besar objek yang diekspor
Menambahkan fungsionalitas terbatas untuk mengonversi objek antara berbagai versi zabbix (seperti dalam kasus kami)

Impor didukung hampir secara eksklusif oleh penciptaan objek baru. Jika suatu objek ada, itu tidak akan diubah. Ini memungkinkan kami untuk menjaga kompleksitas kode setidaknya dalam beberapa kerangka kerja, menghemat waktu dan secara dingin meningkatkan kecepatan kerja - ketika mengimpor ribuan objek. Menggunakan impor sangat sederhana:

./zabbix-import.py /path/to/file.yaml

(Diasumsikan bahwa parameter pemantauan target ditentukan dalam variabel lingkungan, untuk lebih jelasnya, lihat --help output)

Secara umum, Anda dapat menentukan jumlah input file YAML - dan semuanya akan diproses. Tetapi dengan mempertimbangkan bahwa ada banyak ketergantungan antara objek, lebih masuk akal untuk mengimpor objek jenis demi jenis, dimulai dengan yang paling sederhana dan paling dasar. Plus, jika Anda mengimpor satu objek dari satu file, mungkin masuk akal untuk secara spesifik menentukan jenisnya untuk mempercepat impor sedikit - tidak semua cache dimuat, tetapi hanya yang diperlukan.

Dengan demikian, dua repositori muncul di hitlab kami dengan pemutakhiran YAML yang diperbarui secara berkala dari dua versi pemantauan, saat ini dan yang baru. Dan, tentu saja, kemampuan untuk memulihkan hampir semua objek pemantauan kapan saja.

Memantau penyebaran dan migrasi itu sendiri secara berkelanjutan

Sebagai hasilnya, kami sampai pada kesimpulan bahwa gitlab sesuai jadwal meluncurkan pipa pada repositori pemantauan baru, yang, secara bertahap, mengimpor satu jenis objek secara hierarkis satu demi satu dari pemantauan lama. Hal ini memungkinkan kami untuk mengimpor sebagian besar objek dan memberikan waktu kepada tim administrator kami untuk dengan tenang memperbaiki masalah yang keluar - dan mereka tidak menumpuk begitu banyak selama bertahun-tahun. Objek "Ekstra" tidak dihapus.

Masalah dengan kata sandi pengguna - mereka juga diekspor / diimpor, tetapi kata sandi acak diberikan selama pembuatan - dapat diselesaikan dengan mengubah dump SQL tabel dengan kredensial pemantauan saat ini menjadi pernyataan SQL untuk menetapkan kata sandi yang benar dalam pemantauan baru.

Agar tidak menerima porsi tugas ganda selama operasi paralel, semua tindakan dalam pemantauan baru segera dimatikan dan tidak lagi dihapus.

Jadi, peralihannya cukup mudah dan turun ke poin-poin berikut:

hapus semua host di pemantauan baru (beberapa skrip di atas API ditulis untuk ini)
tarik SCM untuk memperbarui versi zabbix-proxy dan mengalihkan proxy ke server baru
tunggu impor host dari dump pemantauan lama
beralih catatan DNS

(rencana disingkat untuk mempermudah)

Apa selanjutnya

Tentu saja, kodenya tidak sempurna dan tidak terlalu indah. Itu tidak mengimpor semuanya, khususnya, ada masalah dengan beberapa templat - cari FIXME dalam kode. Tapi itu sudah cukup bagi kami. Mungkin garpu ini bermanfaat bagi orang lain. Ekstensi logis adalah pengembangan operasi serupa dari utilitas Terraform , ketika pemantauan target sepenuhnya dikurangi menjadi bentuk yang ditentukan, misalnya, oleh direktori dengan dumps YAML. Termasuk dengan pengurangan fasilitas yang ada ke bentuk yang diinginkan.

Ini akan memungkinkan Anda untuk dengan tenang menunggu dukungan HA "asli" di zabbix, memiliki dua server, pengaturan disinkronkan di antara mereka secara otomatis. Sekarang Anda harus menyimpan replika, proksi, dan menulis skrip.

Kamu datang?

Setelah mempelajari bahan-bahan konferensi dan pertemuan, peta jalan resmi, pelacak kesalahan dan pengalaman komunikasi pribadi dengan pengembang zabbix, tampaknya mereka benar-benar memahami situasi mereka sekarang. Ketika zabbix dimulai, penulis tidak memikirkan tentang IaC sembari memecahkan masalah mereka. Satu dekade kemudian, produk tersebut matang dan berkembang. Sisi sebaliknya dari kesuksesan adalah massa klien perusahaan, yang pemantauannya memecahkan masalah mereka. Dan siapa yang tidak terlalu suka revolusi. Dalam kondisi modern, mereka, di satu sisi, menentang menghancurkan segalanya dan mulai dari awal. Di sisi lain, mereka kadang-kadang kurang memiliki kemampuan pemantauan dan melihat "ke samping", tidak lupa untuk menyuarakan Wishlist ke pengembang Zabbix. Perusahaan tidak akan mengambil risiko mereka, meskipun ada simpati untuk pemuda yang baru, nyaman, modis,.

Kami tidak akan melihat prometheus baru yang benar dari Zabbix dalam waktu dekat. Tidak peduli bagaimana saya mau. Tetapi pekerjaan ini jelas sedang terjadi - dan jika Anda, seperti zabbix, teliti dan sabar, masa depan juga mengharapkan masa depan tanpa awan.

Bagaimana kami memperbarui Zabbix