Alarm-alarm yang direkomendasikan

4XXError

Dimensi:ApiName, Panggung

Deskripsi alarm: Alarm ini mendeteksi tingkat kesalahan sisi klien yang tinggi. Hal ini dapat menunjukkan adanya masalah dalam parameter otorisasi atau permintaan klien. Hal ini juga bisa berarti bahwa sebuah sumber daya telah dihapus atau klien meminta sesuatu yang tidak ada. Pertimbangkan untuk mengaktifkan CloudWatch Log dan memeriksa kesalahan apa pun yang mungkin menyebabkan kesalahan 4XX. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk melihat metrik ini per sumber daya dan metode dan mempersempit sumber kesalahan. Kesalahan juga dapat disebabkan karena dilanggarnya batas throttling yang telah dikonfigurasi sebelumnya. Jika respons dan log melaporkan tingkat kesalahan sebanyak 429, jumlah yang tinggi dan tidak terduga, maka Anda harus mengikuti panduan ini untuk memecahkan masalah tersebut.

Maksud: Alarm ini dapat mendeteksi tingkat kesalahan sisi klien yang tinggi untuk permintaan API Gateway.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan yang akan mendeteksi ketika lebih dari 5% dari total permintaan mendapatkan kesalahan 4XX. Namun demikian, Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan serta tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi dan kemudian menyetel ambang batas yang sesuai. Kesalahan 4XX yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

5XXError

Dimensi:ApiName, Panggung

Deskripsi alarm: Alarm ini akan membantu dalam mendeteksi tingkat kesalahan sisi server yang tinggi. Hal ini dapat menunjukkan bahwa ada sesuatu yang salah pada backend API, jaringan, atau integrasi antara gateway API dan backend API. Dokumentasi ini dapat membantu Anda dalam memecahkan masalah yang menjadi penyebab terjadinya kesalahan 5xx.

Maksud: Alarm ini dapat mendeteksi tingkat kesalahan sisi server yang tinggi untuk permintaan API Gateway.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan yang akan mendeteksi ketika lebih dari 5% dari total permintaan mendapatkan kesalahan 5XX. Namun demikian, Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan serta tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi dan kemudian menyetel ambang batas yang sesuai dengan itu. Kesalahan 5XX yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

Hitungan

Dimensi:ApiName, Panggung

Deskripsi alarm: Alarm ini akan membantu dalam mendeteksi volume lalu lintas rendah untuk tahap API REST. Hal ini bisa menjadi indikator akan adanya masalah dengan aplikasi yang memanggil API, seperti misalnya penggunaan titik akhir yang salah. Ini juga bisa menjadi indikator dari terjadinya masalah dengan konfigurasi atau izin API sehingga tidak dapat dijangkau oleh klien.

Maksud: Alarm ini dapat mendeteksi volume lalu lintas rendah secara tak terduga untuk tahap API REST. Kami menyarankan Anda untuk membuat alarm ini jika API Anda menerima jumlah permintaan yang dapat diprediksi dan konsisten dalam kondisi normal. Jika Anda mengaktifkan CloudWatch metrik terperinci dan Anda dapat memprediksi volume lalu lintas normal per metode dan sumber daya, kami sarankan Anda membuat alarm alternatif agar pemantauan penurunan volume lalu lintas yang lebih halus untuk setiap sumber daya dan metode. Alarm ini tidak disarankan untuk API yang diperkirakan memiliki lalu lintas yang tidak konstan dan konsisten.

Statistik: SampleCount

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan ambang batas berdasarkan analisis data historis untuk menentukan jumlah permintaan dasar yang Anda perkirakan untuk API Anda. Menetapkan ambang batas pada nilai yang sangat tinggi akan dapat menyebabkan alarm menjadi terlalu sensitif pada periode lalu lintas normal dan perkiraan lalu lintas rendah. Sebaliknya, menetapkan ambang batas pada nilai yang sangat rendah akan dapat menyebabkan alarm tidak mendeteksi penurunan volume lalu lintas yang lebih kecil.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

Hitungan

Dimensi:ApiName, Panggung, Sumber Daya, Metode

Deskripsi alarm: Alarm ini akan membantu dalam mendeteksi volume lalu lintas rendah untuk sumber daya dan metode API REST dalam tahap. Hal ini bisa menunjukkan adanya masalah dengan aplikasi yang memanggil API, seperti misalnya penggunaan titik akhir yang salah. Ini juga bisa menjadi indikator dari terjadinya masalah dengan konfigurasi atau izin API sehingga tidak dapat dijangkau oleh klien.

Maksud: Alarm ini dapat mendeteksi volume lalu lintas rendah secara tak terduga untuk sumber daya dan metode API REST dalam tahap. Kami menyarankan Anda untuk membuat alarm ini jika API Anda menerima jumlah permintaan yang dapat diprediksi dan konsisten dalam kondisi normal. Alarm ini tidak disarankan untuk API yang diperkirakan memiliki lalu lintas yang tidak konstan dan konsisten.

Statistik: SampleCount

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan ambang batas berdasarkan analisis data historis untuk menentukan jumlah permintaan dasar yang Anda perkirakan untuk API Anda. Menetapkan ambang batas pada nilai yang sangat tinggi akan dapat menyebabkan alarm menjadi terlalu sensitif pada periode lalu lintas normal dan perkiraan lalu lintas rendah. Sebaliknya, menetapkan ambang batas pada nilai yang sangat rendah akan dapat menyebabkan alarm tidak mendeteksi penurunan volume lalu lintas yang lebih kecil.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

Hitungan

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini akan membantu dalam mendeteksi volume lalu lintas rendah untuk tahap API HTTP. Hal ini bisa menunjukkan adanya masalah dengan aplikasi yang memanggil API, seperti misalnya penggunaan titik akhir yang salah. Ini juga bisa menjadi indikator dari terjadinya masalah dengan konfigurasi atau izin API sehingga tidak dapat dijangkau oleh klien.

Maksud: Alarm ini dapat mendeteksi volume lalu lintas rendah secara tak terduga untuk tahap API HTTP. Kami menyarankan Anda untuk membuat alarm ini jika API Anda menerima jumlah permintaan yang dapat diprediksi dan konsisten dalam kondisi normal. Jika Anda mengaktifkan CloudWatch metrik terperinci dan Anda dapat memprediksi volume lalu lintas normal per rute, kami sarankan Anda membuat alarm alternatif untuk ini agar pemantauan penurunan volume lalu lintas yang lebih halus untuk setiap rute. Alarm ini tidak disarankan untuk API yang diperkirakan memiliki lalu lintas yang tidak konstan dan konsisten.

Statistik: SampleCount

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan nilai ambang batas berdasarkan analisis data historis untuk menentukan jumlah permintaan dasar yang Anda perkirakan untuk API Anda. Menetapkan ambang batas pada nilai yang sangat tinggi akan dapat menyebabkan alarm menjadi terlalu sensitif pada periode lalu lintas normal dan perkiraan lalu lintas rendah. Sebaliknya, menetapkan ambang batas pada nilai yang sangat rendah akan dapat menyebabkan alarm tidak mendeteksi penurunan volume lalu lintas yang lebih kecil.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

Hitungan

Dimensi:ApiId, Panggung, Sumber Daya, Metode

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi volume lalu lintas rendah untuk rute API HTTP dalam tahap. Hal ini bisa menunjukkan adanya masalah dengan aplikasi yang memanggil API, seperti misalnya penggunaan titik akhir yang salah. Hal ini juga bisa menunjukkan adanya masalah dengan konfigurasi atau izin API sehingga tidak dapat dijangkau oleh klien.

Maksud: Alarm ini dapat mendeteksi volume lalu lintas rendah secara tak terduga untuk rute API HTTP dalam tahap. Kami menyarankan Anda untuk membuat alarm ini jika API Anda menerima jumlah permintaan yang dapat diprediksi dan konsisten dalam kondisi normal. Alarm ini tidak disarankan untuk API yang diperkirakan memiliki lalu lintas yang tidak konstan dan konsisten.

Statistik: SampleCount

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan nilai ambang batas berdasarkan analisis data historis untuk menentukan jumlah permintaan dasar yang Anda perkirakan untuk API Anda. Menetapkan ambang batas pada nilai yang sangat tinggi akan dapat menyebabkan alarm menjadi terlalu sensitif pada periode lalu lintas normal dan perkiraan lalu lintas rendah. Sebaliknya, menetapkan ambang batas pada nilai yang sangat rendah akan dapat menyebabkan alarm tidak mendeteksi penurunan volume lalu lintas yang lebih kecil.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

IntegrationLatency

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi apakah ada latensi integrasi tinggi untuk permintaan API dalam suatu tahap. Anda dapat mengkorelasikan nilai metrik IntegrationLatency dengan metrik latensi yang sesuai dari backend Anda seperti metrik Duration untuk integrasi Lambda. Hal ini membantu Anda dalam menentukan apakah API backend membutuhkan lebih banyak waktu untuk memproses permintaan dari klien karena masalah performa, atau apakah ada overhead lain dari inisialisasi atau cold start. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch Log untuk API Anda dan memeriksa log untuk setiap kesalahan yang mungkin menyebabkan masalah latensi tinggi. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk mendapatkan tampilan metrik ini per rute, untuk membantu Anda mempersempit sumber latensi integrasi.

Maksud: Alarm ini dapat mendeteksi kapan permintaan API Gateway dalam satu tahap memiliki latensi integrasi yang tinggi. Kami merekomendasikan alarm ini untuk WebSocket API, dan kami menganggapnya opsional untuk API HTTP karena mereka sudah memiliki rekomendasi alarm terpisah untuk metrik Latensi. Jika CloudWatch metrik mendetail telah diaktifkan dan Anda memiliki persyaratan kinerja latensi integrasi yang berbeda per rute, kami sarankan Anda membuat alarm alternatif agar memiliki pemantauan latensi integrasi yang lebih halus untuk setiap rute.

Statistik: p90

Ambang batas yang disarankan: 2000,0

Pembenaran ambang batas: Nilai ambang yang disarankan tidak akan berfungsi untuk semua beban kerja API. Namun demikian, Anda dapat menggunakannya sebagai titik awal untuk ambang batas tersebut. Anda kemudian dapat memilih nilai ambang batas yang berbeda berdasarkan beban kerja dan persyaratan latensi, performa, dan SLA yang dapat diterima untuk API. Jika API dapat diterima untuk memiliki latensi yang lebih tinggi secara umum, maka Anda harus menetapkan nilai ambang batas yang lebih tinggi untuk membuat alarm tersebut menjadi kurang sensitif. Namun demikian, jika API tersebut Anda harapkan dapat memberikan respons mendekati waktu nyata, maka Anda harus menetapkan nilai ambang batas yang lebih rendah. Anda juga dapat menganalisis data historis untuk menentukan latensi dasar yang diharapkan untuk beban kerja aplikasi, dan kemudian menggunakannya untuk menyetel nilai ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

Dimensi:ApiId, Panggung, Rute

Deskripsi alarm: Alarm ini membantu mendeteksi apakah ada latensi integrasi tinggi untuk permintaan WebSocket API untuk rute dalam satu tahap. Anda dapat mengkorelasikan nilai metrik IntegrationLatency dengan metrik latensi yang sesuai dari backend Anda seperti metrik Duration untuk integrasi Lambda. Hal ini akan membantu Anda dalam menentukan apakah API backend membutuhkan lebih banyak waktu untuk memproses permintaan dari klien karena adanya masalah performa atau apakah ada beberapa overhead lain dari inisialisasi atau cold start. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch Log untuk API Anda dan memeriksa log untuk setiap kesalahan yang mungkin menyebabkan masalah latensi tinggi.

Maksud: Alarm ini dapat mendeteksi kapan permintaan API Gateway untuk sebuah rute dalam satu tahap memiliki latensi integrasi yang tinggi.

Statistik: p90

Ambang batas yang disarankan: 2000,0

Pembenaran ambang batas: Nilai ambang yang disarankan tidak akan berfungsi untuk semua beban kerja API. Namun demikian, Anda dapat menggunakannya sebagai titik awal untuk ambang batas tersebut. Anda kemudian dapat memilih nilai ambang batas yang berbeda berdasarkan beban kerja dan persyaratan latensi, performa, dan SLA yang dapat diterima untuk API. Jika API dapat diterima untuk memiliki latensi yang lebih tinggi secara umum, maka Anda dapat menetapkan nilai ambang batas yang lebih tinggi untuk membuat alarm tersebut menjadi tidak begitu sensitif. Namun demikian, jika API tersebut Anda harapkan dapat memberikan respons mendekati waktu nyata, maka Anda harus menetapkan nilai ambang batas yang lebih rendah. Anda juga dapat menganalisis data historis untuk menentukan latensi dasar yang diharapkan untuk beban kerja aplikasi, dan kemudian menggunakannya untuk menyetel nilai ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latensi

Dimensi:ApiName, Panggung

Deskripsi alarm: Alarm ini akan mendeteksi latensi tinggi dalam satu tahap. Temukan nilai metrik IntegrationLatency untuk memeriksa latensi API backend. Jika kedua metrik sebagian besar selaras, maka API backend akan menjadi sumber latensi yang lebih tinggi dan Anda harus menyelidiki masalah yang terjadi di sana. Pertimbangkan juga mengaktifkan CloudWatch Log dan memeriksa kesalahan yang mungkin menyebabkan latensi tinggi. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk melihat metrik ini per sumber daya dan metode dan mempersempit sumber latensi. Jika perlu, silakan lihat pemecahan masalah dengan Lambda atau panduan pemecahan masalah untuk titik akhir API yang dioptimalkan-edge.

Maksud: Alarm ini dapat mendeteksi kapan permintaan API Gateway dalam satu tahap memiliki latensi yang tinggi. Jika CloudWatch metrik mendetail telah diaktifkan dan Anda memiliki persyaratan kinerja latensi yang berbeda untuk setiap metode dan sumber daya, sebaiknya Anda membuat alarm alternatif agar pemantauan latensi yang lebih halus untuk setiap sumber daya dan metode.

Statistik: p90

Ambang batas yang disarankan: 2500,0

Pembenaran ambang batas: Nilai ambang batas yang disarankan tidak akan berfungsi untuk semua beban kerja API. Namun demikian, Anda dapat menggunakannya sebagai titik awal untuk ambang batas tersebut. Anda kemudian dapat memilih nilai ambang batas yang berbeda berdasarkan beban kerja dan persyaratan latensi, performa, dan SLA yang dapat diterima untuk API. Jika API dapat diterima untuk memiliki latensi yang lebih tinggi secara umum, maka Anda dapat menetapkan nilai ambang batas yang lebih tinggi untuk membuat alarm tersebut menjadi tidak begitu sensitif. Namun demikian, jika API tersebut Anda harapkan dapat memberikan respons mendekati waktu nyata, maka Anda harus menetapkan nilai ambang batas yang lebih rendah. Anda juga dapat menganalisis data historis untuk menentukan apa latensi dasar yang diharapkan untuk beban kerja aplikasi dan kemudian menggunakannya untuk menyetel nilai ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latensi

Dimensi:ApiName, Panggung, Sumber Daya, Metode

Deskripsi alarm: Alarm ini dapat mendeteksi latensi tinggi untuk sebuah sumber daya dan metode dalam satu tahap. Temukan nilai metrik IntegrationLatency untuk memeriksa latensi API backend. Jika kedua metrik sebagian besar selaras, maka API backend akan menjadi sumber latensi yang lebih tinggi dan Anda harus menyelidiki masalah performa yang terjadi di sana. Pertimbangkan juga mengaktifkan CloudWatch Log dan memeriksa kesalahan apa pun yang mungkin menyebabkan latensi tinggi. Jika perlu, Anda juga dapat melihat pemecahan masalah dengan Lambda atau panduan pemecahan masalah untuk titik akhir API yang dioptimalkan-edge.

Maksud: Alarm ini dapat mendeteksi kapan permintaan API Gateway untuk sebuah sumber daya dan metode dalam satu tahap memiliki latensi yang tinggi.

Statistik: p90

Ambang batas yang disarankan: 2500,0

Pembenaran ambang batas: Nilai ambang yang disarankan tidak akan berfungsi untuk semua beban kerja API. Namun demikian, Anda dapat menggunakannya sebagai titik awal untuk ambang batas tersebut. Anda kemudian dapat memilih nilai ambang batas yang berbeda berdasarkan beban kerja dan persyaratan latensi, performa, dan SLA yang dapat diterima untuk API. Jika API dapat diterima untuk memiliki latensi yang lebih tinggi secara umum, maka Anda dapat menetapkan nilai ambang batas yang lebih tinggi untuk membuat alarm tersebut menjadi tidak begitu sensitif. Namun demikian, jika API tersebut Anda harapkan dapat memberikan respons mendekati waktu nyata, maka Anda harus menetapkan nilai ambang batas yang lebih rendah. Anda juga dapat menganalisis data historis untuk menentukan latensi dasar yang diharapkan untuk beban kerja aplikasi dan kemudian menggunakannya untuk menyetel nilai ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latensi

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini akan mendeteksi latensi tinggi dalam satu tahap. Temukan nilai metrik IntegrationLatency untuk memeriksa latensi API backend. Jika kedua metrik sebagian besar selaras, maka API backend akan menjadi sumber latensi yang lebih tinggi dan Anda harus menyelidiki masalah performa yang terjadi di sana. Pertimbangkan juga mengaktifkan CloudWatch Log dan memeriksa kesalahan apa pun yang mungkin menyebabkan latensi tinggi. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk melihat metrik ini per rute dan mempersempit sumber latensi. Anda juga dapat melihat panduan pemecahan masalah dengan integrasi Lambda, jika perlu.

Maksud: Alarm ini dapat mendeteksi kapan permintaan API Gateway dalam satu tahap memiliki latensi yang tinggi. Jika CloudWatch metrik mendetail telah diaktifkan dan Anda memiliki persyaratan kinerja latensi yang berbeda per rute, kami sarankan Anda membuat alarm alternatif agar pemantauan latensi yang lebih halus untuk setiap rute.

Statistik: p90

Ambang batas yang disarankan: 2500,0

Pembenaran ambang batas: Nilai ambang yang disarankan tidak akan berfungsi untuk semua beban kerja API. Namun demikian, ia dapat Anda gunakan sebagai titik awal untuk ambang batas tersebut. Anda kemudian dapat memilih nilai ambang batas yang berbeda berdasarkan beban kerja dan persyaratan latensi, performa dan SLA yang dapat diterima untuk API. Jika API tersebut dapat diterima untuk memiliki latensi yang lebih tinggi secara umum, maka Anda dapat menetapkan nilai ambang batas yang lebih tinggi agar API menjadi tidak begitu sensitif. Namun demikian, jika API diharapkan untuk memberikan respons mendekati waktu nyata, maka Anda harus menetapkan nilai ambang batas yang lebih rendah. Anda juga dapat menganalisis data historis untuk menentukan latensi dasar yang diharapkan untuk beban kerja aplikasi dan kemudian menggunakannya untuk menyetel nilai ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latensi

Dimensi:ApiId, Panggung, Sumber Daya, Metode

Deskripsi alarm: Alarm ini dapat mendeteksi latensi tinggi untuk sebuah rute dalam satu tahap. Temukan nilai metrik IntegrationLatency untuk memeriksa latensi API backend. Jika kedua metrik sebagian besar selaras, maka API backend akan menjadi sumber latensi yang lebih tinggi dan Anda harus menyelidiki masalah performa yang terjadi. Pertimbangkan juga mengaktifkan CloudWatch log dan memeriksa kesalahan apa pun yang mungkin menyebabkan latensi tinggi. Anda juga dapat melihat panduan pemecahan masalah dengan integrasi Lambda, jika perlu.

Maksud: Alarm ini dapat digunakan untuk mendeteksi kapan permintaan API Gateway untuk sebuah rute dalam satu tahap memiliki latensi yang tinggi.

Statistik: p90

Ambang batas yang disarankan: 2500,0

Pembenaran ambang batas: Nilai ambang yang disarankan tidak akan berfungsi untuk semua beban kerja API. Namun demikian, ia dapat Anda gunakan sebagai titik awal untuk ambang batas tersebut. Anda kemudian dapat memilih nilai ambang batas yang berbeda berdasarkan beban kerja dan persyaratan latensi, performa, dan SLA yang dapat diterima untuk API. Jika API dapat diterima untuk memiliki latensi yang lebih tinggi secara umum, maka Anda dapat menetapkan nilai ambang batas yang lebih tinggi untuk membuat alarm tersebut menjadi tidak begitu sensitif. Namun demikian, jika API tersebut Anda harapkan dapat memberikan respons mendekati waktu nyata, maka Anda harus menetapkan nilai ambang batas yang lebih rendah. Anda juga dapat menganalisis data historis untuk menentukan latensi dasar yang diharapkan untuk beban kerja aplikasi dan kemudian menggunakannya untuk menyetel nilai ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4xx

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini mendeteksi tingkat kesalahan sisi klien yang tinggi. Hal ini dapat menunjukkan adanya masalah dalam parameter otorisasi atau permintaan klien. Hal ini juga bisa berarti bahwa sebuah rute telah dihapus atau klien meminta sesuatu yang tidak ada dalam API. Pertimbangkan untuk mengaktifkan CloudWatch Log dan memeriksa kesalahan apa pun yang mungkin menyebabkan kesalahan 4xx. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk melihat metrik ini per rute, untuk membantu Anda mempersempit sumber kesalahan. Kesalahan juga bisa disebabkan karena dilanggarnya batas throttling yang telah dikonfigurasi sebelumnya. Jika respons dan log melaporkan tingkat kesalahan sebanyak 429, jumlah yang tinggi dan tidak terduga, maka Anda harus mengikuti panduan ini untuk memecahkan masalah tersebut.

Maksud: Alarm ini dapat mendeteksi tingkat kesalahan sisi klien yang tinggi untuk permintaan API Gateway.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan yang akan mendeteksi ketika lebih dari 5% dari total permintaan mendapatkan kesalahan 4xx. Namun demikian, Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan serta tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi dan kemudian menyetel ambang batas yang sesuai. Kesalahan 4xx yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

5xx

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini akan membantu dalam mendeteksi tingkat kesalahan sisi server yang tinggi. Hal ini dapat menunjukkan bahwa ada sesuatu yang salah pada backend API, jaringan, atau integrasi antara gateway API dan backend API. Dokumentasi ini dapat membantu Anda memecahkan masalah penyebab terjadinya kesalahan 5xx.

Maksud: Alarm ini dapat mendeteksi tingkat kesalahan sisi server yang tinggi untuk permintaan API Gateway.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan yang akan mendeteksi ketika lebih dari 5% dari total permintaan mendapatkan kesalahan 5xx. Namun demikian, Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan serta tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas sesuai dengan itu. Kesalahan 5xx yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

MessageCount

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini membantu mendeteksi volume lalu lintas rendah untuk tahap WebSocket API. Hal ini dapat menunjukkan adanya masalah saat klien memanggil API, seperti penggunaan titik akhir yang salah, atau terjadinya masalah dengan backend yang mengirim pesan ke klien. Hal ini juga bisa menunjukkan adanya masalah dengan konfigurasi atau izin API, sehingga API tidak dapat dijangkau oleh klien.

Maksud: Alarm ini dapat mendeteksi volume lalu lintas rendah secara tak terduga untuk tahap API. WebSocket Kami menyarankan Anda untuk membuat alarm ini jika API Anda menerima dan mengirimkan jumlah pesan yang dapat diprediksi dan tetap konsisten dalam kondisi normal. Jika Anda mengaktifkan CloudWatch metrik terperinci dan Anda dapat memprediksi volume lalu lintas normal per rute, lebih baik membuat alarm alternatif untuk yang satu ini, agar pemantauan penurunan volume lalu lintas yang lebih halus untuk setiap rute. Kami tidak merekomendasikan alarm ini untuk API yang diperkirakan tidak memiliki lalu lintas yang konstan dan konsisten.

Statistik: SampleCount

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan nilai ambang batas berdasarkan analisis data historis untuk menentukan jumlah pesan dasar yang Anda perkirakan untuk API Anda. Menetapkan ambang batas dengan nilai yang sangat tinggi akan dapat menyebabkan alarm menjadi terlalu sensitif pada periode lalu lintas normal dan perkiraan lalu lintas rendah. Sebaliknya, menetapkan ambang batas dengan nilai yang sangat rendah akan dapat menyebabkan alarm tidak mendeteksi penurunan volume lalu lintas yang lebih kecil.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

MessageCount

Dimensi:ApiId, Panggung, Rute

Deskripsi alarm: Alarm ini membantu mendeteksi volume lalu lintas rendah untuk rute WebSocket API di panggung. Hal ini dapat menunjukkan adanya masalah pada klien yang memanggil API, seperti penggunaan titik akhir yang salah, atau terjadinya masalah dengan backend yang mengirim pesan ke klien. Hal ini juga bisa menunjukkan adanya masalah dengan konfigurasi atau izin API, sehingga API tidak dapat dijangkau oleh klien.

Maksud: Alarm ini dapat mendeteksi volume lalu lintas rendah secara tak terduga untuk rute WebSocket API di panggung. Kami menyarankan Anda untuk membuat alarm ini jika API Anda menerima dan mengirimkan jumlah pesan yang dapat diprediksi dan tetap konsisten dalam kondisi normal. Kami tidak merekomendasikan alarm ini untuk API yang diperkirakan tidak memiliki lalu lintas yang konstan dan konsisten.

Statistik: SampleCount

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan ambang batas berdasarkan analisis data historis untuk menentukan jumlah pesan dasar yang Anda perkirakan untuk API Anda. Menetapkan ambang batas dengan nilai yang sangat tinggi akan dapat menyebabkan alarm menjadi terlalu sensitif pada periode lalu lintas normal dan perkiraan lalu lintas rendah. Sebaliknya, menetapkan ambang batas dengan nilai yang sangat rendah akan dapat menyebabkan alarm tidak mendeteksi penurunan volume lalu lintas yang lebih kecil.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

ClientError

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini akan mendeteksi tingkat kesalahan klien yang tinggi. Hal ini dapat menunjukkan adanya masalah dalam parameter otorisasi atau pesan. Hal ini juga bisa berarti bahwa sebuah rute telah dihapus atau klien meminta sesuatu yang tidak ada dalam API. Pertimbangkan untuk mengaktifkan CloudWatch Log dan memeriksa kesalahan apa pun yang mungkin menyebabkan kesalahan 4xx. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk melihat metrik ini per rute, untuk membantu Anda mempersempit sumber kesalahan. Kesalahan juga dapat disebabkan karena dilanggarnya batas throttling yang telah dikonfigurasi sebelumnya. Jika respons dan log melaporkan tingkat kesalahan sebanyak 429, jumlah yang tinggi dan tidak terduga, maka Anda harus mengikuti panduan ini untuk memecahkan masalah tersebut.

Maksud: Alarm ini dapat mendeteksi tingkat kesalahan klien yang tinggi untuk pesan WebSocket API Gateway.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan yang akan mendeteksi ketika lebih dari 5% dari total permintaan mendapatkan kesalahan 4xx. Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan serta sesuai dengan tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai. Kesalahan 4xx yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ExecutionError

Dimensi:ApiId, Panggung

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi tingkat kesalahan eksekusi yang tinggi. Hal ini dapat disebabkan oleh adanya kesalahan 5xx dari integrasi Anda, permasalahan izin, atau faktor lain yang mencegah berhasilnya invokasi atas integrasi, seperti integrasi yang dibatasi atau dihapus. Pertimbangkan untuk mengaktifkan CloudWatch Log untuk API Anda dan memeriksa log untuk jenis dan penyebab kesalahan. Selain itu, pertimbangkan untuk mengaktifkan CloudWatch metrik terperinci untuk mendapatkan tampilan metrik ini per rute, untuk membantu Anda mempersempit sumber kesalahan. Dokumentasi ini juga dapat membantu Anda dalam memecahkan masalah penyebab terjadinya kesalahan koneksi.

Maksud: Alarm ini dapat mendeteksi tingkat kesalahan eksekusi yang tinggi untuk pesan WebSocket API Gateway.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan yang akan mendeteksi ketika lebih dari 5% dari total permintaan mendapatkan kesalahan eksekusi. Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan, dan sesuai dengan tingkat kesalahan yang dapat diterima. Anda dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai. Kesalahan eksekusi yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

GroupInServiceCapacity

Dimensi: AutoScalingGroupName

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi kapan kapasitas dalam grup berada di bawah kapasitas yang diinginkan yang diperlukan untuk beban kerja Anda. Untuk memecahkan masalah tersebut, Anda perlu memeriksa aktivitas penskalaan Anda, apakah ada kegagalan peluncuran yang terjadi, dan konfirmasikan apakah konfigurasi kapasitas yang Anda inginkan sudah dibuat dengan benar.

Maksud: Alarm ini dapat mendeteksi ketersediaan rendah di grup penskalaan otomatis (grup Auto Scaling) yang terjadi karena kegagalan peluncuran atau peluncuran yang ditangguhkan.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas harus dijadikan sebagai kapasitas minimum yang diperlukan untuk menjalankan beban kerja Anda. Dalam kebanyakan kasus, Anda dapat mengatur ini agar sesuai dengan GroupDesiredCapacity metrik.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

5 xxErrorRate

Dimensi:DistributionId, Wilayah = Global

Deskripsi alarm: Alarm ini memantau persentase respons kesalahan 5xx dari server asal Anda, untuk membantu Anda mendeteksi apakah CloudFront layanan mengalami masalah. Lihat Memecahkan masalah respons kesalahan dari server asal Anda untuk mendapatkan informasi yang akan membantu Anda memahami masalah yang terjadi pada server Anda. Selain itu, aktifkan metrik tambahan jika Anda ingin mendapatkan metrik kesalahan terperinci.

Maksud: Alarm ini digunakan untuk mendeteksi masalah dengan melayani permintaan dari server asal, atau masalah dengan komunikasi antara CloudFront dan server asal Anda.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang direkomendasikan untuk alarm ini sangat tergantung pada toleransi untuk respons 5xx. Anda dapat melakukan analisis data historis dan tren, dan kemudian Anda dapat menetapkan ambang batas yang sesuai. Karena kesalahan 5xx dapat disebabkan oleh masalah sementara, maka kami sarankan Anda untuk mengatur ambang batas ke nilai yang lebih besar dari 0 sehingga alarm tidak menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

OriginLatency

Dimensi:DistributionId, Wilayah = Global

Deskripsi alarm: Alarm ini dapat membantu Anda memantau apakah server asal terlalu lama untuk memberikan respons. Jika server membutuhkan waktu terlalu lama untuk memberi respons, hal itu mungkin akan menyebabkan habis waktu. Silakan lihat menemukan dan memperbaiki respons yang tertunda dari aplikasi di server asal Anda jika Anda terus-menerus mengalami nilai OriginLatency yang tinggi.

Maksud: Alarm ini dapat digunakan untuk mendeteksi masalah yang terjadi pada server asal yang terlalu lama dalam memberi respons.

Statistik: p90

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung nilainya sekitar 80% dari batas waktu respons asal, dan menggunakan hasilnya sebagai nilai ambang batas. Jika metrik ini terus-menerus mendekati nilai batas waktu respons asal, maka Anda mungkin mulai mengalami kesalahan 504.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

FunctionValidationErrors

Dimensi:DistributionId, FunctionName, Wilayah = Global

Deskripsi alarm: Alarm ini membantu Anda memantau kesalahan validasi dari CloudFront fungsi sehingga Anda dapat mengambil langkah-langkah untuk mengatasinya. Analisis log CloudWatch fungsi dan lihat kode fungsi untuk menemukan dan menyelesaikan akar penyebab masalah. Lihat Pembatasan fungsi tepi untuk memahami kesalahan konfigurasi umum untuk CloudFront Fungsi.

Maksud: Alarm ini digunakan untuk mendeteksi kesalahan validasi dari CloudFront fungsi.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Nilai yang lebih besar dari 0 menunjukkan terjadinya kesalahan validasi. Kami merekomendasikan pengaturan ambang batas ke 0 karena kesalahan validasi menyiratkan masalah ketika CloudFront fungsi diserahkan kembali. CloudFront Misalnya, CloudFront membutuhkan header Host HTTP untuk memproses permintaan. Tidak ada yang menghentikan pengguna untuk menghapus header Host dalam kode CloudFront fungsinya. Tetapi ketika CloudFront mendapat respons kembali dan header Host hilang, CloudFront melempar kesalahan validasi.

Periode: 60

Titik data untuk alarm: 2

Periode evaluasi: 2

Operator Perbandingan: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

Dimensi:DistributionId, FunctionName, Wilayah = Global

Deskripsi alarm: Alarm ini membantu Anda memantau kesalahan eksekusi dari CloudFront fungsi sehingga Anda dapat mengambil langkah-langkah untuk mengatasinya. Analisis log CloudWatch fungsi dan lihat kode fungsi untuk menemukan dan menyelesaikan akar penyebab masalah.

Maksud: Alarm ini digunakan untuk mendeteksi kesalahan eksekusi dari CloudFront fungsi.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Kami merekomendasikan Anda untuk mengatur ambang batasnya menjadi 0 karena kesalahan eksekusi menunjukkan adanya masalah dengan kode yang terjadi saat runtime.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

FunctionThrottles

Dimensi:DistributionId, FunctionName, Wilayah = Global

Deskripsi alarm: Alarm ini membantu Anda memantau jika CloudFront fungsi Anda dibatasi. Jika fungsi Anda dibatasi, maka itu berarti fungsi tersebut terlalu lama untuk melakukan eksekusi. Untuk menghindari pembatasan fungsi, Anda perlu mempertimbangkan untuk mengoptimalkan kode fungsi.

Maksud: Alarm ini dapat mendeteksi ketika CloudFront fungsi Anda dibatasi sehingga Anda dapat bereaksi dan menyelesaikan masalah untuk pengalaman pelanggan yang lancar.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Kami merekomendasikan Anda untuk mengatur ambang batasnya menjadi 0, hal ini untuk memungkinkan resolusi lebih cepat atas pembatasan fungsi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

SignUpThrottles

Dimensi:UserPool, UserPoolClient

Deskripsi alarm: Alarm ini dapat memantau jumlah permintaan yang dibatasi. Jika pengguna terus-menerus mengalami pembatasan, maka Anda harus meningkatkan batasnya dengan meminta peningkatan kuota layanan. Silakan lihat Kuota di Amazon Cognito untuk mempelajari cara meminta kenaikan kuota. Untuk melakukan tindakan-tindakan secara proaktif, Anda perlu mempertimbangkan untuk melacak kuota penggunaan.

Maksud: Alarm ini akan membantu Anda dalam memantau terjadinya permintaan pendaftaran yang dibatasi. Hal ini dapat membantu Anda mengetahui kapan harus melakukan tindakan-tindakan untuk mengurangi penurunan dalam pengalaman pendaftaran. Throttling permintaan yang terjadi terus-menerus adalah pengalaman pendaftaran pengguna yang negatif.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Kolam pengguna yang disediakan dengan baik seharusnya tidak mengalami throttling apa pun yang mencakup beberapa titik data. Jadi, ambang batas yang biasa digunakan untuk beban kerja yang diharapkan adalah nol. Untuk beban kerja yang tidak teratur dengan peningkatan beban tiba-tiba yang sering terjadi, Anda dapat melakukan analisis data historis untuk menentukan throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai. Permintaan yang dibatasi harus dicoba ulang untuk meminimalkan dampaknya terhadap aplikasi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

SignInThrottles

Dimensi:UserPool, UserPoolClient

Deskripsi alarm: Alarm ini dapat memantau jumlah permintaan autentikasi pengguna yang dibatasi. Jika pengguna terus-menerus mengalami pembatasan, maka Anda mungkin perlu meningkatkan batasnya dengan meminta peningkatan kuota layanan. Silakan lihat Kuota di Amazon Cognito untuk mempelajari cara meminta kenaikan kuota. Untuk melakukan tindakan-tindakan secara proaktif, Anda perlu mempertimbangkan untuk melacak kuota penggunaan.

Maksud: Alarm ini akan membantu Anda dalam memantau terjadinya permintaan masuk yang dibatasi. Hal ini dapat membantu Anda mengetahui kapan harus melakukan tindakan-tindakan untuk mengurangi penurunan dalam pengalaman masuk. Throttling permintaan yang terus-menerus terjadi akan menjadi pengalaman autentikasi pengguna yang buruk.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Kolam pengguna yang disediakan dengan baik seharusnya tidak mengalami throttling apa pun yang mencakup beberapa titik data. Jadi, ambang batas yang biasa digunakan untuk beban kerja yang diharapkan adalah nol. Untuk beban kerja yang tidak teratur dengan peningkatan beban tiba-tiba yang sering terjadi, Anda dapat melakukan analisis data historis untuk menentukan throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai. Permintaan yang dibatasi harus dicoba ulang untuk meminimalkan dampaknya terhadap aplikasi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

TokenRefreshThrottles

Dimensi:UserPool, UserPoolClient

Deskripsi alarm: Anda dapat mengatur nilai ambang batasnya agar sesuai dengan lalu lintas permintaan serta agar sesuai dengan throttling yang dapat diterima untuk permintaan penyegaran token. Throttling digunakan untuk melindungi sistem Anda dari terlalu banyaknya permintaan yang dikirimkan. Namun demikian, Anda juga harus memantau apakah Anda berada di bawah lalu lintas normal yang ditentukan. Anda dapat melakukan analisis data historis untuk menemukan throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas alarm Anda menjadi lebih tinggi dari tingkat throttling yang dapat diterima. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi/layanan karena pembatasan bersifat sementara. Oleh karena itu, menetapkan nilai ambang batas yang sangat rendah dapat menyebabkan alarm menjadi sensitif.

Maksud: Alarm ini akan membantu Anda dalam memantau terjadinya permintaan penyegaran token yang dibatasi. Hal ini dapat membantu Anda dalam mengetahui kapan harus melakukan tindakan untuk mengurangi potensi masalah, dan untuk memastikan pengalaman pengguna yang lancar serta kesehatan dan keandalan sistem autentikasi Anda. Throttling permintaan yang terus-menerus terjadi akan menjadi pengalaman autentikasi pengguna yang buruk.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batasnya juga dapat Anda atur agar sesuai dengan lalu lintas permintaan serta throttling yang dapat diterima untuk permintaan penyegaran token. Throttling ada untuk melindungi sistem Anda dari terlalu banyaknya permintaan yang dikirim, namun demikian, Anda juga harus memantau apakah Anda berada di bawah lalu lintas normal yang ditentukan dan memeriksa apakah hal itu yang menyebabkan dampak tersebut. Data historis juga dapat Anda analisis untuk melihat tingkat throttling yang dapat diterima untuk beban kerja aplikasi dan Anda kemudian dapat mengatur ambang batasnya lebih tinggi dari tingkat throttling yang dapat diterima yang biasa Anda gunakan. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi/layanan karena pembatasan bersifat sementara. Oleh karena itu, menetapkan nilai ambang batas yang sangat rendah dapat menyebabkan alarm menjadi sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

FederationThrottles

Dimensi:UserPool, UserPoolClient, IdentityProvider

Deskripsi alarm: Alarm ini dapat memantau jumlah permintaan federasi identitas yang dibatasi. Jika Anda terus-menerus melihat terjadinya throttling, hal itu mungkin menunjukkan bahwa Anda perlu meningkatkan batas dengan meminta peningkatan kuota layanan. Silakan lihat Kuota di Amazon Cognito untuk mempelajari cara meminta kenaikan kuota.

Maksud: Alarm ini akan membantu Anda dalam memantau terjadinya permintaan federasi identitas yang dibatasi. Hal ini dapat membantu Anda melakukan respons proaktif terhadap kemacetan performa atau kesalahan konfigurasi, dan memastikan pengalaman autentikasi yang lancar bagi pengguna Anda. Throttling permintaan yang terus-menerus terjadi akan menjadi pengalaman autentikasi pengguna yang buruk.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda dapat mengatur ambang batasnya agar sesuai dengan lalu lintas permintaan dan untuk menyesuaikannya dengan throttling yang dapat diterima untuk permintaan federasi identitas. Throttling digunakan untuk melindungi sistem Anda dari terlalu banyaknya permintaan yang dikirim. Namun demikian, Anda juga harus memantau apakah Anda berada di bawah lalu lintas normal yang ditentukan. Anda dapat melakukan analisis data historis untuk menemukan tingkat throttling yang dapat diterima untuk beban kerja aplikasi, dan Anda kemudian dapat menetapkan ambang batasnya dengan nilai yang lebih tinggi dari tingkat throttling yang dapat diterima. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi/layanan karena pembatasan bersifat sementara. Oleh karena itu, menetapkan nilai ambang batas yang sangat rendah dapat menyebabkan alarm menjadi sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

AccountProvisionedReadCapacityUtilization

Dimensi: Tidak ada

Deskripsi alarm: Alarm ini akan mendeteksi apakah kapasitas baca akun telah mencapai batas yang ditentukan. Jika hal ini terjadi, maka Anda dapat menaikkan kuota akun untuk pemanfaatan kapasitas baca. Anda dapat melihat kuota untuk unit kapasitas baca Anda saat ini dan meminta peningkatan dengan menggunakan Kuota Layanan.

Maksud: Alarm ini dapat mendeteksi apakah pemanfaatan kapasitas baca akun sudah mendekati pemanfaatan kapasitas baca yang disediakan. Jika pemanfaatan tersebut telah mencapai batas maksimumnya, maka DynamoDB akan mulai membatasi permintaan baca.

Statistik: Maksimum

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Tetapkan ambang batas menjadi 80%, sehingga tindakan (seperti menaikkan batas akun) dapat dilakukan sebelum mencapai kapasitas penuh untuk menghindari terjadinya throttling.

Periode: 300

Titik data untuk alarm: 2

Periode evaluasi: 2

Operator Perbandingan: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

Dimensi: Tidak ada

Deskripsi alarm: Alarm ini akan mendeteksi apakah kapasitas tulis akun telah mencapai batas yang ditentukan. Jika hal ini terjadi, maka Anda dapat menaikkan kuota akun untuk pemanfaatan kapasitas tulis. Anda dapat melihat kuota untuk unit kapasitas tulis Anda saat ini dan meminta peningkatan dengan menggunakan Kuota Layanan.

Maksud: Alarm ini dapat mendeteksi apakah pemanfaatan kapasitas tulis akun sudah mendekati pemanfaatan kapasitas tulis yang disediakan. Jika pemanfaatan tersebut telah mencapai batas maksimumnya, maka DynamoDB akan mulai membatasi permintaan tulis.

Statistik: Maksimum

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Tetapkan ambang batas menjadi 80%, sehingga tindakan (seperti menaikkan batas akun) dapat dilakukan sebelum mencapai kapasitas penuh yang ditentukan untuk menghindari terjadinya throttling.

Periode: 300

Titik data untuk alarm: 2

Periode evaluasi: 2

Operator Perbandingan: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

Dimensi:TableName, DelegatedOperation

Deskripsi alarm: Alarm ini dapat mendeteksi penundaan pada replikasi ke aliran data Kinesis. Dalam operasi normal, AgeOfOldestUnreplicatedRecord seharusnya hanya memerlukan waktu milidetik. Jumlah ini akan semakin besar sesuai dengan upaya replikasi yang gagal yang disebabkan oleh pilihan konfigurasi yang dikendalikan pelanggan. Contoh konfigurasi yang dikendalikan oleh pelanggan yang menyebabkan upaya replikasi yang gagal adalah kapasitas aliran data Kinesis yang penyediaannya kurang yang menyebabkan terjadinya throttling yang berlebihan. atau pembaruan manual dapat dilakukan pada kebijakan akses aliran data Kinesis yang mencegah DynamoDB menambahkan data ke aliran data. Untuk menjaga metrik ini tetap berada pada tingkat serendah mungkin, Anda perlu memastikan bahwa penyediaan kapasitas aliran data Kinesis yang tepat telah dilakukan dan memastikan bahwa izin DynamoDB tidak berubah.

Maksud: Alarm ini dapat memantau upaya replikasi yang gagal dan penundaan replikasi yang diakibatkan terhadap aliran data Kinesis.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan penundaan replikasi yang diinginkan yang diukur dalam milidetik. Nilai ini tergantung pada persyaratan beban kerja Anda dan performa yang Anda harapkan.

Periode: 300

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

Dimensi:TableName, DelegatedOperation

Deskripsi alarm: Alarm ini dapat mendeteksi jumlah catatan yang gagal direplikasi oleh DynamoDB ke aliran data Kinesis Anda. Item tertentu yang ukurannya lebih besar dari 34 KB mungkin akan diperluas ukurannya untuk mengubah catatan data yang lebih besar dari batas ukuran item 1 MB dari Aliran Data Kinesis. Perluasan ukuran ini terjadi ketika item yang lebih besar dari 34 KB ini menyertakan sejumlah besar nilai atribut Boolean atau kosong. Nilai atribut Boolean dan kosong disimpan sebagai 1 byte di DynamoDB, namun diperluas hingga 5 byte saat diserialkan menggunakan JSON standar untuk replikasi Kinesis Data Streams. DynamoDB tidak dapat mereplikasi catatan perubahan tersebut ke aliran data Kinesis Anda. DynamoDB akan melewatkan catatan data perubahan ini, dan secara otomatis akan tetap melakukan replikasi atas catatan-catatan berikutnya.

Maksud: Alarm ini dapat memantau jumlah catatan yang gagal direplikasi oleh DynamoDB ke aliran data Kinesis Anda karena batas ukuran item Aliran Data Kinesis.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Anda harus menetapkan ambang batasnya menjadi 0 untuk mendeteksi catatan apa pun yang gagal direplikasi oleh DynamoDB.

Periode: 60

Titik data untuk alarm: 1

Periode evaluasi: 1

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensi: TableName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah ada banyak permintaan baca yang dibatasi untuk tabel DynamoDB. Untuk memecahkan masalah ini, silakan lihat Memecahkan masalah throttling di Amazon DynamoDB.

Maksud: Alarm ini dapat mendeteksi throttling yang berkelanjutan untuk permintaan baca ke tabel DynamoDB. Throttling permintaan baca yang berkelanjutan dapat berdampak negatif pada operasi pembacaan beban kerja Anda dan akan mengurangi efisiensi sistem secara keseluruhan.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan lalu lintas baca yang diharapkan untuk tabel DynamoDB, dan memperhitungkan tingkat throttling yang dapat diterima. Penting untuk memantau apakah Anda sedang mengalami kurang penyediaan dan bahwa hal itu tidak menyebabkan throttling yang terjadi terus-menerus Anda juga dapat melakukan analisis data historis untuk menemukan tingkat throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batasnya ke tingkat yang lebih tinggi dari level throttling yang biasa Anda gunakan. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi atau layanan karena pembatasan bersifat sementara. Oleh karena itu, ambang batas yang ditetapkan sangat rendah akan dapat menyebabkan alarm menjadi terlalu sensitif, dan menyebabkan perubahan status yang tidak diinginkan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensi:TableName, GlobalSecondaryIndexName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah ada banyak jumlah permintaan baca yang dibatasi untuk Indeks Sekunder Global dari tabel DynamoDB. Untuk memecahkan masalah ini, silakan lihat Memecahkan masalah throttling di Amazon DynamoDB.

Maksud: Alarm ini dapat mendeteksi adanya throttling yang terjadi secara berkelanjutan untuk permintaan baca untuk Indeks Sekunder Global dari Tabel DynamoDB. Throttling permintaan baca yang berkelanjutan dapat berdampak negatif pada operasi pembacaan beban kerja Anda dan akan mengurangi efisiensi sistem secara keseluruhan.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan lalu lintas baca yang diharapkan untuk tabel DynamoDB, dan memperhitungkan tingkat throttling yang dapat diterima. Penting untuk memantau apakah Anda sedang mengalami kurang penyediaan dan bahwa hal itu tidak menyebabkan throttling yang terjadi terus-menerus. Anda juga dapat melakukan analisis data historis untuk menemukan tingkat throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batasnya ke tingkat yang lebih tinggi dari level throttling yang dapat diterima yang biasa Anda gunakan. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi atau layanan karena pembatasan bersifat sementara. Oleh karena itu, ambang batas yang ditetapkan sangat rendah akan dapat menyebabkan alarm menjadi terlalu sensitif, dan menyebabkan perubahan status yang tidak diinginkan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReplicationLatency

Dimensi:TableName, ReceivingRegion

Deskripsi alarm: Alarm ini dapat mendeteksi apakah replika dalam sebuah Wilayah untuk tabel global tertinggal di belakang Wilayah sumber. Latensi dapat meningkat jika suatu AWS Wilayah terdegradasi dan Anda memiliki tabel replika di Wilayah tersebut. Dalam hal ini, Anda dapat mengalihkan sementara aktivitas baca dan tulis aplikasi Anda ke AWS Wilayah yang berbeda. Jika Anda menggunakan tabel global 2017.11.29 (Legacy) dari tabel global, maka Anda harus memverifikasi apakah unit kapasitas tulis (WCU) tersebut identik untuk masing-masing tabel replika. Anda juga dapat memastikan untuk mengikuti rekomendasi-rekomendasi yang diberikan dalam Praktik terbaik dan persyaratan untuk mengelola kapasitas.

Maksud: Alarm ini dapat mendeteksi apakah tabel replika di sebuah Wilayah tertinggal untuk mereplikasi perubahan yang datang dari Wilayah lain. Hal ini dapat menyebabkan replika Anda menyimpang dari replika-replika lainnya. Sangat berguna untuk mengetahui latensi replikasi setiap AWS Wilayah dan memperingatkan jika latensi replikasi itu terus meningkat. Replikasi tabel hanya berlaku untuk tabel global.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat tergantung pada kasus penggunaan Anda. Latensi replikasi dengan durasi lebih dari 3 menit biasanya akan menjadi penyebab dimulainya penyelidikan. Lakukan peninjauan kekritisan dan persyaratan penundaan replikasi dan lakukan analisis tren historis, dan kemudian pilih ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

Dimensi:TableName, Operasi

Deskripsi alarm: Alarm ini dapat mendeteksi latensi tinggi untuk operasi tabel DynamoDB (ditunjukkan oleh nilai dimensi dari Operation pada alarm tersebut). Silakan lihat dokumen pemecahan masalah ini untuk mengatasi terjadinya masalah latensi di Amazon DynamoDB.

Maksud: Alarm ini akan dapat mendeteksi latensi tinggi untuk operasi tabel DynamoDB. Latensi yang lebih tinggi untuk operasi akan dapat berdampak negatif pada efisiensi sistem secara keseluruhan.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: DynamoDB menyediakan latensi milidetik satu digit rata-rata untuk operasi tunggal seperti,, dan sebagainya. GetItem PutItem Namun demikian, Anda dapat mengatur ambang batasnya berdasarkan toleransi yang dapat diterima untuk latensi untuk jenis operasi dan tabel yang digunakan dalam beban kerja. Anda dapat melakukan analisis data historis dari metrik ini untuk menemukan latensi yang biasanya terjadi untuk operasi tabel, dan kemudian Anda dapat mengatur ambang batasnya ke angka yang mewakili penundaan kritis untuk operasi tersebut.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

SystemErrors

Dimensi: TableName

Deskripsi alarm: Alarm ini dapat mendeteksi sejumlah besar kesalahan sistem yang terjadi terus-menerus untuk permintaan tabel DynamoDB. Jika Anda masih tetap mendapatkan kesalahan 5xx, silakan buka AWS Service Health Dashboard untuk memeriksa apakah terjadi masalah operasional dengan layanan. Anda dapat menggunakan alarm ini untuk mendapatkan pemberitahuan jika ada masalah yang terjadi terhadap layanan internal yang berkepanjangan atas DynamoDB dan hal ini akan membantu Anda mengorelasikan diri Anda dengan masalah yang dihadapi oleh aplikasi klien Anda. Silakan lihat Penanganan kesalahan untuk DynamoDB, untuk mendapatkan informasi lebih lanjut mengenai hal ini.

Maksud: Alarm ini dapat mendeteksi terjadinya kesalahan sistem yang berkelanjutan untuk permintaan tabel DynamoDB. Kesalahan sistem ini menunjukkan adanya kesalahan dalam layanan internal dari DynamoDB dan akan membantu Anda dalam mengorelasikan diri Anda dengan masalah yang dialami oleh klien Anda.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan lalu lintas yang Anda harapkan, yang memperhitungkan tingkat kesalahan sistem yang dapat diterima. Anda juga dapat melakukan analisis data historis untuk menemukan jumlah kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai. Kesalahan-kesalahan sistem harus dicoba ulang oleh aplikasi/layanan karena kesalahan tersebut bersifat sementara. Oleh karena itu, ambang batas yang ditetapkan sangat rendah akan dapat membuat alarm menjadi terlalu sensitif, dan menyebabkan perubahan status yang tidak diinginkan.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

Dimensi:TableName, DelegatedOperation

Deskripsi alarm: Alarm ini dapat mendeteksi catatan-catatan yang terhambat oleh aliran data Kinesis Anda selama dilakukan replikasi pengambilan data perubahan ke Kinesis. Throttling ini disebabkan oleh kapasitas aliran data Kinesis yang tidak mencukupi. Jika Anda mengalami throttling yang berlebihan dan secara rutin, maka Anda mungkin perlu meningkatkan jumlah serpihan aliran Kinesis secara proporsional dengan throughput tulis yang diamati pada tabel Anda. Untuk mempelajari selengkapnya tentang menentukan ukuran aliran data Kinesis, silakan lihat Menentukan Ukuran Awal Aliran Data Kinesis.

Maksud: Alarm ini dapat memantau jumlah data yang dibatasi oleh aliran data Kinesis karena kapasitas aliran data Kinesis tidak mencukupi.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda mungkin mengalami beberapa throttling selama puncak penggunaan yang luar biasa, tetapi catatan-catatan yang dibatasi harus tetap berada pada tingkat serendah mungkin untuk menghindari latensi replikasi yang lebih tinggi (DynamoDB akan mencoba lagi mengirimkan catatan-catatan yang dibatasi ke aliran data Kinesis). Anda harus mengatur ambang batasnya ke angka yang dapat membantu Anda dalam mengatasi throttling berlebihan yang terjadi secara rutin. Anda juga dapat melakukan analisis data historis mengenai metrik ini untuk menemukan tingkat throttling yang dapat diterima untuk beban kerja aplikasi. Anda kemudian harus mengatur ambang batasnya ke nilai yang dapat ditoleransi oleh aplikasi Anda berdasarkan kasus penggunaan Anda.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

UserErrors

Dimensi: Tidak ada

Deskripsi alarm: Alarm ini dapat mendeteksi sejumlah besar kesalahan pengguna yang terjadi terus-menerus untuk permintaan tabel DynamoDB. Anda dapat memeriksa log aplikasi klien selama kerangka waktu terjadinya masalah untuk memeriksa penyebab yang membuat permintaan menjadi tidak valid. Anda dapat memeriksa kode status HTTP 400 untuk melihat jenis kesalahan apa yang Anda alami dan kemudian melakukan tindakan yang semestinya. Anda mungkin juga harus memperbaiki logika aplikasi untuk membuat permintaan yang valid.

Maksud: Alarm ini dapat mendeteksi terjadinya kesalahan pengguna yang berkelanjutan untuk permintaan tabel DynamoDB. Terjadinya kesalahan pengguna untuk operasi yang diminta menandakan bahwa klien membuat permintaan yang tidak valid dan gagal.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas ke nol untuk mendeteksi kesalahan yang terjadi pada sisi klien. Atau Anda dapat mengaturnya ke nilai yang lebih tinggi jika Anda tidak ingin membuat alarm yang aktif karena jumlah kesalahan yang sangat rendah. Anda harus membuat keputusan berdasarkan kasus penggunaan dan lalu lintas Anda untuk permintaan Anda.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensi: TableName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah ada banyak permintaan tulis yang dibatasi untuk tabel DynamoDB. Silakan lihat Memecahkan masalah throttling di Amazon DynamoDB, untuk memecahkan masalah ini.

Maksud: Alarm ini dapat mendeteksi throttling yang berkelanjutan untuk permintaan tulis ke tabel DynamoDB. Throttling permintaan tulis yang berkelanjutan dapat berdampak negatif pada operasi tulis beban kerja Anda dan akan mengurangi efisiensi sistem secara keseluruhan.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan lalu lintas tulis yang diharapkan untuk tabel DynamoDB, dan memperhitungkan tingkat throttling yang dapat diterima. Penting untuk memantau apakah Anda sedang mengalami kurang penyediaan dan bahwa hal itu tidak menyebabkan throttling yang terjadi terus-menerus. Anda juga dapat melakukan analisis data historis untuk menemukan tingkat throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batasnya dengan tingkat yang lebih tinggi dari level throttling yang dapat diterima yang biasa Anda gunakan. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi/layanan karena pembatasan bersifat sementara. Oleh karena itu, ambang batas yang ditetapkan sangat rendah akan dapat membuat alarm menjadi terlalu sensitif, dan menyebabkan perubahan status yang tidak diinginkan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensi:TableName, GlobalSecondaryIndexName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah ada banyak jumlah permintaan tulis yang dibatasi untuk Indeks Sekunder Global dari tabel DynamoDB. Silakan lihat Memecahkan masalah throttling di Amazon DynamoDB, untuk memecahkan masalah ini.

Maksud: Alarm ini dapat mendeteksi adanya throttling yang terjadi secara berkelanjutan untuk permintaan tulis untuk Indeks Sekunder Global dari Tabel DynamoDB. Throttling permintaan tulis yang berkelanjutan dapat berdampak negatif pada operasi tulis beban kerja Anda dan akan mengurangi efisiensi sistem secara keseluruhan.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan lalu lintas Tulis yang diharapkan untuk tabel DynamoDB, dan memperhitungkan tingkat throttling yang dapat diterima. Penting untuk memantau apakah Anda sedang mengalami kurang penyediaan dan bahwa hal itu tidak menyebabkan throttling yang terjadi terus-menerus. Anda juga dapat melakukan analisis data historis untuk menemukan tingkat throttling yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batasnya dengan tingkat yang lebih tinggi dari level throttling yang dapat diterima yang biasa digunakan. Permintaan-permintaan yang dibatasi harus dicoba ulang oleh aplikasi/layanan karena pembatasan bersifat sementara. Oleh karena itu, nilai yang ditetapkan sangat rendah akan dapat membuat alarm menjadi terlalu sensitif, dan menyebabkan perubahan status yang tidak diinginkan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

VolumeStalledIOCheck

Dimensi:VolumeId, InstanceId

Deskripsi alarm: Alarm ini membantu Anda memantau kinerja IO volume Amazon EBS Anda. Pemeriksaan ini mendeteksi masalah mendasar dengan infrastruktur Amazon EBS, seperti masalah perangkat keras atau perangkat lunak pada subsistem penyimpanan yang mendasari volume Amazon EBS, masalah perangkat keras pada host fisik yang memengaruhi jangkauan volume Amazon EBS dari instans Amazon EC2 Anda, dan dapat mendeteksi masalah konektivitas antara instans dan volume Amazon EBS. Jika Pemeriksaan IO Terhenti gagal, Anda dapat menunggu AWS untuk menyelesaikan masalah, atau Anda dapat mengambil tindakan seperti mengganti volume yang terpengaruh atau menghentikan dan memulai ulang instance tempat volume terpasang. Dalam kebanyakan kasus, ketika metrik ini gagal, Amazon EBS akan secara otomatis mendiagnosis dan memulihkan volume Anda dalam beberapa menit.

Maksud: Alarm ini dapat mendeteksi status volume Amazon EBS Anda untuk menentukan kapan volume ini terganggu dan tidak dapat menyelesaikan operasi I/O.

Statistik: Maksimum

Ambang batas yang disarankan: 1,0

Pembenaran ambang batas: Ketika terjadi kegagalan pemeriksaan status, nilai metrik ini adalah 1. Ambang batasnya diatur sedemekian rupa sehingga setiap kali terjadi kegagalan pemeriksaan status, alarm akan berada dalam status ALARM.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

CPUUtilization

Dimensi: InstanceId

Deskripsi alarm: Alarm ini dapat membantu Anda memantau pemanfaatan CPU dari instans EC2. Tergantung pada aplikasinya, tingkat pemanfaatan yang tinggi mungkin akan normal secara terus-menerus. Tetapi jika performanya menurun, dan aplikasi tidak dibatasi oleh disk I/O, memori, atau sumber daya jaringan, maka CPU yang telah mencapai batas atasnya mungkin akan menunjukkan hambatan sumber daya atau masalah performa aplikasi. Pemanfaatan CPU yang tinggi mungkin menunjukkan bahwa diperlukan adanya peningkatan ke instans yang lebih intensif CPU. Jika Anda mengaktifkan pemantauan terperinci, maka Anda dapat mengubah periodenya menjadi 60 detik, bukan 300 detik. Untuk informasi selengkapnya, silakan lihat Mengaktifkan atau menonaktifkan pemantauan terperinci untuk instans Anda.

Maksud: Alarm ini dapat digunakan untuk mendeteksi pemanfaatan CPU yang tinggi.

Statistik: Rata-rata

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Anda biasanya dapat mengatur ambang batas untuk pemanfaatan CPU hingga 70-80%. Namun demikian, Anda dapat menyesuaikan nilai ini berdasarkan tingkat performa dan karakteristik beban kerja yang dapat diterima. Untuk beberapa sistem, pemanfaatan CPU yang tinggi yang terjadi secara terus-menerus mungkin adalah hal normal dan tidak menunjukkan adanya masalah, sementara untuk yang lain, hal itu mungkin akan menimbulkan kekhawatiran tersendiri. Anda perlu melakukan analisis data pemanfaatan CPU historis untuk mengidentifikasi penggunaannya, menemukan seberapa besar pemanfaatan CPU yang dapat diterima untuk sistem Anda, dan kemudian menetapkan ambang batas sesuai dengan itu.

Periode: 300

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

StatusCheckFailed

Dimensi: InstanceId

Deskripsi alarm: Alarm ini akan membantu Anda memantau pemeriksaan status sistem dan pemeriksaan status instans. Jika salah satu jenis pemeriksaan status mengalami kegagalan, maka alarm ini seharusnya beralih menjadi ALARM.

Maksud: Alarm ini dapat digunakan untuk mendeteksi masalah-masalah mendasar yang terjadi terhadap instans, termasuk masalah kegagalan pemeriksaan status sistem dan kegagalan pemeriksaan status instans.

Statistik: Maksimum

Ambang batas yang disarankan: 1,0

Pembenaran ambang batas: Ketika terjadi kegagalan pemeriksaan status, nilai metrik ini adalah 1. Ambang batasnya diatur sedemekian rupa sehingga setiap kali terjadi kegagalan pemeriksaan status, alarm akan berada dalam status ALARM.

Periode: 300

Titik data untuk alarm: 2

Periode evaluasi: 2

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_melampirkan Debs

Dimensi: InstanceId

Deskripsi alarm: Alarm ini membantu Anda memantau apakah volume Amazon EBS yang dilampirkan ke instans dapat dijangkau dan dapat menyelesaikan operasi I/O. Pemeriksaan status ini mendeteksi masalah mendasar dengan komputasi atau infrastruktur Amazon EBS seperti berikut ini:

Masalah perangkat keras atau perangkat lunak pada subsistem penyimpanan yang mendasari volume Amazon EBS
Masalah perangkat keras pada host fisik yang memengaruhi jangkauan volume Amazon EBS
Masalah konektivitas antara instans dan volume Amazon EBS

Jika pemeriksaan status EBS terlampir gagal, Anda dapat menunggu Amazon menyelesaikan masalah, atau Anda dapat mengambil tindakan seperti mengganti volume yang terpengaruh atau menghentikan dan memulai ulang instance.

Maksud: Alarm ini digunakan untuk mendeteksi volume Amazon EBS yang tidak dapat dijangkau yang dilampirkan ke sebuah instans. Ini dapat menyebabkan kegagalan dalam operasi I/O.

Statistik: Maksimum

Ambang batas yang disarankan: 1,0

Pembenaran ambang batas: Ketika terjadi kegagalan pemeriksaan status, nilai metrik ini adalah 1. Ambang batasnya diatur sedemekian rupa sehingga setiap kali terjadi kegagalan pemeriksaan status, alarm akan berada dalam status ALARM.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

CPUUtilization

Dimensi:CacheClusterId, CacheNodeId

Deskripsi alarm: Alarm ini membantu memantau pemanfaatan CPU untuk seluruh ElastiCache instance, termasuk proses mesin database dan proses lain yang berjalan pada instance. AWS Elasticache mendukung dua jenis mesin: Memcached dan Redis. Ketika Anda mencapai pemanfaatan CPU yang tinggi pada sebuah simpul Memcached, Anda harus mempertimbangkan untuk meningkatkan tipe instans Anda atau menambahkan simpul cache yang baru. Untuk Redis, jika beban kerja utama Anda adalah dari permintaan baca, maka Anda harus mempertimbangkan untuk menambahkan lebih banyak replika baca pada klaster cache Anda. Jika beban kerja utama Anda berasal dari permintaan tulis, maka Anda harus mempertimbangkan untuk menambahkan lebih banyak serpihan untuk mendistribusikan beban kerja di lebih banyak simpul primer jika Anda berjalan dalam mode klaster, atau menaikkan skala tipe instans Anda jika Anda menjalankan Redis dalam mode non-klaster.

Maksud: Alarm ini digunakan untuk mendeteksi pemanfaatan CPU host yang ElastiCache tinggi. Hal ini berguna untuk mendapatkan pandangan yang luas dari penggunaan CPU di seluruh instans, termasuk proses-proses non-mesin.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batasnya dengan persentase yang mencerminkan tingkat pemanfaatan CPU kritis untuk aplikasi Anda. Untuk Memcached, mesinnya dapat menggunakan hingga inti num_threads. Untuk Redis, mesinnya sebagian besar berupa mesin single-threaded, tetapi mungkin akan menggunakan inti tambahan, jika ada, untuk mempercepat I/O. Dalam kebanyakan kasus, Anda dapat mengatur ambang batasnya hingga sekitar 90% dari CPU yang tersedia. Karena Redis bersifat single-threaded, nilai ambang batas yang sebenarnya harus dihitung sebagai bagian kecil dari seluruh kapasitas simpul ini.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

CurrConnections

Dimensi:CacheClusterId, CacheNodeId

Deskripsi alarm: Alarm ini dapat mendeteksi jumlah koneksi yang tinggi, yang mungkin mengindikasikan beban berat atau masalah-masalah performa. Peningkatan yang terjadi secara terus-menerus terhadap CurrConnections akan dapat menyebabkan terjadinya letih yang berlebihan pada 65.000 koneksi yang tersedia. Hal ini mungkin menunjukkan bahwa koneksi-koneksi tersebut tidak ditutup dengan benar di sisi aplikasi dan dibiarkan dibuat di sisi server. Anda harus mempertimbangkan untuk menggunakan pengumpulan koneksi atau batas waktu koneksi idle untuk membatasi jumlah koneksi yang dibuat ke klaster, atau untuk Redis, Anda harus mempertimbangkan untuk menyetel tcp-keepalive di klaster Anda untuk mendeteksi dan menghentikan potensi rekan mati.

Maksud: Alarm membantu Anda mengidentifikasi jumlah koneksi tinggi yang dapat memengaruhi kinerja dan stabilitas klaster Anda ElastiCache .

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat bergantung pada rentang koneksi yang dapat diterima untuk klaster Anda. Tinjau kapasitas dan beban kerja yang diharapkan dari ElastiCache klaster Anda dan analisis jumlah koneksi historis selama penggunaan reguler untuk menetapkan garis dasar, lalu pilih ambang batas yang sesuai. Ingatlah bahwa masing-masing simpul dapat mendukung hingga 65.000 koneksi secara bersamaan.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

Dimensi: CacheClusterId

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau pemanfaatan memori pada klaster Anda. Ketika DatabaseMemoryUsagePercentage Anda mencapai 100%, kebijakan memori maksimal Redis akan diaktifkan dan pengosongan mungkin akan dilakukan berdasarkan kebijakan yang dipilih. Jika tidak ada objek dalam cache yang cocok dengan kebijakan pengosongan, maka operasi penulisan akan digagalkan. Beberapa beban kerja mengharapkan atau mengandalkan pengosongan, tetapi jika tidak, Anda perlu meningkatkan kapasitas memori klaster Anda. Anda dapat meningkatkan skala klaster Anda dengan menambahkan lebih banyak simpul primer, atau menaikkan skalanya dengan menggunakan tipe simpul yang lebih besar. Lihat Scaling ElastiCache for Redis cluster untuk detailnya.

Maksud: Alarm ini dapat digunakan untuk mendeteksi pemanfaatan memori klaster yang tinggi sehingga Anda dapat mencegah terjadinya kegagalan saat menulis ke klaster Anda. Akan sangat berguna jika Anda mengetahui kapan Anda perlu menaikkan skala klaster Anda jika aplikasi Anda tidak diharapkan untuk mengalami pengosongan.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Bergantung pada persyaratan memori aplikasi Anda dan kapasitas memori ElastiCache klaster Anda, Anda harus menetapkan ambang batas ke persentase yang mencerminkan tingkat kritis penggunaan memori klaster. Anda dapat menggunakan data penggunaan memori historis sebagai acuan untuk ambang batas penggunaan memori yang dapat diterima.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

EngineCPUUtilization

Dimensi: CacheClusterId

Deskripsi alarm: Alarm ini membantu memantau pemanfaatan CPU dari thread mesin Redis dalam instance. ElastiCache Alasan umum yang menyebabkan adanya CPU mesin tinggi adalah perintah yang berjalan lama yang mengkonsumsi CPU tinggi, jumlah permintaan yang tinggi, peningkatan permintaan koneksi klien baru dalam periode waktu singkat, dan pengosongan yang tinggi ketika cache tidak memiliki cukup memori untuk menyimpan data baru. Anda harus mempertimbangkan Penskalaan ElastiCache untuk klaster Redis dengan menambahkan lebih banyak node atau meningkatkan jenis instance Anda.

Maksud: Alarm ini dapat digunakan untuk mendeteksi pemanfaatan CPU yang tinggi dari thread mesin Redis. Hal ini akan berguna jika Anda ingin memantau penggunaan CPU dari mesin basis data itu sendiri.

Statistik: Rata-rata

Ambang batas yang disarankan: 90,0

Pembenaran ambang batas: Anda harus menetapkan ambang batasnya dengan persentase yang mencerminkan tingkat pemanfaatan CPU mesin kritis untuk aplikasi Anda. Anda dapat melakukan penolokukuran atas klaster Anda dengan menggunakan aplikasi dan beban kerja yang diharapkan untuk mengkorelasikan EngineCPUUtilization dan performa sebagai referensi, dan kemudian Anda harus menetapkan ambang batas yang sesuai. Dalam kebanyakan kasus, Anda dapat mengatur ambang batas tersebut hingga sekitar 90% dari CPU yang tersedia.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReplicationLag

Dimensi: CacheClusterId

Deskripsi alarm: Alarm ini membantu memantau kesehatan replikasi ElastiCache cluster Anda. Kelambatan replikasi yang tinggi menunjukkan bahwa simpul primer atau replikanya tidak dapat mengikuti laju replikasi. Jika aktivitas tulis Anda terlalu tinggi, maka Anda harus mempertimbangkan untuk menaikkan skala klaster Anda dengan menambahkan lebih banyak simpul primer, atau menaikkan skalanya dengan menggunakan tipe simpul yang lebih besar. Lihat Scaling ElastiCache for Redis cluster untuk detailnya. Jika replika baca Anda kelebihan beban karena jumlah permintaan baca yang terlalu besar, maka Anda harus mempertimbangkan untuk menambahkan lebih banyak replika baca.

Maksud: Alarm ini dapat digunakan untuk mendeteksi penundaan antara pembaruan data pada simpul primer dan sinkronisasinya dengan simpul replika. Hal ini akan membantu Anda memastikan konsistensi data dari simpul klaster replika baca.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas sesuai dengan persyaratan aplikasi Anda dan dampak kelambatan replikasi yang mungkin terjadi. Anda juga harus mempertimbangkan tingkat tulis yang diharapkan dan kondisi jaringan aplikasi Anda untuk kelambatan replikasi yang dapat diterima.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

GPU ConnectivityCheckFailed

Dimensi:InstanceId, EGPUID

Deskripsi alarm: Alarm ini dapat membantu Anda mendeteksi kegagalan koneksi antara instans dan akselerator Elastic Graphics. Elastic Graphics menggunakan jaringan instans untuk mengirimkan perintah-perintah OpenGL ke kartu grafis yang terpasang secara jarak jauh. Selain itu, sebuah desktop yang menjalankan aplikasi OpenGL dengan akselerator Elastic Graphics biasanya dapat diakses dengan menggunakan teknologi akses jarak jauh. Penting bagi Anda untuk bisa membedakan antara masalah performa yang terkait dengan rendering OpenGL atau teknologi akses jarak jauh desktop. Untuk mempelajari lebih lanjut tentang masalah ini, silakan lihat Menyelidiki masalah performa aplikasi.

Maksud: Alarm ini dapat digunakan untuk mendeteksi masalah-masalah terkait dengan konektivitas dari instans ke akselerator Elastic Graphics.

Statistik: Maksimum

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Nilai ambang batas 1 menunjukkan bahwa terjadi kegagalan konektivitas.

Periode: 300

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

GPU HealthCheckFailed

Dimensi:InstanceId, EGPUID

Deskripsi alarm: Alarm ini dapat membantu Anda mengetahui saat status akselerator grafis Elastis dalam kondisi tidak sehat. Jika akselerator berada dalam kondisi tidak sehat, silakan lihat langkah-langkah pemecahan masalah di Menyelesaikan masalah status Tidak Sehat.

Maksud: Alarm ini digunakan untuk mendeteksi apakah akselerator Elastic Graphics sedang tidak sehat atau tidak.

Statistik: Maksimum

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Nilai ambang batas 1 menunjukkan terjadinya kegagalan pemeriksaan status.

Periode: 300

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

CPUReservation

Dimensi: ClusterName

Deskripsi alarm: Alarm ini dapat membantu Anda mendeteksi reservasi CPU yang tinggi pada klaster ECS. Reservasi CPU yang tinggi mungkin menunjukkan bahwa klaster telah mengalami kehabisan CPU terdaftar untuk tugas tersebut. Untuk memecahkan masalah itu, Anda dapat menambahkan kapasitas lebih banyak, Anda juga dapat menskalakan klaster, atau Anda dapat mengatur penskalaan otomatis.

Maksud: Alarm ini digunakan untuk mendeteksi apakah jumlah total unit CPU yang dicadangkan oleh tugas pada klaster mencapai total unit CPU yang terdaftar untuk klaster tersebut. Hal ini akan membantu Anda mengetahui kapan Anda seharusnya menaikkan skala klaster. Jika total unit CPU untuk klaster telah tercapai, maka hal itu dapat mengakibatkan tugas kehabisan CPU. Jika Anda mengaktifkan penskalaan terkelola penyedia kapasitas EC2, atau Anda telah mengaitkan Fargate untuk penyedia kapasitas, maka alarm ini tidak disarankan untuk Anda.

Statistik: Rata-rata

Ambang batas yang disarankan: 90,0

Pembenaran ambang batas: Anda harus menetapkan ambang batas untuk reservasi CPU hingga 90%. Atau, Anda bisa memilih nilai yang lebih rendah berdasarkan karakteristik klaster.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

CPUUtilization

Dimensi:ClusterName, ServiceName

Deskripsi alarm: Alarm ini akan membantu Anda mendeteksi pemanfaatan CPU yang tinggi pada layanan-layanan ECS. Jika tidak ada deployment ECS yang sedang berlangsung, maka pemanfaatan CPU yang maksimal mungkin menunjukkan adanya kemacetan sumber daya atau masalah performa pada aplikasi. Untuk mengatasi masalah ini, Anda dapat menaikkan batas CPU.

Maksud: Alarm ini dapat Anda gunakan untuk mendeteksi pemanfaatan CPU yang tinggi untuk layanan-layanan ECS. Pemanfaatan CPU tinggi yang terjadi secara terus-menerus dapat menunjukkan adanya kemacetan sumber daya atau masalah performa pada aplikasi.

Statistik: Rata-rata

Ambang batas yang disarankan: 90,0

Pembenaran ambang batas: Metrik layanan untuk pemanfaatan CPU boleh melebihi 100% pemanfaatan. Namun demikian, kami menyarankan Anda untuk memantau metrik untuk pemanfaatan CPU yang tinggi agar hal itu tidak memengaruhi layanan-layanan yang lain. Aturlah ambang batasnya menjadi sekitar 90-95%. Kami menyarankan Anda untuk memperbarui penentuan tugas untuk mencerminkan penggunaan aktual sehingga Anda bisa mencegah masalah-masalah yang mungkin terjadi di masa depan dengan layanan-layanan lainnya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

MemoryReservation

Dimensi: ClusterName

Deskripsi alarm: Alarm ini dapat membantu Anda mendeteksi reservasi memori tinggi pada klaster ECS. Reservasi memori yang tinggi mungkin menunjukkan adanya kemacetan sumber daya untuk klaster tersebut. Untuk memecahkan masalah ini, Anda harus melakukan analisis tugas layanan untuk performa sehingga Anda bisa memeriksa apakah pemanfaatan memori tugas dapat dioptimalkan. Selain itu, Anda juga dapat mendaftarkan lebih banyak memori atau mengatur penskalaan otomatis.

Intent: Alarm ini digunakan untuk mendeteksi apakah total unit memori yang dicadangkan oleh tugas di klaster telah mencapai total unit memori yang terdaftar untuk klaster tersebut. Hal ini akan dapat membantu Anda mengetahui kapan Anda seharusnya menaikkan skala klaster. Ketika unit memori total untuk klaster tersebut telah tercapai, hal itu dapat menyebabkan klaster tidak dapat meluncurkan tugas baru. Jika Anda mengaktifkan penskalaan terkelola penyedia kapasitas EC2, atau Anda telah mengaitkan Fargate untuk penyedia kapasitas, maka alarm ini tidak disarankan bagi Anda.

Statistik: Rata-rata

Ambang batas yang disarankan: 90,0

Pembenaran ambang batas: Anda harus menetapkan ambang batas untuk reservasi memori menjadi 90%. Anda dapat menyesuaikan ambang batas ini dengan nilai yang lebih rendah berdasarkan karakteristik klaster.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

Dimensi:ClusterName, ServiceName

Deskripsi alarm: Alarm ini dapat membantu Anda mendeteksi jumlah kesalahan sisi server yang tinggi untuk layanan ECS. Hal ini dapat menunjukkan bahwa telah terjadi kesalahan yang menyebabkan server tidak dapat melayani permintaan. Untuk memecahkan masalah seperti itu, Anda bisa memeriksa log aplikasi Anda.

Maksud: Alarm ini dapat digunakan untuk mendeteksi jumlah kesalahan sisi server yang tinggi untuk layanan ECS.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung nilai sekitar 5% dari lalu lintas rata-rata Anda dan kemudian menggunakannya sebagai titik awal untuk ambang batas. Anda dapat menemukan lalu lintas rata-rata dengan menggunakan metrik RequestCount. Anda juga dapat menganalisis data historis untuk menentukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai. Kesalahan 5XX yang sering terjadi perlu Anda waspadai. Namun demikian, menetapkan nilai yang sangat rendah untuk ambang batas akan dapat menyebabkan alarm menjadi terlalu sensitif.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

TargetResponseTime

Dimensi:ClusterName, ServiceName

Deskripsi alarm: Alarm ini akan membantu Anda mendeteksi waktu respons target yang tinggi untuk permintaan-permintaan layanan ECS. Hal ini dapat menunjukkan bahwa telah terjadi masalah yang menyebabkan layanan tidak dapat melayani permintaan secara tepat waktu. Untuk memecahkan masalah tersebut, Anda perlu memeriksa metrik CPUUtilization untuk melihat apakah layanan kehabisan CPU, atau memeriksa pemanfaatan CPU dari layanan hilir lain yang bergantung pada layanan Anda.

Maksud: Alarm ini digunakan untuk mendeteksi waktu respons target yang tinggi untuk permintaan-permintaan layanan ECS.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat tergantung pada kasus penggunaan Anda. Anda perlu meninjau kekritisan dan persyaratan waktu respons target layanan dan kemudian melakukan analisis perilaku historis metrik ini untuk menentukan tingkat ambang batas yang masuk akal.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

EphemeralStorageUtilized

Dimensi:ClusterName, ServiceName

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi penyimpanan sementara tinggi yang digunakan dari klaster Fargate. Jika penyimpanan sementara secara konsisten tinggi, Anda dapat memeriksa penggunaan penyimpanan sementara dan meningkatkan penyimpanan sementara tersebut.

Maksud: Alarm ini digunakan untuk mendeteksi penggunaan penyimpanan sementara yang tinggi untuk klaster Fargate. Penyimpanan sementara yang tinggi dan konsisten yang digunakan dapat menunjukkan bahwa disk sudah penuh dan dapat menyebabkan terjadinya kegagalan terhadap kontainer.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Tetapkan ambang batas menjadi sekitar 90% dari ukuran penyimpanan sementara. Anda dapat menyesuaikan nilai ini berdasarkan pemanfaatan penyimpanan sementara yang dapat diterima dari klaster Fargate. Untuk beberapa sistem, adanya penyimpanan sementara tinggi yang digunakan secara konsisten mungkin bisa jadi hal normal, sedangkan untuk sistem yang lain, dapat menyebabkan terjadinya kegagalan terhadap kontainer.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

RunningTaskCount

Dimensi:ClusterName, ServiceName

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi jumlah tugas yang berjalan rendah dari layanan ECS. Jika jumlah tugas yang berjalan terlalu rendah, hal ini dapat menunjukkan bahwa aplikasi tidak dapat menangani beban layanan dan hal tersebut dapat menyebabkan terjadinya masalah performa. Jika tidak ada tugas yang berjalan, layanan Amazon ECS mungkin tidak tersedia atau mungkin ada masalah yang terjadi dalam deployment.

Maksud: Alarm ini digunakan untuk mendeteksi apakah jumlah tugas yang berjalan terlalu rendah atau tidak. Jumlah tugas berjalan yang rendah yang terjadi secara konsisten dapat menunjukkan adanya masalah deployment layanan ECS atau masalah performa.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Anda dapat menyesuaikan ambang batas berdasarkan jumlah tugas minimum yang berjalan dari layanan ECS. Jika jumlah tugas yang berjalan adalah 0, artinya layanan Amazon ECS tidak akan tersedia.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

Dimensi:InstanceId, ContainerInstanceId, ClusterName

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi pemanfaatan sistem file klaster ECS yang berada dalam level yang tinggi. Jika pemanfaatan sistem file secara konsisten berada dalam level yang tinggi, periksa penggunaan disk.

Maksud: Alarm ini digunakan untuk mendeteksi pemanfaatan sistem file yang tinggi untuk klaster Amazon ECS. Pemanfaatan sistem file yang berada dalam level yang tinggi secara konsisten dapat menunjukkan terjadinya kemacetan sumber daya atau masalah performa pada aplikasi, dan mungkin akan mencegah berjalannya tugas-tugas baru.

Statistik: Rata-rata

Ambang batas yang disarankan: 90,0

Pembenaran ambang batas: Anda dapat mengatur ambang batas untuk pemanfaatan sistem file hingga 90-95%. Anda dapat menyesuaikan nilai ini berdasarkan tingkat kapasitas sistem file klaster Amazon ECS yang dapat diterima. Untuk beberapa sistem, terjadinya pemanfaatan sistem file yang berada dalam level yang tinggi secara konsisten mungkin menjadi sesuatu yang normal dan tidak menunjukkan adanya masalah, sedangkan untuk sistem yang lain, hal itu mungkin menjadi penyebab munculnya kekhawatiran dan dapat menyebabkan terjadinya masalah performa dan mencegah berjalannya tugas-tugas baru.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

PercentIOLimit

Dimensi: FileSystemId

Deskripsi alarm: Alarm ini akan membantu Anda untuk memastikan bahwa beban kerja tetap berada dalam ambang batas I/O yang tersedia untuk sistem file. Jika metrik terus-menerus mencapai batas I/O, Anda perlu mempertimbangkan untuk memindahkan aplikasi ke sistem file yang menggunakan mode performa Max I/O. Untuk memecahkan masalah ini, Anda perlu memeriksa klien yang terhubung ke sistem file dan aplikasi klien yang membatasi sistem file.

Maksud: Alarm ini digunakan untuk mendeteksi seberapa dekat sistem file untuk mencapai batas I/O pada mode performa Tujuan Umum. Persentase I/O yang tinggi yang terjadi secara terus-menerus dapat menjadi indikator yang menunjukkan bahwa sistem file tidak dapat menskalakan sehubungan dengan permintaan I/O yang cukup dan bahwa sistem file dapat menjadi hambatan sumber daya untuk aplikasi yang menggunakan sistem file tersebut.

Statistik: Rata-rata

Ambang batas yang disarankan: 100,0

Pembenaran ambang batas: Ketika sistem file mencapai batas I/O, sistem file tersebut mungkin akan merespons permintaan baca dan tulis dengan lebih lambat. Oleh karena itu, Anda disarankan untuk memantau metrik ini sehingga Anda dapat mencegah dampak aplikasi yang menggunakan sistem file tersebut. Ambang batasnya dapat diatur sekitar 100%. Namun demikian, nilai ini dapat disesuaikan dengan nilai yang lebih rendah berdasarkan karakteristik sistem file.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

Dimensi: FileSystemId

Deskripsi alarm: Alarm ini akan membantu Anda memastikan bahwa ada lonjakan saldo kredit yang tersedia untuk penggunaan sistem file. Ketika tidak ada lonjakan kredit yang tersedia, maka akses aplikasi ke sistem file akan terbatas karena throughput yang rendah. Jika metrik terus-menerus turun menjadi 0, maka Anda harus mempertimbangkan untuk mengubah mode throughput ke mode throughput Elastic atau Provisioned.

Maksud: Alarm ini digunakan untuk mendeteksi lonjakan saldo kredit yang rendah pada sistem file. Lonjakan saldo kredit yang rendah yang terjadi secara terus-menerus dapat menjadi indikator yang menunjukkan terjadinya perlambatan throughput dan peningkatan latensi I/O.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Ketika sistem file kehabisan kredit burst dan bahkan jika tingkat throughput dasar lebih rendah, EFS terus memberikan throughput terukur 1 ke semua sistem file. MiBps Namun demikian, Anda disarankan untuk memantau lonjakan saldo kredit rendah pada metrik untuk mencegah sistem file bertindak menjadi hambatan sumber daya untuk aplikasi. Ambang batasnya dapat Anda atur di sekitar 0 byte.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: LESS_THAN_OR_EQUAL_TO_THRESHOLD

node_cpu_utilization

Dimensi: ClusterName

Deskripsi alarm: Alarm ini akan membantu Anda mendeteksi pemanfaatan CPU yang tinggi pada simpul pekerja klaster EKS. Jika pemanfaatannya secara terus-menerus berada dalam level yang tinggi, hal ini mungkin menunjukkan bahwa Anda perlu mengganti simpul pekerja Anda dengan instans yang memiliki CPU lebih besar atau Anda perlu menskalakan sistem secara horizontal.

Maksud: Alarm ini akan membantu Anda memantau pemanfaatan CPU dari simpul pekerja di klaster EKS sehingga penurunan performa sistem tidak terjadi.

Statistik: Maksimum

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Anda disarankan untuk menetapkan ambang batas kurang dari atau sama dengan 80% sehingga Anda dapat memberikan waktu yang cukup untuk melakukan men-debug masalah sebelum sistem mulai merasakan dampak yang diakibatkannya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

node_filesystem_utilization

Dimensi: ClusterName

Deskripsi alarm: Alarm ini akan membantu mendeteksi pemanfaatan sistem file yang berada dalam level tinggi pada simpul pekerja klaster EKS. Jika pemanfaatan yang tinggi itu terjadi secara terus-menerus, Anda mungkin perlu memperbarui simpul pekerja Anda agar Anda memiliki volume disk yang lebih besar, atau Anda mungkin perlu menskalakan secara horizontal.

Maksud: Alarm ini akan membantu Anda memantau pemanfaatan sistem file simpul pekerja yang ada di klaster EKS. Jika pemanfaatan mencapai 100%, hal itu akan dapat menyebabkan terjadinya kegagalan aplikasi, kemacetan I/O disk, pengosongan pod, atau simpul menjadi tidak sepenuhnya responsif.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Jika ada tekanan disk yang memadai (artinya disk semakin penuh), maka simpul akan ditandai sebagai simpul yang tidak sehat, dan pod akan dikeluarkan dari simpul. Pod yang ada pada sebuah simpul dengan tekanan disk akan dikosongkan ketika sistem file yang tersedia berada pada level yang lebih rendah dari ambang batas pengosongan yang telah ditetapkan pada kubelet. Anda harus mengatur ambang batas alarm sedemikian rupa sehingga Anda akan memiliki cukup waktu untuk bereaksi sebelum simpul tersebut dikeluarkan dari klaster.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

node_memory_utilization

Dimensi: ClusterName

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi pemanfaatan memori yang tinggi pada simpul pekerja di klaster EKS. Jika pemanfaatannya berada dalam level yang tinggi secara terus-menerus, hal ini mungkin menunjukkan bahwa Anda perlu menskalakan jumlah replika pod, atau Anda harus mengoptimalkan aplikasi Anda.

Maksud: Alarm ini akan membantu Anda memantau pemanfaatan memori dari simpul pekerja di klaster EKS sehingga penurunan performa sistem tidak terjadi.

Statistik: Maksimum

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Anda disarankan untuk menetapkan ambang batas kurang dari atau sama dengan 80% sehingga Anda dapat memiliki waktu yang cukup untuk melakukan men-debug masalah sebelum sistem mulai merasakan dampak yang diakibatkannya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

Dimensi:ClusterName, Namespace, Layanan

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi pemanfaatan CPU yang berada dalam level tinggi yang terjadi di pod klaster EKS. Jika pemanfaatannya secara terus-menerus berada dalam level yang tinggi, hal ini mungkin menunjukkan bahwa Anda harus menaikkan batas CPU untuk pod yang terpengaruh.

Maksud: Alarm ini akan membantu Anda memantau pemanfaatan CPU dari Pod yang dimiliki oleh Layanan Kubernetes yang ada di klaster EKS, sehingga Anda dapat dengan cepat mengidentifikasi apakah pod layanan mengkonsumsi CPU yang lebih tinggi dari yang diharapkan.

Statistik: Maksimum

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Anda disarankan untuk menetapkan ambang batas kurang dari atau sama dengan 80% sehingga Anda dapat memiliki waktu yang cukup untuk melakukan men-debug masalah sebelum sistem mulai merasakan dampak yang diakibatkannya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

Dimensi:ClusterName, Namespace, Layanan

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi pemanfaatan memori yang berada dalam level tinggi yang terjadi di pod klaster EKS. Jika pemanfaatannya secara terus-menerus berada dalam level yang tinggi, hal ini mungkin menunjukkan bahwa Anda harus menaikkan batas memori untuk pod yang terpengaruh.

Maksud: Alarm ini akan membantu Anda memantau pemanfaatan memori dari pod yang ada di klaster EKS sehingga penurunan performa sistem tidak terjadi.

Statistik: Maksimum

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Anda disarankan untuk menetapkan ambang batas kurang dari atau sama dengan 80% sehingga Anda dapat memiliki waktu yang cukup untuk melakukan men-debug masalah sebelum sistem mulai merasakan dampak yang diakibatkannya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

GetRecords.IteratorAgeMilliseconds

Dimensi: StreamName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah usia maksimum iterator terlalu tinggi, atau tidak. Untuk aplikasi pemrosesan data waktu nyata, Anda perlu mengonfigurasikan retensi data sesuai dengan toleransi penundaan. Ini biasanya memakan waktu beberapa menit. Untuk aplikasi-aplikasi yang memproses data historis, Anda perlu menggunakan metrik ini untuk memantau kecepatan penangkapan. Solusi cepat untuk menghentikan peristiwa kehilangan data adalah dengan meningkatkan periode retensi saat Anda melakukan pemecahan masalah. Anda juga dapat menaikkan jumlah pekerja yang memproses catatan dalam aplikasi konsumen Anda. Penyebab yang paling umum yang mengakibatkan peningkatan usia iterator bertahap adalah sumber daya fisik yang tidak memadai atau logika pemrosesan catatan yang belum diskalakan dengan peningkatan throughput aliran. Silakan lihat tautan ini untuk informasi selengkapnya.

Maksud: Alarm ini digunakan untuk mendeteksi apakah data dalam aliran Anda akan menjadi kedaluwarsa karena sudah disimpan terlalu lama atau karena pemrosesan catatan yang dilakukan terlalu lambat. Hal ini akan membantu Anda dalam mencegah terjadinya kehilangan data setelah mencapai 100% waktu retensi aliran.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang kami sarankan untuk alarm ini sangat tergantung pada periode retensi aliran dan toleransi penundaan pemrosesan untuk catatan. Anda harus meninjau persyaratan Anda dan kemudian melakukan analisis tren historis, lalu menetapkan ambang batasnya dengan jumlah milidetik yang mewakili penundaan pemrosesan kritis. Jika usia iterator melewati 50% periode retensi (secara default, 24 jam, dapat dikonfigurasi hingga 365 hari), maka akan ada risiko terjadinya kehilangan data karena kedaluwarsanya catatan. Anda dapat memantau metrik untuk memastikan bahwa tidak ada serpihan Anda yang pernah mendekati batas ini.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

GetRecords.Sukses

Dimensi: StreamName

Deskripsi alarm: Metrik ini akan meningkat setiap kali konsumen Anda berhasil membaca data dari streaming Anda. GetRecords tidak akan mengembalikan data apa pun saat menerapkan pengecualian. Pengecualian yang paling umum adalah ProvisionedThroughputExceededException karena tingkat permintaan untuk alirannya yang terlalu tinggi, atau karena throughput yang tersedia sudah disajikan untuk detik tertentu. Kurangi frekuensi atau ukuran dari permintaan-permintaan Anda. Untuk informasi selengkapnya, silakan lihat Batas dalam Panduan Developer Amazon Kinesis Data Streams, dan Mencoba Ulang Kesalahan dan Mundur Eksponensial di AWS.

Maksud: Alarm ini dapat mendeteksi apakah pengambilan catatan dari aliran oleh konsumen gagal, atau tidak. Dengan menyetel alarm pada metrik ini, Anda akan dapat secara proaktif mendeteksi setiap masalah yang terjadi dengan konsumsi data, misalnya peningkatan tingkat kesalahan atau penurunan pengambilan yang berhasil. Hal ini akan memungkinkan Anda untuk melakukan tindakan secara tepat waktu untuk menyelesaikan masalah yang mungkin terjadi di masa depan dan mempertahankan jalur pemrosesan data yang lancar.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Bergantung pada pentingnya pengambilan catatan dari aliran, Anda harus menetapkan ambang batas ini berdasarkan toleransi aplikasi Anda terhadap catatan-catatan yang gagal. Ambang batas tersebut harus berupa persentase yang sesuai dari operasi yang berhasil. Anda dapat menggunakan data GetRecords metrik historis sebagai referensi untuk tingkat kegagalan yang dapat diterima. Anda juga harus mempertimbangkan percobaan ulang saat menyetel ambang batas ini karena catatan yang gagal dapat Anda coba lagi. Hal ini akan membantu mencegah lonjakan sementara sehingga tidak memicu peringatan yang tidak perlu.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

PutRecord.Sukses

Dimensi: StreamName

Deskripsi alarm: Alarm ini akan mendeteksi apakah jumlah operasi PutRecord yang gagal sudah melanggar ambang batas, atau tidak. Anda perlu menyelidiki log produsen data untuk menemukan akar penyebab yang mengakibatkan terjadinya kegagalan. Alasan yang paling umum untuk kegagalan tersebut karena throughput yang disediakan tidak memadai pada serpihan yang menyebabkan ProvisionedThroughputExceededException. Hal itu terjadi karena tingkat permintaan untuk aliran terlalu tinggi, atau throughput yang dicoba untuk dimasukkan ke dalam serpihan terlalu tinggi. Kurangi frekuensi atau ukuran dari permintaan-permintaan Anda. Untuk informasi selengkapnya, lihat Batas Streams dan Error Retries dan Exponential Backoff di. AWS

Maksud: Alarm ini dapat mendeteksi apakah penyerapan catatan ke dalam aliran mengalami kegagalan, atau tidak. Hal ini akan membantu Anda mengidentifikasi masalah yang terjadi dalam penulisan data ke aliran. Dengan menyetel alarm pada metrik ini, Anda akan dapat secara proaktif mendeteksi masalah yang dialami produsen saat menerbitkan data ke aliran, seperti terjadinya peningkatan tingkat kesalahan atau menurunnya catatan sukses yang diterbitkan. Hal ini akan memungkinkan Anda untuk melakukan tindakan-tindakan secara tepat waktu untuk mengatasi masalah yang mungkin terjadi dan untuk mempertahankan proses penyerapan data yang andal.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Bergantung pada pentingnya penyerapan data dan pemrosesan data untuk layanan Anda, Anda harus menetapkan ambang batasnya berdasarkan toleransi aplikasi Anda terhadap catatan-catatan yang gagal. Ambang batas tersebut harus berupa persentase yang sesuai dari operasi yang berhasil. Anda dapat menggunakan data PutRecord metrik historis sebagai referensi untuk tingkat kegagalan yang dapat diterima. Anda juga harus mempertimbangkan percobaan ulang saat menyetel ambang batas ini karena catatan yang gagal dapat Anda coba lagi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

Dimensi: StreamName

Deskripsi alarm: Alarm ini akan mendeteksi apakah jumlah PutRecords yang mengalami kegagalan sudah melebihi ambang batas, atau tidak. Aliran Data Kinesis akan berusaha untuk memproses semua catatan dalam setiap permintaan PutRecords, tetapi satu kegagalan catatan yang terjadi tidak akan menghentikan pemrosesan catatan berikutnya. Alasan utama yang mengakibatkan terjadinya kegagalan ini adalah dilampauinya throughput aliran atau serpihan individu. Penyebab umumnya adalah lonjakan lalu lintas dan latensi jaringan yang menyebabkan catatan tiba ke aliran dengan tidak merata. Anda harus mendeteksi catatan-catatan yang gagal diproses dan mencobanya kembali dalam panggilan berikutnya. Lihat Menangani Kegagalan Saat Menggunakan PutRecords untuk detail selengkapnya.

Maksud: Alarm ini dapat mendeteksi kegagalan yang terjadi secara terus-menerus saat Anda menggunakan operasi batch untuk menempatkan catatan ke aliran Anda. Jika Anda menyetel alarm pada metrik ini, maka Anda dapat secara proaktif mendeteksi peningkatan catatan yang mengalami kegagalan, memungkinkan Anda melakukan tindakan secara tepat waktu untuk mengatasi masalah mendasar dan memastikan proses penyerapan data berjalan dengan lancar dan andal.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas ini dengan jumlah catatan yang mengalami kegagalan yang mencerminkan toleransi aplikasi untuk catatan yang gagal. Anda dapat menggunakan data historis sebagai acuan untuk nilai kegagalan yang dapat diterima. Anda juga harus mempertimbangkan percobaan ulang saat menyetel ambang batas karena catatan yang gagal dapat dicoba lagi dalam panggilan berikutnya PutRecords .

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

Dimensi: StreamName

Deskripsi alarm: Alarm akan melacak jumlah catatan yang mengakibatkan throttling pada kapasitas throughput baca. Jika Anda menyadari bahwa Anda dibatasi secara terus-menerus, maka Anda harus mempertimbangkan untuk menambahkan lebih banyak serpihan ke aliran Anda untuk meningkatkan throughput baca yang disediakan. Jika ada lebih dari satu aplikasi konsumen yang berjalan di aliran, dan aplikasi-aplikasi itu berbagi batas GetRecords, kami menyarankan agar Anda mendaftarkan aplikasi konsumen baru melalui Enhanced Fan-Out. Jika dengan menambahkan lebih banyak serpihan tidak membuat jumlah throttling menurun, maka Anda mungkin memiliki serpihan "panas" yang sedang dibaca lebih dari pecahan lainnya. Anda perlu mengaktifkan pemantauan yang disempurnakan, dan kemudian menemukan serpihan "panas" itu, dan memisahkannya.

Maksud: Alarm ini dapat mendeteksi apakah konsumen mengalami throttling saat melebihi throughput baca yang Anda sediakan (ditentukan oleh jumlah serpihan yang Anda miliki). Dalam hal ini, Anda tidak akan dapat membaca dari aliran, dan aliran dapat mulai melakukan pencadangan.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Biasanya permintaan-permintaan yang mengalami throttling dapat dicoba ulang dan karenanya mengatur ambang batasnya dengan nol akan membuat alarm menjadi terlalu sensitif. Namun demikian, throttling yang terjadi secara terus-menerus dapat memengaruhi pembacaan dari aliran dan akan memicu alarm. Anda harus menetapkan ambang batasnya dengan persentase yang sesuai dengan permintaan yang mengalami throttling untuk aplikasi dan mencoba lagi konfigurasi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

Dimensi:StreamName, ConsumerName

Deskripsi alarm: Alarm ini akan mendeteksi apakah penundaan pemrosesan catatan dalam aplikasi telah melanggar ambang batas, atau tidak. Masalah-masalah sementara, seperti kegagalan operasi API ke aplikasi hilir, akan dapat menyebabkan peningkatan metrik yang terjadi secara tiba-tiba. Anda harus menyelidiki apakah hal itu terjadi secara terus-menerus, atau tidak. Penyebab umumnya adalah konsumen tidak memproses catatan dengan cukup cepat karena sumber daya fisik yang tidak memadai atau logika pemrosesan catatan yang belum diskalakan dengan peningkatan throughput aliran. Pemblokiran panggilan di jalur kritis sering kali menjadi penyebab terjadinya perlambatan dalam pemrosesan catatan. Anda dapat meningkatkan paralelisme Anda dengan meningkatkan jumlah serpihan. Anda juga harus mengonfirmasi bahwa simpul pemrosesan yang mendasarinya memiliki sumber daya fisik yang memadai saat permintaan mencapai puncaknya.

Maksud: Alarm ini dapat mendeteksi penundaan dalam berlangganan peristiwa serpihan aliran. Hal ini menunjukkan bahwa terjadi kelambatan pemrosesan dan dapat membantu Anda mengidentifikasi potensi masalah yang mungkin terjadi pada performa aplikasi konsumen atau kesehatan aliran secara keseluruhan. Ketika kelambatan pemrosesan menjadi semakin parah, Anda harus menyelidiki dan mengatasi kemacetan atau ketidakefisienan aplikasi konsumen untuk menjamin pelaksanaan pemrosesan data waktu nyata dan meminimalkan backlog data.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang kami sarankan untuk alarm ini sangat bergantung pada penundaan yang dapat ditoleransi oleh aplikasi Anda. Anda perlu meninjau persyaratan aplikasi Anda dan melakukan analisis tren historis, dan kemudian pilih ambang batas yang sesuai. Ketika SubscribeToShard panggilan berhasil, konsumen Anda mulai menerima SubscribeToShardEvent acara melalui koneksi persisten hingga 5 menit, setelah itu Anda perlu menelepon SubscribeToShard lagi untuk memperbarui langganan jika Anda ingin terus menerima catatan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

Dimensi: StreamName

Deskripsi alarm: Alarm ini akan mendeteksi ketika jumlah catatan yang mengakibatkan throttling kapasitas throughput penulisan mencapai ambang batasnya. Ketika produsen Anda melebihi throughput penulisan yang disediakan (ditentukan oleh jumlah serpihan yang Anda miliki), mereka akan mengalami throttling dan Anda tidak akan dapat memasukkan catatan ke aliran. Untuk mengatasi throttling yang terjadi secara terus-menerus, Anda harus mempertimbangkan untuk menambahkan serpihan ke aliran Anda. Hal ini menaikkan throughput penulisan yang Anda sediakan dan throttling terjadi lagi di masa depan. Anda juga harus mempertimbangkan pilihan kunci partisi saat menyerap catatan. Kunci partisi acak lebih disukai karena kunci ini akan menyebarkan catatan secara merata di seluruh serpihan aliran, bila memungkinkan.

Maksud: Alarm ini dapat mendeteksi apakah produsen Anda ditolak, atau tidak, untuk menulis catatan karena terjadi throttling aliran atau serpihan. Jika aliran Anda berada dalam mode Provisioned, maka dengan menyetel alarm ini akan membantu Anda secara proaktif dalam mengambil tindakan-tindakan saat aliran data mencapai batasnya, dan memungkinkan Anda mengoptimalkan kapasitas yang disediakan atau melakukan tindakan-tindakan penskalaan yang sesuai untuk menghindari terjadinya kehilangan data dan menjaga kelancaran pemrosesan data.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Biasanya permintaan yang mengalami throttling dapat dicoba lagi, jadi dengan menyetel ambang batas dengan nilai nol akan membuat alarm menjadi terlalu sensitif. Namun demikian, throttling yang terjadi secara terus-menerus akan dapat memengaruhi penulisan ke aliran, dan Anda harus mengatur ambang batas alarm untuk mendeteksi hal ini. Anda harus menetapkan ambang batasnya dengan persentase yang sesuai dengan permintaan yang mengalami throttling untuk aplikasi dan mencoba lagi konfigurasi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ClaimedAccountConcurrency

Dimensi: Tidak ada

Deskripsi alarm: Alarm ini membantu memantau apakah konkurensi fungsi Lambda Anda mendekati batas konkurensi tingkat Wilayah akun Anda. Sebuah fungsi akan mulai mengalami throttling jika mencapai batas konkurensinya. Anda dapat mengambil tindakan-tindakan berikut untuk menghindari terjadinya throttling.

Minta peningkatan konkurensi di Wilayah ini.
Identifikasi dan kurangi konkurensi cadangan yang tidak terpakai atau konkurensi yang disediakan.
Identifikasi masalah kinerja dalam fungsi untuk meningkatkan kecepatan pemrosesan dan karenanya meningkatkan throughput.
Tingkatkan ukuran batch fungsi, sehingga lebih banyak pesan diproses oleh setiap pemanggilan fungsi.

Maksud: Alarm ini dapat mendeteksi secara proaktif jika konkurensi fungsi Lambda Anda mendekati kuota konkurensi tingkat Wilayah akun Anda, sehingga Anda dapat menindaklanjutinya. Fungsi dibatasi jika ClaimedAccountConcurrency mencapai kuota konkurensi tingkat Wilayah akun. Jika Anda menggunakan Reserved Concurrency (RC) atau Provisioned Concurrency (PC), alarm ini memberi Anda lebih banyak visibilitas tentang pemanfaatan konkurensi daripada alarm yang digunakan. ConcurrentExecutions

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung nilai sekitar 90% dari kuota konkurensi yang ditetapkan untuk akun di Wilayah, dan menggunakan hasilnya sebagai nilai ambang batas. Secara default, akun Anda memiliki kuota konkurensi sebesar 1.000 di semua fungsi di sebuah Wilayah. Namun, Anda harus memeriksa kuota akun Anda dari dasbor Service Quotas.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

Kesalahan

Dimensi: FunctionName

Deskripsi alarm: Alarm ini akan mendeteksi terjadinya jumlah kesalahan yang tinggi. Kesalahan tersebut mencakup pengecualian yang dibuat oleh kode serta pengecualian yang dibuat oleh runtime Lambda. Anda dapat memeriksa log yang terkait dengan fungsi tersebut untuk melakukan diagnosis masalah.

Maksud: Alarm ini akan membantu mendeteksi jumlah kesalahan yang tinggi dalam invokasi fungsi.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas dengan angka yang lebih besar dari nol. Nilai yang tepat dapat bergantung pada toleransi terhadap kesalahan yang diterapkan dalam aplikasi Anda. Anda juga harus memahami kekritisan invokasi yang ditangani oleh fungsi tersebut. Untuk beberapa aplikasi, kesalahan apa pun mungkin tidak akan dapat diterima, sedangkan untuk aplikasi yang lain mungkin memungkinkan margin kesalahan tertentu.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: GREATER_THAN_THRESHOLD

Pembatasan

Dimensi: FunctionName

Deskripsi alarm: Alarm ini akan mendeteksi sejumlah besar permintaan invokasi yang mengalami throttling. Throttling terjadi ketika tidak ada konkurensi yang tersedia untuk menaikkan skala. Ada beberapa pendekatan yang bisa dilakukan untuk mengatasi masalah ini. 1) Minta peningkatan konkurensi dari AWS Support di Wilayah ini. 2) Mengidentifikasi masalah performa yang terjadi dalam fungsi tersebut untuk meningkatkan kecepatan pemrosesan dan karenanya juga akan meningkatkan throughput. 3) Meningkatkan ukuran batch fungsi, sehingga lebih banyak pesan yang bisa diproses oleh masing-masing invokasi fungsi.

Maksud: Alarm ini akan membantu Anda dalam mendeteksi sejumlah besar permintaan invokasi yang mengalami throttling untuk fungsi Lambda. Penting bagi Anda untuk mengetahui apakah permintaan terus-menerus ditolak karena terjadinya throttling dan apakah Anda perlu meningkatkan performa fungsi Lambda atau meningkatkan kapasitas konkurensi untuk menghindari terjadinya throttling yang sulit diatasi.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batas dengan angka yang lebih besar dari nol. Nilai pasti dari ambang batas ini dapat bergantung pada toleransi aplikasi. Anda harus menetapkan ambang batas tersebut sesuai dengan persyaratan penggunaan dan penskalaan fungsinya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Durasi

Dimensi: FunctionName

Deskripsi alarm: Alarm ini akan mendeteksi waktu durasi yang lama untuk mengolah suatu peristiwa dengan fungsi Lambda. Durasi yang lama tersebut mungkin saja terjadi karena adanya perubahan kode fungsi yang membuat fungsi membutuhkan waktu yang lebih lama untuk dijalankan, atau dependensi fungsi tersebut memakan waktu yang lebih lama.

Maksud: Alarm ini dapat mendeteksi durasi yang berjalan lama dari sebuah fungsi Lambda. Durasi runtime yang tinggi menjadi indikasi bahwa suatu fungsi memerlukan waktu yang lebih lama untuk invokasi, dan hal ini juga dapat memengaruhi kapasitas invokasi konkurensi apabila Lambda menangani jumlah peristiwa yang lebih tinggi. Sangat penting bagi Anda untuk mengetahui apakah fungsi Lambda tersebut terus-menerus memakan waktu eksekusi yang lebih lama dari yang diharapkan, atau tidak.

Statistik: p90

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Ambang batas untuk durasi akan tergantung pada aplikasi dan beban kerja Anda serta persyaratan performa Anda. Untuk persyaratan performa tinggi, Anda perlu menetapkan ambang batasnya dengan waktu yang lebih singkat untuk melihat apakah fungsi tersebut sesuai dengan harapan. Anda juga dapat melakukan analisis data historis untuk metrik durasi untuk melihat apakah waktu yang dibutuhkan sesuai dengan ekspektasi performa yang diharapkan dari fungsi tersebut, dan kemudian Anda juga perlu mengatur ambang batasnya dengan waktu yang lebih lama daripada waktu rata-rata sesuai riwayatnya. Anda harus memastikan untuk mengatur ambang batas tersebut lebih rendah dari batas waktu fungsi yang dikonfigurasi.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

ConcurrentExecutions

Dimensi: FunctionName

Deskripsi alarm: Alarm ini akan membantu Anda memantau apakah konkurensi fungsi sudah mendekati batas konkurensi tingkat Wilayah yang ditetapkan untuk akun Anda. Sebuah fungsi akan mulai mengalami throttling jika mencapai batas konkurensinya. Anda dapat mengambil tindakan-tindakan berikut untuk menghindari terjadinya throttling.

Minta peningkatan konkurensi di Wilayah ini.
Identifikasi masalah kinerja dalam fungsi untuk meningkatkan kecepatan pemrosesan dan karenanya meningkatkan throughput.
Tingkatkan ukuran batch fungsi, sehingga lebih banyak pesan diproses oleh setiap pemanggilan fungsi.

Untuk mendapatkan visibilitas yang lebih baik pada konkurensi cadangan dan pemanfaatan konkurensi yang disediakan, setel alarm pada metrik baru sebagai gantinya. ClaimedAccountConcurrency

Maksud: Alarm ini dapat mendeteksi secara proaktif apakah konkurensi fungsi sudah mendekati kuota konkurensi tingkat Wilayah yang ditetapkan untuk akun Anda, sehingga Anda dapat menindaklanjutinya. Sebuah fungsi mengalami throttling jika fungsi tersebut mencapai kuota konkurensi tingkat Wilayah yang ditetapkan untuk akun tersebut.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menetapkan ambang batasnya menjadi sekitar 90% dari kuota konkurensi yang ditetapkan untuk akun di Wilayah. Secara default, akun Anda memiliki kuota konkurensi sebesar 1.000 di semua fungsi di sebuah Wilayah. Namun, Anda dapat memeriksa kuota akun Anda, karena dapat ditingkatkan dengan menghubungi AWS dukungan.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

memory_utilization

Dimensi: function_name

Deskripsi alarm: Alarm ini digunakan untuk mendeteksi apakah pemanfaatan memori dari sebuah fungsi lambda sudah mendekati batas yang dikonfigurasikan untuknya. Untuk pemecahan masalah, Anda dapat mencoba untuk 1) Mengoptimalkan kode Anda. 2) Mengukur alokasi memori Anda dengan benar dengan memperkirakan kebutuhan memori yang Anda perlukan secara akurat. Anda dapat melihat Lambda Power Tuning untuk mendapatkan informasi selengkapnya tengang hal ini. 3) Menggunakan penyatuan koneksi. Silakan lihat Menggunakan Proksi Amazon RDS dengan Lambda untuk melakukan penyatuan koneksi untuk basis data RDS. 4) Anda juga dapat mempertimbangkan untuk merancang fungsi Anda dengan tujuan untuk mencegah penyimpanan sejumlah besar data dalam memori di antara invokasi.

Maksud: Alarm ini digunakan untuk mendeteksi apakah pemanfaatan memori untuk fungsi Lambda sudah mendekati batas yang dikonfigurasikan.

Statistik: Rata-rata

Saran Ambang Batas: 90,0

Pembenaran Ambang Batas:Anda perlu mengatur ambang batas menjadi 90% untuk mendapatkan peringatan ketika pemanfaatan memori melampaui 90% dari memori yang dialokasikan. Anda dapat menyesuaikan nilai ambang batas ini dengan nilai yang lebih rendah jika Anda memiliki kekhawatiran terhadap beban kerja untuk pemanfaatan memori. Anda juga dapat memeriksa data historis untuk metrik ini dan menetapkan ambang batas sesuai dengan data historis tersebut.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

ComparisonOperator: LEBIH BESAR_THAN_THRESHOLD

ErrorPortAllocation

Dimensi: NatGatewayId

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi ketika NAT Gateway tidak dapat memberikan alokasi port untuk koneksi baru. Untuk mengatasi permasalahan ini, Anda bisa lihat Mengatasi kesalahan alokasi port pada NAT Gateway.

Maksud: Alarm ini akan digunakan untuk mendeteksi apakah NAT gateway tidak dapat mengalokasikan port sumber.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Jika nilai ErrorPortAllocation lebih besar dari nol, itu berarti terlalu banyak koneksi bersamaan ke satu tujuan populer terbuka melalui NatGateway.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

PacketsDropCount

Dimensi: NatGatewayId

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi apakah paket sudah dijatuhkan oleh NAT Gateway, atau tidak. Ini mungkin terjadi karena masalah dengan NAT Gateway, jadi periksa dasbor kesehatan AWS layanan untuk status AWS NAT Gateway di Wilayah Anda. Hal ini akan dapat membantu Anda dalam menghubungkan masalah jaringan yang terjadi yang berkaitan dengan lalu lintas dengan menggunakan NAT gateway.

Maksud: Alarm ini akan digunakan untuk mendeteksi apakah paket sudah dijatuhkan oleh NAT Gateway, atau tidak.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung nilai 0,01 persen dari total lalu lintas di NAT Gateway dan menggunakan hasil perhitungan itu sebagai nilai ambang batas. Anda juga perlu menggunakan data historis lalu lintas pada NAT Gateway untuk menentukan ambang batas tersebut.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

PacketsDropped

Dimensi: Id VPC, Id Titik Akhir VPC, Jenis Titik Akhir, Id Subnet, Nama Layanan

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi apakah titik akhir atau layanan titik akhir sedang dalam kondisi tidak sehat dengan memantau jumlah paket yang dijatuhkan oleh titik akhir. Perlu Anda perhatikan bahwa paket yang lebih besar dari 8500 byte yang tiba di titik akhir VPC akan dijatuhkan. Untuk pemecahan masalah, silakan lihat masalah konektivitas antara sebuah titik akhir VPC antarmuka dan sebuah layanan titik akhir.

Maksud: Alarm ini akan digunakan untuk mendeteksi apakah titik akhir atau layanan titik akhir sedang dalam kondisi tidak sehat.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda perlu menetapkan ambang batas ini sesuai dengan kasus penggunaan Anda. Jika Anda ingin mengetahui status titik akhir atau layanan titik akhir yang sedang dalam kondisi tidak sehat, maka Anda harus menetapkan ambang batas dengan nilai rendah sehingga Anda akan mendapatkan kesempatan untuk memperbaiki masalah sebelum Anda mengalami kehilangan data dalam jumlah besar. Anda juga dapat menggunakan data historis untuk memahami toleransi terhadap paket-paket yang dijatuhkan dan menetapkan ambang batas sesuai dengan data historis tersebut.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

RstPacketsSent

Dimensi: Id Layanan, Penyeimbang Beban Arn, Az

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi target yang sedang dalam kondisi tidak sehat dari layanan titik akhir berdasarkan jumlah paket reset yang dikirim ke titik akhir. Saat Anda men-debug kesalahan koneksi dengan konsumen layanan Anda, Anda dapat memvalidasi apakah layanan mengatur ulang koneksi dengan RstPacketsSent metrik, atau jika ada hal lain yang gagal di jalur jaringan.

Maksud: Alarm ini akan digunakan untuk mendeteksi target yang sedang dalam kondisi tidak sehat dari layanan titik akhir.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Ambang batas ini akan bergantung pada kasus penggunaan Anda. Jika kasus penggunaan Anda dapat memberikan toleransi pada target yang sedang dalam kondisi tidak sehat, maka Anda dapat menetapkan ambang batas dengan nilai yang tinggi. Jika kasus penggunaan tersebut tidak dapat memberikan toleransi pada target yang tidak sehat, maka Anda dapat menetapkan ambang batas dengan nilai yang sangat rendah.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

CPUUtilization

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau pemanfaatan CPU yang berada dalam level yang tinggi secara konsisten. Pemanfaatan CPU mengukur waktu non-idle. Pertimbangkan untuk menggunakan Pemantauan yang Ditingkatkan atau Wawasan Performa untuk meninjau waktu tunggu mana yang menghabiskan sebagian besar waktu CPU (guest, irq, wait, nice dan sebagainya) untuk MariaDB, MySQL, Oracle, dan PostgreSQL. Kemudian evaluasi kueri-kueri mana yang mengkonsumsi jumlah CPU yang paling tinggi. Jika Anda tidak dapat menyetel beban kerja Anda, pertimbangkanlah untuk pindah ke kelas instans DB yang lebih besar.

Maksud: Alarm ini digunakan untuk mendeteksi pemanfaatan CPU yang berada dalam level yang tinggi secara konsisten untuk mencegah waktu respons dan batas waktu yang sangat tinggi. Jika Anda ingin memeriksa micro-bursting yang terjadi pada pemanfaatan CPU, Anda dapat mengatur waktu evaluasi alarm yang lebih rendah.

Statistik: Rata-rata

Ambang batas yang disarankan: 90,0

Pembenaran ambang batas: Lonjakan acak dalam konsumsi CPU mungkin tidak akan menghambat performa basis data, tetapi pemanfaatan CPU yang tinggi yang terus-menerus dapat menghambat permintaan basis data yang akan datang. Bergantung pada beban kerja basis data secara keseluruhan, CPU tinggi pada instans RDS/Aurora Anda dapat menurunkan performa secara keseluruhan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

DatabaseConnections

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini mendeteksi koneksi dalam jumlah besar. Tinjau koneksi-koneksi yang ada dan hentikan semua koneksi yang berada dalam keadaan `sleep` atau koneksi yang tidak ditutup dengan benar. Pertimbangkan untuk menggunakan penyatuan koneksi untuk membatasi jumlah koneksi yang baru. Atau, tingkatkan ukuran instans DB untuk menggunakan kelas yang memiliki lebih banyak memori dan karenanya memiliki nilai default yang lebih tinggi untuk `max_connections` atau tingkatkan nilai `max_connections` di RDS dan Aurora MySQL dan PostgreSQL untuk kelas saat ini jika hal itu dapat mendukung beban kerja Anda.

Maksud: Alarm ini digunakan untuk membantu mencegah koneksi-koneksi yang ditolak ketika jumlah maksimum koneksi DB tercapai. Alarm ini tidak disarankan jika Anda sering mengubah kelas instans DB, karena hal itu akan mengubah memori dan jumlah koneksi maksimum default.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Jumlah koneksi yang diperkenankan bergantung pada ukuran kelas instans DB Anda dan parameter spesifik mesin basis data yang terkait dengan proses/koneksi. Anda harus menghitung nilai antara 90-95% dari jumlah maksimum koneksi untuk basis data Anda dan menggunakan hasil tersebut sebagai nilai ambang batas.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

EBS% ByteBalance

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau persentase kredit throughput yang tersisa yang berada dalam level yang rendah. Untuk pemecahan masalah, silakan periksa masalah latensi di RDS.

Maksud: Alarm ini digunakan untuk mendeteksi persentase sisa kredit throughput di bucket burst yang berada dalam level rendah. Persentase saldo byte yang rendah dapat menyebabkan terjadinya masalah-masalah kemacetan throughput. Alarm ini tidak disarankan untuk instans Aurora PostgreSQL.

Statistik: Rata-rata

Ambang batas yang disarankan: 10,0

Pembenaran ambang batas: Saldo kredit throughput di bawah 10% dianggap buruk dan Anda harus menetapkan ambang batas yang semestinya. Anda juga dapat menetapkan sebuah ambang batas yang lebih rendah jika aplikasi Anda dapat mentolerir throughput yang lebih rendah untuk beban kerja tersebut.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: LESS_THAN_THRESHOLD

EBSIOBalance%

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau persentase kredit IOPS yang tersisa yang berada dalam level yang rendah. Untuk pemecahan masalah, silakan lihat masalah latensi di RDS.

Maksud: Alarm ini digunakan untuk mendeteksi persentase sisa kredit I/O di bucket burst yang berada dalam level rendah. Persentase saldo byte yang rendah dapat menyebabkan terjadinya masalah-masalah kemacetan IOPS. Alarm ini tidak disarankan untuk instans Aurora.

Statistik: Rata-rata

Ambang batas yang disarankan: 10,0

Pembenaran ambang batas: Saldo kredit IOPS di bawah 10% dianggap buruk dan Anda dapat menetapkan ambang batas yang semestinya. Anda juga dapat menetapkan sebuah ambang batas yang lebih rendah jika aplikasi Anda dapat mentolerir IOPS yang lebih rendah untuk beban kerja tersebut.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: LESS_THAN_THRESHOLD

FreeableMemory

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau memori yang bisa dibebaskan yang berada dalam level yang rendah yang dapat berarti bahwa ada lonjakan koneksi basis data atau instans Anda mungkin berada di bawah tekanan memori tinggi. Periksa tekanan memori dengan memantau CloudWatch metrik untuk SwapUsage `selain. FreeableMemory Jika penggunaan memori instans sering berada dalam level yang terlalu tinggi, hal ini menunjukkan bahwa Anda harus memeriksa beban kerja Anda atau meningkatkan kelas instans Anda. Untuk instans DB pembaca Aurora, pertimbangkan untuk menambahkan instans DB pembaca tambahan ke klaster tersebut. Untuk informasi tentang pemecahan masalah Aurora, lihat masalah memori yang dapat dibebaskan.

Maksud: Alarm ini digunakan untuk membantu mencegah terjadinya kehabisan memori yang dapat mengakibatkan koneksi ditolak.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Bergantung pada beban kerja dan kelas instans, nilai-nilai yang berbeda untuk ambang batas dapat dibenarkan. Idealnya, memori yang tersedia tidak boleh berada di bawah 25% dari total memori dalam waktu yang lama. Untuk Aurora, Anda dapat mengatur ambang batasnya mendekati 5%, karena metrik mendekati 0, itu artinya instans DB telah dinaikkan skalanya sebisa mungkin. Anda dapat menganalisis perilaku historis metrik ini untuk menentukan tingkat ambang batas yang masuk akal.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: LESS_THAN_THRESHOLD

FreeLocalStorage

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau penyimpanan lokal bebas dalam level yang rendah. Aurora PostgreSQL-Compatible Edition menggunakan penyimpanan lokal untuk menyimpan log kesalahan dan file sementara. Aurora MySQL menggunakan penyimpanan lokal untuk menyimpan log kesalahan, log umum, log kueri lambat, log audit, dan tabel-tabel sementara non-InnoDB. Volume penyimpanan lokal ini didukung oleh Amazon EBS dan dapat diperluas dengan menggunakan kelas instans DB yang lebih besar. Untuk pemecahan masalah, periksa Aurora PostgreSQL-Compatible dan MySQL-Compatible.

Maksud: Alarm ini digunakan untuk mendeteksi seberapa dekat instans Aurora DB untuk mencapai batas penyimpanan lokal, jika Anda tidak menggunakan Aurora Serverless v2 atau yang lebih tinggi. Penyimpanan lokal dapat mencapai kapasitas saat Anda menyimpan data non-persisten, seperti tabel sementara dan file log, di penyimpanan lokal tersebut. Alarm ini dapat mencegah out-of-space kesalahan yang terjadi ketika instans DB Anda kehabisan penyimpanan lokal.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung sekitar 10% -20% dari jumlah penyimpanan yang tersedia berdasarkan kecepatan dan tren penggunaan volume, dan kemudian menggunakan hasil itu sebagai nilai ambang batas untuk secara proaktif mengambil tindakan sebelum volume tersebut mencapai batasnya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

FreeStorageSpace

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini berfungsi untuk jumlah ruang penyimpanan yang tersedia yang rendah. Pertimbangkan untuk menaikkan skala penyimpanan basis data Anda jika Anda sering kali mendekati batas kapasitas penyimpanan. Sertakan beberapa buffer untuk mengakomodasi peningkatan permintaan yang tidak terduga dari aplikasi Anda. Atau, pertimbangkan untuk mengaktifkan penskalaan otomatis penyimpanan RDS. Selain itu, pertimbangkan untuk membebaskan lebih banyak ruang dengan menghapus data dan log yang tidak terpakai atau sudah usang. Untuk informasi lebih lanjut, silakan periksa dokumen RDS kehabisan penyimpanan dan dokumen masalah penyimpanan PostgreSQL.

Maksud: Alarm ini akan membantu Anda mencegah masalah-masalah penyimpanan penuh. Hal ini dapat mencegah terjadinya downtime ketika instans basis data Anda kehabisan penyimpanan. Kami tidak menyarankan Anda untuk menggunakan alarm ini jika Anda mengaktifkan penskalaan otomatis penyimpanan, atau jika Anda sering kali mengubah kapasitas penyimpanan instans basis data Anda.

Statistik: Minimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas akan tergantung pada ruang penyimpanan yang saat ini dialokasikan. Biasanya, Anda harus menghitung nilai 10 persen dari ruang penyimpanan yang dialokasikan dan menggunakan hasil itu sebagai nilai ambang batasnya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

MaximumUsedTransactionID

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam mencegah penutupan ID transaksi untuk PostgreSQL. Lihat langkah-langkah pemecahan masalah yang diuraikan di blog ini untuk menyelidiki dan menyelesaikan masalah. Anda juga dapat merujuk ke blog ini untuk membiasakan diri Anda lebih jauh dengan konsep autovacuum, masalah umum, dan praktik terbaik.

Maksud: Alarm ini digunakan untuk membantu mencegah penutupan ID transaksi untuk PostgreSQL.

Statistik: Rata-rata

Ambang batas yang disarankan: 1.0E9

Pembenaran ambang batas: Menetapkan ambang batas ini menjadi 1 miliar akan memberi Anda waktu untuk menyelidiki masalahnya. Nilai default autovacuum_freeze_max_age adalah 200 juta. Jika usia transaksi tertua adalah 1 miliar, maka autovacuum akan mengalami masalah dalam menjaga ambang batas ini di bawah target 200 juta ID transaksi.

Periode: 60

Titik data untuk alarm: 1

Periode evaluasi: 1

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReadLatency

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau latensi baca yang tinggi. Jika latensi penyimpanan berada dalam level yang tinggi, hal itu karena beban kerja melebihi batas sumber daya. Anda dapat meninjau pemanfaatan I/O relatif terhadap instans dan konfigurasi penyimpanan yang dialokasikan. Lihat pemecahan masalah latensi volume Amazon EBS yang disebabkan oleh kemacetan IOPS. Untuk Aurora, Anda dapat beralih ke kelas instans yang memiliki konfigurasi penyimpanan I/O-Optimized. Lihat Perencanaan I/O di Aurora untuk mendapatkan panduannya.

Maksud: Alarm ini digunakan untuk mendeteksi latensi baca tinggi. Disk basis data biasanya memiliki latensi baca/tulis yang rendah, tetapi mereka dapat memiliki masalah yang dapat menyebabkan terjadinya operasi latensi yang tinggi.

Statistik: p90

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat tergantung pada kasus penggunaan Anda. Latensi-latensi baca yang lebih tinggi dari 20 milidetik kemungkinan menjadi penyebab terjadinya penyelidikan. Anda juga dapat menetapkan ambang batas yang lebih tinggi jika aplikasi Anda dapat memiliki latensi yang lebih tinggi untuk operasi baca. Tinjau kekritisan dan persyaratan latensi baca dan kemudian lakukan analisis perilaku historis dari metrik ini untuk menentukan tingkat ambang batas yang masuk akal.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ReplicaLag

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memahami jumlah detik sebuah replika berada di belakang instans utama. Replika Baca PostgreSQL melaporkan keterlambatan replikasi hingga lima menit jika tidak ada transaksi pengguna yang dilakukan pada instans basis data sumber. Ketika ReplicaLag metrik mencapai 0, replika telah menyusul instans DB utama. Jika ReplicaLag metrik mengembalikan -1, maka replikasi saat ini tidak aktif. Untuk panduan terkait PostgreSQL RDS, lihat praktik terbaik replikasi dan untuk ReplicaLag pemecahan masalah dan kesalahan terkait, lihat pemecahan masalah. ReplicaLag

Maksud: Alarm ini dapat mendeteksi lag replika yang mencerminkan kehilangan data yang dapat terjadi jika ada kegagalan pada instans primernya. Jika replika tersebut terlalu jauh di belakang instans primer dan instans primer tersebut gagal, maka replika akan kehilangan data yang ada di instans primer.

Statistik: Maksimum

Ambang batas yang disarankan: 60,0

Pembenaran ambang batas: Biasanya, keterlambatan yang dapat diterima tergantung pada aplikasi. Kami merekomendasikan tidak lebih dari 60 detik.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: GREATER_THAN_THRESHOLD

WriteLatency

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau latensi tulis yang tinggi. Jika latensi penyimpanan berada dalam level yang tinggi, hal itu karena beban kerja melebihi batas sumber daya. Anda dapat meninjau pemanfaatan I/O relatif terhadap instans dan konfigurasi penyimpanan yang dialokasikan. Lihat pemecahan masalah latensi volume Amazon EBS yang disebabkan oleh kemacetan IOPS. Untuk Aurora, Anda dapat beralih ke kelas instans yang memiliki konfigurasi penyimpanan I/O-Optimized. Lihat Perencanaan I/O di Aurora untuk mendapatkan panduannya.

Maksud: Alarm ini digunakan untuk mendeteksi latensi tulis yang tinggi. Meskipun disk basis data biasanya memiliki latensi baca/tulis yang rendah, mereka mungkin mengalami masalah yang menyebabkan operasi latensi yang tinggi. Pemantauan ini akan memastikan kepada Anda latensi disk serendah yang diharapkan.

Statistik: p90

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat tergantung pada kasus penggunaan Anda. Latensi-latensi tulis yang lebih tinggi dari 20 milidetik kemungkinan menjadi penyebab terjadinya penyelidikan. Anda juga dapat menetapkan ambang batas yang lebih tinggi jika aplikasi Anda dapat memiliki latensi yang lebih tinggi untuk operasi tulis. Tinjau kekritisan dan persyaratan latensi tulis dan kemudian lakukan analisis perilaku historis dari metrik ini untuk menentukan tingkat ambang batas yang masuk akal.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

DBLoad

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau beban DB yang tinggi. Jika jumlah proses melebihi jumlah vCPU, maka proses ini akan mulai mengantre. Ketika antrean meningkat, performa akan terpengaruh. Jika muatan DB sering melampaui vCPU maksimum dan status tunggu utamanya adalah CPU, maka CPU akan kelebihan muatan. Dalam hal ini, Anda dapat memantau CPUUtilization, DBLoadCPU dan tugas yang diantrekan di Wawasan Performa/Pemantauan yang Ditingkatkan. Anda mungkin ingin melakukan throttling koneksi ke instans, menyesuaikan kueri semua SQL dengan muatan CPU yang tinggi, atau mempertimbangkan kelas instans yang lebih besar. Instans yang tinggi dan konsisten dari setiap status tunggu menunjukkan bahwa mungkin terjadi kemacetan atau masalah ketidakcocokan sumber daya yang perlu diselesaikan.

Maksud: Alarm ini digunakan untuk mendeteksi muatan DB yang tinggi. Beban DB yang tinggi dapat menyebabkan terjadinya masalah performa pada instans DB. Alarm ini tidak berlaku untuk instans DB nirserver.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai vCPU maksimum ditentukan oleh jumlah inti vCPU (CPU virtual) untuk instans DB Anda. Bergantung pada vCPU maksimum, nilai-nilai yang berbeda untuk ambang batas tersebut bisa dibenarkan. Idealnya, muatan DB tidak boleh melebihi garis vCPU.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

Dimensi: DB ClusterIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau volume total sisa yang rendah. Ketika total volume yang tersisa mencapai batas ukuran, cluster melaporkan out-of-space kesalahan. Penyimpanan Aurora secara otomatis menskalakan dengan data dalam volume klaster dan bisa berekspansi hingga 128 TiB atau 64 TiB tergantung pada versi mesin DB. Pertimbangkan untuk mengurangi penyimpanan dengan menghapus tabel dan basis data yang tidak lagi Anda perlukan. Untuk informasi lebih lanjut, silakan periksa penskalaan penyimpanan.

Maksud: Alarm ini digunakan untuk mendeteksi seberapa dekat klaster Aurora dengan batas ukuran volume tersebut. Alarm ini dapat mencegah out-of-space kesalahan yang terjadi ketika cluster Anda kehabisan ruang. Alarm ini direkomendasikan hanya untuk Aurora MySQL.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung 10% -20% dari batas ukuran yang sebenarnya berdasarkan kecepatan dan tren kenaikan penggunaan volume, dan kemudian menggunakan hasil itu sebagai nilai ambang batas untuk secara proaktif mengambil tindakan sebelum volume tersebut mencapai batasnya.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

Dimensi: DBClusterIdentifier, peran = penulis

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau status kesalahan replikasi instans penulis Aurora. Untuk informasi selengkapnya, lihat Mereplikasi kluster DB MySQL Aurora di seluruh Wilayah. AWS Untuk pemecahan masalah, silakan lihat Masalah replikasi Aurora MySQL.

Maksud: Alarm ini digunakan untuk mendeteksi apakah instans penulis berada dalam status kesalahan, atau tidak, dan tidak dapat mereplikasi sumbernya. Alarm ini direkomendasikan hanya untuk Aurora MySQL.

Statistik: Rata-rata

Ambang batas yang disarankan: -1,0

Pembenaran ambang batas: Kami menyarankan Anda menggunakan -1 sebagai nilai ambang batas karena Aurora MySQL akan menerbitkan nilai ini jika replika berada dalam status kesalahan.

Periode: 60

Titik data untuk alarm: 2

Periode evaluasi: 2

Operator Perbandingan: LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau jumlah transaksi yang diblokir yang sedang dalam level yang tinggi dalam sebuah instans Aurora DB. Transaksi-transaksi yang diblokir dapat berakhir dengan rollback atau commit. Konkurensi yang berada dalam level yang tinggi, idle dalam transaksi, atau transaksi yang berjalan lama dapat menyebabkan terjadinya pemblokiran transaksi. Untuk pemecahan masalah, silakan lihat dokumentasi Aurora MySQL.

Maksud: Alarm ini digunakan untuk mendeteksi jumlah transaksi yang diblokir dalam sebuah instans Aurora DB untuk mencegah terjadinya kemunduran transaksi dan penurunan performa.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung 5% dari semua transaksi instans Anda dengan menggunakan metrik ActiveTransactions dan menggunakan hasil itu sebagai nilai ambang batas. Anda juga dapat meninjau kekritisan dan persyaratan transaksi yang diblokir dan menganalisis perilaku historis metrik ini untuk menentukan tingkat ambang batas yang masuk akal.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

BufferCacheHitRatio

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau rasio hit cache yang berada dalam level yang rendah secara konsisten dari klaster Aurora. Rasio hit yang rendah menunjukkan bahwa kueri Anda pada instans DB ini sering kali masuk ke disk. Untuk pemecahan masalah, lakukan investigasi pada beban kerja Anda untuk melihat kueri mana yang menyebabkan perilaku ini, dan kemudian lihat dokumen rekomendasi RAM instans DB.

Maksud: Alarm ini digunakan untuk mendeteksi rasio hit cache yang berada dalam level rendah secara konsisten untuk mencegah terjadinya penurunan performa berkelanjutan pada instans Aurora.

Statistik: Rata-rata

Ambang batas yang disarankan: 80,0

Pembenaran ambang batas: Anda dapat mengatur ambang batas untuk rasio hit cache buffer menjadi 80%. Namun demikian, Anda dapat menyesuaikan nilai ini berdasarkan tingkat performa dan karakteristik beban kerja yang dapat diterima.

Periode: 60

Titik data untuk alarm: 10

Periode evaluasi: 10

Operator Perbandingan: LESS_THAN_THRESHOLD

EngineUptime

Dimensi: DBClusterIdentifier, peran = penulis

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau downtime rendah dari instans DB penulis. Instans DB penulis dapat turun karena adanya reboot, pemeliharaan, peningkatan, atau failover. Ketika waktu aktif mencapai 0 karena terjadi failover dalam klaster tersebut, dan klaster itu memiliki satu atau beberapa Replika Aurora, maka Replika Aurora akan dipromosikan ke instans penulis primer selama peristiwa kegagalan. Untuk meningkatkan ketersediaan klaster DB Anda, pertimbangkan untuk membuat setidaknya satu atau beberapa Replika Aurora di dua Zona Ketersediaan yang berbeda. Untuk informasi lebih lanjut, silakan periksa faktor-faktor yang memengaruhi downtime Aurora.

Maksud: Alarm ini digunakan untuk mendeteksi apakah instans DB penulis Aurora sedang berada dalam keadaan downtime. Hal ini dapat mencegah terjadinya kegagalan jangka panjang dalam instans penulis karena crash atau failover.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Peristiwa kegagalan mengakibatkan terjadinya interupsi dalam waktu singkat, di mana pada saat itu operasi baca dan tulis gagal dengan pengecualian. Namun demikian, layanan biasanya akan pulih dalam waktu kurang dari 60 detik, dan sering kali kurang dari 30 detik.

Periode: 60

Titik data untuk alarm: 2

Periode evaluasi: 2

Operator Perbandingan: LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

Dimensi: DB InstanceIdentifier

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau panjang riwayat segmen rollback yang berada dalam level tinggi secara konsisten dari sebuah instans Aurora. Panjang daftar riwayat InnoDB yang tinggi menunjukkan bahwa sejumlah besar versi baris lama, kueri, dan shutdown basis data menjadi lebih lambat. Untuk informasi selengkapnya dan pemecahan masalah, silakan lihat dokumentasi panjang daftar riwayat InnoDB meningkat secara signifikan.

Maksud: Alarm ini digunakan untuk mendeteksi panjang riwayat segmen rollback yang berada dalam level tinggi secara konsisten. Hal ini dapat membantu Anda mencegah penurunan performa berkelanjutan dan penggunaan CPU yang tinggi yang terjadi di instans Aurora. Alarm ini direkomendasikan hanya untuk Aurora MySQL.

Statistik: Rata-rata

Ambang batas yang disarankan: 1000000,0

Pembenaran ambang batas: Menetapkan ambang batas ini menjadi 1 juta akan memberi Anda waktu untuk menyelidiki masalahnya. Namun demikian, Anda dapat menyesuaikan nilai ini berdasarkan tingkat performa dan karakteristik beban kerja yang dapat diterima.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

StorageNetworkThroughput

Dimensi: DBClusterIdentifier, peran = penulis

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau throughput jaringan penyimpanan yang tinggi. Jika throughput jaringan penyimpanan melewati total bandwidth jaringan dari instans EC2, hal ini akan dapat menyebabkan latensi baca dan tulis yang tinggi dan kemudian dapat menyebabkan penurunan performa. Anda dapat memeriksa jenis instans EC2 dari AWS Console. Untuk pemecahan masalah, silakan periksa setiap perubahan pada latensi tulis/baca dan evaluasi apakah Anda juga menekan alarm pada metrik ini. Jika itu masalahnya, lakukan evaluasi pada pola beban kerja Anda selama alarm dipicu. Hal ini dapat membantu Anda dalam mengidentifikasi apakah Anda dapat mengoptimalkan beban kerja kami untuk mengurangi jumlah total lalu lintas jaringan. Jika ini tidak memungkinkan, maka Anda mungkin perlu mempertimbangkan untuk menskalakan instans Anda.

Maksud: Alarm ini digunakan untuk mendeteksi throughput jaringan penyimpanan yang tinggi. Mendeteksi throughput yang tinggi dapat mencegah terjadinya penurunan paket jaringan dan penurunan performa.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda harus menghitung sekitar 80%-90% dari total bandwidth jaringan tipe instans EC2, dan kemudian menggunakan hasil itu sebagai nilai ambang batas untuk secara proaktif mengambil tindakan sebelum paket jaringan terpengaruh. Anda juga dapat meninjau kekritisan dan persyaratan throughput jaringan penyimpanan dan melakukan analisis terhadap perilaku historis metrik ini untuk menentukan tingkat ambang batas yang masuk akal.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

HealthCheckStatus

Dimensi: HealthCheckId

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi titik akhir yang sedang dalam kondisi tidak sehat sesuai pemeriksa kondisi. Untuk memahami alasan kegagalan yang mengakibatkan status tidak sehat tersebut, Anda perlu menggunakan tab Pemeriksaan Kondisi di Konsol Pemeriksaan Kondisi Route 53 untuk melihat status dari masing-masing Wilayah serta kegagalan pemeriksaan kondisi terakhir yang mengalami kegagalan. Tab status tersebut juga dapat menampilkan alasan yang mengakibatkan titik akhir dilaporkan tidak sehat. Silakan lihat langkah-langkah pemecahan masalah.

Maksud: Alarm ini menggunakan pemeriksa kondisi Route53 untuk mendeteksi titik akhir yang sedang dalam kondisi tidak sehat.

Statistik: Rata-rata

Ambang batas yang disarankan: 1,0

Pembenaran ambang batas: Status titik akhir dilaporkan dengan nilai 1 saat sedang dalam kondisi yang sehat. Jika nilainya kurang dari 1, berarti kondisinya tidak sehat.

Periode: 60

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: LESS_THAN_THRESHOLD

4xxErrors

Dimensi:BucketName, FilterId

Deskripsi alarm: Alarm ini akan membantu kami dalam melaporkan jumlah total kode status kesalahan 4xx yang dibuat sebagai respons atas permintaan klien. Kode kesalahan 403 mungkin menunjukkan adanya kebijakan IAM yang salah, dan kode kesalahan 404 mungkin menunjukkan bahwa aplikasi klien yang berperilaku salah, begitu contohnya. Mengaktifkan pencatatan log akses server S3 sementara waktu akan membantu Anda dalam menentukan dari mana asal masalah yang terjadi dengan menggunakan bidang status HTTP dan Kode Kesalahan. Agar Anda dapat lebih memahami tentang kode kesalahan tersebut, silakan lihat Respons Kesalahan.

Maksud: Alarm ini akan digunakan untuk membuat garis dasar untuk tingkat kesalahan 4xx tipikal sehingga Anda dapat melihat kelainan apa pun yang terjadi yang mungkin menjadi indikasi dari sebuah masalah penyiapan.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Ambang batas yang disarankan adalah untuk mendeteksi apakah lebih dari 5% dari total permintaan telah mendapatkan kesalahan 4XX. Kesalahan 4XX yang sering terjadi harus Anda waspadai. Namun demikian, jika Anda menetapkan nilai yang sangat rendah untuk ambang batas ini, hal itu akan dapat menyebabkan alarm menjadi terlalu sensitif. Anda juga dapat menyetel ambang batas ini agar sesuai dengan beban permintaan, dengan memperhitungkan tingkat kesalahan 4XX yang dapat diterima. Anda juga dapat menganalisis data historis untuk menemukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

5xxErrors

Dimensi:BucketName, FilterId

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi sejumlah besar kesalahan yang terjadi pada sisi server. Kesalahan ini menunjukkan bahwa ada klien yang sudah membuat permintaan dan tidak dapat diselesaikan oleh server. Hal ini dapat membantu Anda untuk mengkorelasikan masalah yang dihadapi aplikasi Anda karena S3. Untuk informasi selengkapnya guna membantu Anda menangani atau mengurangi kejadian kesalahan secara efisien, silakan lihat Mengoptimalkan pola desain performa. Kesalahan mungkin juga disebabkan oleh masalah yang terjadi pada S3, Anda perlu memeriksa dasbor kesehatan layanan AWS untuk mengetahui status Amazon S3 di Wilayah Anda.

Maksud: Alarm ini dapat membantu Anda dalam mendeteksi apakah aplikasi sedang mengalami masalah yang diakibatkan oleh kesalahan 5xx.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Kami menyarankan agar pengaturan ambang batas dilakukan untuk mendeteksi apakah lebih dari 5% dari total permintaan mendapatkan 5XXError, atau tidak. Namun demikian, Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan, dan sesuai dengan tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk mengetahui tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas sesuai dengan data historis itu.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

OperationsFailedReplication

Dimensi:SourceBucket, DestinationBucket, RuleId

Deskripsi alarm: Alarm ini akan membantu Anda dalam memahami terjadinya kegagalan replikasi. Metrik ini akan melacak status objek baru yang direplikasi dengan menggunakan S3 CRR atau S3 SRR, dan juga melacak objek yang ada yang direplikasi dengan menggunakan replikasi batch S3. Silakan lihat Pemecahan masalah replikasi untuk mendapatkan informasi selengkapnya.

Maksud: Alarm ini digunakan untuk mendeteksi apakah ada operasi replikasi yang mengalami kegagalan.

Statistik: Maksimum

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Metrik ini memancarkan nilai 0 untuk operasi yang berhasil dilakukan, dan tidak memancarkan apa-apa ketika tidak ada operasi replikasi yang dilakukan dalam satu menit. Ketika metrik memancarkan nilai yang lebih besar dari 0, artinya operasi replikasi yang dilakukan tidak berhasil.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

4xxErrors

Dimensi:AccessPointName, DataSource ARN

Deskripsi alarm: Alarm ini akan membantu kami melaporkan jumlah total kode status kesalahan 4xx yang dibuat sebagai respons atas permintaan klien. Mengaktifkan pencatatan log akses server S3 sementara waktu akan membantu Anda dalam menentukan dari mana asal masalah yang terjadi dengan menggunakan bidang status HTTP dan Kode Kesalahan.

Maksud: Alarm ini akan digunakan untuk membuat garis dasar untuk tingkat kesalahan 4xx tipikal sehingga Anda dapat melihat kelainan apa pun yang terjadi yang mungkin menjadi indikasi dari sebuah masalah penyiapan.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Kami menyarankan agar pengaturan ambang batas dilakukan untuk mendeteksi apakah lebih dari 5% dari total permintaan mendapatkan 4xxError, atau tidak. Kesalahan 4XX yang sering terjadi harus Anda waspadai. Namun demikian, jika Anda menetapkan nilai yang sangat rendah untuk ambang batas ini, hal itu akan dapat menyebabkan alarm menjadi terlalu sensitif. Anda juga dapat menyetel ambang batas ini agar sesuai dengan beban permintaan, dengan memperhitungkan tingkat kesalahan 4XX yang dapat diterima. Anda juga dapat menganalisis data historis untuk menemukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

5xxErrors

Dimensi:AccessPointName, DataSource ARN

Deskripsi alarm: Alarm ini akan membantu Anda mendeteksi sejumlah besar kesalahan yang terjadi pada sisi server. Kesalahan ini menunjukkan bahwa ada klien yang sudah membuat permintaan dan tidak dapat diselesaikan oleh server. Kesalahan-kesalahan ini mungkin juga disebabkan oleh masalah yang terjadi pada S3, jadi Anda perlu memeriksa dasbor kesehatan layanan AWS untuk mengetahui status Amazon S3 di Wilayah Anda. Hal ini dapat membantu Anda untuk mengkorelasikan masalah yang dihadapi aplikasi Anda karena S3. Untuk informasi selengkapnya guna membantu Anda menangani atau mengurangi kejadian-kejadian kesalahan ini secara efisien, silakan lihat Mengoptimalkan pola desain performa.

Maksud: Alarm ini dapat membantu Anda dalam mendeteksi apakah aplikasi sedang mengalami masalah yang diakibatkan oleh kesalahan 5xx.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Kami menyarankan agar pengaturan ambang batas dilakukan untuk mendeteksi apakah lebih dari 5% dari total permintaan mendapatkan kesalahan 5XX, atau tidak. Namun demikian, Anda dapat menyetel ambang batas tersebut agar sesuai dengan lalu lintas permintaan, dan sesuai dengan tingkat kesalahan yang dapat diterima. Anda juga dapat menganalisis data historis untuk mengetahui tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas sesuai dengan data historis itu.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

LambdaResponse4xx

Dimensi:AccessPointName, DataSource ARN

Deskripsi alarm: Alarm ini akan membantu Anda dalam mendeteksi dan melakukan diagnosis kegagalan (500s) dalam panggilan ke S3 Object Lambda. Kesalahan-kesalahan ini dapat disebabkan oleh terjadinya kesalahan atau salah konfigurasi dalam fungsi Lambda yang bertanggung jawab untuk memberikan respons atas permintaan Anda. Menyelidiki Aliran CloudWatch Log dari fungsi Lambda yang terkait dengan Object Lambda Access Point dapat membantu Anda menentukan asal masalah berdasarkan respons dari S3 Object Lambda.

Maksud: Alarm ini digunakan untuk mendeteksi kesalahan klien 4xx untuk WriteGetObjectResponse panggilan.

Statistik: Rata-rata

Ambang batas yang disarankan: 0,05

Pembenaran ambang batas: Kami menyarankan agar pengaturan ambang batas dilakukan untuk mendeteksi apakah lebih dari 5% dari total permintaan mendapatkan 4xxError, atau tidak. Kesalahan 4XX yang sering terjadi harus Anda waspadai. Namun demikian, jika Anda menetapkan nilai yang sangat rendah untuk ambang batas ini, hal itu akan dapat menyebabkan alarm menjadi terlalu sensitif. Anda juga dapat menyetel ambang batas ini agar sesuai dengan beban permintaan, dengan memperhitungkan tingkat kesalahan 4XX yang dapat diterima. Anda juga dapat menganalisis data historis untuk menemukan tingkat kesalahan yang dapat diterima untuk beban kerja aplikasi, dan kemudian Anda dapat menyetel ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_THRESHOLD

NumberOfMessagesPublished

Dimensi: TopicName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah jumlah pesan SNS yang diterbitkan terlalu rendah, atau tidak. Untuk pemecahan masalah, Anda perlu memeriksa penyebab yang mengakibatkan penerbit mengirim lalu lintas dalam jumlah lebih sedikit.

Maksud: Alarm ini akan membantu Anda secara proaktif memantau dan mendeteksi terjadinya penurunan yang signifikan dalam penerbitan notifikasi. Hal ini akan membantu Anda dalam mengidentifikasi masalah yang mungkin terjadi dengan aplikasi atau proses bisnis Anda, sehingga Anda dapat mengambil tindakan-tindakan yang tepat untuk mempertahankan aliran notifikasi yang Anda harapkan. Anda harus membuat alarm ini jika Anda memperkirakan bahwa sistem Anda akan melayani lalu lintas dengan jumlah minimum.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Jumlah pesan yang diterbitkan harus sesuai dengan perkiraan jumlah pesan yang dipublikasikan untuk aplikasi Anda. Anda juga dapat melakukan analisis data historis, tren, dan lalu lintas untuk menemukan ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

Dimensi: TopicName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah jumlah pesan SNS yang dikirim terlalu rendah, atau tidak. Hal ini bisa jadi karena terjadinya penghentian berlangganan titik akhir yang dilakukan secara tidak disengaja, atau karena ada peristiwa SNS yang menyebabkan pesan mengalami penundaan.

Maksud: Alarm ini akan membantu Anda mendeteksi penurunan volume pesan yang dikirimkan. Anda harus membuat alarm ini jika Anda memperkirakan bahwa sistem Anda akan melayani lalu lintas dengan jumlah minimum.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Jumlah pesan yang dikirim harus sejalan dengan perkiraan jumlah pesan yang dihasilkan dan jumlah konsumen. Anda juga dapat melakukan analisis data historis, tren, dan lalu lintas untuk menemukan ambang batas yang sesuai.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

Dimensi: TopicName

Deskripsi alarm: Alarm ini dapat mendeteksi apakah jumlah pesan SNS yang gagal sudah terlalu tinggi, atau tidak. Untuk memecahkan masalah pemberitahuan yang gagal, aktifkan pencatatan ke CloudWatch Log. Dengan melakukan pemeriksaan log, hal itu dapat membantu Anda menemukan pelanggan mana yang mengalami kegagalan, dan menemukan kode status yang mereka kembalikan.

Maksud: Alarm ini akan membantu Anda secara proaktif menemukan masalah yang terjadi dengan pengiriman notifikasi dan mengambil tindakan yang tepat untuk mengatasi masalah ini.

Statistik: Jumlah

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat bergantung pada dampak notifikasi yang mengalami kegagalan. Anda juga perlu meninjau SLA yang diberikan kepada pengguna akhir Anda, toleransi kesalahan dan kekritisan notifikasi dan analisis data historis, dan kemudian memilih ambang batas yang sesuai. Jumlah notifikasi yang mengalami kegagalan harus 0 untuk topik yang hanya memiliki langganan SQS, Lambda, atau Firehose.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

Dimensi: TopicName

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau dan menyelesaikan masalah-masalah yang mungkin terjadi terhadap penerbit atau pelanggan. Anda perlu memeriksa apakah penerbit menerbitkan pesan dengan atribut yang tidak valid atau apakah filter yang tidak pantas diterapkan ke pelanggan. Anda juga dapat menganalisis CloudWatch Log untuk membantu menemukan akar penyebab masalah.

Maksud: Alarm ini digunakan untuk mendeteksi apakah pesan yang dipublikasikan tidak valid atau apakah filter yang tidak pantas telah diterapkan ke pelanggan.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Atribut yang tidak valid, hampir selalu menjadi kesalahan yang diakibatkan oleh penerbit. Kami menyarankan Anda untuk menetapkan ambang batasnya dengan nilai 0 karena atribut yang tidak valid tidak diharapkan ada dalam sistem yang sehat.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

Dimensi: TopicName

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau dan menyelesaikan masalah-masalah yang mungkin terjadi terhadap penerbit atau pelanggan. Anda perlu memeriksa apakah penerbit menerbitkan sebuah pesan yang memiliki badan pesan yang tidak valid, atau apakah filter yang tidak pantas telah diterapkan ke pelanggan. Anda juga dapat menganalisis CloudWatch Log untuk membantu menemukan akar penyebab masalah.

Maksud: Alarm ini digunakan untuk mendeteksi apakah pesan yang dipublikasikan tidak valid atau apakah filter yang tidak pantas telah diterapkan ke pelanggan.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Badan pesan yang tidak valid biasanya merupakan kesalahan yang diakibatkan oleh penerbit. Kami menyarankan Anda untuk menetapkan ambang batasnya dengan nilai 0 karena badan pesan yang tidak valid tidak diharapkan ada dalam sistem yang sehat.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

Dimensi: TopicName

Deskripsi alarm: Alarm ini akan membantu Anda memantau jumlah pesan yang sudah dipindahkan ke antrean surat mati.

Maksud: Alarm ini digunakan untuk mendeteksi pesan-pesan yang sudah dipindahkan ke antrean surat mati. Kami menyarankan Anda agar Anda membuat alarm ini ketika SNS digabungkan dengan SQS, Lambda atau Firehose.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Dalam sebuah sistem yang sehat yang terdiri dari semua jenis pelanggan, pesan tidak boleh dipindahkan ke antrean surat mati. Kami menyarankan Anda agar Anda mendapatkan notifikasi jika ada pesan yang masuk ke dalam antrean, sehingga Anda dapat mengidentifikasi dan mengatasi akar penyebabnya, dan hal ini berpotensi mengarahkan ulang pesan-pesan yang ada dalam antrean surat mati untuk mencegah terjadinya kehilangan data.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

Dimensi: TopicName

Deskripsi alarm: Alarm ini akan membantu Anda dalam memantau pesan-pesan yang tidak dapat dipindahkan ke antrean surat mati. Anda perlu memeriksa apakah antrean surat mati Anda ada dan apakah hal itu sudah dikonfigurasi dengan benar. Selain itu, Anda juga perlu memverifikasi bahwa SNS memiliki izin untuk mengakses antrean surat mati. Silakan lihat dokumentasi antrean surat mati untuk mempelajari hal ini lebih lanjut.

Maksud: Alarm ini digunakan untuk mendeteksi pesan-pesan yang tidak dapat dipindahkan ke antrean surat mati.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Hampir selalu menjadi kesalahan jika pesan tidak dapat dipindahkan ke antrean surat mati. Disarankan untuk mengatur ambang batasnya dengan 0, yang berarti semua pesan yang mengalami kegagalan dalam prosesnya harus dapat mencapai antrean surat mati ketika antrean telah dikonfigurasi.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

SMS MonthToDateSpent USD

Dimensi: TopicName

Deskripsi alarm: Alarm ini akan membantu Anda memantau apakah Anda memiliki kuota yang cukup pada akun Anda sehingga SNS dapat mengirimkan pesan. Jika Anda sudah mencapai kuota Anda, maka SNS tidak akan dapat mengirimkan pesan SMS. Untuk informasi tentang pengaturan kuota belanja SMS bulanan Anda, atau untuk informasi tentang meminta peningkatan kuota belanja dengan AWS, lihat Menyetel preferensi pesan SMS.

Maksud: Alarm ini digunakan untuk mendeteksi apakah Anda memiliki kuota yang cukup yang ada di akun Anda agar pesan-pesan SMS Anda bisa dikirim dengan sukses.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda perlu menetapkan ambang batasnya sesuai dengan kuota (Batas pengeluaran akun) untuk akun. Anda harus memilih ambang batas yang memberi tahu Anda cukup awal apakah Anda telah mencapai batas kuota Anda sehingga Anda punya waktu untuk meminta dilakukan kenaikan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

SMS SuccessRate

Dimensi: TopicName

Deskripsi alarm: Alarm ini akan membantu Anda memantau tingkat kegagalan pengiriman pesan SMS. Anda dapat mengatur Cloudwatch Logs untuk memahami sifat yang ada pada kegagalan dan mengambil tindakan berdasarkan hal itu.

Maksud: Alarm ini digunakan untuk mendeteksi kejadian gagalnya pengiriman pesan SMS.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Anda perlu menetapkan ambang batas untuk alarm ini sesuai dengan toleransi Anda untuk pengiriman pesan SMS yang mengalami kegagalan.

Periode: 60

Titik data untuk alarm: 5

Periode evaluasi: 5

Operator Perbandingan: GREATER_THAN_THRESHOLD

ApproximateAgeOfOldestMessage

Dimensi: QueueName

Deskripsi alarm: Alarm ini mengawasi usia pesan tertua yang ada dalam antrean. Anda dapat menggunakan alarm ini untuk memantau apakah para pelanggan Anda memproses pesan SQS dengan kecepatan yang diinginkan. Anda juga perlu mempertimbangkan untuk meningkatkan jumlah konsumen atau throughput konsumen untuk mengurangi usia pesan. Metrik ini dapat digunakan dengan dikombinasikan dengan ApproximateNumberOfMessagesVisible untuk menentukan seberapa besar antrean backlog dan seberapa cepat pesan yang sedang diproses. Untuk mencegah pesan dihapus sebelum diproses, Anda perlu mempertimbangkan untuk mengonfigurasi antrean surat mati untuk mengesampingkan pesan pil racun yang mungkin terjadi.

Maksud: Alarm ini digunakan untuk mendeteksi apakah usia pesan tertua dalam QueueName antrian terlalu tinggi. Usia yang tinggi dapat menjadi indikasi bahwa pesan tidak diproses dengan cukup cepat atau bahwa ada beberapa pesan pil racun yang terjebak dalam antrean dan tidak dapat diproses.

Statistik: Maksimum

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat bergantung pada waktu pemrosesan pesan yang Anda harapkan. Anda dapat menggunakan data historis untuk menghitung waktu pemrosesan pesan rata-rata, dan kemudian menetapkan ambang batasnya menjadi 50% lebih tinggi dari waktu pemrosesan pesan SQS maksimum yang diharapkan oleh konsumen antrean.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

Dimensi: QueueName

Deskripsi alarm: Alarm ini akan membantu Anda mendeteksi sejumlah besar pesan yang sedang berjalan sehubungan dengan QueueName. Untuk pemecahan masalah, Anda perlu memeriksa penurunan backlog pesan.

Maksud: Alarm ini digunakan untuk mendeteksi sejumlah besar pesan sedang berjalan yang ada dalam antrean. Jika konsumen tidak menghapus pesan-pesan yang ada dalam periode batas waktu visibilitas, ketika antrean disurvei, pesan-pesan tersebut akan muncul kembali dalam antrean. Untuk antrean FIFO, bisa ada maksimal 20.000 pesan sedang berjalan. Jika Anda mencapai kuota ini, maka SQS tidak akan mengembalikan pesan kesalahan. Antrean FIFO memeriksa 20k pesan pertama untuk menentukan grup pesan yang tersedia. Hal ini artinya bahwa jika Anda memiliki backlog pesan dalam satu grup pesan, maka Anda tidak akan dapat menggunakan pesan-pesan dari grup pesan lain yang dikirim ke antrean di lain waktu hingga Anda berhasil mengkonsumsi pesan-pesan dari backlog tersebut.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Nilai ambang batas yang disarankan untuk alarm ini sangat tergantung pada perkiraan jumlah pesan sedang berjalan. Anda dapat menggunakan data historis untuk menghitung perkiraan jumlah pesan maksimum sedang berjalan dan menetapkan ambang batasnya menjadi 50% di atas nilai ini. Jika konsumen antrean sedang memproses tetapi tidak menghapus pesan-pesan dari antrean tersebut, maka jumlah ini akan meningkat secara tiba-tiba.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

Dimensi: QueueName

Deskripsi alarm: Alarm ini akan mengawasi backlog antrean pesan yang menjadi lebih besar dari yang diharapkan, yang mana hal ini menunjukkan bahwa konsumen terlalu lambat atau jumlah konsumen tidak memadai. Anda perlu mempertimbangkan untuk menaikkan jumlah konsumen atau mempercepat konsumen Anda, jika alarm ini beralih statusnya menjadi ALARM.

Maksud: Alarm ini digunakan untuk mendeteksi apakah jumlah pesan dari antrean aktif terlalu tinggi dan apakah konsumen memproses pesan dengan lambat atau tidak tersedia jumlah konsumen yang memadai untuk memproses pesan-pesan tersebut.

Statistik: Rata-rata

Ambang batas yang disarankan: Tergantung pada situasi Anda

Pembenaran ambang batas: Jumlah pesan yang terlihat sangat tinggi menunjukkan bahwa pesan-pesan tersebut tidak diproses oleh konsumen dengan kecepatan yang diharapkan. Anda juga perlu mempertimbangkan data historis saat Anda menetapkan ambang batas ini.

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

Dimensi: QueueName

Deskripsi alarm: Alarm ini akan membantu Anda mendeteksi apakah tidak ada pesan yang dikirim dari produsen sehubungan dengan QueueName. Untuk pemecahan masalah, Anda perlu memeriksa alasan yang menyebabkan produsen tersebut tidak mengirim pesan.

Maksud: Alarm ini digunakan untuk mendeteksi ketika produsen berhenti mengirim pesan.

Statistik: Jumlah

Ambang batas yang disarankan: 0,0

Pembenaran ambang batas: Jika jumlah pesan yang dikirim adalah 0, artinya produsen tidak mengirim pesan apa pun. Jika antrian ini memiliki TPS rendah, tambah jumlahnya. EvaluationPeriods

Periode: 60

Titik data untuk alarm: 15

Periode evaluasi: 15

Operator Perbandingan: LESS_THAN_OR_EQUAL_TO_THRESHOLD

TunnelState

Dimensi: VpnId

Deskripsi alarm: Alarm ini akan membantu Anda memahami apakah satu atau beberapa terowongan sedang berada dalam status DOWN. Untuk memecahkan masalah ini, silakan lihat Pemecahan masalah terowongan VPN.

Maksud: Alarm ini digunakan untuk mendeteksi jika setidaknya ada satu terowongan yang statusnya beralih menjadi DOWN untuk VPN ini, sehingga Anda dapat memecahkan masalah yang dialami oleh VPN yang terkena dampaknya. Alarm ini akan selalu berada dalam status ALARM untuk jaringan yang dikonfigurasi untuk memiliki hanya satu terowongan.

Statistik: Minimum

Ambang batas yang disarankan: 1,0

Pembenaran ambang batas: Nilai ambang batas yang kurang dari 1 menunjukkan bahwa setidaknya ada satu terowongan yang statusnya DOWN.

Periode: 300

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: LESS_THAN_THRESHOLD

TunnelState

Dimensi: TunnelIpAddress

Deskripsi alarm: Alarm ini akan membantu Anda mengetahui jika terowongan ini berada dalam status DOWN. Untuk memecahkan masalah ini, silakan lihat Pemecahan masalah terowongan VPN.

Maksud: Alarm ini digunakan untuk mendeteksi apakah terowongan dalam status DOWN atau tidak, sehingga Anda dapat menyelesaikan masalah-masalah yang dialami VPN yang terkena dampaknya. Alarm ini akan selalu berada dalam status ALARM untuk jaringan yang dikonfigurasi untuk memiliki hanya satu terowongan.

Statistik: Minimum

Ambang batas yang disarankan: 1,0

Pembenaran ambang batas: Nilai ambang batas yang kurang dari 1 menunjukkan bahwa terowongan sedang berada dalam status DOWN.

Periode: 300

Titik data untuk alarm: 3

Periode evaluasi: 3

Operator Perbandingan: LESS_THAN_THRESHOLD

Alarm-alarm yang direkomendasikan

Topik

Amazon API Gateway

Amazon EC2 Auto Scaling

Amazon CloudFront

Amazon Cognito

Amazon DynamoDB

Amazon EBS

Amazon EC2

Amazon ElastiCache

Amazon EC2 (`AWS/ElasticGPUs`)

Amazon ECS

Amazon ECS dengan Wawasan Kontainer

Amazon EFS

Amazon EKS dengan Wawasan Kontainer

Amazon Kinesis Data Streams

Lambda

Wawasan Lambda

Amazon VPC (`AWS/NATGateway`)

AWS Tautan Pribadi (`AWS/PrivateLinkEndpoints`)

AWS Tautan Pribadi (`AWS/PrivateLinkServices`)

`Amazon RDS`

`Amazon Route 53 Public Data Plane`

`Amazon S3`

`S3ObjectLambda`

Amazon SNS

Amazon SQS

AWS VPN

Alarm-alarm yang direkomendasikan

Topik

Amazon API Gateway

Amazon EC2 Auto Scaling

Amazon CloudFront

Amazon Cognito

Amazon DynamoDB

Amazon EBS

Amazon EC2

Amazon ElastiCache

Amazon EC2 (AWS/ElasticGPUs)

Amazon ECS

Amazon ECS dengan Wawasan Kontainer

Amazon EFS

Amazon EKS dengan Wawasan Kontainer

Amazon Kinesis Data Streams

Lambda

Wawasan Lambda

Amazon VPC (AWS/NATGateway)

AWS Tautan Pribadi (AWS/PrivateLinkEndpoints)

AWS Tautan Pribadi (AWS/PrivateLinkServices)

Amazon RDS

Amazon Route 53 Public Data Plane

Amazon S3

S3ObjectLambda

Amazon SNS

Amazon SQS

AWS VPN

Amazon EC2 (`AWS/ElasticGPUs`)

Amazon VPC (`AWS/NATGateway`)

AWS Tautan Pribadi (`AWS/PrivateLinkEndpoints`)

AWS Tautan Pribadi (`AWS/PrivateLinkServices`)

`Amazon RDS`

`Amazon Route 53 Public Data Plane`

`Amazon S3`

`S3ObjectLambda`