View a markdown version of this page

Pemeriksaan status aplikasi - Amazon Elastic Compute Cloud

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.

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 di situs web Amazon Web Services.

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.

AWS CLI

Untuk menggunakan AWS jalur jaringan terkelola, hilangkan --health-check-paths parameter dan biarkan AWS pilih subnet sumber dan tujuan serta grup keamanan.

aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200"

Untuk menggunakan jalur jaringan yang dikelola pelanggan, sertakan parameter. --health-check-paths Setiap jalur pemeriksaan kesehatan berisi sumber (subnet dan grup keamanan untuk pemeriksaan kesehatan ENI) dan satu atau lebih tujuan (subnet dan grup keamanan untuk instans target).

aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200" \ --health-check-paths '[{"Source":{"SubnetId":"subnet-111","SecurityGroupId":"sg-aaa"},"Destinations":[{"SubnetId":"subnet-222","SecurityGroupId":"sg-bbb"}]}]'
Langkah 3: Mengaitkan cek dengan instance

Kaitkan pemeriksaan dengan instans yang ingin Anda pantau, baik berdasarkan ID instance atau dengan tag.

AWS CLI

Dengan ID instance:

aws ec2 associate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --instance-ids i-0123456789abcdef0

Dengan tag:

aws ec2 associate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --target-tag-associations Key=Environment,Value=production

Untuk mengaitkan dengan semua instance dalam grup Auto Scaling, gunakan tag aws:autoscaling:groupName sistem:

aws ec2 associate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --target-tag-associations Key=aws:autoscaling:groupName,Value=my-asg

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.

AWS CLI
aws ec2 describe-application-status \ --instance-ids i-0123456789abcdef0

Respons mencakup status aplikasi secara keseluruhan dan, untuk setiap pemeriksaan terkait, status pemeriksaan dan, untuk pemeriksaan gagal, kode status HTTP yang dikembalikan oleh aplikasi Anda.

Contoh respons:

{ "ApplicationStatuses": [ { "InstanceId": "i-0123456789abcdef0", "ApplicationStatus": { "Status": "ok", "Details": [ { "ApplicationStatusCheckId": "asc-1234567890abcdef0", "Status": "passed", "Reason": { "Code": "ResponseCodeMatched", "StatusCode": 200, "Protocol": "HTTP" } } ] } } ] }

Untuk melihat definisi cek (bukan status per instans), gunakan descri be-application-status-checks. Perintah ini mengembalikan konfigurasi pemeriksaan status aplikasi Anda, termasuk protokol, port, jalur HTTP, dan pengaturan pencocokan kode status.

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 private upan; 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.

AWS CLI
aws ec2 enable-application-status-check-suppression \ --instance-ids i-0123456789abcdef0 \ --duration-seconds 3600

Respons kembali, untuk setiap contoh, ketika penekanan dimulai dan kapan akan berakhir. Keberhasilan sebagian dimungkinkan; beberapa contoh mungkin gagal ditekan dan muncul dalam respons dengan alasan.

Untuk melanjutkan pemeriksaan sebelum jendela penekanan berakhir:

aws ec2 disable-application-status-check-suppression \ --instance-ids i-0123456789abcdef0

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:

  1. Di hook pra-penerapan, panggil enable-application-status-check-suppression untuk instance, dengan durasi yang mencakup jendela penerapan yang diharapkan.

  2. Lakukan penyebaran.

  3. 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.

  1. Buat cek dengan pengaturan agregasi disetel keexcluded.

    aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200" \ --aggregation excluded
  2. Kaitkan cek dengan instance pengujian atau subset armada produksi Anda.

  3. Tunggu setidaknya dua interval pemeriksaan (sekitar dua menit) untuk memungkinkan pemeriksaan menyelesaikan evaluasi awal.

  4. Gunakan describe-application-status untuk memverifikasi pemeriksaan melaporkan status yang diharapkan dan kode respons HTTP.

    aws ec2 describe-application-status \ --instance-ids i-0123456789abcdef0
  5. Jika pemeriksaan dilaporkan seperti yang diharapkan, perbarui setelan agregasi included agar 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:

  1. Jangkauan contoh. Konfirmasikan bahwa pemeriksaan status Instance dan System instans sudah adaok.

  2. 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.

  3. Firewall host. Setiap firewall tingkat host (iptables, Windows Firewall, firewall host pihak ketiga) pada instance harus mengizinkan lalu lintas masuk pada port cek.

  4. Titik akhir aplikasi. Aplikasi harus mendengarkan pada port dan jalur yang Anda konfigurasikan. Konfirmasikan dengan permintaan lokal dari instance (curl http://localhost:PORT/PATH).

  5. Ketidakcocokan protokol. Jika pemeriksaan dikonfigurasi sebagai HTTPS tetapi titik akhir hanya melayani HTTP (atau sebaliknya), semua panggilan akan gagal.

  6. Pencocokan kode status. Konfirmasikan bahwa kode respons aktual aplikasi Anda disertakan dalam pencocokan kode status yang Anda konfigurasikan.

  7. 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.

  8. 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 ResponseCodeMatched danResponseCodeMismatch, StatusCode bidang berisi kode status HTTP yang dikembalikan dan Protocol bidang berisi protokol yang digunakan untuk pemeriksaan kesehatan. Untuk kesalahan koneksi, sepertiConnectionTimeout, ResponseTimeoutConnectionRefused,, danConnectionReset, Protocol bidang StatusCode dan tidak ada.

Protocol

Protokol yang digunakan untuk pemeriksaan kesehatan. Salah satu HTTP atauHTTPS.

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

200

Aplikasi mengembalikan respons yang berhasil.

Tidak ada. Ini biasanya status yang sehat.

301, 302

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.

401, 403

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.

404

Jalur pemeriksaan kesehatan yang dikonfigurasi tidak ditemukan pada aplikasi.

Konfirmasikan jalur cocok dengan rute yang dilayani aplikasi Anda.

500

Aplikasi mengembalikan kesalahan server internal.

Selidiki log aplikasi pada instance.

502, 503, 504

Aplikasi dapat dijangkau tetapi melaporkan masalah hulu atau kapasitas.

Selidiki kesehatan aplikasi, dependensi, dan kapasitas. Jika aplikasi Anda mengembalikan kode-kode ini selama startup, tingkatkanInitializationGracePeriodSeconds.

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.1 dan 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 InitializationGracePeriodSeconds nilainya, 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_Application rik 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.