| Desember 11, 2020 |
Menggunakan Datadog untuk Amazon EC2 Monitoring? Sandingkan dengan SIOS AppKeeper untuk Remediasi Otomatis |
)| {
“InstanceId”: “{{EC2 Instance ID}}”, “Nama”: “nginx” } |
Header Khusus: Centang kotak dan masukkan yang berikut ini
| { “Jenis konten”: “application / json”, “Accept”: “application / json”, "Appkeeper-integration-token": "{{Dapatkan AppKeeper token integrasi eksternal Token yang diperoleh di}}" } |
Setelah selesai, tekan "Simpan".
Langkah Delapan: Menghubungkan AppKeeper ke tes Synthetics
Selanjutnya, saya harus mengonfigurasi AppKeeper (integrasi Webhooks terdaftar) untuk dipanggil ketika peringatan pemantauan Synthetics terjadi.
Buka kasus pengujian yang Anda siapkan di "Mengonfigurasi Pemantauan Sintetis dengan Datadog" dari Pemantauan UX> Pengujian Sintetis di menu.
Pilih "Edit detail pengujian" dari kotak roda gigi kanan atas dan masukkan nilai berikut di "5. Beri tahu Tim Anda ”untuk menyimpan perubahan.
| @webhook – {{Nama integrasi Webhook di Datadog}} |
※ Anda dapat mengatur "renotify jika monitor belum diselesaikan".Anda dapat mencoba lagi jika AppKeeper gagal memulihkan untuk pertama kalinya.Ini tidak diperlukan untuk tujuan pengujian, tetapi kami menyarankan Anda untuk mengaturny[10 minutes]a ke (interval minimum).
Penyiapan sekarang selesai.
Langkah Sembilan: Konfirmasikan integrasi dengan menjalankan tes lagi
Saya kemudian mengonfirmasi bahwa AppKeeper akan memulihkan server web jika Datadog mendeteksinya tidak aktif.
Buka kasus uji pemantauan Synthetics yang baru saja Anda siapkan dari UX Monitoring> Synthetic Tests di Datadog.
Klik "Lanjutkan Tes" di pojok kanan atas dan aktifkan pemantauan Synthetics.
Sekarang Datadog akan melakukan pemantauan Synthetics secara berkala.
Hasil Tes menunjukkan bahwa server berhasil diakses.
Selanjutnya, saya membuat server web pseudo-failure untuk menguji remediasi otomatis AppKeeper.
Karena sulit untuk menyebabkan kegagalan yang nyata, saya menghentikan layanan dan membuat situasi di mana Anda tidak dapat melihat halaman web.Untuk melakukan ini, saya terhubung ke instance EC2 di mana server Nginx diinstal menggunakan SSH dan menghentikan Nginx.
| sudo systemctl menghentikan nginx |
Setelah menunggu sebentar, Datadog mendeteksi bahwa server web tidak dapat diakses lagi.
Halaman Tes Sintetis di Datadog juga menunjukkan bahwa kasus pengujian telah gagal.
Jika kasus uji gagal, Datadog akan memberi tahu AppKeeper bahwa pemantauan Synthetics telah gagal.
Ketika AppKeeper menerima notifikasi, secara otomatis akan mencoba untuk memulai ulang Nginx.
Jadi, jika Anda menunggu sebentar, Anda akan melihat bahwa pemeriksaan pemantauan Sintetik Datadog akan lulus lagi.
Selain itu, jika Anda masuk ke dasbor AppKeeper, Anda akan melihat bahwa pemulihan telah dilakukan.
–
Dalam latihan ini saya menggunakan server web (Nginx) sebagai contoh untuk mengotomatiskan proses mendeteksi kegagalan dengan Datadog dan memulihkan layanan dengan AppKeeper.
Otomatisasi serupa dapat dicapai dengan mengintegrasikan Datadog dengan EventBridge dan Lambda atau dengan membuat skrip khusus.
Namun, jika Anda sering menambahkan instans target atau memulai ulang berbagai layanan, biaya dan kerumitan pemeliharaan EventBridge dan Lambda atau skrip akan meningkat.
Integrasi AppKeeper yang telah terbukti dengan Datadog dan kemudahan untuk menambahkan instance target ke aplikasi Anda membuatnya mudah untuk menambahkan otomatisasi ke lingkungan DevOps Anda untuk mengurangi waktu henti.
Jika saat ini Anda menggunakan Datadog dan ingin mencoba AppKeeper's Restart API, harap daftar dulu untuk uji coba gratis 14 hari kami di sini (Anda dapat membeli langganan setelah menginstal uji coba gratis).Kemudian klik di sini untuk meminta uji coba gratis. Kami akan memandu Anda melalui proses dan memberi Anda token evaluasi gratis untuk membantu Anda memulai.
Ajukan permohonan token evaluasi
Terima kasih.Saya harap Anda akan mengambil kesempatan ini untuk mempelajari lebih lanjut tentang SIOS AppKeeper, yang menyediakan pemantauan otomatis dan pemulihan aplikasi yang berjalan di EC2.
– Tatsuya Hirao di tim teknis Teknologi SIOS.
Direproduksi dengan izin dari SIOS
5 Tanda Bahwa Diperlukan Lebih Dari Satu Posting Blog Untuk Memperbaiki Ketersediaan Tinggi Anda
5 Tanda Bahwa Diperlukan Lebih Dari Satu Posting Blog Untuk Memperbaiki Ketersediaan Tinggi Anda
Tanda-tandanya ada di sana. Lampu peringatan berkedip.Di dalam perut Anda, Anda bisa merasakannya. Mungkin Anda tidak bisa tidur.Masalah Anda dengan ketersediaan tinggi sangat dalam. Tapi, mungkin Anda kurang yakin.
1. Jika menurut Anda cloud SLA adalah semua yang Anda butuhkan untuk ketersediaan tinggi
Solusi cloud telah memberikan kemajuan besar dalam peningkatan ketersediaan dan ketahanan perangkat keras. Namun, ketersediaan tinggi aplikasi membutuhkan lebih dari sekadar memilih hypervisor atau penyedia cloud yang tepat. Strategi Anda untuk ketersediaan tinggi tidak dapat berhenti dengan SLA yang disediakan oleh cloud atau penyedia virtualisasi. Seperti dikutip oleh Wired, "Penghentian Amazon selama hampir empat hari pada April 2011 tidak melanggar SLA EC2 Amazon, yang dijelaskan oleh FAQ," menjamin 99,95% ketersediaan layanan dalam suatu Wilayah selama periode 365 yang tertinggal. " Dalam artikel DZone ini, David Bermingham kami menjelaskan secara mendetail perbedaan antara cloud SLA dan ketersediaan aplikasi. Jika Anda menginginkan infrastruktur yang sangat tersedia, itu harus mencakup pemantauan, pemulihan, dan ketahanan pada lapisan data dan aplikasi juga.
2. Jika Anda hanya menggunakan pengelompokan ketersediaan tinggi yang disertakan dengan sistem operasi sumber terbuka Anda
Jika demikian, maka kemungkinan Anda tidak memilih database Anda berdasarkan apa yang dibundel dengan OS, jadi mengapa Anda memilih solusi HA berdasarkan kriteria itu saja. Alat yang dibundel sangat membantu dalam memberikan jaminan, kemungkinan, dan kemampuan ekstra. Namun, terlepas dari kemudahan akses, alat yang dibundel dan perangkat lunak pengelompokan OS tidak selalu mampu memenuhi persyaratan SLA, RPO, RTO, dan ketersediaan Anda. Jika perusahaan Anda memiliki kombinasi Sistem Operasi, tim Anda kemungkinan akan membutuhkan bantuan untuk menjelajahi berbagai alat dan memahami bagaimana mereka berintegrasi. Ini seperti memilih gunting tanaman dan mendorong mesin pemotong rumput ke kiri di tepi jalan untuk membentuk "Azalea" di lubang ke-13 par 5 (di Augusta). Kedua mesin pemotong rumput dirancang untuk memotong rumput, tetapi berapa banyak waktu yang Anda miliki? Bagaimana Anda akan menangani kompleksitas? Mana yang akan Anda percayai? Strategi Anda untuk ketersediaan tinggi membutuhkan lebih dari sekadar mempertimbangkan kemudahan dari apa yang dibundel dengan OS, jika tidak, Anda akan menjalankan MySQL alih-alih SAP HANA.
3. Jika menurut Anda lisensi aplikasi perusahaan, seperti SQL Enterprise atau Oracle Enterprise, sama dengan ketersediaan tinggi perusahaan
Selain peningkatan biaya, banyak lisensi aplikasi perusahaan juga meningkatkan kemampuan aplikasi untuk pulih dalam beberapa skenario ketersediaan tinggi. Namun, sangat tidak mungkin seluruh perusahaan Anda didasarkan pada satu aplikasi. Ketersediaan tinggi Anda akan membutuhkan lebih dari sekedar solusi database yang sangat tersedia. Anda akan memerlukan solusi pemulihan dan pemantauan aplikasi tingkat perusahaan dengan dukungan luas untuk semua aplikasi dan database Anda. Selain itu, Anda memerlukan kemampuan untuk mengelola dan mereplikasi tidak hanya data database, tetapi juga aplikasi penting dan data konfigurasi. Ketersediaan untuk satu database atau aplikasi sederhana adalah satu hal – tetapi HA untuk aplikasi multipart yang kompleks dan database pendukung sangat berbeda. Lebih banyak layanan, lebih banyak bagian yang perlu dikoordinasikan, arsitektur yang lebih kompleks untuk diatur, praktik terbaik yang lebih spesifik untuk dipatuhi sebelum, selama dan setelah failover / peralihan. Lebih dari apa yang dibayar lisensi perusahaan Anda.
4. Jika waktu henti Anda bertambah dan waktu kerja Anda menyusut
Laju kehidupan semakin meningkat di berbagai bidang. Kapan terakhir kali tim Anda memulihkan dari cadangan, secara manual memulai ulang aplikasi yang dianggap penting, atau memulai ulang serangkaian mesin virtual atau node yang gagal? Laju peristiwa pemadaman Anda tidak dapat terus melebihi keberlanjutan, atau kemampuan tim Anda untuk bergerak dari pemadaman kebakaran ke pencegahan kebakaran dan pemeriksaan kebakaran. "Anda hanya bisa berlari begitu keras selama ini (Carey Nieuwhof)." Untuk beberapa dari Anda, Anda telah melakukan pemadam kebakaran terlalu lama, dan pemadaman Anda menjadi lebih umum daripada waktu aktif Anda.
5. Jika pengujian failover pertama Anda dilakukan di server produksi
Seorang klien baru-baru ini mengatakan bahwa tidak mungkin menguji setiap kemungkinan skenario bencana. Saat perangkat lunak baru dibuat, diterapkan, diperbarui, dan ditambal, tantangan dalam ketersediaan yang lebih tinggi semakin meningkat. Tapi, data produksi dan live Anda bukanlah tempat untuk mencari tahu apa yang tidak berjalan baik bersama. Dan sementara Go-Live dan Post-Go-Live akan selalu memiliki kejutan, ketidakmampuan untuk benar-benar melakukan failover dan berjalan di node cadangan seharusnya tidak menjadi salah satunya.
Menjelajahi blog dapat memberi Anda tip dan wawasan yang berguna untuk mendefinisikan, mendefinisikan ulang, dan meningkatkan ketersediaan Anda yang lebih tinggi. Tetapi, jika tanda peringatan berbunyi bahwa Anda telah memperdagangkan ketersediaan yang sebenarnya untuk beberapa kemiripan 'cukup', maka itu akan membutuhkan lebih dari satu posting blog, atau menjelajahi setiap posting blog di dunia ketersediaan dalam hal ini, untuk memperbaikinya HA Anda.
– Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan
Direproduksi dengan izin dari SIOS
9 Tanda Anda Memiliki Masalah Ketersediaan Aplikasi
SIOS AppKeeper sekarang tersedia di AWS Marketplace
SIOS AppKeeper sekarang tersedia di AWS Marketplace
Mempermudah penambahan remediasi otomatis ke lingkungan DevOps Anda.
Hari ini kami dengan bangga mengumumkan bahwa solusi SIOS AppKeeper kami sekarang tersedia di AWS Marketplace, katalog digital dengan ribuan daftar perangkat lunak dari vendor perangkat lunak independen yang memudahkan untuk menemukan, menguji, membeli, dan menerapkan perangkat lunak yang berjalan di Amazon Web Services (AWS). Sekarang lebih mudah dari sebelumnya bagi pengguna akhir dan anggota AWS Partner Network (APN) untuk mencoba, memperoleh, dan menerapkan SIOS AppKeeper untuk menambahkan remediasi otomatis ke lingkungan DevOps mereka.Klik di sini untuk melihat AppKeeper di AWS Marketplace.
SIOS AppKeeper terus memantau dan melindungi aplikasi Anda yang berjalan di Amazon EC2. Kami telah menjual AppKeeper di Jepang sejak 2017 dan membawa layanan SaaS ke pasar AS awal tahun ini.Kami membuat AppKeeper sebagai tanggapan atas permintaan yang kami dengar dari pelanggan kami yang pindah ke cloud dan khawatir tentang mengurangi potensi waktu henti sementara berjuang dengan sumber daya yang terbatas. Klik di sini jika Anda ingin melihat video tentang betapa mudahnya menginstal dan menggunakan AppKeeper.
Pemantauan Aplikasi AWS EC2 – SIOS AppKeeper | SIOS
Seberapa sering pengguna Amazon EC2 mengalami waktu henti? Menurut data pelanggan kami, rata-rata pelanggan dengan hanya tiga instans Amazon EC2 mengalami waktu henti setidaknya sebulan sekali.Itu bisa jadi karena kesalahan konfigurasi perangkat lunak, dll.
Melampaui pemantauan aplikasi untuk menawarkan remediasi otomatis
Banyak pengguna AWS menerapkan solusi pemantauan kinerja aplikasi (APM), seperti dari AppDynamics, Datadog, Dynatrace atau New Relic, untuk memantau lingkungan AWS mereka.Tapi ini hanya mengingatkan Anda pada fakta bahwa sesuatu terjadi, dan mengapa itu terjadi. Mereka tidak melakukan apa pun untuk mengurangi waktu henti Anda.
Di situlah AppKeeper berperan. Jika AppKeeper mendeteksi waktu henti dengan layanan aplikasi apa pun yang berjalan di Amazon EC2, AppKeeper akan merespons secara otomatis dengan memulai ulang layanan yang terpengaruh dan me-reboot instans jika perlu. AppKeeper mengatasi 85% kegagalan layanan aplikasi. Mengurangi kebutuhan akan pemantauan atau gangguan outsourcing yang mahal untuk tim TI Anda dengan pemulihan otomatis.Pelajari lebih lanjut tentang otomatisasi APM dari AppKeeper.
Pelanggan AWS yang sudah menggunakan solusi APM dan ingin memperluas fungsionalitas untuk menyertakan remediasi otomatis, jika dan ketika waktu henti Amazon EC2 terdeteksi, dapat memanfaatkan API webhooks AppKeeper untuk berintegrasi dengan solusi APM pilihan mereka.
Mengapa kami memutuskan untuk mendaftarkan SIOS AppKeeper ke AWS Marketplace
Di sini, di SIOS Technology Corporation kami telah memiliki kemitraan strategis dengan Amazon AWS sejak 2014, terutama seputar solusi ketersediaan tinggi SIOS DataKeeper dan SIOS LifeKeeper.Teknologi SIOS adalah APN Advanced Partner hari ini, dan kami berbagi 100 pelanggan bersama.
Sekarang kami memiliki bukti pelanggan untuk keefektifan SIOS AppKeeper (berikut adalah beberapa studi kasus terbaru yang mungkin Anda nikmati), kami ingin mempermudah pelanggan Amazon dan mitra APN untuk mencoba, membeli, dan menggunakan AppKeeper.Menurut banyak perkiraan, ada lebih dari 200.000 pelanggan AWS aktif yang menggunakan perangkat lunak dari AWS Marketplace, yang semuanya memanfaatkan betapa mudahnya AWS Marketplace untuk menemukan, memperoleh, dan menggunakan solusi pelengkap saat mereka melanjutkan perjalanan cloud mereka.
Dan teman-teman kami di Amazon tidak dapat mengatakannya dengan lebih baik: "Karena pelanggan kami memigrasi semakin banyak aplikasi ke cloud, mereka mencari fleksibilitas dalam menyeimbangkan tingkat ketersediaan dengan biaya di semua aplikasi mereka," kata Chris Grusz, Director, AWS Marketplace, Amazon Web Services, Inc. "Kami dengan senang hati menyambut SIOS AppKeeper di AWS Marketplace dan memberikan lebih banyak pilihan kepada pelanggan kami saat perubahan kinerja terjadi."
Pelanggan AWS yang tertarik untuk melindungi aplikasi EC2 mereka dari waktu henti yang tidak perlu sekarang dapat dengan cepat mencoba AppKeeper untuk diri mereka sendiri, dan dapat memperoleh AppKeeper di bawah Paket Diskon Amazon Enterprise mereka, jika mereka sudah memilikinya.Harga untuk SIOS AppKeeper mulai dari hanya US $ 40 per instans, per bulan.
Mitra sekarang mengintegrasikan AppKeeper ke dalam solusi pelanggan mereka
Berbagai mitra sekarang mengintegrasikan AppKeeper ke dalam solusi pelanggan mereka, dan memiliki AppKeeper yang tersedia di AWS Marketplace berarti akan lebih mudah bagi anggota APN untuk mengevaluasi apakah solusi tersebut sesuai untuk bisnis dan pelanggan mereka. Penyedia Layanan Terkelola (MSP) mulai menyertakan AppKeeper ke dalam cara mereka memantau dan mengelola lingkungan AWS pelanggan mereka, sebagai cara untuk mengurangi waktu henti dan biaya operasional mereka sendiri.ISV lainnya mengintegrasikan fungsionalitas remediasi otomatis AppKeeper ke dalam solusi manajemen cloud mereka sendiri, dan AWS Consulting Partner mengemas AppKeeper saat mereka mengembangkan dan menerapkan aplikasi di AWS untuk pelanggan mereka.
Anggota APN yang tertarik untuk mengevaluasi apakah AppKeeper cocok untuk bisnis mereka harus menghubungi kami melalui email di d-yoshioka@us.sios.com.
Kami berharap Anda akan mencoba SIOS AppKeeper untuk diri Anda sendiri (kami memiliki uji coba gratis selama 14 hari dan proses instalasi yang mudah), dan bergabunglah dengan banyak pelanggan yang sekarang santai mengetahui bahwa mereka memiliki remediasi otomatis untuk mengurangi waktu henti Amazon EC2 yang mereka mungkin mengalami.
Otomatisasi APM – Bahan yang Hilang Untuk Solusi Pemantauan Kinerja Aplikasi
Otomatisasi APM – Bahan yang Hilang Untuk Solusi Pemantauan Kinerja Aplikasi
Perusahaan yang pindah ke cloud untuk menghosting aplikasi mereka memahami bahwa meskipun mereka telah mengalihkan hosting aplikasi mereka ke vendor cloud pihak ketiga seperti Amazon Web Services, mereka masih perlu memantau dan mengelola aplikasi tersebut sendiri, biasanya dengan Application Performance Monitoring solusi atau APM. Dengan aplikasi komputasi server-klien kemarin, I.T. departemen memiliki kendali penuh atas server, jaringan, dan lingkungan komputasi pengguna akhir.Namun lingkungan cloud saat ini lebih kompleks, dengan lebih banyak bagian bergerak yang sering kali berada di luar kendali Anda.
Beberapa perusahaan telah memulai transformasi digital, mendorong interaksi pelanggan menjadi aplikasi kritis berbasis web.Sekarang lebih penting dari sebelumnya untuk segera menanggapi masalah kinerja aplikasi dan waktu henti apa pun melalui solusi otomatisasi APM.
Cara Memilih Solusi APM
Banyak perusahaan beralih ke solusi Manajemen Kinerja Aplikasi seperti dari AppDynamics, Datadog, Dynatrace, atau New Relic.Solusi APM harus mengidentifikasi semua hambatan kinerja dalam kode Anda, dan membantu Anda memperbaiki masalah tersebut sebelum pengguna Anda terpengaruh.
Solusi APM yang baik akan memberi tahu Anda apa yang terjadi, mengapa, dan bagaimana mencegahnya terjadi di masa mendatang.Solusi APM akan mengingatkan Anda ketika aplikasi atau sistem yang dipantau memenuhi kondisi tertentu (beban, waktu respons, dll.).Setelah Anda menerima peringatan, Anda harus dapat mengidentifikasi mengapa aplikasi tidak bekerja dengan baik.Berbekal informasi ini, Anda dapat memberi tim pengembangan Anda diagnosis yang sangat mendetail yang akan memungkinkan mereka untuk mengatasi masalah dan mencegahnya terjadi di masa mendatang.
Tetapi bagaimana Anda memilih solusi solusi Pemantauan Kinerja Aplikasi yang tepat?Pencarian cepat di Google untuk "solusi cloud APM" menghasilkan 5.830.000 hasil!Itu bisa sangat membebani siapa pun yang tidak terbiasa dengan ruang tersebut.Untungnya, pencarian Google lainnya juga akan memberi Anda banyak saran dan sumber daya tentang cara memilih solusi APM yang tepat untuk Anda.Anda harus mencari saran pihak ketiga non-vendor untuk membantu Anda menyusun persyaratan Anda dan mengembangkan daftar pendek pilihan yang memenuhi persyaratan tersebut.Gartner telah mengamati kategori ini selama beberapa waktu dan menerbitkan APM Magic Quadrant setiap tahun.Ini adalah sumber daya yang baik dalam hal memahami cara mengevaluasi solusi solusi Pemantauan Kinerja Aplikasi dan memberikan gambaran umum yang baik tentang vendor teratas.
Tambahkan APM otomatis ke daftar persyaratan remediasi Anda
Di sini, di SIOS Technology Corporation, kami selalu bekerja dengan pelanggan yang memigrasi aplikasi mereka ke cloud.Mereka sering kali ingin mengetahui cara melindungi aplikasi mereka dari waktu henti yang tidak perlu dan meminta saran dari kami.Pilihan bagaimana melindungi aplikasi mereka adalah fungsi dari kekritisan aplikasi tersebut (aplikasi yang lebih kritis sering kali membutuhkan solusi failover, dll.). Namun kami juga membantu mereka memahami mengapa aplikasi mereka mungkin rentan.
Dulu pencadangan dan perlindungan data adalah fungsi terpisah (yang hanya diperlukan jika solusi APM mengidentifikasi waktu henti).Namun dalam lingkungan cloud yang kompleks saat ini, kami percaya bahwa organisasi harus mencari pendekatan holistik dalam hal memantau dan mengelola aplikasi penting mereka.Jika solusi APM tradisional mengidentifikasi kapan sesuatu terjadi dan memungkinkan Anda mendiagnosis mengapa hal itu terjadi, mengapa solusi itu tidak mencegah downtime yang tidak perlu jika memungkinkan?
Kami percaya bahwa otomatisasi adalah unsur yang hilang dari sebagian besar solusi cloud APM.Banyak pelanggan kami memberi tahu kami bagaimana mereka kewalahan dengan menerima terlalu banyak peringatan dari solusi APM mereka, masing-masing meminta mereka untuk berhenti dan memahami apa yang terjadi dan mengapa.Mereka dengan cepat memahami apa yang harus diabaikan dan apa yang harus diperhatikan (dan solusi APM yang baik membantu mereka melakukan ini melalui pembelajaran mesin).Dan jika dan ketika aplikasi mereka turun, solusi APM memperingatkan mereka tentang waktu henti dan mendiagnosis mengapa membantu mencegah hal itu terjadi lagi.Namun solusi APM tidak akan mengurangi waktu henti langsung mereka.
Di situlah SIOS AppKeeper berperan. AppKeeper memantau aplikasi pelanggan yang berjalan di Amazon EC2 dan secara otomatis memulai ulang layanan di EC2 atau bahkan me-reboot instans EC2 jika dan saat waktu henti terdeteksi.Pelanggan rata-rata kami, dengan hanya 3 instans Amazon EC2, mengalami waktu henti setidaknya sebulan sekali.Itu adalah waktu henti ketika aplikasi kritis, seringkali berhadapan dengan pelanggan, tidak tersedia, dan ketika I.T. tim harus melepaskan semuanya dan merespons.
Solusi otomatisasi APM AppKeeper memungkinkan pelanggan pulih secara otomatis dari lebih dari 85% situasi waktu henti Amazon EC2 mereka.Berikut tautan ke video singkat jika Anda ingin melihat AppKeeper beraksi.
Melalui AppKeeper's API, pelanggan secara terprogram memperluas nilai solusi APM mereka dengan meminta peringatan dari solusi APM mereka memicu AppKeeper untuk secara otomatis memulai ulang layanan Amazon EC2 yang diterapkan atau memulai ulang instans jika perlu.
Pemantauan Kinerja Aplikasi dan Remediasi Otomatis.Lebih baik dari selai kacang dan agar-agar?
Dalam banyak kasus, pelanggan AppKeeper memiliki kemudahan untuk mengelola lingkungan Amazon EC2, dengan mungkin kurang dari 8 instans Amazon EC2.Bagi mereka, fungsi pemantauan asli dan remediasi otomatis dari AppKeeper cukup untuk membuat mereka tidur nyenyak di malam hari, mengetahui bahwa mereka secara proaktif mengurangi waktu henti jika dan ketika hal itu terjadi.
Namun kami menyadari bahwa banyak pelanggan memiliki lingkungan cloud yang lebih canggih, dan telah berinvestasi dalam solusi APM, seperti dari New Relic, Datadog, Dynatrace, LogicMonitor, atau Zabbix.Mereka mengharapkan lansiran langsung dan kumpulan data yang kaya untuk membantu mereka mendiagnosis apa yang terjadi dan mengapa.Untuk kumpulan pelanggan ini, menurut kami, penambahan fungsi remediasi otomatis AppKeeper ke toolkit APM mereka memberi mereka yang terbaik dari kedua dunia: kontrol atas kinerja aplikasi mereka, dan pengurangan waktu henti.
Selama beberapa bulan ke depan, SIOS Technology akan bekerja dengan beberapa vendor APM terkemuka untuk menyediakan integrasi paket dan bersertifikat antara solusi APM dan AppKeeper mereka.Dengan menggunakan integrasi ini dengan AppKeeper, pengguna ini sekarang akan menikmati sistem loop tertutup, di mana mereka akan diberi tahu untuk mendeteksi waktu henti Amazon EC2 dan tindakan perbaikan yang dilakukan AppKeeper.
Jadi nantikan beberapa berita menarik.Sementara itu, jika Anda ingin mencoba SIOS AppKeeper sendiri, silakan mendaftar uji coba AppKeeper gratis selama 14 hari. AppKeeper mulai hanya dengan US $ 40 per instance per bulan.
Direproduksi dengan izin dari SIOS