Haruskah Saya Tetap Menggunakan Zabbix Di AWS?

Pemantauan Amazon EC2

Zabbix memiliki pangsa pasar yang tinggi sebagai alat pemantauan OSS terintegrasi.Meskipun telah digunakan secara luas di lingkungan di lokasi, ada banyak contoh Zabbix yang digunakan di lingkungan AWS.Terlepas dari kenyataan bahwa AWS juga memiliki layanan pemantauan seperti Amazon CloudWatch, mengapa Anda harus menggunakan Zabbix?Bagian ini menjelaskan manfaat pemantauan instans EC2 dan instans lainnya, serta proses konfigurasi.

Mengapa menggunakan Zabbix daripada Amazon CloudWatch?

Di lingkungan AWS, semua infrastruktur dioperasikan oleh AWS, tetapi Anda harus bertanggung jawab atas pengoperasian instans Amazon EC2 itu sendiri dan aplikasi yang dibangun di Amazon EC2. Dengan kata lain, Anda harus memantau aplikasi untuk memastikan bahwa aplikasi tersebut beroperasi dengan benar, dan Anda harus mengambil tindakan saat terjadi masalah.Zabbix adalah kandidat yang baik untuk alat pemantauan semacam ini.

Zabbix memiliki keunggulan karena dapat memantau tidak hanya di tempat. Tetapi juga cloud dan lingkungan virtual secara terintegrasi.

Sedangkan Amazon CloudWatch standar terbatas untuk memantau sumber daya AWS (CPU, memori, dll.), Zabbix memungkinkan Anda untuk memantau bahkan status aplikasi Anda secara detail.

Berikut ini adalah daftar keunggulan lain dari Zabbix.

Pemantauan lingkungan terintegrasi dengan beberapa akun AWS

Amazon CloudWatch melakukan pemantauan per akun AWS.Zabbix dapat memantau lingkungan beberapa akun AWS, yang dapat memantau sistem bisnis yang terdiri dari beberapa akun.Itu juga dapat mendeteksi anomali tidak hanya dengan peringatan sederhana berdasarkan ambang batas, tetapi juga dengan beberapa ambang batas dan kondisi dalam kombinasi. 

Itu dapat dikonfigurasi dengan pemberitahuan rinci agar sesuai dengan kondisi operasi yang sebenarnya

Amazon CloudWatch dapat memberi tahu Anda dengan pesan jika terjadi anomali.Misalnya, jika sistem Anda sedang dalam pemeliharaan, Anda tidak perlu diberi tahu melalui pesan.Di sinilah Zabbix memungkinkan Anda untuk mengkonfigurasi kasus ini dengan cara yang memungkinkan Anda untuk menyembunyikan pesan yang tidak diinginkan.Dengan cara ini Anda dapat memastikan bahwa Anda hanya diberi tahu ketika ada sesuatu yang benar-benar salah yang perlu ditangani.

Tidak ada periode retensi untuk metrik (log pemantauan)

Dengan Amazon CloudWatch, metrik dapat disimpan hingga 15 bulan.Selain itu, Anda hanya dapat menyimpan metrik setiap jam selama 15 bulan, dan jika interval pemantauan disetel ke kurang dari 60 detik, Anda hanya dapat menyimpannya selama maksimal 3 jam.Zabbix memungkinkan penyimpanan metrik jangka panjang tanpa mengubah perincian informasi.

Cara memantau lingkungan AWS dengan Zabbix

Jika Anda ingin menggunakan Zabbix di AWS, Anda perlu membuat instans Amazon EC2 dan DB dan menginstal Zabbix di dalamnya.Setelah instalasi, proses konfigurasi Zabbix pada dasarnya sama dengan proses on-premise, hanya saja Anda perlu mengatur yang berikut ini

1. Akun pengguna (selain pengguna Admin Zabbix, Anda perlu membuat pengguna untuk penggunaan produksi)
2. Agen host Zabbix (menentukan dari mana data dikumpulkan)
3. Item (mengatur data apa yang akan dikumpulkan)
4. Pemicu (menentukan keadaan data yang tidak normal)
5. Tindakan (mendefinisikan tindakan yang akan diambil ketika terjadi kesalahan)

Selain itu, Anda dapat mengonfigurasi pengaturan khusus AWS, seperti membuat pengguna di AWS IAM dengan izin yang diperlukan untuk Zabbix, yang akan memungkinkan Zabbix memantau aplikasi dan aspek lain dari lingkungan AWS Anda.

Gunakan alat yang tepat untuk kebutuhan pemantauan Anda

Tidak semua sistem perusahaan beroperasi secara terpisah, tetapi banyak sistem yang dihubungkan bersama untuk bertukar data dan memastikan konsistensi secara keseluruhan.Dalam lingkungan ini, Zabbix adalah alat yang hebat untuk memantau dan mendeteksi anomali di beberapa server dan sistem.Misalnya, jika aplikasi web berbasis DB memiliki anomali pada server aplikasi web, data dapat dinonaktifkan, misalnya.

Di sisi lain, Zabbix memiliki banyak opsi konfigurasi, jadi Anda harus memutuskan apa yang akan dipantau dan bagaimana, dan kondisi apa yang tidak normal.

Di sisi lain, Zabbix memiliki banyak pengaturan, jadi Anda harus mendesain operasi dengan tepat apa yang harus dipantau dan apa yang harus dilakukan, dan apa yang harus dilakukan. Tentu saja, untuk sistem kritis, desain seperti itu penting, namun, untuk sistem yang relatif sederhana, seperti "jika suatu proses berhenti, mulai ulang saja", tidak ada yang cocok untuk pemantauan Zabbix.SIOS AppKeeper adalah solusi yang baik untuk kasus seperti itu, karena ia memantau layanan (proses) dari aplikasi yang berjalan pada instans EC2, dan memulai ulang aplikasi jika mendeteksi masalah. Ini memungkinkan pemantauan dan pengoperasian yang sederhana.

Tentu saja, tidak “wajib” menggunakan Zabbix di setiap sistem.Dengan menggunakan alat yang tepat untuk setiap jenis pemantauan, Anda akan dapat mengoperasikan sistem Anda dengan lebih efisien.

Tambahkan SIOS AppKeeper ke operasi pemantauan dan pemulihan EC2 Anda.

Direproduksi dari SIOS

Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi

Pahami pasar cloud

Sejumlah firma analis memperkirakan jumlah penerapan aplikasi, database, dan solusi yang terus meningkat di cloud. Menurut Gartner, perusahaan "beralih ke cloud dengan kecepatan yang men^[1]ingkat". Faktanya, Gartner dan analis lainnya memperkirakan laju migrasi dan penerapan cloud akan terus meningkat, sebagian besar didorong oleh laju inovasi di cloud. Dalam artikel TechTarget oleh Kurt Marko, dari MarkoInsights, Marko mencatat bahwa laju inovasi yang "dilakukan di cloud kemungkinan tidak dapat direplikasi di tempat karena sifat cloud publik terkelola yang elastis, dapat diskalakan, dan sesuai permintaan. jasa."

Kami melihat semakin banyak perusahaan yang selama ini menggunakan cloud hanya untuk aplikasi DevOps dan database yang tidak penting untuk bisnis mereka, kini memindahkan aplikasi, ERP, dan database misi penting yang memerlukan perlindungan ketersediaan tinggi ke cloud.

Jika Anda sedang mempertimbangkan untuk pindah ke cloud – dan sepertinya memang demikian – ada beberapa kunci yang perlu dipahami saat Anda membutuhkan ketersediaan tinggi.

Biasakan diri Anda dengan opsi ketersediaan tinggi cloud

Untuk merencanakan solusi ketersediaan yang tepat untuk cloud atau penerapan cloud hybrid, pertimbangkan apa saja poin masalah terkait dengan ketersediaan (99,9% waktu aktif) dan ketersediaan tinggi (99,99% waktu aktif). Anda juga perlu memahami opsi yang tersedia untuk ketersediaan tinggi dengan memperhatikan rencana Anda untuk bermigrasi ke cloud. Analis dan pakar terkemuka menyarankan untuk mencari solusi yang tidak hanya akan mengurangi dan mengurangi rasa sakit saat memigrasi beban kerja Anda, tetapi juga akan memberikan pendekatan yang seimbang dan komprehensif untuk ketersediaan di seluruh masa pakai arsitektur cloud Anda. Perhatikan, sebaiknya pertimbangkan juga solusi yang dapat memberikan perlindungan dan ketersediaan tinggi untuk sebagian dari beban kerja Anda yang suatu hari dapat dikembalikan dari cloud ke lingkungan lokal Anda.

Berikut sepuluh hal yang perlu dipertimbangkan saat membandingkan opsi ketersediaan Anda di cloud:

1. Metode penerapan. Apakah mungkin untuk menerapkan solusi ketersediaan yang Anda pertimbangkan menggunakan gambar, CLI, UI, atau solusi berulang lainnya seperti template pembentukan awan atau skrip paket.

2. Persyaratan sistem.Terutama, pertimbangkan persyaratan sistem operasi (OS), disk, CPU, dan memori.

3. Lingkungan penerapan.Apakah opsi ketersediaan Anda hanya mendukung lokal, satu atau beberapa cloud publik, atau dapatkah mereka mendukung campuran, dan / atau penyebaran cloud hybrid. Apakah ada penawaran SaaS juga tersedia?

4. Luas dan kedalaman perlindungan aplikasi. “Breadth” artinya jenis aplikasi, database, front-end, jaringan, dan komponen infrastruktur apa yang dapat dilindungi?Apakah ada kerangka kerja yang fleksibel untuk menambahkan aplikasi dan varian baru? Arti “Kedalaman” – apakah solusinya sadar aplikasi – dan mampu mempertahankan praktik terbaik khusus aplikasi selama proses failover / failback aplikasi?

5. Persyaratan kinerja. Kami sering memikirkan RTO dan RPO, tetapi bagaimana dengan kinerja lain yang membutuhkan solusi Anda. Akankah solusi ketersediaan Anda menyebabkan masalah kinerja saat failover?

6. Persyaratan ketahanan.Seberapa besar cluster yang dapat didukung oleh solusi ketersediaan ?, Berapa banyak kesalahan dan kegagalan yang dapat dideteksi dan dipulihkan. Bagaimana replikasi akan ditangani sambil menjaga metadata tetap sinkron?

7. Dukungan dan pemeliharaan.Apakah vendor ketersediaan memiliki pengalaman dengan berbagai macam kebutuhan dan konfigurasi ketersediaan? Apakah mereka memiliki umur panjang, dan sistem pendukung yang dirancang untuk mengatasi masalah yang mungkin melampaui solusi mereka? Dapatkah mereka membantu Anda meminimalkan gangguan dan waktu henti yang direncanakan selama pengelolaan dan pemeliharaan sistem Anda (tambalan, peningkatan versi, dan pemeliharaan umum).

8. Total biaya kepemilikan.Ada seluruh industri dan layanan yang didedikasikan untuk membantu Anda menghitung total biaya kepemilikan, jadi kami tidak akan membahasnya di sini. Singkatnya, perhitungan Anda akan unik untuk organisasi, penyedia cloud, aplikasi, dan tim TI Anda. Anda harus mempertimbangkan apakah vendor solusi ketersediaan Anda dapat membantu Anda mengidentifikasi strategi untuk menghemat penggunaan, lisensi, dan biaya lainnya? Apakah solusi mengotomatiskan tugas manual, mengurangi waktu kerja TI?

9. Perizinan dan model harga.Bagaimana Anda menggunakan biaya perangkat lunak? Apakah ada biaya langganan, model langganan, penawaran bayar sesuai pemakaian, bawa lisensi Anda sendiri (BYOL), atau kombinasi opsi fleksibel. Bagaimana Anda akan mengaktifkan lisensi produk?Apakah ada server lisensi, layanan lisensi, atau kunci terenkripsi berdasarkan detail penerapan mesin virtual, seperti alamat, nama host, alamat MAC.

10. Dampaknya pada staf TI.Berapa banyak pelatihan dengan solusinya yang dibutuhkan? Berapa banyak intervensi manual yang akan dibutuhkan jika terjadi peristiwa kegagalan aplikasi atau bencana? Apakah ini memerlukan skrip khusus yang perlu dipertahankan? Siapa yang akan bertanggung jawab atas pemeliharaan berkelanjutan?

Pertimbangkan manfaat dan kompromi

Seperti setiap keputusan penting, Anda perlu memahami pengorbanan Anda dan memilih keseimbangan terbaik untuk memenuhi kebutuhan Anda. Misalnya, baru-baru ini saya meminta seorang teman untuk merekomendasikan sepatu jalan yang bagus. Saya membeli sepasang yang dia ocehkan – memperhatikan betapa ringannya mereka, seberapa kuat dan tahan lama kainnya, dan betapa gayanya mereka.Saya pergi untuk lari jarak jauh pertama saya di dalamnya, dan saya segera menyumbangkan sepasang sepatu “satu lari” pertama saya setelah itu. Ketika saya pergi ke 'Fleet Feet' untuk mendapatkan pendapat ahli, saya mendapatkan sepatu yang lebih berat, dengan kain yang lebih bernapas (juga kurang tahan lama), dan tingkat keburukan yang tak tertandingi. Saya melakukan tradeoff antara penampilan dan fungsi yang sesuai dengan kebutuhan dan anggaran saya.

Seperti sepatu lari, tidak ada solusi peluru perak yang sesuai untuk setiap perusahaan, setiap aplikasi, setiap database, dan setiap server dan arsitektur yang memungkinkan. Anda secara resmi bebas untuk berhenti mencarinya. Alih-alih, selesaikan aktivitas menimbang trade-off untuk menentukan apa yang tepat untuk kebutuhan perusahaan Anda. Pikirkan pengorbanan Anda. Misalnya, jika Anda yakin akan menjadi toko Microsoft sepenuhnya, pentingnya dukungan GCP dan AWS seharusnya sedikit lebih rendah dalam proses evaluasi Anda.

Pertimbangkan dinamika infrastruktur TI Anda

Pikirkan secara holistik tentang ketersediaan di seluruh infrastruktur TI Anda – baik di lokasi maupun di cloud. Alasan untuk melakukannya paling baik dijelaskan dengan analogi lain. Pada tahun 2018, saya menjadi koordinator untuk program penjangkauan memberi makan para tunawisma dan kelaparan di Columbia, Carolina Selatan. Kelompok kami bertemu sekali seminggu untuk menyajikan makanan dan pesan harapan kepada lebih dari 100 pria, wanita dan anak-anak. Saat kami mempertimbangkan untuk memperluas – menambahkan lebih banyak hari dalam seminggu, lebih banyak jam, atau layanan tambahan, kami harus memikirkan jauh di luar persyaratan penjadwalan sederhana. Mengetahui bahwa kami memberikan layanan penting kepada klien yang bergantung pada kami, kami harus mempertimbangkan semua faktor yang memengaruhi kemampuan kami untuk memberikan layanan tersebut secara konsisten untuk jangka panjang, seperti: biaya, usia anggota tim kami, kewajiban luar , metode alternatif untuk mencapai tujuan kami, faktor risiko, dan dinamika lain dalam organisasi induk kami.

Saat Anda memilih solusi, setelah Anda memahami pasar, membiasakan diri dengan opsi, dan menimbang kompromi, langkah terakhir adalah memperhitungkan berbagai dinamika lain di lingkungan Anda secara keseluruhan. Akankah solusi tersebut memenuhi kebutuhan bisnis Anda secara keseluruhan? Akankah data penting Anda dilindungi dari kehilangan? Akankah produktivitas pengguna akhir Anda dilindungi dari waktu henti? Pelatihan apa yang akan diperlukan untuk pindah ke cloud dan bagaimana hal itu akan memengaruhi kemampuan Anda untuk mengelola atau mempertahankan solusi yang Anda pilih? Peran TI apa yang akan ditambahkan, dihapus, atau diubah dalam perjalanan cloud Anda?Akankah tanggung jawab untuk ketersediaan aplikasi berpindah ke pemilik lini bisnis mana pun? Dan bagaimana perubahan dalam tanggung jawab, atau pembentukan tim akan meningkatkan atau menurunkan potensi kesuksesan Anda secara keseluruhan. Pertimbangkan apakah tim Anda perlu mengambil pendekatan langkah demi langkah, memigrasi beban kerja yang lebih kecil terlebih dahulu.

Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah melihat berbagai macam perencanaan migrasi cloud – beberapa langsung yang lainnya sangat mengganggu. Dalam satu contoh, perpindahan pelanggan ke cloud sangat kontroversial karena manajemen melihatnya sebagai peluang untuk menghilangkan seluruh departemen TI. Saya tidak menyarankan Anda untuk bermain politik, tetapi Anda harus menyadari semua faktor yang berperan dalam proyek kompleks ini.

Bermigrasi ke cloud diharapkan dapat menghemat uang, waktu, dan sumber daya sambil meningkatkan ketersediaan dan ketahanan. Apa pun cloud yang Anda pilih, pastikan Anda mempertimbangkan tip berikut dan memilih solusi ketersediaan terkait yang memberi Anda fleksibilitas untuk memberikan perlindungan yang Anda butuhkan dalam konfigurasi yang Anda inginkan.

Pelajari lebih lanjut tentang opsi ketersediaan tinggi cloud dengan SIOS.

– Cassius Rhue, Wakil Presiden Pengalaman Pelanggan, SIOS

Direproduksi dengan izin dari SIOS