Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Cara kerja pemantauan
Lihat grafik berikut tentang arsitektur pemantauan di AWS Managed Services (AMS).
Diagram berikut memberikan gambaran tingkat tinggi dari landing zone multi-akun AMS dan alur kerja pemantauan landing zone akun tunggal AMS.
Pembuatan: Pada saat orientasi akun, AMS mengonfigurasi pemantauan dasar (kombinasi alarm (CW), dan aturan acara CW) untuk semua sumber daya yang dibuat di akun terkelola. CloudWatch Konfigurasi pemantauan dasar menghasilkan peringatan ketika alarm CW dipicu atau peristiwa CW dihasilkan.
Agregasi:
Zona Pendaratan Multi-Akun: Peringatan dihasilkan oleh sumber daya Anda dalam akun Aplikasi dan Unit Organisasi Inti dan dikirim ke sistem pemantauan AMS dengan mengarahkannya melalui akun Keamanan.
Zona Pendaratan Akun Tunggal: Semua peringatan yang dihasilkan oleh sumber daya Anda dikirim ke sistem pemantauan AMS dengan mengarahkannya ke topik SNS di akun.
Anda juga dapat mengonfigurasi cara AMS mengelompokkan EC2 peringatan bersama. AMS mengelompokkan semua peringatan yang terkait dengan EC2 instance yang sama ke dalam satu insiden, atau membuat satu insiden per peringatan, tergantung pada preferensi Anda. Anda dapat mengubah konfigurasi ini kapan saja dengan bekerja sama dengan Cloud Service Delivery Manager atau Cloud Architect Anda. Ini bekerja dengan cara yang sama apakah Anda menggunakan Zona Pendaratan Multi-Akun atau Zona Pendaratan Akun Tunggal.
Pemrosesan: AMS menganalisis peringatan dan memprosesnya berdasarkan potensi dampaknya. Peringatan diproses seperti yang dijelaskan selanjutnya.
Peringatan dengan dampak pelanggan yang diketahui: Ini mengarah pada pembuatan laporan insiden baru dan AMS mengikuti proses manajemen insiden; untuk informasi tentang manajemen insiden, lihatTanggapan insiden AMS.
Contoh peringatan: EC2 Instans Amazon gagal dalam pemeriksaan kesehatan sistem, AMS mencoba memulihkan instance dengan menghentikan dan memulai ulang instans.
Peringatan dengan dampak pelanggan yang tidak pasti: Untuk jenis peringatan ini, AMS mengirimkan laporan insiden, dalam banyak kasus meminta Anda untuk memverifikasi dampak sebelum AMS mengambil tindakan. Namun, jika pemeriksaan terkait infrastruktur lewat, AMS tidak mengirimkan laporan insiden kepada Anda.
Misalnya: Peringatan untuk pemanfaatan CPU > 85% selama lebih dari 10 menit pada EC2 instans Amazon tidak dapat segera dikategorikan sebagai insiden karena perilaku ini mungkin diharapkan berdasarkan penggunaan. Dalam contoh ini, AMS Automation melakukan pemeriksaan terkait infrastruktur pada sumber daya. Jika pemeriksaan tersebut lulus, maka AMS tidak mengirim pemberitahuan peringatan, bahkan jika penggunaan CPU melewati 99%. Jika Automation mendeteksi bahwa pemeriksaan terkait infrastruktur gagal pada sumber daya, AMS mengirimkan pemberitahuan peringatan dan memeriksa apakah mitigasi diperlukan. Pemberitahuan peringatan dibahas secara rinci di bagian ini. AMS menawarkan opsi mitigasi dalam notifikasi. Ketika Anda membalas pemberitahuan yang mengonfirmasi bahwa peringatan tersebut merupakan insiden, AMS akan membuat laporan insiden baru dan proses manajemen insiden AMS dimulai. Pemberitahuan layanan yang menerima respons “tidak ada dampak pelanggan,” atau tidak ada respons sama sekali selama tiga hari, ditandai sebagai diselesaikan dan peringatan terkait ditandai sebagai diselesaikan.
Peringatan tanpa dampak pelanggan: Jika, setelah evaluasi, AMS menentukan bahwa peringatan tidak memiliki dampak pelanggan, maka peringatan ditutup.
Misalnya, AWS Health memberi tahu EC2 instance yang membutuhkan penggantian tetapi instance itu telah dihentikan.
EC2 pemberitahuan yang dikelompokkan misalnya
Anda dapat mengonfigurasi pemantauan AMS untuk mengelompokkan peringatan bersama dari EC2 instance yang sama ke dalam satu insiden. Cloud Service Delivery Manager atau Cloud Architect Anda dapat mengonfigurasinya untuk Anda. Ada empat parameter yang dapat Anda konfigurasikan untuk setiap akun yang dikelola AMS.
Lingkup: Pilih seluruh akun atau berbasis tag.
Untuk menentukan konfigurasi yang berlaku untuk setiap EC2 instance di akun tersebut, pilih scope = account-wide.
Untuk menentukan konfigurasi yang hanya berlaku untuk EC2 instance di akun tersebut dengan tag tertentu, pilih scope = berbasis tag.
Aturan pengelompokan: Pilih klasik atau contoh.
Untuk mengonfigurasi pengelompokan tingkat instans untuk setiap sumber daya di akun Anda, pilih scope = account-wide dan grouping rule = instance.
Untuk mengonfigurasi sumber daya tertentu di akun Anda agar menggunakan pengelompokan tingkat instans, beri tag pada instance tersebut, lalu pilih scope = tag-based dan grouping rule = instance level.
Untuk tidak menggunakan pengelompokan instance untuk peringatan di akun Anda, pilih aturan pengelompokan = klasik.
Opsi keterlibatan: Pilih tidak ada, hanya laporkan, atau default.
Agar AMS tidak membuat insiden atau menjalankan otomatisasi untuk alarm dari sumber daya tersebut saat konfigurasi aktif, pilih none.
Agar AMS tidak membuat insiden atau menjalankan otomatisasi untuk alarm dari sumber daya tersebut saat konfigurasi aktif, dan tidak menjalankan dokumen Systems Manager penyembuhan otomatis tetapi untuk menyertakan catatan peristiwa ini dalam pelaporan Anda, pilih laporan saja. Ini mungkin berguna jika Anda ingin mengurangi volume kasus dukungan insiden yang berinteraksi dengan Anda dan jika beberapa insiden dari beberapa sumber daya tidak memerlukan perhatian segera, misalnya yang ada di akun non-produksi.
Agar AMS dapat memproses peringatan Anda, menjalankan otomatisasi, dan membuat kasus insiden bila diperlukan, pilih default.
Selesaikan setelah: Pilih 24 jam, 48 jam, atau 72 jam. Terakhir, konfigurasikan kapan kasus insiden ditutup secara otomatis. Jika waktu dari korespondensi kasus terakhir mencapai nilai Selesaikan setelah yang dikonfigurasi, insiden ditutup.
Notifikasi pemberitahuan
Sebagai bagian dari pemrosesan peringatan, berdasarkan analisis dampak, AWS Managed Services (AMS) membuat insiden dan memulai proses manajemen insiden untuk remediasi, ketika dampak dapat ditentukan. Jika dampak tidak dapat ditentukan, AMS akan mengirimkan pemberitahuan peringatan ke alamat email yang terkait dengan akun Anda melalui pemberitahuan layanan. Dalam beberapa skenario, pemberitahuan peringatan ini tidak dikirim. Misalnya, jika pemeriksaan terkait infrastruktur melewati peringatan pemanfaatan CPU yang tinggi, maka pemberitahuan peringatan tidak dikirimkan kepada Anda. Untuk informasi selengkapnya, lihat diagram pada arsitektur pemantauan AMS untuk proses penanganan peringatan diCara kerja pemantauan.
Pemberitahuan peringatan berbasis tag
Gunakan tag untuk mengirim pemberitahuan peringatan untuk sumber daya Anda ke alamat email yang berbeda. Ini adalah praktik terbaik untuk menggunakan pemberitahuan peringatan berbasis tag karena pemberitahuan yang dikirim ke satu alamat email dapat menyebabkan kebingungan ketika beberapa tim pengembang menggunakan akun yang sama. Pemberitahuan peringatan berbasis tag tidak terpengaruh oleh EC2 pemberitahuan yang dikelompokkan misalnya pengaturan yang Anda pilih.
Dengan pemberitahuan peringatan berbasis tag, Anda dapat:
Kirim peringatan ke alamat email tertentu: Tag sumber daya yang memiliki peringatan yang harus dikirim ke alamat email tertentu dengan,
key = OwnerTeamEmail.value =EMAIL_ADDRESSKirim peringatan ke beberapa alamat email: Untuk menggunakan beberapa alamat email, tentukan daftar nilai yang dipisahkan koma. Misalnya,
key =,OwnerTeamEmailvalue =. Jumlah total karakter untuk bidang nilai tidak boleh melebihi 260.EMAIL_ADDRESS_1,EMAIL_ADDRESS_2,EMAIL_ADDRESS_3, ...Gunakan kunci tag kustom: Untuk menggunakan kunci tag kustom, berikan nama kunci tag kustom ke CSDM Anda dalam email yang secara eksplisit memberikan persetujuan untuk mengaktifkan notifikasi otomatis untuk komunikasi berbasis tag. Ini adalah praktik terbaik untuk menggunakan strategi penandaan yang sama untuk tag kontak di semua instans dan sumber daya Anda.
catatan
Nilai kuncinya OwnerTeamEmail tidak harus dalam kasus unta. Namun, tag peka huruf besar/kecil dan praktik terbaik adalah menggunakan format yang disarankan.
Alamat email harus ditentukan secara lengkap, dengan tanda “at” (@) untuk memisahkan bagian lokal dari domain. Contoh alamat email yang tidak valid: Team.AppATabc.xyz atau. john.doe Untuk panduan umum tentang strategi penandaan Anda, lihat AWS Menandai sumber daya. Jangan menambahkan informasi identitas pribadi (PII) di tag Anda. Gunakan daftar distribusi atau alias sedapat mungkin.
Pemberitahuan peringatan berbasis tag didukung untuk sumber daya dari Layanan Amazon berikut: EC2, Elastic Block Store (EBS), Elastic Load Balancing (ELB), Application Load Balancer (ALB), Network Load Balancer, Relational Database Service (RDS),, Elastic File System (EFS),, dan VPN. OpenSearch FSx Site-to-Site
