Observabilitas operasional - Praktik Terbaik untuk Menandai Sumber Daya AWS

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

Observabilitas operasional

Observabilitas diperlukan untuk mendapatkan wawasan yang dapat ditindaklanjuti tentang kinerja lingkungan Anda dan membantu Anda mendeteksi dan menyelidiki masalah. Ini juga memiliki tujuan sekunder yang memungkinkan Anda untuk menentukan dan mengukur indikator kinerja utama (KPIs) dan tujuan tingkat layanan (SLOs) seperti uptime. Bagi sebagian besar organisasi, operasi penting KPIs adalah mean time to detect (MTTD) dan mean time to recover (MTTR) dari suatu insiden.

Sepanjang observabilitas, konteks penting, karena data dikumpulkan dan kemudian tag terkait dikumpulkan. Terlepas dari tingkat layanan, aplikasi, atau aplikasi yang Anda fokuskan, Anda dapat memfilter dan menganalisis untuk kumpulan data tertentu. Tag dapat digunakan untuk mengotomatiskan orientasi ke CloudWatch Alarm sehingga tim yang tepat dapat diperingatkan ketika ambang batas metrik tertentu dilanggar. Misalnya, kunci tag example-inc:ops:alarm-tag dan nilai di atasnya dapat menunjukkan pembuatan CloudWatch Alarm. Solusi yang menunjukkan hal ini dijelaskan dalam Gunakan tag untuk membuat dan memelihara CloudWatch alarm Amazon untuk instans Amazon EC2 .

Memiliki terlalu banyak alarm yang dikonfigurasi dapat dengan mudah membuat badai peringatan — ketika sejumlah besar alarm atau notifikasi dengan cepat membanjiri operator dan mengurangi efektivitas keseluruhan mereka sementara operator secara manual memprioritaskan dan memprioritaskan alarm individu. Konteks tambahan untuk alarm dapat disediakan dalam bentuk tag, yang berarti bahwa aturan dapat didefinisikan dalam Amazon EventBridge untuk membantu memastikan bahwa fokus diberikan pada masalah hulu daripada dependensi hilir.

Peran operasi di samping DevOps sering diabaikan, tetapi bagi banyak organisasi, tim operasi pusat masih memberikan respons pertama yang kritis di luar jam kerja normal. (Rincian lebih lanjut dapat ditemukan tentang model ini di whitepaper Operational Excellence.) Tidak seperti DevOps tim yang memiliki beban kerja, mereka biasanya tidak memiliki kedalaman pengetahuan yang sama, sehingga konteks yang disediakan tag dalam dasbor dan peringatan, dapat mengarahkannya ke runbook yang benar untuk masalah ini, atau memulai runbook otomatis (lihat posting blog Mengotomatiskan Alarm Amazon dengan). CloudWatch AWS Systems Manager