View a markdown version of this page

Batas - Amazon CloudWatch
Ku CloudWatch ota umumBatas yang berlaku untuk alarm berdasarkan ekspresi matematika metrikBatas yang berlaku untuk alarm berdasarkan kueri Metrics InsightsBatas yang berlaku untuk Alarm LogBatas yang berlaku untuk alarm berdasarkan kueri PromQLBatasan yang berlaku untuk alarm berdasarkan sumber data yang terhubung

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Batas

Ku CloudWatch ota umum

Untuk informasi tentang kuota CloudWatch layanan umum yang berlaku untuk alarm, lihatCloudWatch kuota layanan.

Batas yang berlaku untuk alarm berdasarkan ekspresi matematika metrik

Alarm berdasarkan ekspresi matematika metrik dapat mereferensikan maksimal 10 metrik. Ini adalah batas keras yang tidak dapat ditingkatkan. Jika Anda perlu memantau lebih dari 10 metrik dalam satu alarm, pertimbangkan salah satu pendekatan berikut:

  • Jika metrik berada di namespace yang sama, gunakan kueri Insights Metrics di alarm Anda alih-alih ekspresi matematika metrik. Metrik Wawasan dapat digabungkan di banyak metrik dengan satu kueri.

  • Pre-aggregate metrik menjadi metrik khusus menggunakan fungsi Lambda, lalu mereferensikan metrik agregat dalam ekspresi alarm Anda.

  • Pisahkan logika Anda di beberapa alarm dan gabungkan mereka menggunakan alarm komposit.

Batas yang berlaku untuk alarm berdasarkan kueri Metrics Insights

Saat bekerja dengan alarm CloudWatch Metrics Insights, perhatikan batas fungsional berikut:

  • Default 200 alarm menggunakan kueri Metrics Insights per akun per Wilayah

  • Hanya data 3 jam terakhir yang dapat digunakan untuk mengevaluasi kondisi alarm. Namun, Anda dapat memvisualisasikan hingga dua minggu data pada grafik halaman detail alarm

  • Alarm yang mengevaluasi beberapa deret waktu akan membatasi jumlah kontributor di ALARM hingga 100

    • Dengan asumsi kueri mengambil 150 deret waktu:

      • Jika ada kurang dari 100 kontributor di ALARM (misalnya 95), StateReason akan menjadi “95 dari 150 deret waktu yang dievaluasi ke ALARM”

      • Jika ada lebih dari 100 kontributor di ALARM (misalnya 105), StateReason akan menjadi “100+ deret waktu dievaluasi ke ALARM”

    • Selanjutnya, jika volume atribut terlalu besar, jumlah kontributor di ALARM dapat dibatasi hingga kurang dari 100.

  • Batasan Metrik Wawasan pada jumlah maksimum deret waktu yang dianalisis atau dikembalikan berlaku

  • Selama evaluasi alarm, EvaluationState akan diatur PARTIAL_DATA untuk batas berikut:

    • Jika kueri Metrics Insights mengembalikan lebih dari 500 deret waktu.

    • Jika kueri Metrics Insights cocok dengan lebih dari 10.000 metrik.

Untuk informasi selengkapnya tentang CloudWatch kuota dan batasan layanan, lihat Kuota layanan CloudWatch Metrics Insights.

Batas yang berlaku untuk Alarm Log

Saat bekerja dengan CloudWatch Log Alarm, perhatikan batasan berikut:

Sumber daya Kuota Dapat Disesuaikan
PutLogAlarm permintaan per detik 3 (ledakan: 5) Tidak
Alarm Log Maksimum per akun ~1000 (dibatasi oleh kuota Kueri Terjadwal AWS yang dikelola CloudWatch Logs) Tidak
Kontributor maksimum per eksekusi kueri 500 Tidak
Kontributor maksimum yang dilacak di ALARM 100 Tidak
Bidang maksimum dalam klausa BY 5 Tidak
Baris log maksimum dalam notifikasi email SNS 50 (juga dibatasi oleh batas muatan notifikasi SNS 256 KB) Tidak

  • Alarm yang mengevaluasi beberapa kontributor membatasi jumlah kontributor di ALARM menjadi 100.

    • Jika ada kurang dari 100 kontributor di ALARM (misalnya 95), itu StateReason adalah “95 dari 100 kontributor yang dievaluasi ke ALARM.”

    • Jika ada lebih dari 100 kontributor di ALARM (misalnya 105), itu StateReason adalah “100+ kontributor yang dievaluasi ke ALARM.”

    • Jika volume atribut terlalu besar, jumlah kontributor di ALARM dapat dibatasi hingga kurang dari 100.

  • Selama evaluasi alarm, EvaluationState diatur ke PARTIAL_DATA jika kueri mengembalikan lebih dari 500 grup kontributor.

  • Total baris log yang disertakan dalam notifikasi dibatasi oleh jumlah yang diminta, hasil total yang tersedia, dan batas ukuran muatan SNS. Jika baris log melebihi batas muatan, lebih sedikit baris yang disertakan.

Batas yang berlaku untuk alarm berdasarkan kueri PromQL

Saat bekerja dengan CloudWatch alarm yang menggunakan query Prometheus Query Language (PromQL), perhatikan batasan fungsional ini:

  • Akun Anda dapat memiliki hingga 500 alarm PromQL di setiap Wilayah secara default.

  • Alarm yang mengevaluasi beberapa deret waktu akan membatasi jumlah kontributor di ALARM menjadi 100.

    • Jika ada kurang dari 100 kontributor di ALARM (misalnya 95), StateReason akan menjadi “95 deret waktu dievaluasi ke ALARM”

    • Jika ada lebih dari 100 kontributor di ALARM (misalnya 105), StateReason akan menjadi “100+ deret waktu dievaluasi ke ALARM”

    • Selanjutnya, jika volume atribut terlalu besar, jumlah kontributor di ALARM dapat dibatasi hingga kurang dari 100.

  • Batas kueri PromQL berlaku untuk jumlah maksimum deret waktu yang dianalisis atau dikembalikan.

  • Selama evaluasi alarm, EvaluationState akan diatur ke PARTIAL_DATA jika kueri PromQL mengembalikan lebih dari 500 deret waktu.

Batasan yang berlaku untuk alarm berdasarkan sumber data yang terhubung

  • Ketika CloudWatch mengevaluasi alarm, ia melakukannya setiap menit, bahkan jika periode alarm lebih lama dari satu menit. Agar alarm berfungsi, fungsi Lambda harus dapat mengembalikan daftar stempel waktu yang dimulai setiap menit, tidak hanya pada kelipatan panjang periode. Stempel waktu ini harus diberi jarak satu periode.

    Oleh karena itu, jika sumber data yang dikueri oleh Lambda hanya dapat mengembalikan stempel waktu yang merupakan kelipatan dari panjang periode, maka fungsi tersebut harus "mengambil sampel ulang" data yang diambil agar sesuai dengan stempel waktu yang diharapkan oleh permintaan GetMetricData.

    Sebagai contoh, sebuah alarm dengan periode lima menit akan dievaluasi setiap menit dengan menggunakan jendela lima menit yang bergeser satu menit setiap kali. Dalam kasus ini:

    • Untuk evaluasi alarm pada 12:15:00, CloudWatch mengharapkan titik data dengan cap waktu,, dan. 12:00:00 12:05:00 12:10:00

    • Kemudian untuk evaluasi alarm pada 12:16:00, CloudWatch mengharapkan titik data dengan stempel waktu,, dan. 12:01:00 12:06:00 12:11:00

  • Saat CloudWatch mengevaluasi alarm, setiap titik data yang dikembalikan oleh fungsi Lambda yang tidak selaras dengan cap waktu yang diharapkan akan dijatuhkan, dan alarm dievaluasi menggunakan titik data yang diharapkan yang tersisa. Sebagai contoh, ketika alarm dievaluasi pada 12:15:00, itu akan mengharapkan data dengan stempel waktu 12:00:00, 12:05:00, dan 12:10:00. Jika menerima data dengan cap waktu,12:00:00,12:05:00, dan 12:06:0012:10:00, data dari 12:06:00 dihapus dan CloudWatch mengevaluasi alarm menggunakan stempel waktu lainnya.

    Kemudian untuk evaluasi berikutnya pada 12:16:00, ia akan mengharapkan data dengan stempel waktu 12:01:00, 12:06:00, dan 12:11:00. Jika ia hanya memiliki data dengan stempel waktu 12:00:00, 12:05:00, dan 12:10:00, maka semua titik data ini akan diabaikan pada 12:16:00 dan alarm akan beralih status sesuai dengan pengaturan yang Anda tetapkan untuk alarm ketika menangani data yang hilang. Untuk informasi selengkapnya, lihat Evaluasi alarm.

  • Kami menyarankan Anda untuk membuat alarm ini agar melakukan tindakan saat beralih statusnya menjadi INSUFFICIENT_DATA, karena beberapa kasus penggunaan fungsi Lambda yang gagal akan mengubah status alarm menjadi INSUFFICIENT_DATA terlepas dari pengaturan yang Anda tentukan untuk alarm ketika menangani data yang hilang.

  • Jika fungsi Lambda mengembalikan kesalahan:

    • Jika ada permasalahan izin ketika memanggil fungsi Lambda, alarm akan mulai memiliki transisi data yang hilang sesuai dengan pengaturan yang Anda tentukan untuk alarm ketika menangani data yang hilang saat Anda membuatnya.

    • Kesalahan-kesalahan lain yang berasal dari fungsi Lambda akan menyebabkan alarm beralih statusnya menjadi INSUFFICIENT_DATA.

  • Jika metrik yang diminta oleh fungsi Lambda mengalami beberapa penundaan sehingga titik data terakhir selalu hilang, maka Anda harus menggunakan sebuah solusi untuk menyelesaikannya. Anda dapat membuat sebuah alarm M dari N atau dapat menaikkan periode evaluasi alarm. Untuk informasi selengkapnya tentang alarm M dari N, silakan lihat Evaluasi alarm.