Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pemeriksaan status aplikasi
Pemeriksaan status aplikasi membantu Anda memantau kinerja dan kesehatan aplikasi yang berjalan di Amazon EC2. Dengan pemeriksaan status aplikasi, Anda dapat mendeteksi dan menanggapi gangguan kesehatan aplikasi dengan memantau aplikasi Anda melalui jalur dan port yang dapat dikonfigurasi. Misalnya, Anda dapat menggunakan pemeriksaan status aplikasi untuk mengonfirmasi bahwa server web Anda mendengarkan port yang diharapkan dan menerima koneksi baru.
Pemeriksaan status aplikasi memantau respons HTTP dan HTTPS aplikasi Anda di jalur dan port yang dapat dikonfigurasi. Mereka berjalan setiap 60 detik dan terintegrasi dengan Amazon EC2 Auto Scaling, sehingga Anda dapat mengotomatiskan penggantian instans yang aplikasinya rusak.
Daftar Isi
Cara kerja pemeriksaan status aplikasi
Pemeriksaan status aplikasi mengirim permintaan HTTP atau HTTPS ke titik akhir yang mendengarkan di port jaringan pada instans Anda setiap 60 detik. AWS membandingkan kode respons dengan pencocokan kode status yang Anda konfigurasikan. Cek ditandai rusak setelah sejumlah permintaan gagal berturut-turut, dan sehat kembali setelah sejumlah permintaan berhasil berturut-turut. Keduanya dihitung secara default ke 2 dan dapat dikonfigurasi. Untuk informasi selengkapnya, lihat Ambang evaluasi.
catatan
Pemeriksaan status aplikasi mengirimkan permintaan pemeriksaan kesehatan HTTP/2.
Pemeriksaan protokol HTTPS tidak memvalidasi sertifikat server.
Selama reboot, pemeriksaan status aplikasi melaporkan kegagalan hingga instans tersedia lagi karena aplikasi tidak dapat menanggapi permintaan pemeriksaan kesehatan saat sistem operasi memulai ulang.
Arsitektur jaringan
Pemeriksaan status aplikasi berasal dari layanan pemeriksaan status aplikasi Amazon EC2. Untuk menjangkau instans Anda, AWS buat antarmuka jaringan elastis terkelola (ENI) di VPC Anda. AWS membuat satu ENI per kombinasi subnet sumber dan grup keamanan yang memiliki instans terkait. AWS membuat ENI terkelola ketika pemeriksaan status aplikasi terlebih dahulu memerlukan kombinasi itu, dan menghapusnya ketika tidak ada pemeriksaan status aplikasi yang tersisa yang memerlukannya. ENI terkelola tidak dihitung terhadap batas ENI instans Anda, tetapi diperhitungkan terhadap batas global untuk ENI per VPC.
Pemeriksaan status aplikasi mencapai instans Anda dari sudut pandang pribadi dalam VPC Anda. Cakupan menjelaskan dari mana cek berasal, bukan properti alamat IP instance Anda. AWS membuat ENI terkelola di subnet dalam VPC Anda dan mencapai instance melalui jalur jaringan pribadi.
Lalu lintas pemeriksaan kesehatan berasal dari AWS instans Amazon EC2 yang dikelola di Zona Ketersediaan yang sama dengan instans target (atau Zona Ketersediaan induk untuk target Zona Lokal), berjalan melalui jaringan AWS internal, dan tidak melintasi internet publik. Untuk informasi selengkapnya, lihat FAQ Amazon VPC
AWS jalur jaringan yang dikelola dan dikelola pelanggan
Pemeriksaan status aplikasi mendukung dua mode orientasi yang menentukan siapa yang memilih subnet sumber dan grup keamanan untuk pemeriksaan kesehatan ENI dan subnet tujuan dan grup keamanan untuk instans target.
- AWS jalur jaringan yang dikelola
-
AWS memilih subnet sumber dan grup keamanan untuk pemeriksaan kesehatan ENI dan subnet tujuan dan grup keamanan untuk instans target.
- Customer-managed jalur jaringan
-
Anda menentukan subnet sumber dan grup keamanan untuk pemeriksaan kesehatan ENI dan subnet tujuan dan grup keamanan untuk instans target.
Gunakan jalur jaringan yang dikelola pelanggan saat Anda perlu mengontrol lalu lintas pemeriksaan kesehatan subnet dan grup keamanan mana yang berasal, seperti ketika VPC Anda memiliki segmentasi jaringan yang ketat, aturan firewall, atau persyaratan kepatuhan yang membatasi sumber mana yang dapat mencapai titik akhir aplikasi Anda.
Anda memilih mode dengan memasukkan atau menghilangkan --health-check-paths parameter dalam perintah create. Jika Anda menghilangkan --health-check-paths parameter, pilih subnet AWS sumber dan tujuan dan grup keamanan (jalur jaringan terkel AWS ola). Jika Anda menyertakan --health-check-paths parameter, Anda mengelolanya (jalur jaringan yang dikelola pelanggan).
Versi IP
Setiap pemeriksaan status aplikasi dikaitkan dengan versi IP tunggal (IPv4 atau IPv6). Untuk memantau instance melalui IPv4 dan IPv6, buat dua pemeriksaan status aplikasi terpisah dan kaitkan keduanya dengan instance.
Pemeriksaan mencapai instans Anda dari dalam VPC untuk IPv4 dan IPv6.
Periksa nilai status
Setiap pemeriksaan individu melaporkan salah satu status berikut:
-
passed: cek selesai dengan sukses -
failed: pemeriksaan gagal. Respons mencakup kode status HTTP yang dikembalikan oleh aplikasi Anda. Untuk panduan interpretasi dan remediasi, lihatPemecahan masalah. -
initializing: cek belum menyelesaikan evaluasi pertamanya -
insufficient-data: cek tidak menerima data yang cukup untuk menentukan hasil -
not-applicable: cek tidak terkait dengan instance
Status aplikasi keseluruhan yang dilaporkan untuk instans menggabungkan semua hasil pemeriksaan individu. Status keseluruhan adalah salah satu dari berikut ini:
-
ok: semua cek lulus -
impaired: satu atau lebih pemeriksaan gagal -
initializing: satu atau lebih pemeriksaan belum menyelesaikan evaluasi pertamanya -
insufficient-data: satu atau lebih cek melaporkan data yang tidak mencukupi -
not-applicable: semua pemeriksaan status aplikasi terkait dikecualikan dari agregasi -
suppressed: evaluasi pemeriksaan status aplikasi ditekan untuk instance
Agregasi
Anda dapat menandai setiap pemeriksaan status aplikasi sebagai termasuk dalam atau dikecualikan dari status keseluruhan instans. Secara default, cek adalahincluded.
included-
Pemeriksaan berkontribusi pada status keseluruhan untuk instans dan Amazon EC2 Auto Scaling menggunakannya.
excluded-
Pemeriksaan melaporkan status individualnya tetapi tidak berkontribusi pada status keseluruhan untuk instans dan Amazon EC2 Auto Scaling tidak menggunakannya. Gunakan pengaturan ini untuk memvalidasi pemeriksaan baru dalam produksi tanpa mempengaruhi status keseluruhan atau memicu penggantian Amazon EC2 Auto Scaling. Ini adalah alur kerja yang disarankan saat menambahkan cek ke beban kerja produksi yang ada; lihatMenguji pemeriksaan status aplikasi baru.
Memulai pemeriksaan status aplikasi
Prasyarat
Sebelum Anda membuat pemeriksaan status aplikasi, pastikan Anda memiliki yang berikut:
-
VPC dengan instans yang ingin Anda pantau.
-
Titik akhir aplikasi pada setiap instance yang dapat merespons permintaan HTTP atau HTTPS pada port dan jalur HTTP yang akan Anda konfigurasikan.
-
Grup keamanan pada setiap instance tujuan yang memungkinkan lalu lintas masuk pada port cek dari grup keamanan sumber yang digunakan oleh pemeriksaan status aplikasi. Lihat Keamanan dan izin.
Langkah 1: Konfigurasikan aplikasi Anda
Konfigurasikan titik akhir aplikasi Anda untuk menanggapi permintaan HTTP atau HTTPS pada port dan jalur HTTP yang akan Anda tentukan saat membuat pemeriksaan. Kembalikan kode respons yang disertakan dalam pencocokan kode status Anda untuk menunjukkan aplikasi sehat.
Pastikan grup keamanan instans tujuan mengizinkan lalu lintas masuk pada port cek dari grup keamanan sumber yang digunakan oleh pemeriksaan status aplikasi. Untuk jalur jaringan terkelola, AWS berikan grup keamanan sumber pada pembuatan cek. Untuk jalur jaringan yang dikelola pelanggan, Anda menentukan grup keamanan sumber saat membuat cek.
Langkah 2: Buat definisi cek
Gunakan AWS CLI untuk membuat pemeriksaan status aplikasi.
Langkah 3: Mengaitkan cek dengan instance
Kaitkan pemeriksaan dengan instans yang ingin Anda pantau, baik berdasarkan ID instance atau dengan tag.
Operasi asosiasi dan disasosiasi mengembalikan hasil keberhasilan dan kegagalan per instans. Jika beberapa contoh tidak dapat dikaitkan (misalnya, karena pemeriksaan sudah dikaitkan), instance tersebut muncul dalam hasil yang tidak berhasil dengan alasan.
Langkah 4: Lihat hasil
Melihat status kesehatan aplikasi per instans.
Opsi konfigurasi
Pemeriksaan status aplikasi menerima beberapa parameter konfigurasi. Bagian ini menjelaskan parameter di mana perilaku tidak terbukti dengan sendirinya dari nama parameter. Untuk daftar lengkap parameter dan aturan validasi, lihat CreateApplicationStatusCheck dan AssociateApplicationStatusCheck di Refer ensi API Amazon EC2.
Ambang evaluasi
FailureThreshold-
Jumlah permintaan gagal berturut-turut sebelum cek ditandai terganggu. Standar: 2.
SuccessThreshold-
Jumlah permintaan berhasil berturut-turut sebelum cek ditandai sehat lagi. Standar: 2.
Timeout-
Jumlah detik untuk menunggu respons sebelum permintaan dicatat sebagai gagal. Diterapkan sebagai batas waktu paksa; jika aplikasi Anda tidak merespons dalam jendela ini, permintaan dicatat sebagai kegagalan terlepas dari tanggapan akhirnya. Standar: 6. Kisaran yang valid: 1-30.
Masa tenggang awal
InitializationGracePeriodSeconds-
Jumlah detik yang harus menunggu setelah instance diluncurkan sebelum AWS mulai mengevaluasi pemeriksaan. Gunakan parameter ini untuk memberi aplikasi waktu untuk mulai mendengarkan sebelum pemeriksaan dimulai. Jika masa tenggang terlalu singkat, Amazon EC2 Auto Scaling dapat menggantikan instans baru sebelum aplikasi mereka siap. Standar: 300. Kisaran yang valid: 1 hingga 600.
Lingkup IP
IpScope-
Pemeriksaan status aplikasi menggunakan cak
privateupan; pemeriksaan berjalan dari dalam VPC Anda. Untuk IPv4, ini sesuai dengan alamat IP pribadi instance. Untuk IPv6, AWS tidak mengklasifikasikan alamat sebagai publik atau pribadi; cek menerima alamat IPv6 apa pun dan mengevaluasinya dari dalam VPC Anda.
Indeks perangkat
DeviceIndex-
Indeks perangkat jaringan pada instans Anda yang AWS mengevaluasi pemeriksaan kesehatan. Ubah ini jika perangkat jaringan utama instans Anda bukan perangkat yang ingin Anda periksa. Default: 0.
Agregasi, versi IP, dan jalur pemeriksaan kesehatan (subnet sumber dan tujuan serta grup keamanan) tercakup dalam bagiannya sendiri sebelumnya di halaman ini.
Pengaturan default
Dengan AWS jalur jaringan terkelola, pemeriksaan status aplikasi menggunakan default berikut.
| Pengaturan | Default |
|---|---|
Periksa interval |
60 detik (tetap; tidak dapat dikonfigurasi) |
Ambang batas kegagalan |
2 kegagalan berturut-turut |
Ambang batas keberhasilan |
2 keberhasilan berturut-turut |
Waktu habis |
6 detik |
Pencocokan kode status |
200 |
Jalur HTTP |
/ |
Versi IP |
ipv4 |
Lingkup IP |
private |
Indeks perangkat |
0 |
Masa tenggang inisialisasi |
300 detik |
Agregasi |
termasuk |
Subnet sumber dan grup keamanan |
Dikelola oleh AWS |
Integrasi Penskalaan Otomatis Amazon EC2
Amazon EC2 Auto Scaling secara otomatis mengakhiri dan mengganti instans yang laporan status aplikasinya secara keseluruhanimpaired, selama pemeriksaan disertakan dalam agregasi. Tidak diperlukan konfigurasi grup Penskalaan Otomatis selain mengaitkan pemeriksaan status aplikasi dengan instans dalam grup.
Amazon EC2 Auto Scaling menggunakan status keseluruhan untuk instans, bukan status pemeriksaan individual. Cek yang ditandai excluded tidak mendorong tindakan Penskalaan Otomatis Amazon EC2. Pemeriksaan di suppressed negara bagian tidak mendorong tindakan Penskalaan Otomatis Amazon EC2.
Gunakan InitializationGracePeriodSeconds parameter pada pemeriksaan untuk memberikan waktu instans baru untuk memulai sebelum pemeriksaan status aplikasi dimulai. Jika masa tenggang terlalu singkat, instans baru mungkin dihentikan dan diganti dengan Amazon EC2 Auto Scaling sebelum aplikasi mereka siap melayani lalu lintas.
Untuk informasi selengkapnya tentang cara Amazon EC2 Auto Scaling menggunakan pemeriksaan kesehatan, lihat Pemeriksaan kesehatan untuk instans dalam grup Penskalaan Otomatis dan Menggunakan pemeriksaan status aplikasi dengan grup Penskalaan Otomatis di Panduan Pengguna Penskalaan Otomatis Amazon EC2.
Menangani penerapan, tambalan di tempat, dan penggantian
Penerapan, tambalan di tempat, dan operasi pemeliharaan lainnya dapat menghentikan atau memulai ulang aplikasi Anda untuk sementara waktu. Selama waktu itu, pemeriksaan status aplikasi melaporkan kegagalan karena aplikasi tidak dapat menanggapi permintaan pemeriksaan kesehatan. Jika instans Anda berada dalam grup Penskalaan Otomatis dengan pemeriksaan status aplikasi disertakan dalam agregasi, Amazon EC2 Auto Scaling mungkin menghentikan dan mengganti instans ini meskipun gangguan diharapkan terjadi.
Opsi A: Menekan cek
Gunakan penindasan untuk jendela pemeliharaan terbatas di mana Anda tahu durasinya. Penindasan diberlakukan pada tingkat instance. Anda menentukan durasi, atau menghilangkannya untuk menekan pemeriksaan sampai Anda menonaktifkan penindasan.
Saat ditekan, status aplikasi keseluruhan untuk instans dilaporkansuppressed. Amazon EC2 Auto Scaling tidak bertindak pada suppressed instans.
Opsi B: Kecualikan cek dari agregasi
Jika Anda ingin cek terus mengevaluasi dan melaporkan status individualnya tetapi tidak memengaruhi status keseluruhan atau memicu tindakan Penskalaan Otomatis Amazon EC2, setel pengaturan agregasi cek keexcluded. Ini berguna untuk skenario yang berumur panjang seperti meluncurkan versi pemeriksaan baru atau memvalidasi perubahan tanpa risiko penggantian, dan untuk kasus di mana Anda ingin telemetri dilanjutkan tanpa dampak operasional.
Untuk informasi selengkapnya, lihat Agregasi.
Opsi C: Lepaskan cek
Gunakan disasosiasi untuk penghapusan yang berumur lebih lama atau tidak terbatas.
aws ec2 disassociate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --instance-ids i-0123456789abcdef0
Jika Anda mengaitkan berdasarkan tag, hapus tag dari instance untuk dipisahkan. Setelah disasosiasi, status aplikasi keseluruhan untuk laporan not-applicable instance.
Panduan penyebaran
Penerapan adalah skenario pemeliharaan paling umum yang memerlukan penindasan. Gunakan penindasan ketika alat penerapan Anda memiliki kait pra-penerapan dan kait pasca-penerapan sehingga Anda dapat menekan pemeriksaan sebelum penerapan dimulai dan menonaktifkan penindasan setelah penerapan selesai.
Pola umumnya adalah:
-
Di hook pra-penerapan, panggil enable-application-status-check-suppression untuk instance, dengan durasi yang mencakup jendela penerapan yang diharapkan.
-
Lakukan penyebaran.
-
Di hook pasca-penerapan, panggil disable-applic ation-status-check-suppression untuk instance.
Jika alat penerapan Anda tidak memiliki kait, tekan drive dari CI/CD pipeline yang memanggil penerapan.
Menguji pemeriksaan status aplikasi baru
Anda dapat memvalidasi pemeriksaan status aplikasi baru dalam produksi sebelum mulai berkontribusi pada pemantauan tingkat instance Anda. Setel pengaturan agregasi ke excluded saat Anda membuat cek, lalu konfirmasikan laporan status yang diharapkan dan kode respons HTTP. Saat Anda siap, ubah setelan included agar pemeriksaan berkontribusi pada status keseluruhan instans dan terintegrasi dengan Amazon EC2 Auto Scaling.
-
Buat cek dengan pengaturan agregasi disetel ke
excluded.aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200" \ --aggregation excluded -
Kaitkan cek dengan instance pengujian atau subset armada produksi Anda.
-
Tunggu setidaknya dua interval pemeriksaan (sekitar dua menit) untuk memungkinkan pemeriksaan menyelesaikan evaluasi awal.
-
Gunakan describe-application-status untuk memverifikasi pemeriksaan melaporkan status yang diharapkan dan kode respons HTTP.
aws ec2 describe-application-status \ --instance-ids i-0123456789abcdef0 -
Jika pemeriksaan dilaporkan seperti yang diharapkan, perbarui setelan agregasi
includedagar pemeriksaan berkontribusi pada status keseluruhan instans dan mendorong tindakan Penskalaan Otomatis Amazon EC2.aws ec2 modify-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --aggregation included
Jaringan lanjutan
Pemeriksaan status aplikasi berasal dari ENI terkelola di subnet sumber dan grup keamanan yang Anda tentukan (atau yang AWS dipilih untuk Anda). Untuk beban kerja yang memerlukan ketersediaan lebih tinggi daripada yang disediakan konfigurasi sumber tunggal, atau untuk beban kerja yang berjalan di Zona Lokal atau Pos Terdepan, pertimbangkan pola berikut.
Zona Lokal
Untuk instans yang berjalan di Zona AWS Lokal, antarmuka jaringan elastis terkelola (ENI) berada di Wil AWS ayah induk, bukan di Zona Lokal. Lalu lintas pemeriksaan kesehatan antara Wilayah induk dan instans Zona Lokal Anda melintasi tautan layanan Zona Lokal, yang mungkin dikenakan biaya transfer data tambahan.
Pemecahan masalah
Ketika pemeriksaan status aplikasi melaporkan gangguan tetapi Anda mengharapkan aplikasi Anda sehat, verifikasi masing-masing hal berikut:
-
Jangkauan contoh. Konfirmasikan bahwa pemeriksaan status Instance dan System instans sudah ada
ok. -
Aturan masuk grup keamanan. Grup keamanan instans tujuan harus mengizinkan lalu lintas masuk pada port cek dari grup keamanan sumber yang digunakan oleh pemeriksaan status aplikasi. Untuk jalur jaringan terkel AWS ola, AWS berikan grup keamanan sumber; untuk jalur jaringan yang dikelola pelanggan, gunakan grup keamanan yang Anda tentukan sebagai sumber.
-
Firewall host. Setiap firewall tingkat host (iptables, Windows Firewall, firewall host pihak ketiga) pada instance harus mengizinkan lalu lintas masuk pada port cek.
-
Titik akhir aplikasi. Aplikasi harus mendengarkan pada port dan jalur yang Anda konfigurasikan. Konfirmasikan dengan permintaan lokal dari instance (
curl http://localhost:PORT/PATH). -
Ketidakcocokan protokol. Jika pemeriksaan dikonfigurasi sebagai HTTPS tetapi titik akhir hanya melayani HTTP (atau sebaliknya), semua panggilan akan gagal.
-
Pencocokan kode status. Konfirmasikan bahwa kode respons aktual aplikasi Anda disertakan dalam pencocokan kode status yang Anda konfigurasikan.
-
Jalur jaringan. Jika Anda mengonfigurasi jalur jaringan yang dikelola pelanggan, konfirmasikan subnet sumber dan grup keamanan memiliki konektivitas ke subnet tujuan. Gunakan VPC Reachability Analyzer untuk melacak jalur jaringan.
-
Kuota ENI tersedia. AWS membuat antarmuka jaringan elastis terkelola (ENI) di akun Anda untuk setiap subnet sumber dan kombinasi grup keamanan. Konfirmasikan akun Anda memiliki ENI yang tersedia dalam kuota untuk VPC. Jika akun Anda telah mencapai ENI per kuota VPC, AWS tidak dapat membuat ENI terkelola dan pemeriksaan tidak dapat dijalankan. Untuk informasi selengkapnya, lihat kuota Amazon VPC.
Kode alasan
Respons deskripsi-aplikasi-status menyer takan alasan untuk setiap pemeriksaan. Alasannya berisi kode status HTTP yang dikembalikan oleh aplikasi Anda (sebagai angka), bersama dengan protokol yang digunakan untuk pemeriksaan. Cek ditandai passed jika kode status yang dikembalikan disertakan dalam pencocokan kode status Anda, dan failed sebaliknya.
Alasannya juga mencakup kode alasan dan, untuk HTTP-level hasil, protokol dan kode status HTTP yang dikembalikan. Alasannya berisi bidang berikut:
Code-
Kode alasan untuk hasil pemeriksaan status aplikasi. Salah satu nilai berikut:
-
ResponseCodeMatched: kode status HTTP yang dikembalikan oleh pemeriksaan kesehatan cocok dengan yang dikonfigurasiStatusCodeMatcher. -
ResponseCodeMismatch: kode status HTTP yang dikembalikan oleh pemeriksaan kesehatan tidak cocok dengan yang dikonfigurasiStatusCodeMatcher. -
ConnectionTimeout: koneksi ke target habis waktunya. -
ResponseTimeout: waktu pemeriksaan kesehatan habis sambil menunggu tanggapan dari target. -
ConnectionRefused: target menolak koneksi pemeriksaan kesehatan. -
ConnectionReset: koneksi pemeriksaan kesehatan diatur ulang sebelum respons diterima.
Untuk
ResponseCodeMatcheddanResponseCodeMismatch,StatusCodebidang berisi kode status HTTP yang dikembalikan danProtocolbidang berisi protokol yang digunakan untuk pemeriksaan kesehatan. Untuk kesalahan koneksi, sepertiConnectionTimeout,ResponseTimeoutConnectionRefused,, danConnectionReset,ProtocolbidangStatusCodedan tidak ada. -
Protocol-
Protokol yang digunakan untuk pemeriksaan kesehatan. Salah satu
HTTPatauHTTPS. StatusCode-
Kode status HTTP dikembalikan oleh pemeriksaan kesehatan.
Gunakan kode status HTTP yang dikembalikan untuk mengidentifikasi mengapa pemeriksaan gagal. Beberapa contoh umum:
| Kode status HTTP | Makna khas | Remediasi umum |
|---|---|---|
|
Aplikasi mengembalikan respons yang berhasil. |
Tidak ada. Ini biasanya status yang sehat. |
|
Aplikasi mengembalikan pengalihan. Panggilan pemeriksaan kesehatan tidak mengikuti pengalihan. |
Arahkan jalur pemeriksaan kesehatan ke tujuan pengalihan, atau tambahkan kode pengalihan ke pencocokan kode status Anda jika Anda menganggapnya sehat. |
|
Aplikasi ini memerlukan otentikasi atau akses ditolak ke jalur pemeriksaan kesehatan. |
Konfigurasikan jalur pemeriksaan kesehatan agar tidak diautentikasi, atau sajikan pemeriksaan kesehatan pada jalur yang tidak memerlukan kredenSIAL. |
|
Jalur pemeriksaan kesehatan yang dikonfigurasi tidak ditemukan pada aplikasi. |
Konfirmasikan jalur cocok dengan rute yang dilayani aplikasi Anda. |
|
Aplikasi mengembalikan kesalahan server internal. |
Selidiki log aplikasi pada instance. |
|
Aplikasi dapat dijangkau tetapi melaporkan masalah hulu atau kapasitas. |
Selidiki kesehatan aplikasi, dependensi, dan kapasitas. Jika aplikasi Anda mengembalikan kode-kode ini selama startup, tingkatkan |
Untuk ApplicationStatusReason struktur lengkapnya, lihat ApplicationStatusReason di Refer ensi API Amazon EC2.
Kesalahan umum
-
Grup keamanan tidak mengizinkan lalu lintas masuk dari sumber pemeriksaan kesehatan pada port cek.
-
Aplikasi terikat
127.0.0.1dan tidak mendengarkan pada antarmuka jaringan. -
Jalur pemeriksaan kesehatan mengembalikan pengalihan (301, 302) daripada respons sukses, dan pencocokan kode status tidak menyertakan kode pengalihan.
-
Pemeriksaan dikonfigurasi untuk HTTPS tetapi aplikasi hanya melayani HTTP, atau sebaliknya.
-
Aplikasi membutuhkan waktu lebih lama untuk memulai daripada
InitializationGracePeriodSecondsnilainya, dan Amazon EC2 Auto Scaling menggantikan instance sebelum siap.
Pantau pemeriksaan status aplikasi
Anda dapat memantau pemeriksaan status aplikasi dengan tiga cara:
-
Amazon CloudWatch. Met
StatusCheckFailed_Applicationrik mencerminkan status aplikasi keseluruhan untuk instance dan dapat mendorong alarm. Metrik digabungkan per instans di seluruh pemeriksaan terkait yang setelan agregasinya adalahincluded. CloudWatch juga menerbitkan metrik per cek untuk setiap cek terkait, bernamaStatusCheckFailed_Application_.application-status-check-id -
deskripsi- instance-status. Mengembalikan status aplikasi secara keseluruhan bersama informasi status instans Anda yang lain.
-
deskripsi- status aplikasi. Mengembalikan hasil per instans terperinci, termasuk status individual setiap cek terkait dan kode status HTTP yang dikembalikan oleh aplikasi Anda.
Gunakan CloudWatch metrik untuk otomatisasi berbasis alarm. Gunakan describe-instance-status saat Anda sudah menanyainya misalnya status. Gunakan describe-application-status untuk visibilitas per cek terperinci.
Keamanan dan izin
AWS membuat dan mengelola antarmuka jaringan yang digunakan untuk pemeriksaan status aplikasi melalui peran terkait layanan. Tidak diperlukan pengaturan IAM untuk layanan untuk membuat ENI ini. Peran terkait layanan menggunakan kebijakan terkel EC2ApplicationStatusChecksServiceRolePolicy AWS
ola.
Untuk membuat, mengaitkan, mendeskripsikan, menghapus, dan menekan pemeriksaan status aplikasi sendiri, pengguna atau peran IAM Anda memerlukan izin Amazon EC2 yang sesuai. Lihat Referensi API Amazon EC2 untuk daftar tindakan lengkap.
Grup keamanan instans Anda harus mengizinkan lalu lintas masuk dari grup keamanan sumber pemeriksaan kesehatan pada port yang Anda konfigurasikan. Dengan jalur jaringan terkel AWS ola, AWS menyediakan grup keamanan sumber; dengan jalur jaringan yang dikelola pelanggan, gunakan grup keamanan yang Anda tentukan sebagai sumber.
Harga
Pemeriksaan status aplikasi ditagih pada komponen berikut:
-
Biaya per jam sebesar $0,01 untuk setiap antarmuka jaringan elastis terkelola (ENI), per Zona Ketersediaan.
-
CloudWatch Harga Amazon standar berlaku untuk metrik pemeriksaan status aplikasi.
Kuota
Pemeriksaan status aplikasi tunduk pada AWS kuota layanan. Untuk nama kuota, nilai default, dan deskripsi, lihat titik akhir dan kuota Amazon EC2 di Referensi AWS Umum.
Selain kuota AWS layanan yang memengaruhi antarmuka jaringan terkelola, pemeriksaan status aplikasi memiliki kuota layanan berikut. Anda dapat melihat penggunaan dan permintaan kenaikan dari konsol Kuota Layanan.
Dalam kuota ini, target adalah satu contoh yang dipantau oleh satu pemeriksaan kesehatan. Jika lebih dari satu pemeriksaan kesehatan memantau instans, setiap pasangan instans dan pemeriksaan kesehatan dihitung sebagai target terpisah. A sosiasi adalah aturan tag tunggal atau ID instans tunggal yang Anda kaitkan dengan pemeriksaan kesehatan. Setiap aturan atau ID instance dihitung sebagai satu asosiasi, terlepas dari berapa banyak instance yang diselesaikan.
| Kuota | Default | Dapat disesuaikan |
|---|---|---|
Pemeriksaan kesehatan per akun |
50 |
Ya, otomatis |
Asosiasi per pemeriksaan kesehatan |
50 |
Ya, otomatis |
Asosiasi per akun |
200 |
Ya, otomatis |
Target per akun |
5000 |
Ya, atas permintaan |
Sebagian besar kenaikan kuota disetujui secara otomatis. Peningkatan ke Target per akun memerlukan permintaan dan persetujuan manual.
penting
Jika jumlah target di akun Anda melebihi ku ota Target per akun, target yang melebihi batas tidak dipantau dan tidak melaporkan status aplikasi. Untuk menghindari kesenjangan dalam pemantauan, pertahankan jumlah target Anda dalam kuota atau minta kenaikan.
Kami menyarankan Anda membuat CloudWatch alarm Amazon pada penggunaan kuota pemeriksaan status aplikasi sehingga Anda diberi tahu sebelum mencapai kuota. Kuota Layanan menerbitkan metrik penggunaan ke AWS/Usage namespace di CloudWatch, yang dapat Anda gunakan untuk membuat alarm.