SRE (Site Reliability Engineering) ialah pendekatan untuk memastikan ketersediaan projek web. Ia dianggap sebagai rangka kerja untuk DevOps dan bercakap tentang cara mencapai kejayaan dalam menggunakan amalan DevOps. Terjemahan dalam artikel ini Bab 6 Memantau Sistem Teragih buku Kejuruteraan Kebolehpercayaan Tapak daripada Google. Saya menyediakan terjemahan ini sendiri dan bergantung kepada pengalaman saya sendiri dalam memahami proses pemantauan. Dalam saluran telegram @monitorim_it и blog di Medium Saya juga menerbitkan pautan kepada terjemahan Bab 4 buku yang sama tentang matlamat tahap perkhidmatan.

Terjemahan oleh kucing. Selamat membaca!

Pasukan SRE Google mempunyai prinsip asas dan amalan terbaik untuk mencipta sistem pemantauan dan pemberitahuan yang berjaya. Bab ini memberikan panduan tentang masalah yang mungkin dihadapi oleh pelawat halaman web dan cara menyelesaikan masalah yang menyebabkan halaman web sukar untuk dipaparkan.

Definisi

Tiada satu perbendaharaan kata yang digunakan untuk membincangkan topik berkaitan pemantauan. Walaupun di Google, istilah di bawah tidak biasa digunakan, tetapi kami akan menyenaraikan tafsiran yang paling biasa.

Pemantauan

Pengumpulan, pemprosesan, pengagregatan dan paparan data kuantitatif dalam masa nyata tentang sistem: bilangan permintaan dan jenis permintaan, bilangan ralat dan jenis ralat, masa pemprosesan permintaan dan masa operasi pelayan.

Pemantauan kotak putih

Pemantauan berdasarkan metrik yang dipaparkan oleh komponen sistem dalaman, termasuk log, metrik pemprofilan Mesin Maya Java atau metrik pengendali HTTP yang menjana statistik dalaman.

Pemantauan kotak hitam

Menguji tingkah laku aplikasi dari sudut pandangan pengguna.

Papan pemuka

Antara muka (biasanya web) yang menyediakan gambaran keseluruhan penunjuk kesihatan utama perkhidmatan. Papan pemuka mungkin mempunyai penapis, keupayaan untuk memilih penunjuk yang ditunjukkan, dsb. Antara muka direka untuk mengenal pasti penunjuk yang paling penting kepada pengguna. Papan pemuka juga boleh memaparkan maklumat untuk kakitangan sokongan teknikal: barisan permintaan, senarai ralat keutamaan tinggi, dan jurutera yang ditugaskan untuk bidang tanggungjawab tertentu.

Makluman (pemberitahuan)

Pemberitahuan yang bertujuan untuk diterima oleh seseorang melalui e-mel atau cara lain, yang mungkin dicetuskan oleh ralat atau peningkatan dalam baris gilir permintaan. Pemberitahuan dikelaskan sebagai: tiket, makluman e-mel dan mesej pesanan segera.

Punca punca

Kecacatan perisian atau ralat manusia yang, setelah diperbetulkan, tidak sepatutnya berlaku lagi. Masalahnya mungkin mempunyai beberapa punca utama: automasi proses yang tidak mencukupi, kecacatan perisian, penghuraian logik aplikasi yang tidak mencukupi. Setiap faktor ini mungkin menjadi punca, dan setiap daripada mereka mesti dihapuskan.

Nod dan mesin (nod dan mesin)

Istilah yang boleh ditukar ganti untuk merujuk kepada satu contoh aplikasi yang sedang berjalan pada pelayan fizikal, mesin maya atau bekas. Satu mesin boleh menjadi tuan rumah beberapa perkhidmatan. Perkhidmatan boleh:

• bersambung antara satu sama lain: contohnya, pelayan caching dan pelayan web;
• perkhidmatan yang tidak berkaitan pada satu perkakasan: contohnya, repositori kod dan wizard untuk sistem konfigurasi, seperti Boneka atau Chef.

Tolak

Sebarang perubahan dalam konfigurasi perisian.

Mengapa pemantauan diperlukan?

Terdapat beberapa sebab mengapa aplikasi perlu dipantau:

Analisis arah aliran jangka panjang

Seberapa besar pangkalan data dan berapa cepat ia berkembang? Bagaimanakah bilangan pengguna harian berubah?

Perbandingan prestasi

Adakah permintaan lebih pantas pada Acme Bucket of Bytes 2.72 berbanding Ajax DB 3.14? Sejauh manakah permintaan dicache selepas kemunculan nod tambahan? Adakah tapak berjalan lebih perlahan berbanding minggu lepas?

Makluman (pemberitahuan)

Ada yang rosak dan seseorang perlu memperbaikinya. Atau sesuatu akan rosak tidak lama lagi dan seseorang perlu menyemaknya tidak lama lagi.

Mencipta papan pemuka

Papan pemuka hendaklah menjawab soalan asas dan memasukkan sesuatu daripadanya "4 isyarat emas" — kelewatan (kependaman), lalu lintas (trafik), ralat (ralat) dan saiz beban (tepu).

Menjalankan analisis retrospektif (debug)

Kelewatan pemprosesan permintaan telah meningkat, tetapi apa lagi yang berlaku pada masa yang sama?
Sistem pemantauan berguna sebagai sumber data untuk sistem risikan perniagaan dan untuk memudahkan analisis insiden keselamatan. Oleh kerana buku ini memberi tumpuan kepada bidang kejuruteraan di mana SRE mempunyai kepakaran, kami tidak akan membincangkan teknik pemantauan di sini.

Pemantauan dan makluman membolehkan sistem memberitahu anda apabila ia telah rosak atau hampir rosak. Apabila sistem tidak dapat membaiki sendiri secara automatik, kami mahu manusia menganalisis amaran, menentukan sama ada masalah masih aktif, menyelesaikannya dan menentukan punca. Jika anda tidak mengaudit komponen sistem, anda tidak akan menerima makluman hanya kerana "sesuatu kelihatan agak pelik."

Membebankan seseorang dengan pemberitahuan adalah penggunaan masa pekerja yang agak mahal. Jika pekerja sedang bekerja, amaran mengganggu proses kerja. Jika pekerja berada di rumah, amaran mengganggu masa peribadi dan mungkin tidur. Apabila makluman berlaku terlalu kerap, pekerja akan menyemaknya, menangguhkannya atau mengabaikan makluman masuk. Dari semasa ke semasa mereka mengabaikan amaran sebenar, yang disembunyikan oleh kejadian bunyi. Gangguan perkhidmatan boleh bertahan untuk jangka masa yang lama kerana kejadian bunyi menghalang masalah daripada didiagnosis dan dibetulkan dengan cepat. Sistem amaran yang berkesan mempunyai nisbah isyarat-ke-bunyi yang baik.

Menetapkan jangkaan yang munasabah untuk sistem pemantauan

Menyediakan pemantauan untuk aplikasi yang kompleks adalah tugas kejuruteraan yang kompleks itu sendiri. Walaupun dengan infrastruktur pengumpulan, paparan dan alatan peringatan yang ketara, pasukan Google SRE yang terdiri daripada 10–12 ahli lazimnya merangkumi satu atau dua orang yang tujuan utamanya adalah untuk membina dan menyelenggara sistem pemantauan. Jumlah ini telah berkurangan dari semasa ke semasa apabila kami menyatukan dan memusatkan infrastruktur pemantauan, tetapi setiap pasukan SRE biasanya mempunyai sekurang-kurangnya seorang yang berdedikasi semata-mata untuk pemantauan. Kita harus mengatakan bahawa walaupun papan pemuka sistem pemantauan agak menarik untuk dilihat, pasukan SRE dengan berhati-hati mengelakkan situasi yang memerlukan seseorang melihat skrin untuk memantau masalah.

Secara keseluruhannya, Google telah beralih kepada sistem pemantauan yang mudah dan pantas dengan alat analisis selepas fakta yang optimum. Kami mengelakkan sistem "sihir" yang cuba meramalkan ambang atau mengesan punca punca secara automatik. Penderia yang mengesan kandungan yang tidak diingini dalam permintaan pengguna akhir adalah satu-satunya contoh balas; Selagi penderia ini kekal mudah, ia dapat mengesan dengan cepat punca anomali yang serius. Format lain untuk menggunakan data pemantauan, seperti perancangan kapasiti atau ramalan trafik, adalah lebih kompleks. Pemerhatian dalam tempoh masa yang sangat lama (bulan atau tahun) pada kadar persampelan yang rendah (jam atau hari) akan mendedahkan arah aliran jangka panjang.

Pasukan Google SRE telah mencapai kejayaan bercampur dengan hierarki pergantungan yang kompleks. Kami jarang menggunakan peraturan seperti "jika saya mengetahui bahawa pangkalan data adalah perlahan, saya mendapat makluman bahawa pangkalan data adalah perlahan, jika tidak, saya mendapat makluman bahawa tapak itu perlahan." Peraturan berasaskan kebergantungan biasanya merujuk kepada bahagian sistem kami yang tidak berubah, seperti sistem untuk menapis trafik pengguna ke pusat data. Contohnya, "jika penapisan trafik ke pusat data dikonfigurasikan, jangan maklumkan saya tentang kelewatan dalam memproses permintaan pengguna" ialah satu peraturan am untuk makluman daripada pusat data. Beberapa pasukan di Google menyokong hierarki pergantungan yang kompleks kerana infrastruktur kami mempunyai kadar pemfaktoran semula berterusan yang berterusan.

Beberapa idea yang diterangkan dalam bab ini masih relevan: sentiasa ada peluang untuk bergerak lebih pantas daripada gejala kepada punca, terutamanya dalam sistem yang sentiasa berubah. Oleh itu, sementara bab ini menggariskan beberapa matlamat untuk sistem pemantauan dan cara mencapai matlamat tersebut, adalah penting bahawa sistem pemantauan adalah mudah dan boleh difahami oleh semua orang dalam pasukan.

Begitu juga, untuk memastikan tahap hingar rendah dan tahap isyarat tinggi, pendekatan untuk memantau aset yang dimaklumkan mestilah sangat mudah dan boleh dipercayai. Peraturan yang menjana amaran untuk orang ramai harus mudah difahami dan memberikan masalah yang jelas.

Gejala berbanding punca

Sistem pemantauan anda harus menjawab dua soalan: "apa yang rosak" dan "mengapa ia pecah."
"Apa yang pecah" bercakap tentang gejala, dan "mengapa ia pecah" bercakap tentang punca. Jadual di bawah menunjukkan contoh sambungan tersebut.

Gejala
Punca

Mendapatkan Ralat HTTP 500 atau 404
Pelayan pangkalan data menolak sambungan

Sambutan pelayan perlahan
Penggunaan CPU yang tinggi atau kabel Ethernet yang rosak

Pengguna di Antartika tidak menerima GIF kucing
CDN anda membenci saintis dan kucing, jadi beberapa alamat IP akhirnya disenaraihitamkan

Kandungan peribadi telah tersedia dari mana-mana sahaja
Pelancaran keluaran perisian baharu membuatkan tembok api melupakan semua ACL dan membenarkan semua orang masuk

"Apa" dan "mengapa" adalah beberapa blok binaan yang paling penting untuk mencipta sistem pemantauan yang baik dengan isyarat maksimum dan bunyi minimum.

Kotak hitam vs Kotak Putih

Kami menggabungkan pemantauan White-box yang meluas dengan pemantauan Black-box yang sederhana untuk metrik kritikal. Cara paling mudah untuk membandingkan Black-box dengan White-box ialah Black-box adalah tertumpu kepada simptom dan reaktif dan bukannya pemantauan proaktif: "sistem tidak berfungsi dengan betul sekarang." Kotak putih bergantung pada keupayaan pengesahan dalaman sistem: log peristiwa atau pelayan web. Oleh itu, White-box membolehkan anda mengesan masalah yang akan berlaku, kesalahan yang kelihatan seperti penghantaran semula permintaan, dsb.

Ambil perhatian bahawa dalam sistem berbilang lapisan, gejala dalam bidang tanggungjawab seorang jurutera adalah gejala dalam bidang tanggungjawab jurutera lain. Sebagai contoh, prestasi pangkalan data telah menurun. Bacaan pangkalan data yang perlahan adalah gejala SRE pangkalan data yang mengesannya. Walau bagaimanapun, untuk SRE bahagian hadapan yang memerhati tapak web yang perlahan, punca pembacaan pangkalan data yang sama adalah pangkalan data yang perlahan. Oleh itu, pemantauan kotak putih kadangkala tertumpu kepada simptom dan kadangkala tertumpu pada sebab, bergantung pada keluasannya.

Apabila mengumpul telemetri untuk penyahpepijatan, pemantauan Kotak Putih diperlukan. Jika pelayan web lambat bertindak balas kepada pertanyaan pangkalan data, anda perlu tahu seberapa cepat pelayan web berkomunikasi dengan pangkalan data dan seberapa cepat ia bertindak balas. Jika tidak, anda tidak akan dapat membezakan antara pelayan pangkalan data yang perlahan dan masalah rangkaian antara pelayan web dan pangkalan data.

Pemantauan kotak hitam mempunyai kelebihan utama apabila menghantar makluman: anda mencetuskan pemberitahuan kepada penerima apabila masalah telah mengakibatkan gejala sebenar. Sebaliknya, pemantauan tidak berguna untuk masalah Black-box yang masih belum timbul tetapi akan berlaku.

Empat isyarat emas

Empat isyarat pemantauan emas ialah kependaman, trafik, ralat dan ketepuan. Jika anda hanya boleh mengukur empat metrik sistem pengguna, fokus pada empat metrik tersebut.

Kelewatan

Masa yang diperlukan untuk memproses permintaan. Adalah penting untuk membezakan antara kependaman permintaan yang berjaya dan tidak berjaya. Sebagai contoh, ralat HTTP 500 yang disebabkan oleh kehilangan sambungan ke pangkalan data atau bahagian belakang lain boleh didiagnosis dengan cepat, namun, ralat HTTP 500 mungkin menunjukkan permintaan yang gagal. Menentukan kesan ralat 500 pada kependaman keseluruhan boleh membawa kepada kesimpulan yang salah. Sebaliknya, ralat yang perlahan adalah ralat yang cepat! Oleh itu, adalah penting untuk memantau kependaman ralat dan bukannya hanya menapis ralat.

trafik

Bilangan permintaan kepada sistem anda diukur dalam metrik sistem peringkat tinggi. Untuk perkhidmatan web, ukuran ini biasanya mewakili bilangan permintaan HTTP sesaat, dibahagikan dengan sifat permintaan (contohnya, kandungan statik atau dinamik). Untuk sistem penstriman audio, pengukuran ini mungkin memfokuskan pada kelajuan I/O rangkaian atau bilangan sesi serentak. Untuk sistem storan nilai kunci, ukuran ini boleh menjadi transaksi atau hasil carian sesaat.

Kesilapan

Ini ialah kadar permintaan gagal yang eksplisit (cth HTTP 500), tersirat (cth HTTP 200 tetapi digabungkan dengan kandungan tidak sah) atau dasar (cth "Jika anda menangkap respons dalam satu saat, mana-mana satu saat adalah ralat"). Jika kod respons HTTP tidak mencukupi untuk menyatakan semua keadaan kegagalan, protokol sekunder (dalaman) mungkin diperlukan untuk mengesan kegagalan separa. Memantau semua permintaan yang gagal sedemikian mungkin tidak bermaklumat, manakala ujian sistem hujung ke hujung akan membantu mengesan bahawa anda sedang memproses kandungan yang salah.

Ketepuan

Metrik menunjukkan betapa intensif perkhidmatan anda digunakan. Ini ialah langkah pemantauan sistem yang mengenal pasti sumber yang paling terhad (contohnya, pada sistem yang dikekang memori, menunjukkan memori, pada sistem yang dikekang I/O, menunjukkan bilangan I/O). Ambil perhatian bahawa banyak sistem merendahkan prestasi sebelum mencapai penggunaan 100%, jadi mempunyai matlamat penggunaan adalah penting.

Dalam sistem yang kompleks, ketepuan boleh dilengkapkan dengan pengukuran beban peringkat lebih tinggi: bolehkah perkhidmatan anda mengendalikan trafik berganda dengan betul, mengendalikan hanya 10% lebih trafik atau mengendalikan lebih sedikit trafik daripada yang dilakukan pada masa ini? Untuk perkhidmatan ringkas yang tidak mempunyai parameter yang mengubah kerumitan permintaan (contohnya, "Beri saya apa-apa" atau "Saya memerlukan integer monoton tunggal yang unik"), yang jarang menukar konfigurasi, nilai ujian beban statik mungkin mencukupi. Walau bagaimanapun, seperti yang dibincangkan dalam perenggan sebelumnya, kebanyakan perkhidmatan mesti menggunakan isyarat tidak langsung seperti penggunaan CPU atau lebar jalur rangkaian, yang mempunyai sempadan atas yang diketahui. Peningkatan kependaman selalunya merupakan penunjuk utama ketepuan. Mengukur masa tindak balas persentil ke-99 dalam tetingkap kecil (mis., satu minit) boleh memberikan isyarat ketepuan yang sangat awal.

Akhir sekali, ketepuan juga dikaitkan dengan ramalan tentang ketepuan yang akan datang, contohnya: "Nampaknya pangkalan data anda akan mengisi cakera keras anda dalam masa 4 jam."

Jika anda mengukur keempat-empat isyarat emas dan apabila terdapat masalah dengan salah satu metrik (atau, dalam kes ketepuan, masalah hampir), anda memaklumkan seseorang, perkhidmatan anda akan lebih kurang dilindungi oleh pemantauan.

Kebimbangan tentang "ekor" (atau instrumentasi dan prestasi)

Apabila mencipta sistem pemantauan dari awal, terdapat godaan untuk membangunkan sistem berdasarkan nilai purata: kependaman purata, penggunaan CPU purata nod, atau purata kepenuhan pangkalan data. Bahaya dua contoh terakhir adalah jelas: pemproses dan pangkalan data dilupuskan dengan cara yang sangat tidak dapat diramalkan. Perkara yang sama berlaku untuk penangguhan. Jika anda menjalankan perkhidmatan web dengan purata kependaman 100ms dengan 1000 permintaan sesaat, 1% permintaan mungkin mengambil masa 5 saat. Jika pengguna bergantung pada berbilang perkhidmatan web sedemikian, persentil ke-99 bagi satu hujung belakang dengan mudah boleh menjadi masa tindak balas median bahagian hadapan.

Cara paling mudah untuk membezakan antara purata perlahan dan ekor permintaan yang sangat perlahan adalah dengan mengumpul ukuran permintaan yang dinyatakan dalam statistik (alat yang baik untuk dipaparkan ialah histogram) berbanding kependaman sebenar: berapa banyak permintaan perkhidmatan yang disampaikan mengambil masa antara 0 ms dan 10 ms, antara 10 ms dan 30 ms, antara 30 ms dan 100 ms, antara 100 ms dan 300 ms, dsb. Mengembangkan sempadan histogram secara lebih kurang eksponen (dengan faktor anggaran 3) selalunya merupakan cara mudah untuk menggambarkan taburan daripada permintaan.

Memilih tahap perincian yang sesuai untuk pengukuran

Elemen sistem yang berbeza mesti diukur pada tahap perincian yang berbeza. Sebagai contoh:

• Memantau penggunaan CPU dalam tempoh masa tidak akan menunjukkan lonjakan jangka panjang yang membawa kepada latensi tinggi.
• Sebaliknya, untuk perkhidmatan web yang menyasarkan masa henti selama tidak lebih daripada 9 jam setahun (99,9% masa operasi tahunan), menyemak respons HTTP 200 lebih daripada sekali atau dua kali seminit berkemungkinan tidak semestinya kerap dilakukan.
• Begitu juga, menyemak ruang cakera keras untuk ketersediaan 99,9% lebih daripada sekali setiap 1-2 minit mungkin tidak diperlukan.

Berhati-hati dalam cara anda menstrukturkan kebutiran ukuran anda. Mengumpul beban CPU sekali sesaat boleh memberikan data yang menarik, tetapi pengukuran kerap sedemikian boleh menjadi sangat mahal untuk mengumpul, menyimpan dan menganalisis. Jika matlamat pemantauan anda memerlukan butiran yang tinggi dan tidak memerlukan responsif yang tinggi, anda boleh mengurangkan kos ini dengan menyediakan pengumpulan metrik pada pelayan dan kemudian menyediakan sistem luaran untuk mengumpul dan mengagregatkan metrik tersebut. Bolehkah awak:

1. Ukur beban CPU setiap saat.
2. Kurangkan perincian kepada 5%.
3. Agregat metrik setiap minit.

Strategi ini akan membolehkan anda mengumpul data pada butiran yang tinggi tanpa memerlukan analisis yang tinggi dan overhed storan.

Semudah mungkin, tetapi tidak lebih mudah

Tindanan keperluan yang berbeza di atas satu sama lain boleh menghasilkan sistem pemantauan yang sangat kompleks. Sebagai contoh, sistem anda mungkin mempunyai elemen yang merumitkan berikut:

• Makluman mengikut ambang yang berbeza untuk kependaman pemprosesan permintaan, dalam persentil yang berbeza, untuk semua jenis penunjuk yang berbeza.
• Menulis kod tambahan untuk mengesan dan mengenal pasti punca yang mungkin.
• Cipta papan pemuka yang berkaitan untuk setiap kemungkinan punca masalah.

Sumber komplikasi yang berpotensi tidak pernah berakhir. Seperti semua sistem perisian, pemantauan boleh menjadi sangat kompleks sehingga menjadi rapuh dan sukar untuk diubah dan diselenggara.

Oleh itu, reka bentuk sistem pemantauan anda untuk memudahkannya sebaik mungkin. Apabila memilih perkara untuk dijejaki, ingat perkara berikut:

• Peraturan yang paling kerap menangkap kejadian sebenar hendaklah semudah, boleh diramal dan boleh dipercayai yang mungkin.
• Konfigurasi untuk pengumpulan data, pengagregatan dan makluman yang jarang dilakukan (contohnya, kurang daripada suku tahunan untuk beberapa pasukan SRE) harus dialih keluar.
• Metrik yang dikumpul tetapi tidak ditunjukkan dalam mana-mana papan pemuka pratonton atau digunakan oleh mana-mana makluman adalah calon untuk dipadamkan.

Di Google, pengumpulan dan pengagregatan metrik asas, digabungkan dengan makluman dan papan pemuka, berfungsi dengan baik sebagai sistem yang agak berdiri sendiri (sistem pemantauan Google sebenarnya dipecahkan kepada beberapa subsistem, tetapi orang biasanya mengetahui semua aspek subsistem ini). Ia mungkin menggoda untuk menggabungkan pemantauan dengan teknik lain untuk memeriksa sistem yang kompleks: pemprofilan sistem terperinci, proses penyahpepijatan, butiran penjejakan tentang pengecualian atau kegagalan, ujian beban, pengumpulan dan analisis log, atau pemeriksaan trafik. Walaupun kebanyakan perkara ini mempunyai persamaan dengan pemantauan asas, mencampurkannya akan menghasilkan terlalu banyak hasil dan mewujudkan sistem yang kompleks dan rapuh. Seperti banyak aspek pembangunan perisian yang lain, menyokong sistem yang berbeza dengan titik penyepaduan yang jelas, mudah dan longgar adalah strategi terbaik (contohnya, menggunakan API web untuk mendapatkan data agregat dalam format yang boleh kekal konsisten dalam jangka masa yang panjang. ).

Mengikat Prinsip Bersama

Prinsip yang dibincangkan dalam bab ini boleh digabungkan menjadi satu falsafah pemantauan dan amaran yang disahkan dan diikuti oleh pasukan Google SRE. Mematuhi falsafah pemantauan ini adalah wajar, merupakan titik permulaan yang baik untuk mencipta atau menyemak metodologi amaran anda, dan boleh membantu anda bertanya soalan yang betul tentang fungsi operasi anda, tanpa mengira saiz organisasi anda atau kerumitan perkhidmatan atau sistem.

Apabila membuat peraturan pemantauan dan amaran, bertanya soalan berikut boleh membantu anda mengelakkan positif palsu dan makluman yang tidak perlu:

• Adakah peraturan ini mengesan keadaan sistem yang tidak dapat dikesan yang mendesak, seruan untuk bertindak dan tidak dapat dielakkan memberi kesan kepada pengguna?
• Bolehkah saya mengabaikan amaran ini, kerana mengetahui bahawa ia adalah jinak? Bila dan mengapa saya boleh mengabaikan amaran ini dan bagaimana saya boleh mengelakkan senario ini?
• Adakah makluman ini bermakna pengguna mendapat kesan negatif? Adakah terdapat situasi di mana pengguna tidak terjejas secara negatif, seperti melalui penapisan trafik atau semasa menggunakan sistem ujian yang mana makluman harus ditapis?
• Bolehkah saya mengambil tindakan sebagai tindak balas kepada makluman ini? Adakah langkah-langkah ini segera atau bolehkah mereka menunggu sehingga pagi? Bolehkah tindakan diautomasikan dengan selamat? Adakah tindakan ini akan menjadi penyelesaian jangka panjang atau penyelesaian jangka pendek?
• Sesetengah orang mendapat berbilang makluman untuk isu ini, jadi adakah cara untuk mengurangkan bilangan makluman?

Soalan-soalan ini mencerminkan falsafah asas mengenai amaran dan sistem amaran:

• Setiap kali amaran masuk, saya perlu bertindak balas dengan segera. Saya boleh bertindak balas dengan segera beberapa kali sehari sebelum saya letih.
• Setiap makluman mestilah berkaitan.
• Setiap tindak balas kepada amaran mesti memerlukan campur tangan manusia. Jika pemberitahuan boleh diproses secara automatik, ia tidak sepatutnya tiba.
• Makluman hendaklah mengenai masalah atau peristiwa baharu yang tidak wujud sebelum ini.

Pendekatan ini mengaburkan perbezaan tertentu: jika amaran memenuhi empat syarat sebelumnya, tidak kira sama ada amaran dihantar daripada sistem pemantauan Kotak Putih atau Kotak Hitam. Pendekatan ini juga mengukuhkan perbezaan tertentu: adalah lebih baik untuk menghabiskan lebih banyak usaha untuk mengenal pasti gejala daripada sebab; apabila ia datang kepada punca, anda hanya perlu bimbang tentang punca yang tidak dapat dielakkan.

Pemantauan jangka panjang

Dalam persekitaran produktiviti hari ini, sistem pemantauan memantau sistem pengeluaran yang sentiasa berkembang dengan seni bina perisian yang berubah, ciri beban kerja dan sasaran prestasi. Makluman yang sukar untuk diautomasikan pada masa ini mungkin menjadi perkara biasa, malah mungkin perlu ditangani. Pada ketika ini, seseorang mesti mencari dan menghapuskan punca masalah; jika resolusi sedemikian tidak mungkin, tindak balas kepada amaran memerlukan automasi penuh.

Adalah penting bahawa keputusan pemantauan dibuat dengan mengambil kira matlamat jangka panjang. Setiap makluman yang dijalankan hari ini mengalihkan perhatian seseorang daripada menambah baik sistem esok, jadi selalunya terdapat pengurangan dalam ketersediaan atau prestasi sistem yang produktif untuk masa yang diperlukan untuk menambah baik sistem pemantauan dalam jangka panjang. Mari kita lihat dua contoh untuk menggambarkan fenomena ini.

Bigtable SRE: Kisah Terlalu Awas

Infrastruktur dalaman Google biasanya diperuntukkan dan diukur berdasarkan tahap perkhidmatan (SLO). Bertahun-tahun yang lalu, perkhidmatan SLO Bigtable adalah berdasarkan prestasi purata transaksi sintetik yang mensimulasikan pelanggan langsung. Disebabkan isu dalam Bigtable dan tahap tindanan storan yang lebih rendah, prestasi purata didorong oleh ekor "besar": 5% pertanyaan terburuk selalunya jauh lebih perlahan daripada yang lain.

Pemberitahuan e-mel telah dihantar apabila ambang SLO didekati, dan makluman messenger telah dihantar apabila SLO telah melebihi. Kedua-dua jenis makluman dihantar agak kerap, memakan masa kejuruteraan yang tidak boleh diterima: pasukan menghabiskan banyak masa mengisih makluman untuk mencari beberapa makluman yang sebenarnya berkaitan. Kami sering terlepas isu yang sebenarnya menjejaskan pengguna kerana hanya beberapa makluman adalah untuk isu khusus itu. Banyak makluman tidak mendesak kerana masalah yang boleh difahami dalam infrastruktur dan diproses dengan cara standard, atau tidak diproses langsung.

Untuk membetulkan keadaan, pasukan mengambil pendekatan serampang tiga mata: Sambil bekerja keras untuk meningkatkan prestasi Bigtable, kami menetapkan matlamat SLO buat sementara waktu untuk menjadi persentil ke-75 untuk kependaman respons pertanyaan. Kami juga mematikan makluman e-mel kerana terdapat banyak daripadanya sehingga mustahil untuk meluangkan masa untuk mendiagnosisnya.

Strategi ini membolehkan kami ruang bernafas untuk mula membetulkan isu jangka panjang dalam Bigtable dan peringkat bawah tindanan storan, dan bukannya sentiasa membetulkan isu taktikal. Jurutera sebenarnya boleh menyelesaikan kerja tanpa dihujani dengan amaran sepanjang masa. Akhirnya, penangguhan sementara pemprosesan makluman membolehkan kami meningkatkan kualiti perkhidmatan kami.

Gmail: Respons Manusia Algoritma Boleh Diramal

Pada penubuhannya, Gmail telah dibina pada sistem pengurusan proses Workqueue yang diubah suai yang direka bentuk untuk membatch bahagian proses indeks carian. Workqueue telah disesuaikan dengan proses jangka panjang dan kemudiannya digunakan pada Gmail, tetapi beberapa pepijat dalam kod penjadual legap terbukti sangat sukar untuk diperbaiki.

Pada masa itu, pemantauan Gmail telah distrukturkan supaya makluman akan dicetuskan apabila tugasan individu dibatalkan menggunakan Workqueue. Pendekatan ini tidak sesuai, kerana walaupun pada masa itu, Gmail melaksanakan beribu-ribu tugasan, setiap satunya diberikan kepada sebahagian kecil daripada peratus pengguna kami. Kami sangat prihatin untuk menyediakan pengguna Gmail dengan pengalaman pengguna yang baik, tetapi pengendalian begitu banyak makluman tidak dapat dicapai.

Untuk menangani isu ini, Gmail SRE mencipta alat untuk membantu nyahpepijat penjadual sebaik mungkin untuk meminimumkan kesan kepada pengguna. Pasukan itu mengadakan beberapa perbincangan tentang sama ada hanya mengautomasikan keseluruhan kitaran daripada penemuan masalah melalui pemulihan sehingga penyelesaian jangka panjang ditemui, tetapi ada yang bimbang bahawa penyelesaian sedemikian akan menangguhkan penyelesaian masalah.

Ketegangan ini adalah perkara biasa dalam pasukan dan sering mencerminkan kekurangan kepercayaan dalam disiplin diri: sementara sesetengah ahli pasukan mahu memberi masa untuk pembetulan yang betul, yang lain bimbang bahawa pembetulan terakhir akan dilupakan dan pembaikan sementara akan mengambil masa selama-lamanya. Isu ini patut diberi perhatian kerana terlalu mudah untuk membetulkan masalah buat sementara waktu dan bukannya menjadikan keadaan kekal. Pengurus dan kakitangan teknikal memainkan peranan penting dalam melaksanakan pembetulan jangka panjang, menyokong dan mengutamakan pembaikan jangka panjang yang berpotensi walaupun selepas "sakit" awal reda.

Makluman yang kerap, berulang dan tindak balas algoritma harus menjadi bendera merah. Keengganan pasukan anda untuk mengautomasikan makluman ini bermakna pasukan tidak yakin bahawa mereka boleh mempercayai algoritma. Ini adalah masalah serius yang perlu ditangani.

Jangka panjang

Tema biasa memautkan contoh Bigtable dan Gmail: persaingan antara ketersediaan jangka pendek dan jangka panjang. Selalunya, usaha yang kuat boleh membantu sistem yang rapuh mencapai ketersediaan yang tinggi, tetapi laluan ini biasanya jangka pendek, penuh dengan keletihan pasukan dan pergantungan kepada sebilangan kecil ahli pasukan heroik yang sama.

Terkawal, pengurangan jangka pendek dalam ketersediaan selalunya menyakitkan, tetapi secara strategik penting untuk kestabilan jangka panjang sistem. Adalah penting untuk tidak melihat setiap amaran secara berasingan, tetapi untuk mempertimbangkan sama ada tahap keseluruhan volum amaran membawa kepada sistem yang sihat dan boleh diakses dengan betul dengan pasukan yang berdaya maju dan prognosis yang menggalakkan. Kami menganalisis statistik kekerapan amaran (biasanya dinyatakan sebagai insiden setiap syif, di mana insiden mungkin terdiri daripada berbilang insiden berkaitan) dalam laporan suku tahunan kepada pengurusan, membolehkan pembuat keputusan mempunyai pandangan berterusan tentang beban sistem amaran dan keseluruhan kesihatan pasukan.

Kesimpulan

Laluan kepada pemantauan dan amaran yang sihat adalah mudah dan jelas. Ia memberi tumpuan kepada simptom masalah yang mencetuskan amaran, dan memantau punca berfungsi sebagai bantuan kepada masalah penyahpepijatan. Memantau simptom adalah lebih mudah apabila anda berada lebih tinggi dalam timbunan yang anda kawal, walaupun pemantauan beban dan prestasi pangkalan data harus dilakukan terus pada pangkalan data itu sendiri. Pemberitahuan e-mel mempunyai kegunaan yang sangat terhad dan cenderung menjadi bising dengan mudah; sebaliknya, anda harus menggunakan papan pemuka yang memantau semua isu semasa yang mencetuskan makluman e-mel. Papan pemuka juga boleh dipasangkan dengan log peristiwa untuk menganalisis korelasi sejarah.

Dalam jangka panjang, adalah perlu untuk mencapai pusingan makluman yang berjaya tentang gejala dan masalah sebenar yang akan berlaku, menyesuaikan matlamat untuk memastikan pemantauan menyokong diagnosis pantas.

Terima kasih kerana membaca terjemahan hingga habis. Langgan saluran telegram saya tentang pemantauan @monitorim_it и blog di Medium.

Sumber: www.habr.com