SRE (Site Reliability Engineering) - pendekatan untuk memastikan ketersediaan proyek web. Ini dianggap sebagai kerangka kerja untuk DevOps dan memberitahu cara untuk berhasil dalam menerapkan praktik-praktik DevOps. Artikel ini adalah terjemahan dari Bab 6 Pemantauan Sistem Terdistribusi dari buku Rekayasa Keandalan Situs Google. Saya menyiapkan terjemahan ini sendiri dan mengandalkan pengalaman saya sendiri dalam memahami proses pemantauan. Di saluran telegram @monitorim_it dan blog di Medium, saya juga menerbitkan tautan ke terjemahan bab 4 buku yang sama tentang tujuan tingkat layanan.

Terjemahan oleh kucing. Selamat membaca!

Tim SRE Google memiliki prinsip dasar dan praktik terbaik untuk menciptakan sistem pemantauan dan pemberitahuan yang berhasil. Bab ini memberikan rekomendasi tentang masalah apa yang mungkin dihadapi pengunjung halaman web dan bagaimana menyelesaikan masalah yang membuat halaman web sulit ditampilkan.

Definisi

Tidak ada kosakata tunggal yang digunakan untuk membahas topik yang terkait dengan pemantauan. Bahkan di Google, istilah di bawah ini tidak umum digunakan, tetapi 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 server.

Pemantauan kotak putih

Pemantauan berdasarkan metrik yang ditampilkan oleh komponen internal sistem, termasuk log, profil metrik mesin virtual Java, atau HTTP handler yang menghasilkan statistik internal.

Pemantauan kotak hitam

Menguji perilaku aplikasi dari sudut pandang pengguna.

Dasbor (dasbor)

Antarmuka (biasanya web) yang menyediakan ikhtisar indikator kesehatan utama untuk layanan. Dasbor mungkin memiliki filter, kemampuan untuk memilih indikator untuk ditampilkan, dll. Antarmuka dibuat untuk mengidentifikasi indikator yang paling penting bagi pengguna. Informasi untuk staf dukungan teknis juga dapat ditampilkan di dasbor: antrian permintaan, daftar kesalahan prioritas tinggi, insinyur yang ditugaskan untuk bidang tanggung jawab tertentu.

Peringatan (pemberitahuan)

Pemberitahuan yang dirancang untuk diterima oleh seseorang melalui email atau dengan cara lain, yang dapat dimulai sebagai akibat dari kesalahan atau peningkatan dalam antrian permintaan. Pemberitahuan diklasifikasikan sebagai: tiket, peringatan email dan pesan kurir.

Penyebab root

Cacat perangkat lunak atau faktor manusia yang seharusnya tidak terjadi lagi ketika dihilangkan. Masalahnya dapat memiliki beberapa alasan utama: otomatisasi proses yang tidak mencukupi, cacat perangkat lunak, studi logika aplikasi yang tidak mencukupi. Masing-masing faktor ini dapat menjadi akar penyebab, dan masing-masing faktor tersebut harus dihilangkan.

Simpul dan mesin

Istilah yang dapat dipertukarkan untuk menunjukkan satu instance aplikasi yang berjalan pada server fisik, mesin virtual, atau wadah. Mungkin ada beberapa layanan pada satu mesin. Layanan mungkin:

• terkait satu sama lain: misalnya, server cache dan server web;
• layanan yang tidak terkait pada satu perangkat keras: misalnya, repositori kode dan panduan untuk sistem konfigurasi, seperti Wayang atau Chef .

Dorong

Setiap perubahan pada konfigurasi perangkat lunak.

Mengapa pemantauan dibutuhkan

Ada beberapa alasan mengapa aplikasi harus dipantau:

Analisis Tren Panjang

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

Perbandingan kinerja

Apakah Acme Bucket of Bytes 2.72 kueri lebih cepat dari Ajax DB 3.14? Seberapa jauh lebih baik permintaan di-cache setelah munculnya simpul tambahan? Apakah situs menjadi lebih lambat dibandingkan minggu lalu?

Peringatan (pemberitahuan)

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

Buat Dashboard

Dasbor harus menjawab pertanyaan dasar dan memasukkan beberapa "4 sinyal emas" - latensi, lalu lintas, kesalahan, dan muat (saturasi).

Melakukan analisis retrospektif (debugging)

Penundaan pemrosesan permintaan telah meningkat, dan apa lagi yang terjadi pada waktu yang bersamaan?
Sistem pemantauan bermanfaat sebagai sumber data untuk sistem intelijen bisnis dan untuk menyederhanakan analisis insiden keamanan. Karena buku ini berfokus pada bidang teknik di mana SRE memiliki keahlian, kami tidak akan membahas teknik pemantauan di sini.

Pemantauan dan peringatan membiarkan sistem memberi tahu kapan ia rusak atau akan rusak. Ketika sistem tidak dapat secara otomatis mengembalikan sendiri, kami ingin lansiran dianalisis oleh seseorang, untuk menentukan apakah masalah tersebut relevan, untuk menghilangkan dan menentukan akar masalahnya. Jika Anda tidak mengaudit komponen sistem, Anda tidak akan pernah menerima peringatan hanya karena "sesuatu tampaknya sedikit aneh."

Muatan peringatan manusia adalah penggunaan waktu karyawan yang agak mahal. Jika seorang karyawan bekerja, peringatan akan mengganggu alur kerja. Jika karyawan di rumah, pemberitahuan mengganggu waktu pribadi dan, mungkin, tidur. Ketika peringatan muncul terlalu sering, karyawan dengan cepat memindai, menunda, atau mengabaikan peringatan masuk. Dari waktu ke waktu, mereka mengabaikan peringatan nyata, yang ditutupi oleh peristiwa kebisingan. Gangguan layanan dapat bertahan lama, karena gangguan kebisingan mengganggu diagnosis cepat dan pemecahan masalah. Sistem peringatan yang efisien memiliki rasio sinyal terhadap kebisingan yang baik.

Menentukan harapan yang masuk akal dari sistem pemantauan

Menyiapkan pemantauan aplikasi yang kompleks itu sendiri merupakan tugas rekayasa yang sulit. Bahkan dengan infrastruktur alat yang signifikan untuk mengumpulkan, menampilkan dan mengingatkan, tim Google SRE dengan 10-12 anggota biasanya mencakup satu atau dua orang yang tujuan utamanya adalah menciptakan dan memelihara sistem pemantauan. Jumlah ini menurun dari waktu ke waktu karena kami menggeneralisasi dan memusatkan infrastruktur pemantauan, tetapi setiap tim SRE biasanya memiliki setidaknya satu staf pemantauan. Saya harus mengatakan bahwa meskipun cukup menarik untuk menonton dasbor sistem pemantauan, tim SRE dengan hati-hati menghindari situasi yang mengharuskan seseorang untuk melihat layar untuk memantau masalah.

Secara umum, Google beralih ke sistem pemantauan yang sederhana dan cepat dengan alat yang optimal untuk analisis pasca-faktum. Kami menghindari sistem "magis" yang mencoba memprediksi ambang batas atau secara otomatis mendeteksi akar permasalahan. Sensor yang mendeteksi konten yang tidak pantas dalam permintaan pengguna akhir adalah satu-satunya contoh tandingan; selama sensor-sensor ini tetap sederhana, mereka dapat dengan cepat mengidentifikasi penyebab anomali yang serius. Format lain untuk menggunakan data pemantauan, seperti perencanaan kapasitas atau perkiraan lalu lintas, lebih menantang. Pengamatan yang dilakukan dalam waktu yang sangat lama (berbulan-bulan atau bertahun-tahun) dengan laju pengambilan sampel yang rendah (jam atau hari) akan mengungkapkan tren jangka panjang.

Tim Google SRE telah bekerja dengan berbagai keberhasilan dengan hierarki ketergantungan yang kompleks. Kami jarang menggunakan aturan seperti "jika saya mengetahui bahwa basis data sudah mulai bekerja lambat, saya mendapat pemberitahuan tentang basis data yang melambat, jika tidak saya akan mendapat peringatan tentang situs yang berjalan lambat." Aturan berbasis ketergantungan biasanya berlaku untuk bagian yang tidak berubah-ubah dari sistem kami, seperti sistem untuk memfilter lalu lintas pengguna ke pusat data. Misalnya, "jika pemfilteran lalu lintas ke pusat data dikonfigurasi, jangan peringatkan saya tentang keterlambatan dalam memproses permintaan pengguna" - ini adalah satu aturan umum untuk pemberitahuan dari pusat data. Beberapa tim di Google mendukung hierarki dependensi yang kompleks karena infrastruktur kami memiliki tingkat refactoring terus menerus yang konstan.

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

Demikian juga, untuk mempertahankan tingkat kebisingan yang rendah dan tingkat sinyal yang tinggi, pendekatan untuk memantau objek yang peringatannya dibuat harus sangat sederhana dan dapat diandalkan. Aturan yang menghasilkan peringatan bagi orang-orang harus mudah dipahami dan menghadirkan masalah yang jelas.

Gejala vs. Penyebab

Sistem pemantauan Anda harus menjawab dua pertanyaan: "apa yang rusak" dan "mengapa rusak".
"Apa yang rusak" berbicara tentang gejala, dan "mengapa itu rusak" dari penyebabnya. Tabel di bawah ini menunjukkan contoh bundel tersebut.

"Apa" dan "mengapa" adalah beberapa blok bangunan terpenting untuk menciptakan sistem pemantauan yang baik dengan sinyal maksimum dan kebisingan minimum.

Black-box vs White-box

Kami menggabungkan pemantauan Kotak Putih yang luas dengan pemantauan Kotak Hitam sederhana untuk metrik kritis. Cara termudah untuk membandingkan Black-box dengan White-box adalah bahwa Black-box berorientasi pada gejala dan reaktif daripada pemantauan proaktif: "sistem tidak berfungsi saat ini." Kotak putih tergantung pada kemampuan verifikasi sistem internal: log peristiwa atau server web. Dengan demikian, Kotak Putih memungkinkan Anda untuk mendeteksi masalah di masa depan, kegagalan fungsi yang terlihat seperti pengiriman ulang permintaan, dll.

Harap dicatat bahwa dalam sistem multilayer, gejala di bidang tanggung jawab satu insinyur adalah gejala di bidang tanggung jawab insinyur lain. Sebagai contoh, kinerja basis data telah menurun. Pembacaan basis data yang lambat adalah gejala SRE pada basis data yang mendeteksi mereka. Namun, untuk SRE front-end, yang mengamati situs web yang lambat, alasan untuk pembacaan database yang lambat adalah karena pengoperasian database yang lambat. Oleh karena itu, pemantauan White-box terkadang terfokus pada gejala, dan kadang-kadang pada alasan, tergantung pada seberapa luas itu.

Saat mengumpulkan telemetri, pemantauan White-box diperlukan untuk debugging. Jika server web merespons permintaan basis data secara perlahan, Anda perlu mengetahui seberapa cepat server web berinteraksi dengan basis data dan seberapa cepat ia merespons. Jika tidak, Anda tidak dapat membedakan server database lambat dari masalah jaringan antara server web dan database.

Pemantauan kotak hitam memiliki keuntungan utama saat mengirim peringatan: Anda memulai pemberitahuan kepada penerima ketika masalahnya sudah mengarah ke gejala nyata. Di sisi lain, untuk masalah Kotak Hitam yang belum muncul, tetapi akan datang, pemantauan tidak berguna.

Empat sinyal emas

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

Tunda

Waktu yang dibutuhkan untuk memproses permintaan. Penting untuk membedakan antara penundaan 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 dapat menunjukkan permintaan yang gagal. Mengidentifikasi efek kesalahan 500 pada keterlambatan keseluruhan dapat menyebabkan kesimpulan yang salah. Di sisi lain, kesalahan lambat bahkan merupakan kesalahan cepat! Karena itu, penting untuk melacak penundaan dengan kesalahan, dan tidak hanya memfilter kesalahan.

Lalu lintas

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

Kesalahan

Ini adalah frekuensi permintaan yang gagal yang secara eksplisit (misalnya, HTTP 500), secara implisit (misalnya, HTTP 200, tetapi dalam kombinasi dengan konten yang salah), atau kebijakan (misalnya, "Jika Anda mencatat respons dalam satu detik, salah satu detik adalah kesalahan"). Jika kode respons protokol HTTP tidak cukup untuk mengungkapkan semua kondisi kegagalan, protokol sekunder (internal) mungkin diperlukan untuk mendeteksi kegagalan parsial. Memantau semua permintaan yang salah seperti itu mungkin tidak informatif, sementara pengujian sistem ujung-ke-ujung akan membantu Anda menemukan bahwa Anda memproses konten yang salah.

Kejenuhan

Metrik menunjukkan seberapa besar layanan Anda digunakan. Ini adalah ukuran pemantauan sistem yang mengidentifikasi sumber daya yang paling terbatas (misalnya, dalam sistem dengan memori terbatas, ini menunjukkan memori, dalam sistem dengan batasan I / O, jumlah I / O ditampilkan). Perhatikan bahwa banyak sistem menurunkan kinerja sebelum mencapai pemanfaatan 100%, jadi memiliki tujuan untuk penggunaan adalah penting.

Dalam sistem yang kompleks, saturasi dapat dilengkapi dengan mengukur beban pada tingkat yang lebih tinggi: dapatkah layanan Anda menangani dua lalu lintas dengan baik, memproses hanya 10% lebih banyak lalu lintas, atau memproses lebih sedikit lalu lintas daripada saat ini? Untuk layanan sederhana yang tidak memiliki parameter yang mengubah kompleksitas permintaan (misalnya, "Beri saya apa-apa" atau "Saya perlu bilangan bulat tunggal yang unik") yang jarang mengubah konfigurasi mereka, nilai statis uji beban mungkin memadai. dibahas dalam paragraf sebelumnya, sebagian besar layanan harus menggunakan sinyal tidak langsung, seperti pemanfaatan CPU atau bandwidth jaringan, yang memiliki batas atas yang diketahui. Peningkatan latensi sering merupakan indikator utama saturasi. Mengukur waktu respons persentil ke-99 dalam jendela kecil (misalnya, satu menit) dapat memberikan sinyal saturasi yang sangat awal.

Akhirnya, saturasi juga dikaitkan dengan prediksi saturasi yang akan datang, misalnya: "Sepertinya database Anda akan mengisi hard drive Anda dalam 4 jam."

Jika Anda mengukur keempat sinyal emas dan ketika masalah muncul dengan salah satu metrik (atau, dalam kasus saturasi, hampir menjadi masalah), beri tahu orang tersebut, layanan Anda akan lebih atau kurang dipantau.

Kecemasan tentang ekor (atau instrumentasi dan kinerja)

Saat membuat sistem pemantauan dari awal, tergoda untuk mengembangkan sistem berdasarkan nilai rata-rata: latensi rata-rata, pemanfaatan CPU rata-rata node, atau rata-rata hunian basis data. Bahaya dari dua contoh terakhir jelas: prosesor dan basis data dibuang dengan cara yang sangat tidak terduga. Hal yang sama berlaku untuk penundaan. Jika Anda menjalankan layanan web dengan penundaan rata-rata 100 ms pada 1000 permintaan per detik, 1% dari permintaan mungkin memakan waktu 5 detik. Jika pengguna bergantung pada beberapa layanan web ini, persentil ke-99 dari satu backend dapat dengan mudah menjadi waktu respons antarmuka median.

Cara paling sederhana untuk membedakan antara rata-rata lambat dan "ekor" kueri yang sangat lambat adalah dengan mengumpulkan dimensi kueri yang dinyatakan dalam statistik (alat yang cocok untuk menampilkan histogram) daripada penundaan aktual: berapa banyak permintaan yang dilayani oleh layanan, yang memakan waktu antara 0 ms dan 10 ms, antara 10 ms dan 30 ms, antara 30 ms dan 100 ms, antara 100 ms dan 300 ms, dll. Memperluas batas histogram kira-kira secara eksponensial (dengan koefisien perkiraan 3) seringkali merupakan cara sederhana untuk memvisualisasikan distribusi kueri.

Memilih Level Detailing yang Tepat untuk Pengukuran

Elemen-elemen yang berbeda dari sistem harus diukur dengan berbagai tingkat detail. Sebagai contoh:

• Pemantauan pemanfaatan beban CPU pada interval waktu tertentu tidak akan menunjukkan outlier jangka panjang yang menghasilkan latensi tinggi.
• Di sisi lain, untuk layanan web yang berfokus pada tidak lebih dari 9 jam downtime per tahun (99,9% dari uptime tahunan), memeriksa respons HTTP sebesar 200 lebih dari sekali atau dua kali satu menit mungkin akan sering tidak perlu.
• Demikian pula, memeriksa ruang hard disk kosong untuk ketersediaan 99,9% lebih dari sekali setiap 1-2 menit mungkin tidak perlu.

Jaga bagaimana Anda menyusun granularitas dimensi. Frekuensi mengumpulkan beban CPU sekali dalam satu detik dapat memberikan data yang menarik, tetapi pengukuran yang sering tersebut bisa sangat mahal untuk dikumpulkan, disimpan, dan dianalisis.Jika tujuan pemantauan memerlukan granularitas tinggi dan tidak memerlukan laju reaksi yang tinggi, Anda dapat mengurangi biaya ini dengan menyiapkan pengumpulan metrik di server, lalu menyiapkan sistem eksternal untuk mengumpulkan dan mengagregasi metrik ini. Anda bisa:

1. Ukur pemanfaatan CPU setiap detik.
2. Potong detail hingga 5%.
3. Metrik agregat setiap menit.

Strategi ini akan memungkinkan data dikumpulkan dengan granularitas tinggi tanpa mengalami analisis tinggi dan overhead penyimpanan.

Sesederhana mungkin, tetapi tidak mudah

Mengenakan persyaratan yang berbeda satu sama lain dapat menyebabkan sistem pemantauan yang sangat kompleks. Misalnya, sistem Anda mungkin memiliki elemen rumit berikut:

• Lansiran menurut nilai ambang yang berbeda untuk keterlambatan dalam memproses permintaan, dalam persentil yang berbeda, untuk semua jenis indikator yang berbeda.
• Menulis kode tambahan untuk mendeteksi dan mengidentifikasi kemungkinan penyebabnya.
• Buat dasbor terkait untuk setiap kemungkinan penyebab masalah.

Sumber komplikasi potensial tidak pernah berakhir. Seperti semua sistem perangkat lunak, pemantauan dapat menjadi sangat rumit sehingga menjadi rapuh dan sulit untuk diubah dan dipelihara.

Karena itu, rancang sistem pemantauan Anda untuk menyederhanakannya sebanyak mungkin. Saat memilih apa yang akan dilacak, ingat yang berikut:

• Aturan yang paling sering menangkap insiden nyata harus sesederhana mungkin, dapat diprediksi dan dapat diandalkan.
• Konfigurasi untuk pengumpulan data, agregasi, dan peringatan yang jarang dilakukan (misalnya, kurang dari seperempat untuk beberapa perintah SRE) harus dihapus.
• , , - - , .

Di Google, pengumpulan dasar dan agregasi indikator, dikombinasikan dengan peringatan dan dasbor, berfungsi dengan baik sebagai sistem yang relatif otonom (Faktanya, sistem pemantauan Google dibagi menjadi beberapa subsistem, tetapi biasanya orang tahu tentang semua aspek dari subsistem ini). Mungkin tergoda untuk menggabungkan pemantauan dengan metode lain untuk memeriksa sistem yang kompleks: profil sistem terperinci, debugging proses, pelacakan detail tentang pengecualian atau kegagalan, pengujian beban, pengumpulan dan analisis log, atau pengecekan lalu lintas. Sementara sebagian besar dari hal-hal ini memiliki fitur umum dengan pemantauan dasar, menggabungkannya bersama-sama akan menghasilkan terlalu banyak hasil dalam menciptakan sistem yang kompleks dan rapuh. Seperti banyak aspek lain dari pengembangan perangkat lunak, dukungan untuk berbagai sistem jelas, sederhana,poin integrasi yang digabungkan secara longgar adalah strategi yang lebih baik (misalnya, menggunakan API web untuk mengambil data ringkasan dalam format yang dapat tetap konstan selama periode waktu yang lama).

Menghubungkan prinsip bersama

Prinsip-prinsip yang dibahas dalam bab ini dapat diintegrasikan ke dalam filosofi pemantauan dan peringatan yang didukung dan dihormati oleh tim SRE Google. Mengikuti filosofi pemantauan ini diinginkan, ini merupakan titik awal yang baik untuk membuat atau merevisi metodologi peringatan dan dapat membantu mengajukan pertanyaan yang tepat untuk layanan operasi terlepas dari ukuran organisasi Anda atau kompleksitas layanan atau sistem.

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

• Apakah aturan ini mendeteksi keadaan yang tidak terdeteksi dari sistem yang mendesak, menyerukan tindakan dan pasti mempengaruhi pengguna?
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

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

• Setiap kali peringatan tiba, saya harus segera merespons. Saya bisa bereaksi beberapa kali sehari sebelum merasa lelah.
• Setiap peringatan harus relevan.
• Setiap respons terhadap peringatan harus memerlukan intervensi manusia. Jika lansiran dapat diproses secara otomatis, peringatan itu seharusnya tidak datang.
• Lansiran harus tentang masalah atau peristiwa baru yang tidak ada sebelumnya.

Pendekatan ini menghapus perbedaan-perbedaan tertentu: jika notifikasi memenuhi empat kondisi sebelumnya, tidak masalah apakah notifikasi 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 penyebabnya; ketika datang ke alasan, Anda hanya perlu khawatir tentang alasan yang tak terhindarkan.

Pemantauan jangka panjang

Dalam lingkungan produktif saat ini, sistem pemantauan melacak sistem produktif yang terus berkembang dengan arsitektur perangkat lunak yang berubah, karakteristik muatan, dan kinerja target. Lansiran yang saat ini sulit diotomatisasi dapat menjadi kejadian yang sering, bahkan mungkin layak untuk diselesaikan. Pada titik ini, seseorang harus menemukan dan menghilangkan akar penyebab masalah; jika izin seperti itu tidak memungkinkan, respons terhadap notifikasi memerlukan otomatisasi penuh.

Penting bahwa keputusan pemantauan dibuat dengan tujuan jangka panjang dalam pikiran. Setiap peringatan yang dilakukan hari ini mengalihkan perhatian seseorang dari perbaikan sistem besok, sehingga sering kali ada penurunan ketersediaan atau produktivitas sistem produktif pada saat yang diperlukan untuk meningkatkan sistem pemantauan dalam jangka panjang. Mari kita lihat dua contoh yang menggambarkan fenomena ini.

Bigtable SRE: Alert History

Infrastruktur internal Google biasanya disediakan dan diukur berdasarkan tingkat layanan (SLO). Bertahun-tahun yang lalu, layanan SLO Bigtable didasarkan pada kinerja rata-rata dari transaksi sintetis yang mensimulasikan klien yang bekerja. Karena masalah dalam Bigtable dan pada tingkat yang lebih rendah dari tumpukan penyimpanan data, kinerja rata-rata adalah karena ekor "besar": 5% permintaan terburuk seringkali jauh lebih lambat daripada yang lain.

Pemberitahuan email dikirim saat mereka mendekati ambang SLO, dan peringatan ke messenger dikirim ketika SLO terlampaui. Kedua jenis lansiran dikirimkan cukup sering, menghabiskan waktu rekayasa yang tidak dapat diterima: tim menghabiskan banyak waktu untuk memilah lansiran untuk menemukan beberapa yang benar-benar relevan. Kami sering melewatkan masalah yang benar-benar memengaruhi pengguna, karena hanya beberapa lansiran yang khusus untuk masalah ini. Banyak peringatan tidak mendesak karena masalah yang dapat dipahami dalam infrastruktur dan bekerja dengan cara standar, atau tidak diproses sama sekali.

Untuk memperbaiki situasi, tim mengambil pendekatan tiga cabang: sambil melakukan upaya besar untuk meningkatkan kinerja Bigtable, kami sementara menetapkan persentil ke-75 sebagai target SLO kami untuk menunda respons terhadap permintaan. Kami juga mematikan peringatan email, karena ada begitu banyak dari mereka yang tidak mungkin menghabiskan waktu untuk mendiagnosisnya.

Strategi ini memungkinkan kami mengambil istirahat untuk mulai memperbaiki masalah jangka panjang di Bigtable dan tingkat yang lebih rendah dari tumpukan penyimpanan data, daripada terus-menerus memperbaiki masalah taktis. Insinyur benar-benar bisa melakukan pekerjaan ketika mereka tidak terus-menerus diserang oleh peringatan. Pada akhirnya, penundaan sementara dalam memproses pemberitahuan memungkinkan kami untuk meningkatkan kualitas layanan.

Gmail: respons yang dapat diprediksi, algoritme dari orang-orang

Pada awalnya, Gmail dibangun di atas sistem kontrol proses Workqueue yang dimodifikasi, yang dibuat untuk mengelompokkan fragmen indeks pencarian proses. Workqueue diadaptasi untuk proses yang berumur panjang dan selanjutnya diterapkan ke Gmail, tetapi beberapa kesalahan dalam kode scheduler buram ternyata sangat sulit untuk disembuhkan.

Pada saat itu, pemantauan Gmail disusun sedemikian rupa sehingga peringatan dipicu ketika tugas individu dibatalkan menggunakan Workqueue. Pendekatan ini tidak ideal, karena bahkan pada waktu itu Gmail melakukan ribuan tugas, yang masing-masing diberikan kepada sebagian kecil dari pengguna kami. Kami memastikan bahwa pengguna Gmail memiliki antarmuka pengguna yang baik, tetapi mengetahui begitu banyak peringatan tidak dapat dicapai.

Untuk mengatasi masalah ini, Gmail SRE menciptakan alat yang membantu men-debug penjadwal sebaik mungkin untuk meminimalkan dampak pada pengguna. Tim melakukan beberapa diskusi tentang apakah hanya perlu mengotomatiskan seluruh siklus dari mendeteksi masalah hingga menyelesaikannya sampai solusi jangka panjang ditemukan, tetapi beberapa dari mereka khawatir bahwa solusi seperti itu akan menunda koreksi masalah yang sebenarnya.

Ketegangan ini biasa terjadi di tim dan sering mencerminkan kurangnya kepercayaan diri dalam 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 berlangsung selamanya. Masalah ini patut mendapat perhatian, karena terlalu mudah untuk memperbaiki masalah sementara, daripada harus memperbaiki situasi secara berkelanjutan. Manajer dan staf teknis memainkan peran kunci dalam menerapkan perbaikan jangka panjang, mendukung dan memprioritaskan perbaikan jangka panjang yang potensial, bahkan ketika "rasa sakit" reda awal.

Lansiran berulang reguler dan respons algoritmik harus menjadi tanda bahaya. Keengganan tim Anda untuk mengotomatiskan peringatan tersebut berarti bahwa tim tersebut kurang percaya diri bahwa mereka dapat mempercayai algoritme. Ini adalah masalah serius yang perlu ditangani.

Dalam 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, tetapi jalur ini biasanya berumur pendek, penuh dengan kelelahan tim dan ketergantungan pada sejumlah kecil anggota tim yang sangat heroik ini.

Penurunan ketersediaan jangka pendek yang terkendali sering kali merupakan tugas yang menyakitkan tetapi secara strategis penting bagi stabilitas sistem jangka panjang. Penting untuk tidak mempertimbangkan setiap peringatan secara terpisah, tetapi untuk mempertimbangkan apakah tingkat peringatan secara keseluruhan mengarah pada sistem yang sehat dan dapat diakses dengan tim yang layak dan prognosis yang menguntungkan. Kami menganalisis statistik frekuensi peringatan (biasanya dinyatakan sebagai insiden shift, ketika sebuah insiden dapat terdiri dari beberapa insiden terkait) dalam laporan triwulanan dengan manajemen, yang memungkinkan pembuat keputusan untuk secara konstan menyajikan beban pada sistem peringatan dan keadaan umum tim.

Kesimpulan

Jalan menuju pemantauan dan peringatan yang sehat sederhana dan mudah. Ini berfokus pada gejala masalah yang dikeluarkan peringatan, dan memantau penyebabnya berfungsi sebagai bantuan untuk debug masalah. Memantau gejala semakin mudah, semakin tinggi Anda berada di tumpukan yang Anda kontrol, meskipun pemantauan beban basis data dan kinerja harus dilakukan langsung di atasnya. Pemberitahuan email memiliki manfaat yang sangat terbatas dan cenderung mudah menjadi bising; alih-alih, Anda harus menggunakan dasbor yang memantau semua masalah saat ini yang diemailkan. Dasbor juga dapat dipasangkan dengan log peristiwa untuk menganalisis korelasi historis.

Dalam jangka panjang, penting untuk mencapai pergantian lansiran yang sukses tentang gejala dan masalah nyata yang tak terhindarkan, menyesuaikan tujuan untuk memastikan bahwa pemantauan mendukung diagnosis cepat.

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