Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate
Pemantauan dan Manajemen Insiden untuk Amazon EKS memantau sumber daya Amazon EKS Anda untuk kegagalan, penurunan kinerja, dan masalah keamanan. AMS Accelerate mengonfigurasi dan menerapkan Layanan Terkelola Amazon untuk aturan manajer peringatan Prometheus, memantau peringatan, dan kemudian melakukan manajemen insiden saat peringatan ini dipicu. [Pemantauan dan manajemen insiden untuk Amazon EKS bergantung pada AMS Alarm Manager dan memanfaatkan AWS layanan asli, seperti [Amazon Managed Service untuk Prometheus](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html), Amazon [Managed Grafana, Amazon](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html), dan. GuardDuty [AWS Lambda[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html)
**catatan**
Pemantauan dan manajemen insiden untuk Amazon EKS tidak mendukung AWS GovCloud (US), node Windows, atau wadah Windows.
# Apa itu pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate?
Pemantauan dan manajemen insiden untuk Amazon EKS memberikan yang berikut:
+ Konfigurasi default yang membuat, mengelola, dan menyebarkan monitor dan kebijakan di seluruh akun terkelola untuk klaster Amazon EKS yang Anda pilih.
+ Garis dasar pemantauan untuk memungkinkan beban kerja Amazon EKS Anda meningkatkan ketersediaan, bahkan jika Anda tidak mengonfigurasi pemantauan lain untuk kluster Amazon EKS Anda. Untuk informasi selengkapnya, lihat [Peringatan dasar dalam pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate](acc-baseline-eks-alerts.md).
+ Pemberitahuan yang dihasilkan oleh pemantauan dasar yang dikonfigurasi untuk kluster Amazon EKS Anda. Notifikasi ini dikenal sebagai peringatan. Peringatan dihasilkan ketika ada yang akan segera terjadi, sedang berlangsung, surut, atau potensi kegagalan, penurunan kinerja, atau masalah keamanan. Contoh peringatan termasuk peringatan Prometheus, acara, atau temuan dari layanan, seperti Amazon. AWS GuardDuty
+ Investigasi peringatan dengan panduan tentang tindakan remediasi yang tepat yang dapat Anda ambil. Untuk informasi selengkapnya, lihat [Laporan insiden dan permintaan layanan di AMS Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html).
+ Remediasi peringatan dan insiden oleh operasi AMS, bila memungkinkan dan dengan persetujuan Anda, untuk mencegah atau mengurangi dampak pada aplikasi Anda. Untuk informasi selengkapnya, lihat [Laporan insiden dan permintaan layanan di AMS Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html).
+ Dasbor Grafana Terkelola Amazon opsional yang telah ditentukan sebelumnya yang memberikan visibilitas ke pemanfaatan sumber daya, kinerja, kesehatan CoreDNS, peringatan aktif, dan peringatan yang telah diselesaikan sebelumnya. Jika Anda mengonfigurasi Grafana Terkelola Amazon menggunakan templat yang disediakan AMS, Anda dapat membuka konsol Grafana Terkelola Amazon untuk melihat metrik dan peringatan untuk klaster Amazon EKS Anda.
# Cara kerja pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate
**Generasi:** Sebagai bagian dari pemantauan orientasi dan manajemen insiden untuk EKS, AMS mengonfigurasi pemantauan dasar untuk kluster Amazon EKS yang Anda pilih di akun terkelola. AMS menggunakan kombinasi Layanan Terkelola Amazon untuk aturan manajer peringatan Prometheus dan aturan peristiwa CloudWatch Amazon untuk mengonfigurasi pemantauan dasar. Server Prometheus yang dikonfigurasi AMS di kluster Anda akan menggores dan menulis metrik Prometheus dari jarak jauh ke Layanan Terkelola Amazon untuk titik akhir Prometheus di Wilayah yang sama. Konfigurasi pemantauan dasar menghasilkan peringatan ketika aturan manajer peringatan Prometheus dipicu atau peristiwa dihasilkan. CloudWatch
**Agregasi:** AMS mengirimkan semua peringatan yang dihasilkan sumber daya Anda ke sistem pemantauan AMS dengan mengarahkannya ke topik Layanan Pemberitahuan Sederhana Amazon yang dikelola oleh AMS.
**Pemrosesan dan analisis dampak:** AMS menganalisis peringatan dan kemudian memprosesnya berdasarkan potensi dampaknya. AMS mengklasifikasikan peringatan sebagai berikut:
+ **Peringatan dengan dampak pelanggan yang diketahui:** Untuk peringatan ini, AMS membuat laporan insiden baru menggunakan proses [manajemen insiden](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-manage-incidents.html).
+ **Peringatan dengan dampak pelanggan yang tidak pasti:** Untuk peringatan ini, AMS mengirimkan laporan insiden. Dalam banyak kasus, peringatan ini meminta Anda untuk memverifikasi dampaknya sebelum AMS dapat mengambil tindakan. Untuk peringatan semacam itu, AMS mengirimkan [pemberitahuan peringatan](acc-baseline-eks-alerts.md#acc-alerts-and-actions) dengan detailnya dan memeriksa apakah peringatan memerlukan tindakan mitigasi. AMS menyediakan opsi untuk mengurangi tindakan dalam notifikasi. Jika balasan Anda mengonfirmasi bahwa peringatan tersebut adalah insiden, AMS kemudian memicu pembuatan laporan insiden baru dan memulai proses manajemen insiden. Setiap pemberitahuan layanan yang menerima tanggapan “tidak ada dampak pelanggan” atau tidak ada tanggapan sama sekali selama tiga hari ditandai sebagai diselesaikan. Juga, peringatan yang sesuai ditandai sebagai diselesaikan.
+ **Peringatan tanpa dampak pelanggan:** Jika, setelah evaluasi, AMS menentukan bahwa peringatan tidak memiliki dampak pelanggan, peringatan ditutup.
## Matriks tanggung jawab AMS (RACI)
Matriks AMS yang bertanggung jawab, bertanggung jawab, dikonsultasikan, dan diinformasikan, atau RACI memberikan tanggung jawab utama kepada pelanggan atau AMS untuk berbagai kegiatan. Tabel f ollowing memberikan gambaran umum tentang tanggung jawab pelanggan dan AMS untuk aktivitas dalam aplikasi yang menggunakan Pemantauan dan Manajemen Insiden untuk Amazon EKS.
+ **R** adalah singkatan dari pihak yang bertanggung jawab yang melakukan pekerjaan untuk mencapai tugas.
+ **A** adalah singkatan dari pihak yang bertanggung jawab.
+ **C** adalah singkatan dari konsultasikan; pihak yang pendapatnya dicari, biasanya sebagai ahli materi pelajaran; dan dengan siapa ada komunikasi bilateral.
+ **Saya** singkatan dari Informed; pihak yang diinformasikan tentang kemajuan, seringkali hanya pada penyelesaian tugas atau deliverable.
| Aktifitas | Pelanggan | AMS |
| --- | --- | --- |
| Penemuan untuk persyaratan AMS | I | R |
| Aktifkan izin AMS (RBAC) untuk akses klaster | R | C |
| Instal Amazon EC2 Systems Manager Agent di node pekerja jika belum ada | R | C |
| Terapkan komponen on-cluster AMS, seperti Prometheus, Prometheus Node Exporter, dan di namespace AMS, sesuai kebutuhan. kube-state-metrics | C | R |
| Menyediakan Layanan Terkelola Amazon untuk Prometheus di bidang kontrol AMS | I | R |
| Konfigurasikan manajer peringatan Prometheus di bidang kontrol AMS | I | R |
| Menyediakan template Grafana yang Dikelola Amazon dan bantu konfigurasi | C | R |
| Aktifkan Pemantauan Log Audit GuardDuty EKS | C | R |
| Aktifkan pencatatan pesawat kontrol Amazon EKS | I | R |
| Pantau kesehatan dan kinerja pesawat kontrol Amazon EKS | I | R |
| Pantau kesehatan dan kinerja klaster Amazon EKS Anda (cluster, node, beban kerja, pod, API Server, dan CoreDNS) | I | R |
| Peringatan triase dan berikan respons insiden untuk Amazon EKS | I | R |
| Jalankan perintah diagnostik selama insiden | I | R |
| Menganalisis log selama insiden (bidang kontrol dan log pod) | I | R |
| Respons insiden untuk masalah AWS jaringan | I | R |
| Menanggapi temuan GuardDuty EKS Audit Log Monitoring | I | R |
| Memberikan panduan pelanggan tentang tindakan untuk memulihkan insiden jika memungkinkan | I | R |
# Peringatan dasar dalam pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate
Setelah memverifikasi peringatan, AMS mengaktifkan peringatan berikut untuk Amazon EKS dan kemudian terlibat dalam pemantauan dan manajemen insiden untuk kluster Amazon EKS pilihan Anda. Waktu respons Perjanjian Tingkat Layanan (SLAs) dan Tujuan Tingkat Layanan (SLOs) bergantung pada Tingkat Layanan akun yang Anda pilih (Plus, Premium). Untuk informasi selengkapnya, lihat [Laporan insiden dan permintaan layanan di AMS Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html).
## Peringatan dan tindakan
Tabel berikut mencantumkan peringatan Amazon EKS dan tindakan masing-masing yang dilakukan AMS:
| Pemberitahuan | Ambang batas | Tindakan |
| --- | --- | --- |
| Kontainer OOM terbunuh | Jumlah kontainer yang dimulai ulang dalam 10 menit terakhir setidaknya 1 dan kontainer Kubernetes dalam sebuah pod telah dihentikan dengan alasan “OOMKilled” dalam 10 menit terakhir. | AMS menyelidiki apakah pembunuhan OOM disebabkan karena mencapai batas kontainer atau batas memori yang berlebihan, dan kemudian memberi tahu Anda tentang tindakan korektif. |
| Pod Job Gagal | Pekerjaan Kubernetes gagal diselesaikan. Kegagalan ditunjukkan dengan adanya setidaknya satu status pekerjaan yang gagal. | AMS menyelidiki mengapa pekerjaan Kubernetes atau pekerjaan cron terkait gagal, dan kemudian memberi tahu Anda tentang tindakan korektif. |
| StatefulSet Bawah | Jumlah replika yang siap melayani lalu lintas tidak sesuai dengan jumlah replika yang ada saat ini per StatefulSet setidaknya 1 menit. | AMS menentukan mengapa pod tidak siap dengan meninjau pesan kesalahan dalam peristiwa pod dan cuplikan log kesalahan di log pod, dan kemudian memberi tahu Anda tentang tindakan korektif. |
| Kemampuan Penskalaan HPA | Horizontal Pod Autoscaler (HPA) tidak dapat menskalakan karena kondisi status “AbleToScale” salah setidaknya selama 2 menit. | AMS menentukan Kubernetes Horizontal Pod Autoscaler (HPA) mana yang tidak dapat menskalakan Pod untuk sumber daya beban kerja berikutnya, seperti Deployment atau. StatefulSet |
| Ketersediaan Metrik HPA | Horizontal Pod Autoscaler (HPA) tidak dapat mengumpulkan metrik karena kondisi status “ScalingActive” salah setidaknya selama 2 menit. | AMS menentukan mengapa HPA tidak dapat mengumpulkan metrik, seperti metrik yang terkait dengan masalah konfigurasi server atau masalah otorisasi RBAC. |
| Pod Belum Siap | Pod Kubernetes tetap dalam keadaan tidak berjalan (seperti Pending, Unknown, atau Failed) selama lebih dari 15 menit. | AMS menyelidiki pod yang terpengaruh untuk detailnya, meninjau log pod untuk kesalahan dan peristiwa terkait, dan kemudian memberi tahu Anda tentang tindakan korektif. |
| Perulangan Kecelakaan Pod | Kontainer pod dimulai ulang setidaknya sekali setiap 15 menit selama periode 1 jam. | AMS menyelidiki alasan pod tidak dimulai, seperti sumber daya yang tidak mencukupi, file yang dikunci oleh wadah lain, database dikunci oleh kontainer lain, dependensi layanan gagal, masalah DNS untuk layanan eksternal, dan kesalahan konfigurasi. |
| Daemonset Salah terjadwal | Setidaknya ada satu pod Kubernetes Daemonset yang salah dalam jangka waktu 10 menit. | AMS menentukan mengapa Daemonset dijadwalkan pada node di mana mereka tidak seharusnya berjalan. Ini mungkin terjadi ketika pod yang salah diterapkan ke pod nodeSelector/taints/affinities Daemonset atau ketika node (kumpulan node) tercemar dan pod yang ada tidak dijadwalkan untuk penggusuran. |
| Kesalahan API Kubernetes | Tingkat kesalahan server API Kubernetes melebihi 3% selama periode 2 menit. | AMS menganalisis log bidang kontrol untuk menentukan volume dan jenis kesalahan yang menyebabkan peringatan ini, dan mengidentifikasi masalah pertentangan sumber daya apa pun untuk grup penskalaan otomatis node master atau etcd. Jika server API tidak pulih, AMS melibatkan tim layanan Amazon EKS. |
| Latensi API Kubernetes | Latensi persentil ke-99 dari permintaan ke server API Kubernetes melebihi 1 detik selama periode 2 menit. | AMS menganalisis log bidang kontrol untuk menentukan volume dan jenis kesalahan yang menyebabkan latensi dan mengidentifikasi masalah pertentangan sumber daya untuk grup auto-scaling node master atau etcd. Jika server API tidak pulih, AMS melibatkan tim layanan Amazon EKS. |
| Sertifikat Klien Kubernetes Kedaluwarsa | Sertifikat klien yang digunakan untuk mengautentikasi ke server API Kubernetes akan kedaluwarsa dalam waktu kurang dari 24 jam. | AMS mengirimkan pemberitahuan ini untuk memberi tahu Anda bahwa sertifikat klaster Anda akan kedaluwarsa dalam 24 jam. |
| Node Tidak Siap | Status kondisi Node “Siap” salah setidaknya selama 10 menit. | AMS menyelidiki kondisi dan peristiwa node, seperti masalah jaringan, yang mencegah akses kubelet ke server API. |
| Node CPU Tinggi | Beban CPU melebihi 80% selama periode 5 menit. | AMS menentukan apakah satu atau lebih pod mengkonsumsi CPU dalam jumlah yang luar biasa tinggi. Kemudian, AMS memverifikasi dengan Anda bahwa permintaan, batasan, dan aktivitas pod Anda seperti yang diharapkan. |
| Node OOM Bunuh Terdeteksi | Setidaknya ada satu host OOM kill yang dilaporkan oleh node dalam jendela 4 menit. | AMS menentukan apakah pembunuhan OOM disebabkan karena mencapai batas kontainer atau komit berlebih node. Jika aktivitas aplikasi normal, AMS memberi tahu Anda tentang permintaan dan batasan untuk overcommit dan merevisi batas pod. |
| Batas Node Conntrack | Rasio jumlah entri pelacakan koneksi saat ini hingga batas maksimum melebihi 80% selama periode 5 menit. | AMS memberi tahu Anda tentang nilai conntrack yang direkomendasikan per inti. Node Kubernetes menetapkan nilai conntrack max sebanding dengan total kapasitas memori node. Aplikasi beban tinggi, terutama pada node yang lebih kecil, dapat dengan mudah melebihi nilai max conntrack, menghasilkan reset koneksi dan batas waktu. |
| Jam Node Tidak Sinkronisasi | Status sinkronisasi minimum selama periode 2 menit adalah 0, dan kesalahan maksimum dalam hitungan detik adalah 16 atau lebih tinggi. | AMS menentukan apakah Network Time Protocol (NTP) diinstal dan berfungsi dengan baik. |
| CPU Pod Tinggi | Penggunaan CPU kontainer melebihi 80% lebih dari 3 menit untuk periode minimal 2 menit. | AMS menyelidiki log pod untuk menentukan tugas pod yang mengkonsumsi CPU dalam jumlah tinggi. |
| Memori Pod Tinggi | Penggunaan memori wadah melebihi 80% dari batas memori yang ditentukan selama periode 2 menit. | AMS menyelidiki log pod untuk menentukan tugas pod yang mengkonsumsi memori dalam jumlah tinggi. |
| CoreDNS Turun | CoreDNS telah menghilang dari penemuan target Prometheus selama lebih dari 15 menit. | Ini adalah peringatan kritis yang menunjukkan bahwa resolusi nama domain untuk layanan klaster internal atau eksternal dihentikan. AMS memeriksa status pod CoreDNS, memverifikasi konfigurasi CoreDNS, memverifikasi titik akhir DNS yang mengarah ke pod CoreDNS, memverifikasi batas CoreDNS, dan dengan persetujuan Anda, mengaktifkan logging debug CoreDNS. |
| Kesalahan CoreDNS | CoreDNS mengembalikan kesalahan SERVFAIL untuk lebih dari 3% permintaan DNS selama periode 10 menit. | Peringatan ini mungkin menandakan masalah dengan aplikasi atau kesalahan konfigurasi. AMS memeriksa status pod CoreDNS, memverifikasi konfigurasi CoreDNS, memverifikasi titik akhir DNS yang mengarah ke pod CoreDNS, memverifikasi batas CoreDNS, dan dengan persetujuan Anda, mengaktifkan logging debug CoreDNS. |
| Latensi CoreDNS | Persentil ke-99 dari durasi permintaan DNS melebihi 4 detik selama 10 menit. | Peringatan ini menandakan bahwa CoreDNS mungkin kelebihan beban. AMS memeriksa status pod CoreDNS, memverifikasi konfigurasi CoreDNS, memverifikasi titik akhir DNS yang mengarah ke pod CoreDNS, memverifikasi batas CoreDNS, dan dengan persetujuan Anda, mengaktifkan logging debug CoreDNS. |
| Latensi Penerusan CoreDNS | Persentil ke-99 dari waktu respons untuk permintaan penerusan CoreDNS ke kube-dns melebihi 4 detik selama periode 10 menit. | Ketika CoreDNS bukan server otoritatif atau tidak memiliki entri cache untuk nama domanin, CoreDNS meneruskan permintaan DNS ke server DNS hulu. Peringatan ini menandakan bahwa CoreDNS mungkin kelebihan beban atau mungkin ada masalah dengan server DNS hulu. AMS memeriksa status pod CoreDNS, memverifikasi konfigurasi CoreDNS, memverifikasi titik akhir DNS yang mengarah ke pod CoreDNS, memverifikasi batas CoreDNS, dan dengan persetujuan Anda, mengaktifkan logging debug CoreDNS. |
| Kesalahan Penerusan CoreDNS | Lebih dari 3% kueri DNS gagal selama periode 5 menit. | Ketika CoreDNS bukan server otoritatif atau tidak memiliki entri cache untuk nama domanin, CoreDNS meneruskan permintaan DNS ke server DNS hulu. Peringatan ini menandakan kemungkinan kesalahan konfigurasi atau masalah dengan server DNS hulu. AMS memeriksa status pod CoreDNS, memverifikasi konfigurasi CoreDNS, memverifikasi titik akhir DNS yang mengarah ke pod CoreDNS, memverifikasi batas CoreDNS, dan dengan persetujuan Anda, mengaktifkan logging debug CoreDNS. |
# Persyaratan untuk pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate
Ini adalah sumber daya yang and/or diperlukan yang didukung untuk pemantauan dan manajemen insiden untuk Amazon EKS untuk AMS Accelerate
+ **Versi **Kubernetes yang didukung: Lihat versi** [Amazon EKS Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) di Panduan Pengguna Amazon EKS.**
+ **Jenis node:** Node terkelola Amazon EKS didukung. Node dan wadah Windows tidak didukung.
+ **Akses klaster Kubernetes: AMS membutuhkan system:master peran cluster** RBAC dan pengguna cluster.
+ **Agen SSM di EC2 node Amazon:** Baik Bottle Rocket dan Amazon EKS AMIs memiliki Agen SSM yang sudah diinstal sebelumnya. Pastikan Agen SSM diinstal pada EC2 node kustom AMIs dan Amazon Anda.
+ **Service Quotas** [Untuk informasi selengkapnya, lihat kuota layanan untuk Amazon Managed Service [for Prometheus dan Amazon Managed](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html) Grafana.](https://docs.aws.amazon.com/grafana/latest/userguide/AMG_quotas.html)
+ ** AWS Wilayah yang Didukung:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/managedservices/latest/accelerate-guide/acc-requirements.html)
**catatan**
Metrik untuk kluster Amazon EKS di af-south-1, Afrika (Cape Town) dan ap-east-1, Asia Pasifik (Hong Kong) diekspor ke layanan pemantauan AMS masing-masing. Wilayah AWS Metrik untuk ini kemudian Wilayah AWS diangkut dalam layanan pemantauan AMS ke Wilayah yang berbeda di mana mereka diproses dan disimpan. Lihat tabel sebelumnya untuk Wilayah yang digunakan layanan pemantauan AMS untuk menyimpan metrik.
# Onboard untuk pemantauan dan manajemen insiden untuk Amazon EKS di AMS Accelerate
Lakukan langkah-langkah berikut untuk melakukan onboard ke pemantauan dan manajemen insiden untuk Amazon EKS.
1. **Mengaktifkan tag pengoptimalan biaya Amazon EKS:** Lihat [Menandai sumber daya Anda untuk penagihan](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html#tag-resources-for-billing) di **Panduan Pengguna Amazon EKS**.
1. **Memulai orientasi pemantauan dan manajemen insiden untuk EKS:** Hubungi Cloud Service Delivery Manager (CSDM) Anda dengan nama akun IDs dan klaster untuk onboard.
1. **Validasi persyaratan:** Cloud Architect (CA) Anda memvalidasi bahwa semua [persyaratan](acc-requirements.md) terpenuhi sebelum orientasi dimulai.
1. **Update Kubernetes role-based access control (RBAC):** AMS membagikan perintah untuk mengimplementasikan perubahan ini. `eksctl` Anda dapat meninjau perubahan ini dan kemudian menerapkan. Anda harus menerapkan pembaruan RBAC sehingga AMS memiliki izin untuk menjalankan perintah atas nama Anda. Pembaruan ini termasuk memetakan peran AMS IAM ke pengguna Kubernetes, membuat peran klaster Kubernetes baru untuk AMS, dan mengikat peran klaster AMS Kubernetes ke pengguna.
1. **Menerapkan komponen cluster:** AMS menerapkan komponen berikut dalam namespace yang dikelola AMS di klaster Anda:
+ Server Prometheus
+ Eksportir simpul Prometheus (tidak berlaku untuk) AWS Fargate
+ kube-state-metrics
1. **Lakukan pembaruan konfigurasi Prometheus: AMS mengonfigurasi Prometheus** untuk mengaktifkan penulisan jarak jauh untuk metrik.
1. **(Opsional) Konfigurasikan dasbor:** CA membantu mengonfigurasi dasbor Grafana Terkelola Amazon di akun Anda.
**catatan**
Setelah klaster Amazon EKS Anda di-onboard, AMS menganalisis sinyal peringatan dan melakukan penilaian dasar untuk mengidentifikasi masalah yang ada di klaster Anda. Setelah penilaian dasar selesai, AMS membagikan temuan dan rekomendasi remediasi melalui Trusted Advisor dan permintaan layanan yang dapat Anda gunakan untuk mengatasi masalah di klaster Anda. Dari penilaian, AMS membuat garis dasar pemantauan Amazon EKS khusus untuk kluster EKS Anda dengan menyesuaikan ambang batas alarm tingkat akun kami. Untuk menghilangkan duplikat respons AMS terhadap temuan ini, kami menyesuaikan pemantauan kami untuk mengecualikan sinyal peringatan tersebut. Kami menyesuaikan kembali pemantauan kami untuk menyertakan sinyal ketika CSDM Anda memberi tahu kami bahwa masalah mendasar telah diperbaiki.
# Offboard dari Pemantauan dan Manajemen Insiden untuk Amazon EKS di AMS Accelerate
Beri tahu manajer pengiriman layanan cloud (CSDM) Anda dengan nama akun IDs dan klaster untuk memulai proses offboarding. Setelah Anda offboard, pemrosesan peringatan, penyimpanan metrik, dan kueri metrik ditangguhkan dan metrik dihapus sesuai dengan kebijakan penyimpanan data [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html) default.
AMS melakukan langkah-langkah offboarding berikut:
1. AMS menonaktifkan peringatan yang dikirimkan kepada Anda dan Operasi AMS.
1. AMS menghapus instans Prometheus dari cluster Amazon EKS Anda.
1. AMS menghapus AWS sumber daya lain yang diinstal di akun Anda, seperti peran dan AWS Config aturan IAM.
Setelah langkah-langkah ini selesai, Anda harus menyelesaikan langkah-langkah offboarding berikut:
1. Gunakan `eksctl` untuk menghapus izin Kubernetes RBAC dari. `aws-auth` `ConfigMap`
1. Jika sebelumnya Anda menginstalnya, hapus instans Grafana Terkelola Amazon yang Anda konfigurasikan untuk disambungkan ke AMS.