Adakah pemantauan mati? - Pemantauan sepanjang hayat

Sejak 2008, syarikat kami terlibat terutamanya dalam pengurusan infrastruktur dan sokongan teknikal sepanjang masa untuk projek web: kami mempunyai lebih daripada 400 pelanggan, iaitu kira-kira 15% daripada e-dagang Rusia. Sehubungan itu, seni bina yang sangat pelbagai disokong. Jika ada yang terjatuh, kami diwajibkan membaikinya dalam masa 15 minit. Tetapi untuk memahami bahawa kemalangan telah berlaku, anda perlu memantau projek dan bertindak balas terhadap insiden. Bagaimana untuk melakukan ini?

Saya percaya bahawa terdapat masalah dalam mengatur sistem pemantauan yang betul. Jika tiada masalah, maka ucapan saya akan terdiri daripada satu tesis: "Sila pasang Prometheus + Grafana dan pemalam 1, 2, 3." Malangnya, ia tidak berfungsi seperti itu lagi. Dan masalah utama ialah semua orang terus mempercayai sesuatu yang wujud pada tahun 2008, dari segi komponen perisian.

Mengenai organisasi sistem pemantauan, saya berani mengatakan bahawa... projek dengan pemantauan yang cekap tidak wujud. Dan keadaannya sangat teruk sehingga jika sesuatu jatuh, terdapat risiko ia tidak disedari - lagipun, semua orang pasti bahawa "semuanya dipantau."
Mungkin semuanya sedang dipantau. Tetapi bagaimana?

Kita semua telah menemui cerita seperti berikut: devops tertentu, pentadbir tertentu sedang bekerja, pasukan pembangunan datang kepada mereka dan berkata - "kami dibebaskan, kini pantau." Pantau apa? Bagaimana ia berfungsi?

OKEY. Kami memantau cara lama. Dan ia sudah berubah, dan ternyata anda memantau perkhidmatan A, yang menjadi perkhidmatan B, yang berinteraksi dengan perkhidmatan C. Tetapi pasukan pembangunan memberitahu anda: "Pasang perisian, ia harus memantau segala-galanya!"

Jadi apa yang telah berubah? - Segalanya telah berubah!

2008 Semuanya baik-baik sahaja

Terdapat beberapa pembangun, satu pelayan, satu pelayan pangkalan data. Semuanya pergi dari sini. Kami mempunyai beberapa maklumat, kami memasang zabbix, Nagios, cacti. Dan kemudian kami menetapkan makluman yang jelas pada CPU, pada operasi cakera, dan pada ruang cakera. Kami juga melakukan beberapa semakan manual untuk memastikan tapak tersebut bertindak balas dan pesanan tiba dalam pangkalan data. Dan itu sahaja - kita lebih kurang dilindungi.

Jika kita membandingkan jumlah kerja yang dilakukan oleh pentadbir untuk menyediakan pemantauan, maka 98% daripadanya adalah automatik: orang yang melakukan pemantauan mesti memahami cara memasang Zabbix, cara mengkonfigurasinya dan mengkonfigurasi amaran. Dan 2% - untuk semakan luaran: bahawa tapak bertindak balas dan membuat permintaan kepada pangkalan data, bahawa pesanan baru telah tiba.

2010 Beban semakin bertambah

Kami mula menskalakan web, menambah enjin carian. Kami ingin memastikan bahawa katalog produk mengandungi semua produk. Dan carian produk itu berfungsi. Bahawa pangkalan data berfungsi, pesanan sedang dibuat, tapak bertindak balas secara luaran dan bertindak balas daripada dua pelayan dan pengguna tidak ditendang keluar dari tapak semasa ia diimbangi semula ke pelayan lain, dsb. Terdapat lebih banyak entiti.

Selain itu, entiti yang dikaitkan dengan infrastruktur masih kekal sebagai yang terbesar dalam kepala pengurus. Masih ada idea di kepala saya bahawa orang yang melakukan pemantauan adalah orang yang akan memasang zabbix dan dapat mengkonfigurasinya.

Tetapi pada masa yang sama, kerja muncul untuk menjalankan semakan luaran, mencipta satu set skrip pertanyaan pengindeks carian, satu set skrip untuk menyemak sama ada carian berubah semasa proses pengindeksan, satu set skrip yang menyemak bahawa barangan dipindahkan ke perkhidmatan penghantaran, dsb. dan sebagainya.

Nota: Saya menulis "satu set skrip" 3 kali. Maksudnya, orang yang bertanggungjawab untuk memantau bukan lagi orang yang hanya memasang zabbix. Ini adalah orang yang mula mengekod. Tetapi tiada apa yang berubah dalam fikiran pasukan lagi.

Tetapi dunia berubah, menjadi lebih dan lebih kompleks. Lapisan virtualisasi dan beberapa sistem baharu ditambah. Mereka mula berinteraksi antara satu sama lain. Siapa kata "berbau seperti perkhidmatan mikro?" Tetapi setiap perkhidmatan masih kelihatan seperti tapak web secara individu. Kita boleh beralih kepadanya dan memahami bahawa ia menyediakan maklumat yang diperlukan dan berfungsi sendiri. Dan jika anda seorang pentadbir yang sentiasa terlibat dalam projek yang telah dibangunkan selama 5-7-10 tahun, pengetahuan ini terkumpul: tahap baharu muncul - anda menyedarinya, tahap lain muncul - anda menyedarinya...

Tetapi jarang ada yang menemani projek selama 10 tahun.

Resume Monitoringman

Katakan anda datang ke permulaan baharu yang segera mengupah 20 pembangun, menulis 15 perkhidmatan mikro, dan anda adalah pentadbir yang diberitahu: “Bina CI/CD. Tolonglah." Anda telah membina CI/CD dan tiba-tiba anda mendengar: "Sukar untuk kami bekerja dengan pengeluaran dalam "kubus", tanpa memahami cara aplikasi akan berfungsi di dalamnya. Jadikan kami kotak pasir dalam "kubus" yang sama.
Anda membuat kotak pasir dalam kiub ini. Mereka segera memberitahu anda: "Kami mahu pangkalan data peringkat yang dikemas kini setiap hari daripada pengeluaran, supaya kami memahami bahawa ia berfungsi pada pangkalan data, tetapi pada masa yang sama tidak merosakkan pangkalan data pengeluaran."

Anda hidup dalam semua ini. Terdapat 2 minggu lagi sebelum pelepasan, mereka memberitahu anda: "Sekarang mari kita pantau semua ini ..." Maksudnya. pantau infrastruktur kluster, pantau seni bina perkhidmatan mikro, pantau kerja dengan perkhidmatan luaran...

Dan rakan sekerja saya mengambil skema biasa dari kepala mereka dan berkata: "Nah, semuanya jelas di sini! Pasang program yang akan memantau semua ini.” Ya, ya: Prometheus + Grafana + pemalam.
Dan mereka menambah: "Anda mempunyai dua minggu, pastikan semuanya selamat."

Dalam banyak projek yang kita lihat, satu orang diperuntukkan untuk pemantauan. Bayangkan kita nak upah orang buat pemantauan selama 2 minggu, dan kita tulis resume untuk dia. Apakah kemahiran yang perlu dimiliki oleh orang ini, memandangkan semua yang kita katakan setakat ini?

• Dia mesti memahami pemantauan dan spesifik operasi infrastruktur besi.
• Dia mesti memahami spesifik pemantauan Kubernetes (dan semua orang mahu pergi ke "kubus", kerana anda boleh abstrak dari segala-galanya, bersembunyi, kerana pentadbir akan berurusan dengan yang lain) - sendiri, infrastrukturnya, dan memahami cara memantau aplikasi dalam.
• Dia mesti memahami bahawa perkhidmatan berkomunikasi antara satu sama lain dengan cara yang istimewa, dan mengetahui secara spesifik cara perkhidmatan berinteraksi antara satu sama lain. Sangat mungkin untuk melihat projek di mana sesetengah perkhidmatan berkomunikasi secara serentak, kerana tidak ada cara lain. Sebagai contoh, bahagian belakang pergi melalui REST, melalui gRPC ke perkhidmatan katalog, menerima senarai produk dan mengembalikannya kembali. Anda tidak boleh menunggu di sini. Dan dengan perkhidmatan lain ia berfungsi secara tak segerak. Pindahkan pesanan ke perkhidmatan penghantaran, hantar surat, dsb.
  Anda mungkin sudah berenang dari semua ini? Dan admin, yang perlu memantau ini, menjadi lebih keliru.
• Dia mesti boleh merancang dan merancang dengan betul - kerana kerja menjadi semakin banyak.
• Oleh itu, dia mesti mencipta strategi daripada perkhidmatan yang dicipta untuk memahami cara memantaunya secara khusus. Dia memerlukan pemahaman tentang seni bina projek dan pembangunannya + pemahaman tentang teknologi yang digunakan dalam pembangunan.

Mari kita ingat kes yang benar-benar biasa: sesetengah perkhidmatan dalam PHP, beberapa perkhidmatan dalam Go, beberapa perkhidmatan dalam JS. Mereka entah bagaimana bekerjasama antara satu sama lain. Di sinilah istilah "perkhidmatan mikro" berasal: terdapat begitu banyak sistem individu sehingga pembangun tidak dapat memahami projek secara keseluruhan. Satu bahagian pasukan menulis perkhidmatan dalam JS yang berfungsi sendiri dan tidak tahu bagaimana sistem lain berfungsi. Bahagian lain menulis perkhidmatan dalam Python dan tidak mengganggu cara perkhidmatan lain berfungsi; mereka terpencil di kawasan mereka sendiri. Yang ketiga ialah perkhidmatan menulis dalam PHP atau sesuatu yang lain.
Kesemua 20 orang ini dibahagikan kepada 15 perkhidmatan, dan hanya seorang admin yang mesti memahami semua ini. Berhenti! kami hanya membahagikan sistem kepada 15 perkhidmatan mikro kerana 20 orang tidak dapat memahami keseluruhan sistem.

Tetapi ia perlu dipantau entah bagaimana...

Apakah keputusannya? Akibatnya, terdapat seorang yang mengemukakan segala-galanya yang tidak dapat difahami oleh seluruh pasukan pembangun, dan pada masa yang sama dia juga mesti tahu dan dapat melakukan apa yang kami nyatakan di atas - infrastruktur perkakasan, infrastruktur Kubernetes, dll.

Apa yang boleh saya katakan... Houston, kami mempunyai masalah.

Memantau projek perisian moden adalah projek perisian itu sendiri

Daripada kepercayaan palsu bahawa pemantauan adalah perisian, kami membangunkan kepercayaan terhadap keajaiban. Tetapi keajaiban, sayangnya, tidak berlaku. Anda tidak boleh memasang zabbix dan mengharapkan semuanya berfungsi. Tidak ada gunanya memasang Grafana dan berharap semuanya akan baik-baik saja. Kebanyakan masa akan dibelanjakan untuk mengatur pemeriksaan operasi perkhidmatan dan interaksi mereka antara satu sama lain, menyemak cara sistem luaran berfungsi. Malah, 90% daripada masa akan dibelanjakan bukan untuk menulis skrip, tetapi untuk membangunkan perisian. Dan ia harus dikendalikan oleh pasukan yang memahami kerja projek.
Jika dalam keadaan ini seseorang dilemparkan ke dalam pemantauan, maka bencana akan berlaku. Itulah yang berlaku di mana-mana.

Sebagai contoh, terdapat beberapa perkhidmatan yang berkomunikasi antara satu sama lain melalui Kafka. Tempahan sampai, kami menghantar mesej tentang pesanan itu kepada Kafka. Terdapat perkhidmatan yang mendengar maklumat tentang pesanan dan menghantar barang. Terdapat perkhidmatan yang mendengar maklumat tentang pesanan dan menghantar surat kepada pengguna. Dan kemudian lebih banyak perkhidmatan muncul, dan kami mula keliru.

Dan jika anda juga memberikan ini kepada pentadbir dan pembangun pada peringkat apabila terdapat masa yang singkat sebelum keluaran, orang itu perlu memahami keseluruhan protokol ini. Itu. Projek berskala ini mengambil masa yang banyak, dan ini harus diambil kira dalam pembangunan sistem.
Tetapi selalunya, terutamanya dalam permulaan, kita melihat bagaimana pemantauan ditangguhkan sehingga kemudian. “Sekarang kami akan membuat Bukti Konsep, kami akan melancarkan dengannya, biarkan ia jatuh - kami bersedia untuk berkorban. Dan kemudian kami akan memantau semuanya.” Apabila (atau jika) projek itu mula menjana wang, perniagaan ingin menambah lebih banyak ciri - kerana ia telah mula berfungsi, jadi ia perlu dilancarkan lagi! Dan anda berada pada titik di mana anda perlu memantau semua yang terdahulu, yang tidak mengambil masa 1%, tetapi lebih banyak lagi. Lagipun, pembangun akan diperlukan untuk pemantauan, dan lebih mudah untuk membiarkan mereka bekerja pada ciri baharu. Akibatnya, ciri baharu ditulis, segala-galanya menjadi kacau, dan anda berada dalam kebuntuan yang tidak berkesudahan.

Jadi bagaimana untuk memantau projek bermula dari awal, dan apa yang perlu dilakukan jika anda mendapat projek yang perlu dipantau, tetapi anda tidak tahu di mana untuk bermula?

Pertama, anda perlu merancang.

Penyimpangan lirik: selalunya ia bermula dengan pemantauan infrastruktur. Sebagai contoh, kami mempunyai Kubernetes. Mari mulakan dengan memasang Prometheus dengan Grafana, memasang pemalam untuk memantau "kubus". Bukan sahaja pembangun, tetapi juga pentadbir mempunyai amalan malang: "Kami akan memasang pemalam ini, tetapi pemalam itu mungkin tahu cara melakukannya." Orang suka bermula dengan yang mudah dan mudah, bukannya dengan tindakan yang penting. Dan pemantauan infrastruktur adalah mudah.

Mula-mula, tentukan perkara dan cara anda ingin memantau, dan kemudian pilih alat, kerana orang lain tidak boleh memikirkan untuk anda. Dan patutkah mereka? Orang lain berfikir sendiri, tentang sistem universal - atau tidak berfikir sama sekali apabila pemalam ini ditulis. Dan hanya kerana plugin ini mempunyai 5 ribu pengguna tidak bermakna ia berguna. Mungkin anda akan menjadi yang ke-5001 hanya kerana sudah ada 5000 orang di sana sebelum ini.

Jika anda mula memantau infrastruktur dan bahagian belakang aplikasi anda berhenti bertindak balas, semua pengguna akan kehilangan sambungan dengan aplikasi mudah alih. Ralat akan muncul. Mereka akan datang kepada anda dan berkata "Aplikasi tidak berfungsi, apa yang anda lakukan di sini?" - "Kami sedang memantau." — “Bagaimanakah anda memantau jika anda tidak melihat bahawa aplikasi itu tidak berfungsi?!”

1. Saya percaya bahawa anda perlu mula memantau dengan tepat dari titik masuk pengguna. Jika pengguna tidak melihat bahawa aplikasi itu berfungsi, itu sahaja, ia adalah kegagalan. Dan sistem pemantauan harus memberi amaran tentang perkara ini terlebih dahulu.
2. Dan barulah kita boleh memantau infrastruktur. Atau lakukan secara selari. Lebih mudah dengan infrastruktur - di sini kita akhirnya boleh memasang zabbix.
3. Dan kini anda perlu pergi ke akar aplikasi untuk memahami di mana perkara tidak berfungsi.

Idea utama saya ialah pemantauan harus selari dengan proses pembangunan. Jika anda mengalih perhatian pasukan pemantau untuk tugas lain (membuat CI/CD, kotak pasir, penyusunan semula infrastruktur), pemantauan akan mula ketinggalan dan anda mungkin tidak akan mengejar pembangunan (atau lambat laun anda perlu menghentikannya).

Semuanya mengikut tahap

Ini adalah bagaimana saya melihat organisasi sistem pemantauan.

1) Tahap permohonan:

• memantau logik perniagaan aplikasi;
• memantau metrik kesihatan perkhidmatan;
• pemantauan integrasi.

2) Tahap infrastruktur:

• pemantauan tahap orkestrasi;
• pemantauan perisian sistem;
• pemantauan tahap besi.

3) Sekali lagi tahap aplikasi - tetapi sebagai produk kejuruteraan:

• mengumpul dan memantau log aplikasi;
• APM;
• menjejak.

4) Makluman:

• organisasi sistem amaran;
• organisasi sistem tugas;
• organisasi "asas pengetahuan" dan aliran kerja untuk pemprosesan insiden.

Ia adalah penting: kita mendapat amaran bukan selepas, tetapi segera! Tidak perlu melancarkan pemantauan dan "entah bagaimana nanti" mengetahui siapa yang akan menerima makluman. Lagipun, apakah tugas pemantauan: untuk memahami di mana dalam sistem ada sesuatu yang salah, dan untuk memberitahu orang yang betul mengenainya. Jika anda membiarkan ini sehingga tamat, maka orang yang betul akan tahu bahawa ada masalah hanya dengan memanggil "tiada apa-apa yang berfungsi untuk kami."

Lapisan Aplikasi - Pemantauan Logik Perniagaan

Di sini kita bercakap tentang menyemak fakta bahawa aplikasi itu berfungsi untuk pengguna.

Tahap ini perlu dilakukan semasa fasa pembangunan. Sebagai contoh, kami mempunyai Prometheus bersyarat: ia pergi ke pelayan yang melakukan semakan, menarik titik akhir dan titik akhir pergi dan menyemak API.

Apabila sering diminta memantau halaman utama untuk memastikan tapak berfungsi, pengaturcara memberikan pemegang yang boleh ditarik setiap kali mereka perlu memastikan bahawa API berfungsi. Dan pengaturcara pada masa ini masih mengambil dan menulis /api/test/helloworld
Satu-satunya cara untuk memastikan semuanya berfungsi? - Tidak!

• Membuat semakan sedemikian pada asasnya adalah tugas pembangun. Ujian unit hendaklah ditulis oleh pengaturcara yang menulis kod. Kerana jika anda membocorkannya kepada pentadbir, "Kawan, ini senarai protokol API untuk semua 25 fungsi, sila pantau semuanya!" - tiada apa yang akan berjaya.
• Jika anda mencetak "hello world", tiada siapa yang akan tahu bahawa API harus dan berfungsi. Setiap perubahan API mesti membawa kepada perubahan dalam semakan.
• Jika anda sudah menghadapi masalah sedemikian, hentikan ciri dan peruntukkan pembangun yang akan menulis semakan ini, atau menerima kerugian, terima bahawa tiada apa yang disemak dan akan gagal.

Petua Teknikal:

• Pastikan anda mengatur pelayan luaran untuk mengatur semakan - anda mesti memastikan projek anda boleh diakses oleh dunia luar.
• Atur semakan merentas keseluruhan protokol API, bukan hanya titik akhir individu.
• Buat titik akhir prometheus dengan keputusan ujian.

Lapisan aplikasi - pemantauan metrik kesihatan

Sekarang kita bercakap tentang metrik kesihatan luaran perkhidmatan.

Kami memutuskan bahawa kami memantau semua "pemegang" aplikasi menggunakan semakan luaran, yang kami panggil daripada sistem pemantauan luaran. Tetapi ini adalah "pegangan" yang "dilihat" oleh pengguna. Kami ingin memastikan bahawa perkhidmatan kami sendiri berfungsi. Terdapat cerita yang lebih baik di sini: K8s mempunyai pemeriksaan kesihatan, supaya sekurang-kurangnya "kiub" itu sendiri boleh diyakinkan bahawa perkhidmatan itu berfungsi. Tetapi separuh daripada cek yang saya lihat adalah cetakan yang sama "hello world". Itu. Jadi dia menarik sekali selepas penempatan, dia menjawab bahawa semuanya baik-baik saja - itu sahaja. Dan perkhidmatan itu, jika ia menyediakan API sendiri, mempunyai sejumlah besar titik masuk untuk API yang sama, yang juga perlu dipantau, kerana kami ingin tahu bahawa ia berfungsi. Dan kami sudah memantaunya di dalam.

Cara melaksanakan ini dengan betul secara teknikal: setiap perkhidmatan mendedahkan titik akhir tentang prestasi semasanya, dan dalam graf Grafana (atau mana-mana aplikasi lain) kami melihat status semua perkhidmatan.

• Setiap perubahan API mesti membawa kepada perubahan dalam semakan.
• Buat perkhidmatan baharu dengan segera dengan metrik kesihatan.
• Pentadbir boleh datang kepada pembangun dan bertanya "tambahkan saya beberapa ciri supaya saya memahami segala-galanya dan menambah maklumat tentang ini pada sistem pemantauan saya." Tetapi pembangun biasanya menjawab, "Kami tidak akan menambah apa-apa dua minggu sebelum keluaran."
  Biarkan pengurus pembangunan tahu bahawa akan ada kerugian sedemikian, maklumkan juga pengurusan pengurus pembangunan. Kerana apabila semuanya jatuh, seseorang masih akan memanggil dan menuntut untuk memantau "perkhidmatan yang sentiasa jatuh" (c)
• Dengan cara ini, peruntukkan pembangun untuk menulis pemalam untuk Grafana - ini akan menjadi bantuan yang baik untuk pentadbir.

Lapisan Aplikasi - Pemantauan Integrasi

Pemantauan integrasi memberi tumpuan kepada pemantauan komunikasi antara sistem kritikal perniagaan.

Sebagai contoh, terdapat 15 perkhidmatan yang berkomunikasi antara satu sama lain. Ini bukan lagi tapak yang berasingan. Itu. kami tidak boleh menarik perkhidmatan itu sendiri, dapatkan /helloworld dan faham bahawa perkhidmatan sedang berjalan. Oleh kerana perkhidmatan web pesanan mesti menghantar maklumat tentang pesanan ke bas - dari bas, perkhidmatan gudang mesti menerima mesej ini dan bekerja dengannya dengan lebih lanjut. Dan perkhidmatan pengedaran e-mel mesti memproses ini lebih jauh, dsb.

Oleh itu, kita tidak dapat memahami, mencucuk pada setiap perkhidmatan individu, bahawa semuanya berfungsi. Kerana kita mempunyai bas tertentu yang melaluinya segala-galanya berkomunikasi dan berinteraksi.
Oleh itu, peringkat ini harus menandakan peringkat perkhidmatan ujian untuk interaksi dengan perkhidmatan lain. Adalah mustahil untuk mengatur pemantauan komunikasi dengan memantau broker mesej. Jika terdapat perkhidmatan yang mengeluarkan data dan perkhidmatan yang menerimanya, apabila memantau broker kita hanya akan melihat data yang terbang dari sisi ke sisi. Walaupun kami entah bagaimana berjaya memantau interaksi data ini secara dalaman - bahawa pengeluar tertentu menyiarkan data, seseorang membacanya, aliran ini terus pergi ke Kafka - ini masih tidak akan memberi kami maklumat jika satu perkhidmatan menghantar mesej dalam satu versi , tetapi perkhidmatan lain tidak menjangkakan versi ini dan melangkaunya. Kami tidak akan tahu tentang perkara ini, kerana perkhidmatan akan memberitahu kami bahawa semuanya berfungsi.

Perkara yang saya cadangkan lakukan:

• Untuk komunikasi segerak: titik akhir membuat permintaan kepada perkhidmatan berkaitan. Itu. kami mengambil titik akhir ini, tarik skrip di dalam perkhidmatan, yang pergi ke semua titik dan berkata "Saya boleh tarik sana, dan tarik sana, saya boleh tarik sana..."
• Untuk komunikasi tak segerak: mesej masuk - titik akhir menyemak bas untuk mesej ujian dan memaparkan status pemprosesan.
• Untuk komunikasi tak segerak: mesej keluar - titik akhir menghantar mesej ujian ke bas.

Seperti yang biasa berlaku: kami mempunyai perkhidmatan yang membuang data ke dalam bas. Kami datang ke perkhidmatan ini dan meminta anda memberitahu kami tentang kesihatan integrasinya. Dan jika perkhidmatan itu perlu menghasilkan mesej di suatu tempat yang lebih jauh (WebApp), maka ia akan menghasilkan mesej ujian ini. Dan jika kami menjalankan perkhidmatan di sebelah OrderProcessing, ia mula-mula menyiarkan sesuatu yang boleh disiarkan secara bebas, dan jika terdapat beberapa perkara yang bergantung, maka ia membaca satu set mesej ujian daripada bas, memahami bahawa ia boleh memprosesnya, melaporkannya dan, jika perlu, siarkannya lebih lanjut, dan tentang perkara ini dia berkata - semuanya ok, saya masih hidup.

Selalunya kita mendengar soalan "bagaimana kita boleh menguji ini pada data pertempuran?" Sebagai contoh, kita bercakap tentang perkhidmatan pesanan yang sama. Perintah itu menghantar mesej ke gudang tempat barang dihapuskan: kami tidak boleh menguji ini pada data pertempuran, kerana "barangan saya akan dihapuskan!" Penyelesaian: Rancang keseluruhan ujian ini pada awalnya. Anda juga mempunyai ujian unit yang membuat olok-olok. Jadi, lakukan pada tahap yang lebih mendalam di mana anda mempunyai saluran komunikasi yang tidak membahayakan operasi perniagaan.

Tahap infrastruktur

Pemantauan infrastruktur adalah sesuatu yang telah lama dianggap sebagai pemantauan itu sendiri.

• Pemantauan infrastruktur boleh dan harus dilancarkan sebagai proses yang berasingan.
• Anda tidak seharusnya bermula dengan pemantauan infrastruktur pada projek yang sedang berjalan, walaupun anda benar-benar mahu. Ini adalah kesakitan untuk semua devops. "Mula-mula saya akan memantau kluster, saya akan memantau infrastruktur" - i.e. Pertama, ia akan memantau apa yang terdapat di bawah, tetapi tidak akan masuk ke dalam aplikasi. Kerana aplikasi adalah perkara yang tidak dapat difahami oleh devops. Ia telah dibocorkan kepadanya, dan dia tidak faham bagaimana ia berfungsi. Dan dia memahami infrastruktur dan bermula dengannya. Tetapi tidak - anda sentiasa perlu memantau aplikasi terlebih dahulu.
• Jangan berlebihan dengan bilangan makluman. Memandangkan kerumitan sistem moden, amaran sentiasa terbang, dan anda perlu entah bagaimana hidup dengan sekumpulan makluman ini. Dan orang yang sedang memanggil, setelah melihat seratus makluman seterusnya, akan memutuskan "Saya tidak mahu memikirkannya." Makluman hendaklah hanya memberitahu tentang perkara kritikal.

Tahap aplikasi sebagai unit perniagaan

Perkara utama:

• ELK. Ini adalah piawaian industri. Jika atas sebab tertentu anda tidak mengagregatkan log, mula melakukannya dengan segera.
• APM. APM luaran sebagai cara untuk menutup pemantauan aplikasi dengan cepat (NewRelic, BlackFire, Datadog). Anda boleh memasang perkara ini buat sementara waktu untuk sekurang-kurangnya memahami apa yang berlaku dengan anda.
• Menjejak. Dalam berpuluh-puluh perkhidmatan mikro, anda perlu mengesan segala-galanya, kerana permintaan itu tidak lagi hidup dengan sendirinya. Sangat sukar untuk ditambah kemudian, jadi lebih baik untuk segera menjadualkan pengesanan dalam pembangunan - ini adalah kerja dan utiliti pemaju. Jika anda belum melaksanakannya, laksanakannya! Lihat Jaeger/Zipkin

Memberi amaran

• Organisasi sistem pemberitahuan: dalam keadaan memantau sekumpulan perkara, harus ada sistem bersatu untuk menghantar pemberitahuan. Anda boleh di Grafana. Di Barat, semua orang menggunakan PagerDuty. Makluman hendaklah jelas (cth dari mana asalnya...). Dan adalah dinasihatkan untuk mengawal bahawa pemberitahuan diterima sama sekali
• Organisasi sistem tugas: makluman tidak boleh dihantar kepada semua orang (sama ada semua orang akan bertindak balas dalam khalayak ramai, atau tiada siapa yang akan bertindak balas). Pembangun juga perlu oncall: pastikan anda mentakrifkan bidang tanggungjawab, buat arahan yang jelas dan tulis di dalamnya siapa sebenarnya yang perlu dihubungi pada hari Isnin dan Rabu, dan siapa yang perlu dihubungi pada hari Selasa dan Jumaat (jika tidak, mereka tidak akan menghubungi sesiapa walaupun dalam peristiwa masalah besar - mereka akan takut untuk membangunkan anda atau mengganggu : orang biasanya tidak suka menelefon dan membangunkan orang lain, terutamanya pada waktu malam). Dan jelaskan bahawa meminta bantuan bukanlah penunjuk ketidakcekapan ("Saya meminta bantuan, itu bermakna saya seorang pekerja yang tidak baik"), menggalakkan permintaan untuk mendapatkan bantuan.
• Organisasi "asas pengetahuan" dan aliran kerja untuk pemprosesan insiden: untuk setiap insiden serius, bedah siasat harus dirancang, dan sebagai langkah sementara, tindakan yang akan menyelesaikan insiden itu harus direkodkan. Dan jadikan amalan bahawa peringatan berulang adalah dosa; mereka perlu diperbaiki dalam kerja kod atau infrastruktur.

Timbunan teknologi

Mari kita bayangkan bahawa timbunan kita adalah seperti berikut:

• pengumpulan data - Prometheus + Grafana;
• analisis log - ELK;
• untuk APM atau Tracing - Jaeger (Zipkin).

Pilihan pilihan tidak kritikal. Kerana jika pada mulanya anda memahami cara memantau sistem dan menulis rancangan, maka anda mula memilih alat yang sesuai dengan keperluan anda. Persoalannya ialah apa yang anda pilih untuk memantau pada mulanya. Kerana mungkin alat yang anda pilih pada mulanya tidak sesuai dengan keperluan anda sama sekali.

Beberapa perkara teknikal yang saya lihat di mana-mana kebelakangan ini:

Prometheus sedang ditolak ke dalam Kubernetes - siapa yang datang dengan ini?! Jika kluster anda ranap, apakah yang akan anda lakukan? Jika anda mempunyai kluster kompleks di dalam, maka harus ada beberapa jenis sistem pemantauan di dalam kluster, dan beberapa di luar, yang akan mengumpul data dari dalam kluster.

Di dalam kluster kami mengumpul log dan segala-galanya. Tetapi sistem pemantauan mesti berada di luar. Selalunya, dalam kluster di mana terdapat Promtheus dipasang secara dalaman, terdapat juga sistem yang melakukan pemeriksaan luaran bagi operasi tapak. Bagaimana jika sambungan anda ke dunia luar telah terputus dan aplikasi tidak berfungsi? Ternyata semuanya baik-baik saja di dalam, tetapi ia tidak memudahkan pengguna.

Penemuan

• Pemantauan pembangunan bukanlah pemasangan utiliti, tetapi pembangunan produk perisian. 98% pemantauan hari ini adalah pengekodan. Pengekodan dalam perkhidmatan, pengekodan semakan luaran, semakan perkhidmatan luaran, dan itu sahaja.
• Jangan buang masa pembangun anda untuk memantau: ia boleh mengambil masa sehingga 30% daripada kerja mereka, tetapi ia berbaloi.
• Devops, jangan risau anda tidak boleh memantau sesuatu, kerana sesetengah perkara adalah cara pemikiran yang berbeza sama sekali. Anda bukan seorang pengaturcara, dan kerja pemantauan adalah tugas mereka.
• Jika projek itu sudah berjalan dan tidak dipantau (dan anda seorang pengurus), peruntukkan sumber untuk pemantauan.
• Jika produk itu sudah dalam pengeluaran, dan anda seorang devops yang diberitahu untuk "menyediakan pemantauan" - cuba terangkan kepada pengurusan tentang apa yang saya tulis semua ini.

Ini adalah versi lanjutan laporan di persidangan Saint Highload++.

Jika anda berminat dengan idea dan pemikiran saya mengenainya dan topik yang berkaitan, maka di sini anda boleh baca saluran (I.e.

Sumber: www.habr.com