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

Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik

Tips dari film – Multiplisitas

Multiplicity adalah film komedi fiksi ilmiah Amerika tahun 1996 yang dibintangi Michael Keaton sebagai Doug Kinney, seorang pekerja konstruksi sibuk yang berjuang untuk menyediakan waktu bagi keluarganya dan pekerjaannya yang menuntut. Saat seorang ilmuwan menawarkan untuk mengkloningnya, Doug setuju untuk mempermudah pemenuhan jadwal dan komitmennya. Tapi kemudian salinan dirinya mulai membuat salinan dari dirinya sendiri. Pada saat salinan terakhir dibuat, intinya sudah jelas. Kloning mungkin tidak semudah yang diharapkan, atau setidaknya disertai dengan beberapa peringatan, tantangan, dan efek samping yang kuat. Episode orisinal Star Trek yang terkenal "Trouble with Tribbles" mengilustrasikan hal serupa.

Seperti kloning di layar besar (atau kecil), kloning di cloud adalah alat yang hebat, tetapi bukannya tanpa tantangan.

Tips tentang cara mendapatkan hasil yang lebih baik saat Anda mengkloning ketersediaan di cloud

1. Menggandakan sistem operasional

Ini terdengar jelas, tetapi saya telah melihat itu terjadi lebih dari sekali di lingkungan perusahaan yang nyata. Jika Anda mengkloning sistem non-fungsional Anda, klon tersebut akan sama-sama tidak berfungsi dan bermasalah saat Anda memulihkannya. Pastikan bahwa klon yang Anda buat berasal dari sistem operasional dan fungsional.

2. Sinkronkan data ke disk dan sinkronkan ulang saat pemulihan

Integritas sistem file sangat penting. Jika Anda tidak memastikan aplikasi dan / atau VM Anda dalam keadaan konsisten, sebagian besar vendor tidak akan menjamin gambar yang dibuat yang dihasilkan. Karena snapshot hanya menangkap data yang telah ditulis ke volume Anda pada saat perintah snapshot dikeluarkan, ini mungkin mengecualikan data apa pun yang telah di-cache oleh aplikasi atau sistem operasi apa pun. Memastikan data telah disinkronkan dengan benar ke sistem file merupakan langkah penting, dan sangat penting dalam lingkungan cluster.

Integritas sistem file juga penting untuk diingat saat Anda memulihkan dari gambar. Jika Anda menggunakan replikasi data dan Anda memulihkan gambar sebagai sumber atau target di cluster, pastikan kedua node sinkron adalah yang terpenting. Kegagalan untuk melakukannya dapat menyebabkan kesalahan sistem file pada failover atau peralihan, atau bahkan potensi kehilangan data. Klon ketersediaan di cloud untuk mendapatkan hasil yang Anda inginkan.

3. Hentikan instance Anda

Banyak lingkungan tidak mengharuskan Anda menghentikan instans untuk membuat gambar, dan beberapa, seperti AWS akan melakukan langkah mematikan node sebelum membuat salinan.Namun, banyak alat dan situs merekomendasikan untuk memastikan aplikasi dihentikan dan akses sistem file disinkronkan dengan benar untuk menghindari kerusakan, kehilangan integritas, atau membuat gambar yang mengalami masalah saat memulai, menghentikan, atau menjalankan aplikasi yang diinstal.

4. Beri label semua yang ada di cloud (node, disk, NIC, semuanya)

Saat membuat klon adalah operasi gratis, disk dan komponen yang dihasilkan biasanya tidak.AWS menyatakan, misalnya, Anda "dikenai biaya untuk snapshot hingga Anda membatalkan pendaftaran gambar dan menghapus snapshot." Ketika sesuatu tidak diberi label, mengetahui apa yang digunakan atau tidak digunakan dan mengapa hal itu dibuat bisa menjadi masalah. Itu juga menjadi sasaran ingatan sekilas atau konsentrasi anggota tim yang ada.Beri label semuanya.

5. Sering-seringlah memangkas klon dan snapshot (penghematan biaya dan penghematan sakit kepala)

Memangkas snapshot dan klon lama tidak hanya baik untuk penghematan biaya, tetapi juga baik untuk mengurangi sakit kepala.Snapshot yang lebih lama berisiko memunculkan kembali kerentanan yang telah diatasi atau diselesaikan di salinan yang lebih baru.Sebagai Wakil Presiden Pengalaman Pelanggan di SIOS Technology Corp., Saya melihat konsekuensinya secara langsung saat kami bekerja dengan pelanggan yang memulihkan dari snapshot. Mereka mengalami beberapa masalah saat memulai ulang aplikasi. Setelah pemecahan masalah, kami memutuskan bahwa klon menjalankan perangkat lunak keamanan versi lama. Kredensial dan metadata yang disimpan dalam profil pengguna tidak lagi disinkronkan dengan data aplikasi aktual yang disimpan di drive data yang dipasang secara eksternal.

6. Batasi atau batasi kloning kloning di cloud

Terakhir, tidak semua yang Anda lakukan di cloud perlu di-clone. Pertimbangkan untuk membatasi jenis beban kerja yang akan Anda klon dan batasi jumlah atau peran yang dapat membuat klon di lingkungan Anda.

Dalam film tersebut, ketika klon Doug memicu serangkaian duplikasi mereka sendiri, Doug (Michael Keaton) yang sudah kewalahan dipaksa untuk mengerahkan energi ekstra untuk mengelola banyak klonnya sambil mencoba menyembunyikan kekacauan yang ia buat dari istrinya. Mencapai ketersediaan klon di cloud dengan hasil yang lebih baik tidaklah sulit. Kloning dengan hati-hati untuk menghindari membuat lebih banyak pekerjaan dan menambah risiko dari alat yang seharusnya membuat pekerjaan Anda lebih mudah dan lingkungan Anda lebih aman.

– Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan

Direproduksi dari SIOS

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

SIOS terus memperbarui produk kami untuk memenuhi kebutuhan pelanggan yang terus berkembang akan ketersediaan tinggi untuk aplikasi penting. Kami sangat senang mengumumkan ketersediaan umum SIOS Protection Suite untuk Linux versi 9.5.1!Fitur rilis ini menambahkan dukungan untuk lebih banyak jenis platform dan penyempurnaan pada fitur antarmuka baris perintah kami.

• • • Dukungan untuk sistem operasi dan platform berikut: VMware Vsphere 7, Red Hat Enterprise Linux (RHEL) 8.2, Oracle Linux 8.2, CentOS 8.2, SUSE Linux Enterprise (SLES) 12 SP5, RHEL 7.8, CentOS 7.8, Oracle Linux 7.8, SLES 15 SP2
    • CLI Auto Install dengan skrip pengaturan yang ditingkatkan – untuk implementasi yang lebih cepat dan mudah
    • Dukungan CLI yang diperluas untuk ARK dan Kloning – memungkinkan penerapan beberapa klaster yang sederhana dan konsisten

Direproduksi dengan izin dari SIOS

Direproduksi dari SIOS