Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Tentukan dan konfigurasikan alarm di Deteksi dan Respons Insiden
AWS bekerja dengan Anda untuk menentukan metrik dan alarm untuk memberikan visibilitas ke kinerja aplikasi Anda dan infrastruktur dasarnya. AWS Kami meminta agar alarm mematuhi kriteria berikut saat mendefinisikan dan mengonfigurasi ambang batas:
+ Alarm hanya memasuki status “Alarm” ketika ada dampak kritis terhadap beban kerja yang dipantau (hilangnya pendapatan atau pengalaman pelanggan yang menurun yang secara signifikan mengurangi kinerja) yang memerlukan perhatian operator segera.
+ Alarm juga harus melibatkan resolver yang Anda tentukan untuk beban kerja pada saat yang sama, atau sebelum, melibatkan tim manajemen insiden. Insinyur manajemen insiden harus berkolaborasi dengan resolver yang Anda tentukan dalam proses mitigasi, bukan berfungsi sebagai responden lini pertama dan kemudian meningkat kepada Anda.
+ Ambang batas alarm harus diatur ke ambang batas dan durasi yang sesuai sehingga setiap kali alarm menyala, penyelidikan harus dilakukan. Jika alarm berkedip di antara status “Alarm” dan “OK”, dampak yang cukup akan terjadi untuk menjamin respons dan perhatian operator.
**Jenis alarm**:
+ Alarm yang menggambarkan tingkat dampak bisnis dan menyampaikan informasi yang relevan untuk deteksi kesalahan sederhana.
+ Burung CloudWatch kenari Amazon. [Untuk informasi lebih lanjut, lihat [Canary dan X-Ray tracing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html), dan X-Ray.](https://aws.amazon.com/xray/)
+ Agregat mengkhawatirkan (pemantauan dependensi)
Tabel berikut memberikan contoh alarm, semua menggunakan sistem CloudWatch pemantauan.
****
| Nama metrik/Ambang alarm | Alarm ARN atau ID sumber daya | Jika alarm ini menyala | Jika terlibat, potong Kasus Dukungan Premium untuk layanan ini |
| --- | --- | --- | --- |
| Kesalahan API/ \$1 kesalahan >= 10 untuk 10 titik data | arn:aws:cloudwatch: us-west- 2:0000000000: Alarm: E2 Lambda-Errors MPmim | Pemotongan tiket ke tim administrator basis data (DBA) | Lambda, API Gateway |
| ServiceUnavailable (Kode status Http 503) \$1 kesalahan >=3 untuk 10 titik data (klien berbeda) dalam jendela 5 menit | arn:aws:cloudwatch: us-west-2:xxxxx:alarm: httperrorcode503 | Pemotongan tiket ke tim Layanan | Lambda, API Gateway |
| ThrottlingException (Kode status Http 400) \$1 kesalahan >=3 untuk 10 titik data (klien berbeda) dalam jendela 5 menit | arn:aws:cloudwatch: us-west-2:xxxxx:alarm: httperrorcode400 | Pemotongan tiket ke tim Layanan | EC2, Amazon Aurora |
Untuk detail selengkapnya, lihat [Deteksi Insiden AWS dan pemantauan dan observabilitas Respons](observe-idr.md).
Jika Anda lebih suka menggunakan alat otomatisasi untuk mengaktifkan alarm, Incident Detection and Response Command Line Interface (CLI) membantu Anda menyebarkan dan mengaktifkan alarm Anda. Untuk detail selengkapnya, lihat [CLI Deteksi dan Respons Insiden AWS](idr-cli.md).
**Output kunci:**
+ Definisi dan konfigurasi alarm pada beban kerja Anda.
+ Penyelesaian detail alarm pada kuesioner orientasi.
**Topics**
+ [Buat CloudWatch alarm](idr-alarms-fit-purpose.md)
+ [Membangun CloudWatch alarm dengan template CloudFormation](idr-create-alarms-with-cfn.md)
+ [Contoh kasus penggunaan untuk CloudWatch alarm](idr-ex-alarm-use-cases.md)
# Buat CloudWatch alarm yang sesuai dengan kebutuhan bisnis Anda di Deteksi dan Respons Insiden
Saat Anda membuat CloudWatch alarm Amazon, ada beberapa langkah yang dapat Anda ambil untuk memastikan alarm Anda paling sesuai dengan kebutuhan bisnis Anda.
**catatan**
Untuk contoh CloudWatch alarm yang direkomendasikan untuk terhubung Layanan AWS ke Deteksi dan Respons Insiden, lihat [Praktik Terbaik Deteksi Insiden dan Alarm Respons](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr) di. AWS re:Post
## Tinjau CloudWatch alarm yang Anda usulkan
Tinjau alarm yang Anda usulkan untuk memastikan bahwa alarm hanya memasuki status “Alarm” ketika ada dampak penting terhadap beban kerja yang dipantau (hilangnya pendapatan atau pengalaman pelanggan yang menurun yang secara signifikan mengurangi kinerja). Misalnya, apakah Anda menganggap alarm ini cukup kritis sehingga Anda harus segera bereaksi jika masuk ke status “Alarm”?
Berikut ini adalah metrik yang disarankan yang mungkin mewakili dampak bisnis yang penting, seperti memengaruhi pengalaman pengguna akhir Anda dengan aplikasi:
+ **CloudFront:** Untuk informasi selengkapnya, lihat [Melihat CloudFront dan metrik fungsi tepi](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html).
+ **Application Load Balancers:** Ini adalah praktik terbaik bahwa Anda membuat alarm berikut untuk Application Load Balancers, jika memungkinkan:
+ HTTPCode\$1ELB\$15xx\$1Hitung
+ HTTPCode\$1Target\$15XX\$1Count
Alarm sebelumnya memungkinkan Anda memantau respons dari target yang berada di belakang Application Load Balancer, atau di belakang sumber daya lainnya. Ini membuatnya lebih mudah untuk mengidentifikasi sumber kesalahan 5XX. Untuk informasi selengkapnya, lihat [CloudWatch metrik untuk Application Load Balancer Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ **Amazon API Gateway:** Jika Anda menggunakan WebSocket API di Elastic Beanstalk, pertimbangkan untuk menggunakan metrik berikut:
+ Tingkat kesalahan integrasi (disaring ke kesalahan 5XX)
+ Latensi integrasi
+ Kesalahan eksekusi
Untuk informasi selengkapnya, lihat [Memantau eksekusi WebSocket API dengan CloudWatch metrik](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html).
+ **Amazon Route 53:** Pantau **EndPointUnhealthyENICount**metrik. Metrik ini adalah jumlah antarmuka jaringan elastis dalam status **Pemulihan otomatis**. Status ini menunjukkan upaya resolver untuk memulihkan satu atau beberapa antarmuka jaringan Amazon Virtual Private Cloud yang terkait dengan titik akhir (ditentukan oleh). **EndpointId** Dalam proses pemulihan, titik akhir berfungsi dengan kapasitas terbatas. Titik akhir tidak dapat memproses kueri DNS sampai sepenuhnya pulih. Untuk informasi selengkapnya, lihat [Memantau titik akhir Amazon Route 53 Resolver dengan](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html) Amazon. CloudWatch
## Validasi konfigurasi alarm Anda
Setelah Anda mengonfirmasi bahwa alarm yang Anda usulkan sesuai dengan kebutuhan bisnis Anda, validasi konfigurasi dan riwayat alarm:
+ Validasi **Ambang** untuk metrik untuk memasukkan status “Alarm” terhadap tren grafik metrik.
+ Validasi **Periode** yang digunakan untuk titik data polling. Titik data polling pada 60 detik membantu dalam deteksi insiden dini.
+ Validasi **DatapointToAlarm**konfigurasi. Dalam kebanyakan kasus, ini adalah praktik terbaik untuk mengatur ini menjadi 3 dari 3 atau 5 dari 5. Dalam sebuah insiden, alarm terpicu setelah 3 menit ketika disetel sebagai [metrik 60 detik dengan 3 dari 3 DatapointToAlarm] atau 5 menit ketika disetel sebagai [metrik 60 detik dengan 5 dari 5]. DatapointToAlarm Gunakan kombinasi ini untuk menghilangkan alarm yang bising.
**catatan**
Rekomendasi sebelumnya mungkin bervariasi tergantung pada bagaimana Anda menggunakan layanan. Setiap AWS layanan beroperasi secara berbeda dalam beban kerja. Dan, layanan yang sama mungkin beroperasi secara berbeda ketika digunakan di banyak tempat. Anda harus yakin bahwa Anda memahami bagaimana beban kerja Anda memanfaatkan sumber daya yang memberi makan alarm, serta efek hulu dan hilir.
## Validasi bagaimana alarm Anda menangani data yang hilang
Beberapa sumber metrik tidak mengirim data CloudWatch secara berkala. Untuk metrik ini, ini adalah praktik terbaik untuk memperlakukan data yang hilang sebagai **NotBreaching**. Untuk informasi selengkapnya, lihat [Mengonfigurasi cara CloudWatch alarm menangani data yang hilang](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) dan [Menghindari transisi prematur ke status](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition) alarm.
Misalnya, jika metrik memantau tingkat kesalahan, dan tidak ada kesalahan, maka metrik tidak melaporkan titik data (nihil). Jika Anda mengonfigurasi alarm untuk memperlakukan data yang **hilang sebagai Hilang**, maka satu titik data pelanggaran diikuti oleh dua titik data tanpa data (nihil) menyebabkan metrik masuk ke status “Alarm” (untuk 3 dari 3 titik data). Ini karena konfigurasi data yang hilang mengevaluasi titik data terakhir yang diketahui dalam periode evaluasi.
Dalam kasus di mana metrik memantau tingkat kesalahan, dengan tidak adanya degradasi layanan, Anda dapat berasumsi bahwa tidak ada data yang baik. Ini adalah praktik terbaik untuk memperlakukan data yang hilang sebagai **NotBreaching** sehingga data yang hilang diperlakukan sebagai “OK” dan metrik tidak memasukkan status “Alarm” pada satu titik data.
## Tinjau riwayat setiap alarm
Jika riwayat alarm menunjukkan bahwa alarm sering memasuki status “Alarm” dan kemudian pulih dengan cepat, maka alarm mungkin menjadi masalah bagi Anda. Pastikan Anda menyetel alarm untuk mencegah kebisingan atau alarm palsu.
## Validasi metrik untuk sumber daya yang mendasarinya
Pastikan metrik Anda melihat sumber daya dasar yang valid dan gunakan statistik yang benar. Jika alarm dikonfigurasi untuk meninjau nama sumber daya yang tidak valid, alarm mungkin tidak dapat melacak data yang mendasarinya. Ini dapat menyebabkan alarm masuk ke status “Alarm”.
## Buat alarm komposit
Jika Anda menyediakan operasi Deteksi Insiden dan Respons dengan sejumlah besar alarm untuk orientasi, Anda mungkin diminta untuk membuat alarm gabungan. Alarm komposit mengurangi jumlah alarm yang perlu di-onboard.
# Bangun CloudWatch alarm di Deteksi dan Respons Insiden dengan template CloudFormation
Untuk mempercepat orientasi ke AWS Incident Detection and Response, dan untuk mengurangi upaya yang diperlukan untuk membangun alarm, AWS berikan template kepada Anda. CloudFormation Template ini mencakup pengaturan alarm yang dioptimalkan untuk layanan yang biasanya di-onboard, seperti Application Load Balancer, Network Load Balancer, dan Amazon. CloudFront
**Membangun CloudWatch alarm dengan template CloudFormation**
1. Unduh templat menggunakan tautan yang disediakan:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. Tinjau file JSON yang diunduh untuk memastikan file tersebut memenuhi proses operasi dan keamanan organisasi Anda.
1. Buat CloudFormation tumpukan:
**catatan**
Langkah-langkah berikut menggunakan proses pembuatan CloudFormation stack standar. Untuk langkah mendetail, lihat [Membuat tumpukan di CloudFormation konsol](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html).
1. Buka AWS CloudFormation konsol di [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Pilih **Buat tumpukan**.
1. Pilih **Template sudah siap**, lalu unggah file template dari folder lokal Anda.
Berikut ini adalah contoh dari **Create stack** screen.
![\[Buat contoh file template unggahan tumpukan\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/create-cfn-stack1.png)
1. Pilih **Berikutnya**.
1. Masukkan informasi yang diperlukan berikut:
+ **AlarmNameConfig**dan **AlarmDescriptionConfig**: Masukkan nama dan deskripsi untuk alarm Anda.
+ **ThresholdConfig**: Merevisi nilai ambang batas untuk memenuhi persyaratan aplikasi Anda.
+ **Distribusi IDConfig**: Pastikan ID distribusi mengarah ke sumber daya yang benar di akun tempat Anda membuat CloudFormation tumpukan.
1. Pilih **Berikutnya**.
1. Tinjau nilai default di **PeriodConfig**, **EvalutionPeriodConfig**, dan **DatapointsToAlarmConfig**bidang. Ini adalah praktik terbaik untuk menggunakan nilai default untuk bidang ini. Anda dapat melakukan penyesuaian, jika diperlukan, untuk memenuhi persyaratan aplikasi Anda.
1. Secara opsional masukkan tag dan informasi notifikasi SNS sesuai kebutuhan. Ini adalah praktik terbaik untuk mengaktifkan **perlindungan Terminasi** untuk mencegah penghapusan alarm yang tidak disengaja. Untuk mengaktifkan perlindungan terminasi, pilih tombol Radio yang **diaktifkan**, seperti yang ditunjukkan pada contoh berikut:
![\[Buat tumpukan mengaktifkan contoh perlindungan terminasi\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/create-cfn-stack2.png)
1. Pilih **Berikutnya**.
1. Tinjau pengaturan tumpukan Anda, lalu pilih **Buat tumpukan**.
1. Setelah membuat tumpukan, Anda akan melihat alarm yang tercantum dalam daftar CloudWatch **Alarm** Amazon, seperti yang ditunjukkan pada contoh berikut:
![\[Contoh daftar CloudWatch alarm\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/create-cfn-stack3.png)
1. Setelah Anda membuat semua alarm di akun dan AWS Wilayah yang benar, beri tahu Manajer Akun Teknis (TAM) Anda. Tim AWS Incident Detection and Response meninjau status alarm baru Anda, lalu melanjutkan orientasi Anda.
# Contoh kasus penggunaan untuk CloudWatch alarm dalam Deteksi dan Respons Insiden
Kasus penggunaan berikut memberikan contoh bagaimana Anda dapat menggunakan CloudWatch alarm Amazon di Deteksi dan Respons Insiden. Contoh-contoh ini menunjukkan bagaimana CloudWatch alarm dapat dikonfigurasi untuk memantau metrik dan ambang batas utama di berbagai AWS layanan, memungkinkan Anda mengidentifikasi dan merespons potensi masalah yang dapat memengaruhi ketersediaan dan kinerja aplikasi dan beban kerja Anda.
## Contoh Kasus Penggunaan A: Application Load Balancer
Anda dapat membuat CloudWatch alarm berikut yang menandakan potensi dampak beban kerja. Untuk melakukan ini, Anda membuat matematika metrik yang mengkhawatirkan saat koneksi yang berhasil turun di bawah ambang batas tertentu. Untuk metrik yang tersedia, lihat CloudWatch [CloudWatch metrik untuk Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) Balancer
**Metrik:** `HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**NameSpace: AWS/AplikasiElb**
**ComparisonOperator(Ambang):** Kurang dari x (x = ambang pelanggan).
**Periode:** 60 detik
**DatapointsToAlarm:** 3 dari 3
**Perlakuan data yang hilang:** Perlakukan data yang hilang sebagai [pelanggaran](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistik: **Jumlah
Diagram berikut menunjukkan aliran untuk Use Case A:
![\[Contoh kasus penggunaan untuk Application Load Balancer\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/UseCaseAALB.png)
## Contoh Kasus Penggunaan B: Amazon API Gateway
Anda dapat membuat CloudWatch alarm berikut yang menandakan potensi dampak beban kerja. Untuk melakukan ini, Anda membuat metrik komposit yang alarm ketika ada lantensi tinggi atau jumlah rata-rata kesalahan 4XX yang tinggi di API Gateway. Untuk metrik yang tersedia, lihat [Dimensi dan metrik Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)
**Metrik:** `compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**NameSpace:** AWS/Gerbang API
**ComparisonOperator(Ambang batas):** Lebih besar dari (ambang batas pelanggan x atau y)
**Periode:** 60 detik
**DatapointsToAlarm:** 1 dari 1
**Perlakuan data yang hilang:** Perlakukan data yang hilang sebagai [tidak melanggar](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistik:**
Diagram berikut menunjukkan aliran untuk Use Case B:
![\[Contoh kasus penggunaan untuk API Gateway\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## Contoh Kasus Penggunaan C: Amazon Route 53
Anda dapat memantau sumber daya Anda dengan membuat pemeriksaan kesehatan Route 53 yang digunakan CloudWatch untuk mengumpulkan dan memproses data mentah menjadi metrik yang dapat dibaca, mendekati waktu nyata. Anda dapat membuat CloudWatch alarm berikut yang menandakan potensi dampak beban kerja. Anda dapat menggunakan CloudWatch metrik untuk membuat alarm yang memicu ketika melanggar ambang batas yang ditetapkan. Untuk metrik yang tersedia, lihat CloudWatch [CloudWatch metrik untuk pemeriksaan kesehatan Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)
**Metrik:** `R53-HC-Success`
**NameSpace:** AWS/Rute 53
**Ambang batas HealthCheckStatus:** HealthCheckStatus < x untuk 3 titik data dalam 3 menit (menjadi ambang batas x pelanggan)
**Periode:** 1 menit
**DatapointsToAlarm:** 3 dari 3
**Perlakuan data yang hilang:** Perlakukan data yang hilang sebagai [pelanggaran](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistik: **Minimum
Diagram berikut menunjukkan aliran untuk Use Case C:
![\[Contoh kasus penggunaan untuk Route 53\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/UseCaseCR53.png)
## Contoh Kasus Penggunaan D: Pantau beban kerja dengan aplikasi khusus
Sangat penting bahwa Anda meluangkan waktu untuk menentukan pemeriksaan kesehatan yang tepat dalam skenario ini. Jika Anda hanya memverifikasi bahwa port aplikasi terbuka, maka Anda belum memverifikasi bahwa aplikasi tersebut berfungsi. Selain itu, melakukan panggilan ke halaman beranda aplikasi belum tentu cara yang benar untuk menentukan apakah aplikasi berfungsi. Misalnya, jika aplikasi bergantung pada database dan Amazon Simple Storage Service (Amazon S3), maka pemeriksaan kesehatan harus memvalidasi semua elemen. Salah satu cara untuk melakukannya adalah dengan membuat halaman web pemantauan, seperti **/monitor**. Halaman web pemantauan membuat panggilan ke database untuk memastikan bahwa itu dapat terhubung dan mendapatkan data. Dan, halaman web pemantauan melakukan panggilan ke Amazon S3. Kemudian, Anda mengarahkan pemeriksaan kesehatan pada penyeimbang beban ke halaman **/monitor**.
Diagram berikut menunjukkan aliran untuk Use Case D:
![\[Contoh kasus penggunaan untuk pemantauan dengan aplikasi khusus\]](http://docs.aws.amazon.com/id_id/IDR/latest/userguide/images/CustomAlarm.png)