SRE (Site Reliability Engineering) adalah pendekatan untuk memastikan aksesibilitas proyek web. Ini dianggap sebagai kerangka kerja untuk DevOps dan membahas tentang cara mencapai kesuksesan dalam menerapkan praktik DevOps. Terjemahan dalam artikel ini Bab 6 Pemantauan Sistem Terdistribusi buku-buku Rekayasa Keandalan Situs dari Google. Saya menyiapkan terjemahan ini sendiri dan mengandalkan pengalaman saya sendiri dalam memahami proses pemantauan. Di saluran telegram @monitorim_it и blog di Medium Saya juga menerbitkan link ke terjemahan Bab 4 buku yang sama tentang sasaran tingkat layanan.

Terjemahan oleh kucing. Selamat membaca!

Tim SRE Google memiliki prinsip dasar dan praktik terbaik untuk menciptakan sistem pemantauan dan notifikasi yang sukses. Bab ini memberikan panduan tentang masalah apa saja yang mungkin dialami pengunjung halaman web dan cara mengatasi masalah yang membuat halaman web sulit ditampilkan.

Definisi

Tidak ada satu kosakata pun yang digunakan untuk membahas topik terkait pemantauan. Bahkan di Google, istilah di bawah ini tidak umum digunakan, namun kami akan mencantumkan interpretasi yang paling umum.

Pemantauan

Pengumpulan, pemrosesan, agregasi, dan tampilan data kuantitatif secara real time tentang sistem: jumlah permintaan dan jenis permintaan, jumlah kesalahan dan jenis kesalahan, waktu pemrosesan permintaan, dan waktu aktif server.

Pemantauan kotak putih

Pemantauan berdasarkan metrik yang ditampilkan oleh komponen sistem internal, termasuk log, metrik pembuatan profil Java Virtual Machine, atau metrik pengendali HTTP yang menghasilkan statistik internal.

Pemantauan kotak hitam

Menguji perilaku aplikasi dari sudut pandang pengguna.

Dasbor

Antarmuka (biasanya web) yang memberikan gambaran umum tentang indikator utama layanan kesehatan. Dasbor mungkin memiliki filter, kemampuan untuk memilih indikator yang ditampilkan, dll. Antarmuka dirancang untuk mengidentifikasi indikator yang paling penting bagi pengguna. Dasbor juga dapat menampilkan informasi untuk staf dukungan teknis: antrian permintaan, daftar kesalahan prioritas tinggi, dan insinyur yang ditugaskan untuk area tanggung jawab tertentu.

Peringatan (pemberitahuan)

Pemberitahuan dimaksudkan untuk diterima oleh seseorang melalui email atau cara lain, yang mungkin dipicu oleh kesalahan atau bertambahnya antrian permintaan. Pemberitahuan diklasifikasikan menjadi: tiket, peringatan email, dan pesan instan.

Akar masalah

Cacat perangkat lunak atau kesalahan manusia yang, setelah diperbaiki, tidak akan terjadi lagi. Masalahnya mungkin disebabkan oleh beberapa hal: otomatisasi proses yang tidak memadai, kerusakan perangkat lunak, elaborasi logika aplikasi yang tidak memadai. Masing-masing faktor ini mungkin menjadi akar permasalahannya, dan masing-masing faktor tersebut harus dihilangkan.

Node dan mesin (node ​​​​dan mesin)

Istilah yang dapat dipertukarkan untuk merujuk pada satu contoh aplikasi yang berjalan di server fisik, mesin virtual, atau kontainer. Satu mesin dapat menampung beberapa layanan. Layanan dapat berupa:

• terhubung satu sama lain: misalnya, server caching dan server web;
• layanan yang tidak terkait pada satu perangkat keras: misalnya, repositori kode dan wizard untuk sistem konfigurasi, seperti Wayang или Koki.

Dorong

Setiap perubahan dalam konfigurasi perangkat lunak.

Mengapa pemantauan diperlukan?

Ada beberapa alasan mengapa aplikasi perlu dipantau:

Analisis tren jangka panjang

Seberapa besar databasenya dan seberapa cepat pertumbuhannya? Bagaimana jumlah pengguna harian berubah?

Perbandingan kinerja

Apakah permintaan lebih cepat di Acme Bucket of Bytes 2.72 dibandingkan dengan Ajax DB 3.14? Seberapa baik permintaan di-cache setelah munculnya node tambahan? Apakah situs berjalan lebih lambat dibandingkan minggu lalu?

Peringatan (pemberitahuan)

Ada yang rusak dan seseorang perlu memperbaikinya. Atau sesuatu akan segera rusak dan seseorang perlu segera memeriksanya.

Membuat dasbor

Dasbor harus menjawab pertanyaan dasar dan menyertakan sesuatu darinya "4 sinyal emas" — penundaan (latensi), lalu lintas (traffic), kesalahan (error) dan ukuran beban (saturasi).

Melakukan analisis retrospektif (debugging)

Penundaan pemrosesan permintaan meningkat, namun apa lagi yang terjadi pada waktu yang sama?
Sistem pemantauan berguna sebagai sumber data untuk sistem intelijen bisnis dan untuk memfasilitasi analisis insiden keamanan. Karena buku ini berfokus pada bidang teknik yang menjadi keahlian SRE, kami tidak akan membahas teknik pemantauan di sini.

Pemantauan dan peringatan memungkinkan sistem memberi tahu Anda saat sistem rusak atau akan rusak. Ketika suatu sistem tidak dapat memperbaiki dirinya sendiri secara otomatis, kami ingin manusia menganalisis peringatan tersebut, menentukan apakah masalahnya masih aktif, menyelesaikannya, dan menentukan akar masalahnya. Jika Anda tidak mengaudit komponen sistem, Anda tidak akan pernah menerima peringatan hanya karena "ada sesuatu yang aneh".

Membebani seseorang dengan notifikasi merupakan pemborosan waktu seorang karyawan yang cukup mahal. Jika karyawan sedang bekerja, peringatan tersebut mengganggu proses kerja. Jika karyawan berada di rumah, peringatan tersebut mengganggu waktu pribadi dan mungkin tidur. Ketika peringatan muncul terlalu sering, karyawan akan mengabaikannya, menundanya, atau mengabaikan peringatan yang masuk. Dari waktu ke waktu mereka mengabaikan peringatan sebenarnya, yang ditutupi oleh kejadian kebisingan. Gangguan layanan dapat berlangsung dalam jangka waktu lama karena kebisingan menghalangi diagnosis dan perbaikan masalah dengan cepat. Sistem peringatan yang efektif mempunyai rasio signal-to-noise yang baik.

Menetapkan harapan yang masuk akal untuk sistem pemantauan

Menyiapkan pemantauan untuk aplikasi yang kompleks merupakan tugas teknis yang rumit. Bahkan dengan infrastruktur pengumpulan, tampilan, dan alat peringatan yang signifikan, tim SRE Google yang beranggotakan 10–12 orang biasanya terdiri dari satu atau dua orang yang tujuan utamanya adalah membangun dan memelihara sistem pemantauan. Jumlah ini menurun seiring berjalannya waktu seiring dengan konsolidasi dan sentralisasi infrastruktur pemantauan, namun setiap tim SRE biasanya memiliki setidaknya satu orang yang khusus melakukan pemantauan. Kami harus mengatakan bahwa meskipun dasbor sistem pemantauan cukup menarik untuk dilihat, tim SRE dengan hati-hati menghindari situasi yang mengharuskan seseorang melihat layar untuk memantau masalah.

Secara keseluruhan, Google telah beralih ke sistem pemantauan yang sederhana dan cepat dengan alat analisis setelah fakta yang optimal. Kami menghindari sistem "ajaib" yang mencoba memprediksi ambang batas atau secara otomatis mendeteksi akar permasalahan. Sensor yang mendeteksi konten yang tidak diinginkan dalam permintaan pengguna akhir adalah satu-satunya contoh tandingan; Selama sensor ini tetap sederhana, mereka dapat dengan cepat mendeteksi penyebab anomali yang serius. Format lain untuk menggunakan data pemantauan, seperti perencanaan kapasitas atau perkiraan lalu lintas, lebih kompleks. Pengamatan dalam jangka waktu yang sangat lama (bulan atau tahun) dengan tingkat pengambilan sampel yang rendah (jam atau hari) akan mengungkapkan tren jangka panjang.

Tim Google SRE mencapai kesuksesan yang beragam dengan hierarki ketergantungan yang kompleks. Kami jarang menggunakan aturan seperti “jika saya mengetahui bahwa databasenya lambat, saya mendapat peringatan bahwa databasenya lambat, jika tidak, saya mendapat peringatan bahwa situsnya lambat.” Aturan berbasis ketergantungan biasanya mengacu pada bagian sistem kami yang tidak dapat diubah, seperti sistem untuk memfilter lalu lintas pengguna ke pusat data. Misalnya, “jika pemfilteran lalu lintas ke pusat data dikonfigurasi, jangan beri tahu saya tentang penundaan dalam memproses permintaan pengguna” adalah salah satu aturan umum untuk peringatan dari pusat data. Hanya sedikit tim di Google yang mendukung hierarki ketergantungan yang kompleks karena infrastruktur kami memiliki tingkat pemfaktoran ulang yang berkelanjutan dan konstan.

Beberapa gagasan yang dijelaskan dalam bab ini masih relevan: selalu ada peluang untuk bergerak lebih cepat dari gejala ke akar permasalahan, terutama dalam sistem yang terus berubah. Oleh karena itu, meskipun bab ini menguraikan beberapa tujuan sistem pemantauan dan cara mencapai tujuan tersebut, sistem pemantauan harus sederhana dan dapat dipahami oleh semua orang di tim.

Demikian pula, untuk menjaga tingkat kebisingan tetap rendah dan tingkat sinyal tetap tinggi, pendekatan untuk memantau aset yang diperingatkan harus sangat sederhana dan dapat diandalkan. Aturan yang memberikan peringatan bagi masyarakat harus mudah dipahami dan menyajikan permasalahan yang jelas.

Gejala versus penyebab

Sistem pemantauan Anda harus menjawab dua pertanyaan: “apa yang rusak” dan “mengapa rusak.”
“Apa yang rusak” berbicara tentang gejalanya, dan “mengapa rusak” berbicara tentang penyebabnya. Tabel di bawah menunjukkan contoh hubungan tersebut.

Sebuah gejala
Menyebabkan

Mendapatkan Kesalahan HTTP 500 atau 404
Server database menolak koneksi

Respons server lambat
Penggunaan CPU yang tinggi atau kabel Ethernet rusak

Pengguna di Antartika tidak menerima GIF kucing
CDN Anda membenci ilmuwan dan kucing, sehingga beberapa alamat IP akhirnya masuk daftar hitam

Konten pribadi telah tersedia dari mana saja
Peluncuran rilis perangkat lunak baru membuat firewall melupakan semua ACL dan membiarkan semua orang masuk

“Apa” dan “mengapa” adalah beberapa elemen terpenting untuk menciptakan sistem pemantauan yang baik dengan sinyal maksimum dan kebisingan minimum.

Kotak Hitam vs Kotak Putih

Kami menggabungkan pemantauan White-box yang ekstensif dengan pemantauan Black-box sederhana untuk metrik penting. Cara termudah untuk membandingkan Black-box dengan White-box adalah bahwa Black-box berfokus pada gejala dan bersifat reaktif dibandingkan pemantauan proaktif: “sistem tidak bekerja dengan benar saat ini.” Kotak putih bergantung pada kemampuan verifikasi internal sistem: log peristiwa atau server web. Dengan demikian, White-box memungkinkan Anda mendeteksi masalah yang akan terjadi, kesalahan yang tampak seperti pengiriman ulang permintaan, dll.

Perhatikan bahwa dalam sistem multilayer, gejala di area tanggung jawab satu insinyur adalah gejala di area tanggung jawab insinyur lain. Misalnya, kinerja database mengalami penurunan. Pembacaan database yang lambat adalah gejala SRE database yang mendeteksinya. Namun, untuk SRE front-end yang mengamati situs web lambat, penyebab lambatnya pembacaan database adalah database yang lambat. Oleh karena itu, pemantauan white-box terkadang berfokus pada gejala dan terkadang berfokus pada penyebab, bergantung pada seberapa luas pemantauan tersebut.

Saat mengumpulkan telemetri untuk proses debug, pemantauan White-box diperlukan. Jika server web lambat merespons permintaan basis data, Anda perlu mengetahui seberapa cepat server web berkomunikasi dengan basis data dan seberapa cepat responsnya. Jika tidak, Anda tidak akan dapat membedakan antara server database yang lambat dan masalah jaringan antara server web dan database.

Pemantauan kotak hitam memiliki keuntungan utama saat mengirimkan peringatan: Anda memicu pemberitahuan kepada penerima ketika masalah telah menimbulkan gejala nyata. Di sisi lain, pemantauan tidak berguna untuk masalah Black-box yang belum muncul namun sudah dekat.

Empat sinyal emas

Empat sinyal pemantauan emas adalah latensi, lalu lintas, kesalahan, dan saturasi. Jika Anda hanya dapat mengukur empat metrik sistem pengguna, fokuslah pada keempat metrik tersebut.

Keterlambatan

Waktu yang diperlukan untuk memproses permintaan. Penting untuk membedakan antara latensi permintaan yang berhasil dan yang tidak berhasil. Misalnya, kesalahan HTTP 500 yang disebabkan oleh hilangnya koneksi ke database atau backend lainnya dapat didiagnosis dengan sangat cepat, namun kesalahan HTTP 500 mungkin menunjukkan permintaan yang gagal. Menentukan dampak kesalahan 500 pada latensi keseluruhan dapat menghasilkan kesimpulan yang salah. Di sisi lain, kesalahan yang lambat bahkan merupakan kesalahan yang cepat! Oleh karena itu, penting untuk memantau latensi kesalahan daripada sekadar menyaring kesalahan.

lalu lintas

Jumlah permintaan ke sistem Anda diukur dalam metrik sistem tingkat tinggi. Untuk layanan web, pengukuran ini biasanya mewakili jumlah permintaan HTTP per detik, dibagi berdasarkan sifat permintaan (misalnya, konten statis atau dinamis). Untuk sistem streaming audio, pengukuran ini mungkin berfokus pada kecepatan I/O jaringan atau jumlah sesi simultan. Untuk sistem penyimpanan nilai kunci, pengukuran ini dapat berupa transaksi atau hasil pencarian per detik.

Kesalahan

Ini adalah tingkat kegagalan permintaan yang bersifat eksplisit (misalnya HTTP 500), implisit (misalnya HTTP 200 tetapi digabungkan dengan konten yang tidak valid) atau kebijakan (misalnya "Jika Anda menangkap respons dalam satu detik, setiap detik adalah kesalahan"). Jika kode respons HTTP tidak cukup untuk menyatakan semua kondisi kegagalan, protokol sekunder (internal) mungkin diperlukan untuk mendeteksi kegagalan sebagian. Memantau semua permintaan yang gagal mungkin tidak informatif, sementara pengujian sistem menyeluruh akan membantu mendeteksi bahwa Anda memproses konten yang salah.

Kejenuhan

Metrik ini menunjukkan seberapa intensif layanan Anda digunakan. Ini adalah ukuran pemantauan sistem yang mengidentifikasi sumber daya yang paling dibatasi (misalnya, pada sistem dengan memori terbatas, menunjukkan memori, pada sistem dengan I/O terbatas, menunjukkan jumlah I/O). Perhatikan bahwa banyak sistem menurunkan kinerja sebelum mencapai pemanfaatan 100%, jadi memiliki sasaran pemanfaatan itu penting.

Dalam sistem yang kompleks, saturasi dapat dilengkapi dengan pengukuran beban tingkat yang lebih tinggi: dapatkah layanan Anda menangani lalu lintas ganda dengan baik, hanya menangani lalu lintas 10% lebih banyak, atau bahkan menangani lalu lintas lebih sedikit dibandingkan saat ini? Untuk layanan sederhana yang tidak memiliki parameter yang mengubah kompleksitas permintaan (misalnya, "Jangan beri saya apa pun" atau "Saya memerlukan bilangan bulat monotonik tunggal") yang jarang mengubah konfigurasi, nilai uji beban statis mungkin cukup. Namun, seperti yang dibahas di paragraf sebelumnya, sebagian besar layanan harus menggunakan sinyal tidak langsung seperti penggunaan CPU atau bandwidth jaringan, yang memiliki batas atas yang diketahui. Peningkatan latensi sering kali menjadi indikator utama kejenuhan. Mengukur waktu respons persentil ke-99 dalam jangka waktu kecil (misalnya, satu menit) dapat memberikan sinyal saturasi yang sangat awal.

Terakhir, saturasi juga dikaitkan dengan prediksi tentang saturasi yang akan datang, misalnya: “Sepertinya database Anda akan memenuhi hard drive Anda dalam 4 jam.”

Jika Anda mengukur keempat sinyal emas dan ketika ada masalah dengan salah satu metrik (atau, dalam kasus saturasi, hampir ada masalah), Anda memperingatkan seseorang, layanan Anda kurang lebih akan tercakup dalam pemantauan.

Kekhawatiran tentang "ekor" (atau instrumentasi dan kinerja)

Saat membuat sistem pemantauan dari awal, ada godaan untuk mengembangkan sistem berdasarkan nilai rata-rata: latensi rata-rata, rata-rata penggunaan CPU pada node, atau rata-rata kepenuhan database. Bahaya dari dua contoh terakhir sudah jelas: prosesor dan database dibuang dengan cara yang sangat tidak terduga. Hal yang sama berlaku untuk penundaan. Jika Anda menjalankan layanan web dengan latensi rata-rata 100 ms dengan 1000 permintaan per detik, 1% permintaan mungkin memerlukan waktu 5 detik. Jika pengguna bergantung pada beberapa layanan web tersebut, persentil ke-99 dari satu backend dapat dengan mudah menjadi median waktu respons frontend.

Cara termudah untuk membedakan antara permintaan rata-rata lambat dan permintaan sangat lambat adalah dengan mengumpulkan pengukuran permintaan yang dinyatakan dalam statistik (alat yang baik untuk menampilkannya adalah histogram) daripada latensi sebenarnya: berapa banyak permintaan yang dilayani layanan yang membutuhkan waktu antara 0 ms dan 10 mdtk, antara 10 mdtk dan 30 mdtk, antara 30 mdtk dan 100 mdtk, antara 100 mdtk dan 300 mdtk, dll. Memperluas batas histogram kira-kira secara eksponensial (dengan faktor perkiraan 3) seringkali merupakan cara sederhana untuk memvisualisasikan distribusi permintaan.

Memilih tingkat detail yang sesuai untuk pengukuran

Elemen sistem yang berbeda harus diukur pada tingkat detail yang berbeda. Misalnya:

• Memantau penggunaan CPU selama jangka waktu tertentu tidak akan menunjukkan lonjakan jangka panjang yang menyebabkan latensi tinggi.
• Di sisi lain, untuk layanan web yang menargetkan waktu henti tidak lebih dari 9 jam per tahun (waktu aktif tahunan 99,9%), memeriksa respons HTTP 200 lebih dari sekali atau dua kali per menit kemungkinan besar tidak perlu sering dilakukan.
• Demikian pula, memeriksa ruang hard drive untuk ketersediaan 99,9% lebih dari sekali setiap 1-2 menit mungkin tidak diperlukan.

Berhati-hatilah dalam menyusun granularitas pengukuran Anda. Mengumpulkan beban CPU sekali per detik dapat memberikan data yang menarik, namun pengukuran yang sering seperti itu bisa sangat mahal untuk dikumpulkan, disimpan, dan dianalisis. Jika sasaran pemantauan Anda memerlukan perincian tinggi dan tidak memerlukan respons yang tinggi, Anda dapat mengurangi biaya ini dengan menyiapkan pengumpulan metrik di server, lalu menyiapkan sistem eksternal untuk mengumpulkan dan mengagregasi metrik tersebut. Bisakah kamu:

1. Ukur beban CPU setiap detik.
2. Kurangi detailnya menjadi 5%.
3. Gabungkan metrik setiap menit.

Strategi ini akan memungkinkan Anda mengumpulkan data dengan tingkat granularitas tinggi tanpa menimbulkan biaya analisis dan penyimpanan yang tinggi.

Sesederhana mungkin, tapi tidak sederhana

Persyaratan yang berbeda-beda yang saling tumpang tindih dapat menghasilkan sistem pemantauan yang sangat kompleks. Misalnya, sistem Anda mungkin memiliki elemen rumit berikut:

• Peringatan berdasarkan ambang batas berbeda untuk latensi pemrosesan permintaan, dalam persentil berbeda, untuk semua jenis indikator berbeda.
• Menulis kode tambahan untuk mendeteksi dan mengidentifikasi kemungkinan penyebabnya.
• Buat dasbor terkait untuk setiap kemungkinan penyebab masalah.

Sumber potensi komplikasi tidak pernah berakhir. Seperti semua sistem perangkat lunak, pemantauan bisa menjadi begitu rumit sehingga menjadi rapuh dan sulit untuk diubah dan dipelihara.

Oleh karena itu, rancanglah sistem pemantauan Anda untuk menyederhanakannya semaksimal mungkin. Saat memilih apa yang akan dilacak, ingatlah hal berikut:

• Aturan yang paling sering menangkap kejadian nyata harus sesederhana, dapat diprediksi, dan dapat diandalkan.
• Konfigurasi pengumpulan, agregasi, dan peringatan data yang jarang dilakukan (misalnya, kurang dari triwulanan untuk beberapa tim SRE) harus dihapus.
• Metrik yang dikumpulkan tetapi tidak ditampilkan di dasbor pratinjau atau digunakan oleh peringatan apa pun merupakan kandidat untuk dihapus.

Di Google, pengumpulan dan agregasi metrik dasar, dipadukan dengan lansiran dan dasbor, berfungsi dengan baik sebagai sistem yang relatif berdiri sendiri (sistem pemantauan Google sebenarnya dipecah menjadi beberapa subsistem, namun orang biasanya mengetahui semua aspek dari subsistem ini). Mungkin tergoda untuk menggabungkan pemantauan dengan teknik lain untuk memeriksa sistem yang kompleks: pembuatan profil sistem secara terperinci, debugging proses, pelacakan detail tentang pengecualian atau kegagalan, pengujian beban, pengumpulan dan analisis log, atau inspeksi lalu lintas. Meskipun sebagian besar dari hal-hal ini memiliki kesamaan dengan pemantauan dasar, menggabungkannya akan memberikan hasil yang terlalu banyak dan menciptakan sistem yang rumit dan rapuh. Seperti banyak aspek pengembangan perangkat lunak lainnya, mendukung sistem yang berbeda dengan titik integrasi yang jelas, sederhana, dan digabungkan secara longgar adalah strategi terbaik (misalnya, menggunakan API web untuk mengambil data gabungan dalam format yang tetap konsisten dalam jangka waktu yang lama. ).

Mengikat Prinsip-Prinsip Bersama

Prinsip-prinsip yang dibahas dalam bab ini dapat digabungkan menjadi filosofi pemantauan dan peringatan yang didukung dan diikuti oleh tim SRE Google. Mematuhi filosofi pemantauan ini sangat diharapkan, merupakan titik awal yang baik untuk membuat atau merevisi metodologi peringatan Anda, dan dapat membantu Anda mengajukan pertanyaan yang tepat mengenai fungsi operasi Anda, terlepas dari ukuran organisasi Anda atau kompleksitas layanan atau sistem.

Saat membuat aturan pemantauan dan peringatan, mengajukan pertanyaan berikut dapat membantu Anda menghindari kesalahan positif dan peringatan yang tidak perlu:

• Apakah aturan ini mendeteksi keadaan sistem yang tidak terdeteksi dan mendesak, ajakan bertindak, dan pasti berdampak pada pengguna?
• Dapatkah saya mengabaikan peringatan ini karena mengetahui bahwa peringatan ini tidak berbahaya? Kapan dan mengapa saya dapat mengabaikan peringatan ini dan bagaimana cara menghindari skenario ini?
• Apakah peringatan ini berarti bahwa pengguna terkena dampak negatif? Apakah ada situasi di mana pengguna tidak terkena dampak negatif, misalnya melalui pemfilteran lalu lintas atau saat menggunakan sistem pengujian yang peringatannya harus difilter?
• Bisakah saya mengambil tindakan sebagai respons terhadap peringatan ini? Apakah langkah-langkah ini mendesak atau dapatkah ditunda hingga pagi hari? Bisakah suatu tindakan diotomatisasi dengan aman? Apakah tindakan ini akan menjadi solusi jangka panjang atau solusi jangka pendek?
• Beberapa orang mendapatkan banyak lansiran untuk masalah ini, jadi adakah cara untuk mengurangi jumlah lansiran?

Pertanyaan-pertanyaan ini mencerminkan filosofi dasar sistem peringatan dan peringatan:

• Setiap kali ada peringatan, saya harus segera bereaksi. Saya dapat bereaksi segera beberapa kali sehari sebelum saya lelah.
• Setiap peringatan harus relevan.
• Setiap respons terhadap peringatan harus memerlukan campur tangan manusia. Jika notifikasi dapat diproses secara otomatis, maka notifikasi tersebut tidak akan sampai.
• Peringatan harus mengenai masalah atau peristiwa baru yang belum pernah ada sebelumnya.

Pendekatan ini mengaburkan perbedaan tertentu: jika peringatan memenuhi empat kondisi sebelumnya, tidak masalah apakah peringatan dikirim dari sistem pemantauan White-box atau Black-Box. Pendekatan ini juga memperkuat perbedaan-perbedaan tertentu: lebih baik menghabiskan lebih banyak upaya untuk mengidentifikasi gejala daripada penyebab; jika menyangkut penyebabnya, Anda hanya perlu mengkhawatirkan penyebab yang tidak bisa dihindari.

Pemantauan jangka panjang

Dalam lingkungan produktivitas saat ini, sistem pemantauan memantau sistem produksi yang terus berkembang dengan perubahan arsitektur perangkat lunak, karakteristik beban kerja, dan target kinerja. Peringatan yang saat ini sulit untuk diotomatisasi mungkin sudah menjadi hal biasa, bahkan mungkin perlu ditangani. Pada titik ini, seseorang harus menemukan dan menghilangkan akar penyebab masalahnya; jika penyelesaian seperti itu tidak memungkinkan, respons terhadap peringatan memerlukan otomatisasi penuh.

Keputusan pemantauan harus dibuat dengan mempertimbangkan tujuan jangka panjang. Setiap peringatan yang berjalan hari ini mengalihkan perhatian seseorang dari perbaikan sistem di masa depan, sehingga sering kali terjadi penurunan ketersediaan atau kinerja sistem produktif selama waktu yang diperlukan untuk meningkatkan sistem pemantauan dalam jangka panjang. Mari kita lihat dua contoh untuk menggambarkan fenomena ini.

SRE Bigtable: Kisah Kewaspadaan Berlebihan

Infrastruktur internal Google biasanya disediakan dan diukur berdasarkan tingkat layanan (SLO). Bertahun-tahun yang lalu, SLO layanan Bigtable didasarkan pada kinerja rata-rata transaksi sintetis yang menyimulasikan klien langsung. Karena masalah di Bigtable dan tingkat tumpukan penyimpanan yang lebih rendah, kinerja rata-rata didorong oleh dampak "besar": 5% kueri terburuk sering kali jauh lebih lambat dibandingkan yang lain.

Notifikasi email dikirim saat ambang batas SLO didekati, dan peringatan messenger dikirim saat SLO terlampaui. Kedua jenis peringatan tersebut dikirim cukup sering, sehingga menghabiskan banyak waktu teknis: tim menghabiskan banyak waktu untuk memilah-milah peringatan untuk menemukan beberapa peringatan yang benar-benar relevan. Kami sering melewatkan masalah yang sebenarnya memengaruhi pengguna karena hanya beberapa peringatan yang ditujukan untuk masalah khusus tersebut. Banyak dari peringatan tersebut tidak mendesak karena masalah infrastruktur yang dapat dimengerti dan diproses dengan cara standar, atau tidak diproses sama sekali.

Untuk memperbaiki situasi ini, tim mengambil pendekatan tiga cabang: Sambil bekerja keras untuk meningkatkan kinerja Bigtable, kami untuk sementara menetapkan sasaran SLO kami menjadi persentil ke-75 untuk latensi respons kueri. Kami juga mematikan peringatan email karena jumlahnya sangat banyak sehingga tidak mungkin menghabiskan waktu untuk mendiagnosisnya.

Strategi ini memberi kami ruang untuk mulai memperbaiki masalah jangka panjang di Bigtable dan tumpukan penyimpanan di tingkat yang lebih rendah, daripada terus-menerus memperbaiki masalah taktis. Insinyur sebenarnya bisa menyelesaikan pekerjaan tanpa harus terus menerus dibombardir dengan peringatan. Pada akhirnya, menunda pemrosesan peringatan untuk sementara waktu memungkinkan kami meningkatkan kualitas layanan kami.

Gmail: Respons Manusia Algoritmik yang Dapat Diprediksi

Pada awalnya, Gmail dibangun pada sistem manajemen proses Workqueue yang dimodifikasi yang dirancang untuk memproses kumpulan potongan indeks pencarian. Workqueue disesuaikan dengan proses yang berumur panjang dan kemudian diterapkan ke Gmail, namun beberapa bug dalam kode penjadwal buram terbukti sangat sulit untuk diperbaiki.

Pada saat itu, pemantauan Gmail disusun sehingga peringatan akan terpicu ketika tugas individu dibatalkan menggunakan Workqueue. Pendekatan ini tidak ideal, karena bahkan pada saat itu, Gmail melakukan ribuan tugas, yang masing-masing tugas diberikan kepada sebagian kecil dari pengguna kami. Kami sangat prihatin dalam memberikan pengalaman pengguna yang baik kepada pengguna Gmail, namun menangani begitu banyak peringatan di luar jangkauan.

Untuk mengatasi masalah ini, Gmail SRE membuat alat untuk membantu men-debug penjadwal sebaik mungkin guna meminimalkan dampaknya terhadap pengguna. Tim melakukan beberapa diskusi tentang apakah akan mengotomatiskan seluruh siklus dari penemuan masalah hingga remediasi hingga solusi jangka panjang ditemukan, namun beberapa orang khawatir bahwa solusi seperti itu akan menunda penyelesaian masalah.

Ketegangan ini biasa terjadi dalam tim dan sering kali mencerminkan kurangnya kepercayaan terhadap disiplin diri: sementara beberapa anggota tim ingin memberikan waktu untuk perbaikan yang benar, yang lain khawatir bahwa perbaikan terakhir akan dilupakan dan perbaikan sementara akan memakan waktu lama. Masalah ini patut mendapat perhatian karena terlalu mudah untuk memperbaiki masalah sementara daripada menjadikannya permanen. Manajer dan staf teknis memainkan peran penting dalam menerapkan perbaikan jangka panjang, mendukung dan memprioritaskan perbaikan yang berpotensi jangka panjang bahkan setelah “kesulitan” awal mereda.

Peringatan yang teratur dan berulang serta respons algoritmik harus menjadi tanda bahaya. Keengganan tim Anda untuk mengotomatiskan peringatan ini berarti tim kurang yakin bahwa mereka dapat mempercayai algoritme. Ini adalah masalah serius yang perlu diatasi.

Jangka panjang

Tema umum menghubungkan contoh Bigtable dan Gmail: persaingan antara ketersediaan jangka pendek dan jangka panjang. Seringkali, upaya yang kuat dapat membantu sistem yang rapuh mencapai ketersediaan tinggi, namun jalur ini biasanya berumur pendek, penuh dengan kelelahan tim dan ketergantungan pada sejumlah kecil anggota tim heroik yang sama.

Pengurangan ketersediaan yang terkendali dan dalam jangka pendek sering kali menyakitkan, namun secara strategis penting bagi stabilitas sistem dalam jangka panjang. Penting untuk tidak melihat setiap peringatan secara terpisah, namun mempertimbangkan apakah tingkat volume peringatan secara keseluruhan menghasilkan sistem yang sehat, dapat diakses dengan baik, dengan tim yang aktif dan prognosis yang baik. Kami menganalisis statistik frekuensi peringatan (biasanya dinyatakan sebagai insiden per shift, di mana sebuah insiden dapat terdiri dari beberapa insiden terkait) dalam laporan triwulanan kepada manajemen, sehingga memungkinkan pengambil keputusan untuk terus melihat beban sistem peringatan dan kesehatan tim secara keseluruhan.

Kesimpulan

Jalan menuju pemantauan dan peringatan yang sehat sangatlah sederhana dan jelas. Ini berfokus pada gejala masalah yang memicu peringatan, dan memantau penyebabnya berfungsi sebagai bantuan untuk melakukan debug masalah. Gejala pemantauan lebih mudah semakin tinggi Anda berada di tumpukan yang Anda kendalikan, meskipun pemantauan beban dan kinerja database harus dilakukan langsung pada database itu sendiri. Notifikasi email memiliki kegunaan yang sangat terbatas dan cenderung mudah menimbulkan kebisingan; sebagai gantinya, Anda harus menggunakan dasbor yang memantau semua masalah terkini yang memicu peringatan email. Dasbor juga dapat dipasangkan dengan log peristiwa untuk menganalisis korelasi historis.

Dalam jangka panjang, kita perlu mencapai rotasi peringatan yang sukses mengenai gejala dan masalah nyata yang akan terjadi, dengan menyesuaikan tujuan untuk memastikan bahwa pemantauan mendukung diagnosis yang cepat.

Terima kasih telah membaca terjemahannya sampai akhir. Berlangganan saluran telegram saya tentang pemantauan @monitorim_it и blog di Medium.

Sumber: www.habr.com