Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# CloudWatch Alarm yang disarankan untuk cluster yang disediakan Amazon MSK
Pantau cluster Amazon MSK Provisioned Anda untuk mendeteksi masalah sebelum memengaruhi aplikasi Anda. CloudWatch alarm melakukan tindakan ketika CloudWatch metrik melebihi nilai yang ditentukan untuk beberapa waktu. Misalnya, Anda mungkin ingin mendapatkan pemberitahuan email jika jumlah partisi melebihi nilai yang disarankan untuk ukuran instans broker Anda selama lebih dari 15 menit. Alarm kritis dalam tabel berikut direkomendasikan, tetapi mereka bukan daftar lengkap alarm yang dapat Anda buat untuk memantau cluster Anda.
Untuk informasi selengkapnya tentang mengonfigurasi alarm, lihat [ Membuat CloudWatch alarm * Amazon *](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) di Panduan CloudWatch Pengguna Amazon.
Tabel berikut mencantumkan alarm yang berlaku untuk broker Standar dan Ekspres.
| Alarm | Isu |
| --- | --- |
| `CPUUser`\+ Rat `CPUSystem` a-rata >= 60 selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker memiliki CPUuser\+CPUsystem rata-rata di atas 60% yang direkomendasikan. Untuk mempelajari selengkapnya, lihat [Memantau penggunaan CPU](bestpractices.md#bestpractices-monitor-cpu). |
| `PartitionCount`Rata-rata >= * X * selama 5 menit, 3 kali berturut-turut (*X * = Jumlah partisi yang disarankan untuk ukuran instance broker)
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker memiliki partisi yang lebih tinggi dari batas jumlah partisi yang disarankan. Untuk mempelajari selengkapnya, lihat [Right-size cluster Anda: Jumlah partisi per broker Standar](bestpractices.md#partitions-per-broker) dan [Kuota partisi broker ekspres](limits.md#msk-express-broker-partition-quota). |
| `SumOffsetLag`Rata-rata >= * X * selama 5 menit, 3 kali berturut-turut (*X * ditetapkan untuk kelompok konsumen dan kombinasi topik berdasarkan kasus penggunaan)
Dimensi:`Cluster Name`,`Consumer Group`, `Topic` | Jeda offset agregat untuk semua partisi dalam suatu topik lebih dari * X*. Untuk informasi selengkapnya tentang lag, Anda dapat menggunakan `Offset` metrik tingkat partisi, yang mewakili lag untuk setiap partisi, atau menggunakan alat baris perintah Kafka untuk menggambarkan grup konsumen. Tinjau kecepatan pemrosesan aplikasi konsumen Anda relatif terhadap produsen untuk memahami apakah konsumen tidak dapat mengikuti, dan periksa apakah ada keseimbangan konsumen yang memperlambat konsumen. |
Tabel berikut mencantumkan alarm yang hanya berlaku untuk broker Standar.
| Alarm | Isu |
| --- | --- |
| `OfflinePartitionsCount`Rata-rata >= 1 selama 1 menit, 3 kali berturut-turut
Dimensi: `Cluster Name` | Satu atau lebih partisi topik tidak tersedia. Ketika partisi tidak tersedia, operasi produksi dan konsumsi ke partisi tersebut gagal. Partisi offline seharusnya tidak terjadi pada cluster yang seimbang, berukuran benar, dan dikonfigurasi dengan benar. Untuk mempelajari selengkapnya, lihat [Bangun cluster yang sangat tersedia](bestpractices.md#ensure-high-availability). |
| `UnderMinIsrPartitionCount`Rata-rata >= 1 selama 1 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih topik memiliki partisi di bawah set replika in-sync yang dikonfigurasi minimum (ISR). Ketika partisi jatuh di bawah ISR minimum, operasi produksi gagal (dengan produsen`acks=all`). Untuk mempelajari selengkapnya, lihat [Bangun cluster yang sangat tersedia](bestpractices.md#ensure-high-availability). |
| `KafkaDataLogsDiskUsed`Rata-rata > = 80 selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker memiliki penggunaan disk data 80% atau lebih. Untuk mempelajari selengkapnya, lihat [Memantau ruang disk](bestpractices.md#bestpractices-monitor-disk-space). |
| `HeapMemoryAfterGC`Rata-rata >= 60 selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker memiliki 60% atau lebih dari total memori tumpukan yang digunakan setelah pengumpulan sampah. Untuk mempelajari selengkapnya, lihat [Memantau memori Apache Kafka](bestpractices.md#bestpractices-monitor-memory). |
| (Sum (`VolumeReadBytes`) \+ Sum (`VolumeWriteBytes`))/(5 \* 60 \* 1024 \* 1024) >= * X * MiB selama 5 menit, 3 kali berturut-turut (*X * = 80% dari throughput volume yang tersedia)
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker memiliki aktivitas baca dan tulis volume yang mendasari menggunakan hingga 80% dari throughput volume yang tersedia. Untuk mempelajari selengkapnya, lihat Th [ roughput penyimpanan yang disediakan. ](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provision-throughput-management.html) |
| `CPUCreditBalance`Rata-rata <= 100 selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Ini hanya relevan dengan jenis broker t3.small. Satu atau lebih broker telah menghabiskan saldo kredit CPU mereka dari maksimum 576 menjadi kurang dari 100. Ketika saldo mencapai 0, broker tidak dapat melebihi baseline CPU 20%. Untuk menghindari penipisan kredit CPU, tingkatkan dari tipe instans broker t3 ke tipe instans m7g, yang tidak menggunakan kredit CPU. |
| `RequestHandlerAvgIdlePercent`Rata-rata <= 0,3 selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker melihat kemacetan aktivitas di threadpool yang bertanggung jawab untuk melayani permintaan (threadpool kurang dari 30% idle). Saturasi di sini menunjukkan permintaan lambat, yang dapat menyebabkan batas waktu sisi klien. Juga, tinjau apakah klien Anda menghasilkan permintaan yang berlebihan. Misalnya, klien yang tidak sah mungkin secara agresif mencoba kembali permintaan yang ditolak oleh broker. Untuk mempelajari selengkapnya tentang mengoptimalkan throughput cluster, lihat[Mengoptimalkan throughput cluster untuk m5.4xl, m7g.4xl, atau instans yang lebih besar](bestpractices.md#optimize-broker-threads). |
| `NetworkProcessorAvgIdlePercent`Rata-rata <= 0,3 selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker melihat kemacetan aktivitas pada threadpool koneksi jaringan (threadpool kurang dari 30% idle). Saturasi di sini dapat menyebabkan batas waktu. Juga, tinjau apakah klien Anda menghasilkan permintaan yang berlebihan. Misalnya, klien yang tidak sah mungkin secara agresif mencoba kembali permintaan yang ditolak oleh broker. Untuk mempelajari selengkapnya tentang mengoptimalkan throughput cluster, lihat[Mengoptimalkan throughput cluster untuk m5.4xl, m7g.4xl, atau instans yang lebih besar](bestpractices.md#optimize-broker-threads). |
| `KafkaFileDescriptorsUsagePercent`> 80% selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Persentase deskriptor file yang digunakan pada broker. Pada 100% kelelahan, broker Kafka mungkin tidak dapat memulai. Jumlah deskriptor file meningkat dengan jumlah partisi, jumlah segmen log di setiap partisi, dan jumlah koneksi klien. Tinjau apakah Anda memiliki topik dengan `segment.ms` nilai rendah yang mengakibatkan penggulingan log yang sering terjadi, dan pertimbangkan untuk mengurangi jumlah koneksi klien. |
| `KafkaMemoryMappedFilesUsagePercent`> 80% selama 5 menit, 3 kali berturut-turut
Dimensions: `Cluster Name`, `Broker ID` | Persentase file yang dipetakan memori yang digunakan pada broker. Pada 100% kelelahan, broker Kafka mungkin tidak dapat memulai. Jumlah penggunaan file yang dipetakan memori meningkat dengan jumlah partisi dan jumlah segmen log di setiap partisi. Tinjau apakah Anda memiliki topik dengan `segment.ms` nilai rendah yang mengakibatkan penggulungan log yang sering terjadi. |
## Alarm kontrol akses IAM
Selain alarm sebelumnya, sebaiknya buat alarm untuk metrik berikut khusus untuk kontrol akses IAM. Alarm ini berlaku untuk broker Standar dan Ekspres dengan otentikasi IAM diaktifkan. Amazon MSK menempatkan batasan logis pada koneksi IAM untuk melindungi broker dari permintaan koneksi IAM yang berlebihan. Melanggar batasan ini menyebabkan batas waktu koneksi klien, yang akan berdampak pada beban kerja Anda.
| Alarm | Isu |
| --- | --- |
| `ClientConnectionCount`Jumlahkan >= * X * selama 1 menit, 3 kali berturut-turut (*X * = 80% dari koneksi TCP maksimum per broker)
Dimensi:`Cluster Name`,`Broker ID`, `Client Authentication` | Satu atau lebih broker memiliki jumlah koneksi sama dengan 80% dari batas koneksi. Koneksi TCP maksimum default per broker untuk kontrol akses IAM adalah 3000. Nilai ini dapat diubah. Untuk informasi lebih lanjut, lihat [Kuota broker Amazon MSK Express](limits.md#msk-express-quota) untuk broker Express dan [Kuota broker Amazon MSK Standard](limits.md#msk-provisioned-quota) untuk broker Standar. |
| `ConnectionCreationRate`Jumlahkan >= * X * selama 1 menit, 3 kali berturut-turut (*X * = 80% dari batas kecepatan pembuatan koneksi untuk ukuran instans Anda)
Dimensions: `Cluster Name`, `Broker ID` | Satu atau lebih broker memiliki klien yang membuat koneksi IAM pada tingkat yang sama dengan 80% dari batas tingkat pembuatan koneksi. Tingkat koneksi TCP maksimum per broker untuk kontrol akses IAM tergantung pada ukuran instans. Untuk informasi lebih lanjut, lihat [Kuota broker Amazon MSK Express](limits.md#msk-express-quota) untuk broker Express dan [Kuota broker Amazon MSK Standard](limits.md#msk-provisioned-quota) untuk broker Standar. |