Apakah pemantauan sudah mati? — Pemantauan jangka panjang

Sejak 2008, perusahaan kami terutama bergerak dalam bidang manajemen infrastruktur dan dukungan teknis sepanjang waktu untuk proyek web: kami memiliki lebih dari 400 klien, yaitu sekitar 15% dari e-commerce Rusia. Oleh karena itu, arsitektur yang sangat beragam didukung. Jika ada yang terjatuh, kami wajib memperbaikinya dalam waktu 15 menit. Namun untuk memahami bahwa kecelakaan telah terjadi, Anda perlu memantau proyek dan merespons insiden tersebut. Bagaimana cara melakukannya?

Saya yakin ada masalah dalam mengatur sistem pemantauan yang tepat. Kalau tidak ada masalah, maka pidato saya akan terdiri dari satu tesis: “Silakan instal Prometheus + Grafana dan plugin 1, 2, 3.” Sayangnya, cara itu tidak lagi berlaku. Dan permasalahan utamanya adalah semua orang tetap percaya pada sesuatu yang ada pada tahun 2008, dari segi komponen perangkat lunak.

Mengenai pengorganisasian sistem pemantauan, saya berani mengatakan bahwa... tidak ada proyek dengan pemantauan yang kompeten. Dan situasinya sangat buruk sehingga jika ada sesuatu yang jatuh, ada risiko hal itu tidak diketahui - lagipula, semua orang yakin bahwa “semuanya diawasi”.
Mungkin semuanya sedang dipantau. Tapi bagaimana caranya?

Kita semua pernah mengalami cerita seperti berikut: pengembang tertentu, admin tertentu sedang bekerja, tim pengembangan mendatangi mereka dan berkata - “kami dibebaskan, sekarang pantau.” Pantau apa? Bagaimana itu bekerja?

OKE. Kami memantau dengan cara lama. Dan itu sudah berubah, dan ternyata Anda memantau layanan A, yang menjadi layanan B, yang berinteraksi dengan layanan C. Namun tim pengembangan memberi tahu Anda: "Instal perangkat lunak, mereka harus memantau semuanya!"

Jadi apa yang berubah? - Semuanya telah berubah!

2008 Semuanya baik-baik saja

Ada beberapa pengembang, satu server, satu server database. Semuanya dimulai dari sini. Kami punya beberapa informasi, kami menginstal zabbix, Nagios, cacti. Lalu kami menyetel peringatan yang jelas pada CPU, pada pengoperasian disk, dan pada ruang disk. Kami juga melakukan beberapa pemeriksaan manual untuk memastikan bahwa situs merespons dan pesanan masuk ke database. Selesai – kita sedikit banyak terlindungi.

Jika kita membandingkan jumlah pekerjaan yang dilakukan administrator untuk menyediakan pemantauan, maka 98% di antaranya dilakukan secara otomatis: orang yang melakukan pemantauan harus memahami cara menginstal Zabbix, cara mengonfigurasinya, dan mengonfigurasi peringatan. Dan 2% - untuk pemeriksaan eksternal: bahwa situs merespons dan membuat permintaan ke database, bahwa pesanan baru telah tiba.

2010 Bebannya semakin bertambah

Kami mulai memperluas web, menambahkan mesin pencari. Kami ingin memastikan bahwa katalog produk berisi semua produk. Dan pencarian produk itu berhasil. Bahwa database berfungsi, pesanan sedang dibuat, bahwa situs merespons secara eksternal dan merespons dari dua server dan pengguna tidak dikeluarkan dari situs saat diseimbangkan kembali ke server lain, dll. Ada lebih banyak entitas.

Terlebih lagi, entitas yang terkait dengan infrastruktur masih menjadi yang terbesar di kepala pengelola. Masih ada gambaran di kepala saya bahwa orang yang melakukan monitoring adalah orang yang akan menginstal zabbix dan dapat mengkonfigurasinya.

Namun pada saat yang sama, muncul pekerjaan untuk melakukan pemeriksaan eksternal, membuat sekumpulan skrip kueri pengindeks penelusuran, sekumpulan skrip untuk memeriksa apakah penelusuran berubah selama proses pengindeksan, sekumpulan skrip yang memeriksa apakah barang ditransfer ke layanan pengiriman, dll. dan seterusnya.

Catatan: Saya menulis “satu set skrip” 3 kali. Artinya, penanggung jawab monitoring bukan lagi yang sekadar menginstal zabbix. Ini adalah orang yang memulai coding. Namun belum ada yang berubah dalam pikiran tim.

Namun dunia sedang berubah dan menjadi semakin kompleks. Lapisan virtualisasi dan beberapa sistem baru ditambahkan. Mereka mulai berinteraksi satu sama lain. Siapa bilang “berbau seperti layanan mikro?” Namun setiap layanan tetap terlihat seperti situs web satu per satu. Kita dapat melihatnya dan memahami bahwa ini memberikan informasi yang diperlukan dan berfungsi dengan sendirinya. Dan jika Anda adalah seorang administrator yang terus-menerus terlibat dalam proyek yang telah berkembang selama 5-7-10 tahun, pengetahuan ini terakumulasi: level baru muncul - Anda menyadarinya, level lain muncul - Anda menyadarinya...

Namun jarang ada orang yang mendampingi suatu proyek selama 10 tahun.

Resume petugas pemantau

Misalkan Anda datang ke sebuah startup baru yang segera mempekerjakan 20 pengembang, menulis 15 layanan mikro, dan Anda adalah seorang admin yang diberi tahu: “Bangun CI/CD. Silakan." Anda telah membuat CI/CD dan tiba-tiba Anda mendengar: “Sulit bagi kami untuk bekerja dengan produksi dalam “kubus”, tanpa memahami bagaimana aplikasi akan bekerja di dalamnya. Jadikan kami kotak pasir di “kubus” yang sama.
Anda membuat kotak pasir di kubus ini. Mereka segera memberi tahu Anda: “Kami menginginkan database panggung yang diperbarui setiap hari dari produksi, sehingga kami memahami bahwa database tersebut berfungsi pada database, tetapi pada saat yang sama tidak merusak database produksi.”

Anda hidup dalam semua ini. Ada 2 minggu tersisa sebelum rilis, mereka memberi tahu Anda: “Sekarang mari kita pantau semua ini…” Yaitu. memantau infrastruktur cluster, memantau arsitektur layanan mikro, memantau pekerjaan dengan layanan eksternal...

Dan rekan-rekan saya mengambil alih skema yang biasa dan berkata: “Baiklah, semuanya jelas di sini! Instal program yang akan memantau semua ini.” Ya, ya: plugin Prometheus + Grafana +.
Dan mereka menambahkan: “Anda punya waktu dua minggu, pastikan semuanya aman.”

Di banyak proyek yang kami lihat, satu orang dialokasikan untuk pemantauan. Bayangkan kita ingin mempekerjakan seseorang untuk melakukan monitoring selama 2 minggu, dan kita menulis resume untuknya. Keterampilan apa yang harus dimiliki orang ini, mengingat semua yang telah kita katakan sejauh ini?

• Ia harus memahami pemantauan dan spesifik pengoperasian infrastruktur besi.
• Dia harus memahami secara spesifik pemantauan Kubernetes (dan semua orang ingin masuk ke "kuber", karena Anda dapat mengabstraksi semuanya, bersembunyi, karena admin akan menangani sisanya) - itu sendiri, infrastrukturnya, dan memahami cara memantau aplikasi di dalam.
• Ia harus memahami bahwa layanan berkomunikasi satu sama lain dengan cara yang khusus, dan mengetahui secara spesifik bagaimana layanan berinteraksi satu sama lain. Sangat mungkin untuk melihat proyek di mana beberapa layanan berkomunikasi secara sinkron, karena tidak ada cara lain. Misalnya, backend melewati REST, melalui gRPC ke layanan katalog, menerima daftar produk dan mengembalikannya. Anda tidak bisa menunggu di sini. Dan dengan layanan lain, ini bekerja secara asinkron. Transfer pesanan ke layanan pengiriman, kirim surat, dll.
  Anda mungkin sudah berenang dari semua ini? Dan admin yang perlu memantau hal ini semakin bingung.
• Ia harus mampu merencanakan dan merencanakan dengan benar – seiring dengan semakin banyaknya pekerjaan.
• Oleh karena itu, ia harus membuat strategi dari layanan yang dibuat untuk memahami cara memantaunya secara spesifik. Dia membutuhkan pemahaman tentang arsitektur proyek dan pengembangannya + pemahaman tentang teknologi yang digunakan dalam pengembangan.

Mari kita ingat kasus yang benar-benar normal: beberapa layanan menggunakan PHP, beberapa layanan menggunakan Go, beberapa layanan menggunakan JS. Mereka entah bagaimana bekerja satu sama lain. Dari sinilah istilah “layanan mikro” berasal: ada begitu banyak sistem individual sehingga pengembang tidak dapat memahami proyek secara keseluruhan. Salah satu bagian dari tim menulis layanan di JS yang bekerja sendiri dan tidak mengetahui cara kerja sistem lainnya. Bagian lainnya menulis layanan dengan Python dan tidak mengganggu cara kerja layanan lain; mereka diisolasi di areanya sendiri. Yang ketiga adalah layanan penulisan dalam PHP atau yang lainnya.
Semua 20 orang ini dibagi menjadi 15 layanan, dan hanya ada satu admin yang harus memahami semua ini. Berhenti! kami baru saja membagi sistem menjadi 15 layanan mikro karena 20 orang tidak dapat memahami keseluruhan sistem.

Tapi entah bagaimana, itu perlu diawasi...

Apa hasilnya? Akibatnya, ada satu orang yang menemukan segala sesuatu yang tidak dapat dipahami oleh seluruh tim pengembang, dan pada saat yang sama dia juga harus mengetahui dan mampu melakukan apa yang kami sebutkan di atas - infrastruktur perangkat keras, infrastruktur Kubernetes, dll.

Apa yang bisa saya katakan... Houston, kita punya masalah.

Memantau proyek perangkat lunak modern adalah proyek perangkat lunak itu sendiri

Dari keyakinan yang salah bahwa pemantauan adalah perangkat lunak, kita mengembangkan keyakinan akan keajaiban. Namun keajaiban, sayangnya, tidak terjadi. Anda tidak dapat menginstal zabbix dan mengharapkan semuanya berfungsi. Tidak ada gunanya menginstal Grafana dan berharap semuanya akan baik-baik saja. Sebagian besar waktu akan dihabiskan untuk mengatur pemeriksaan pengoperasian layanan dan interaksinya satu sama lain, memeriksa cara kerja sistem eksternal. Faktanya, 90% waktunya akan dihabiskan bukan untuk menulis skrip, tetapi untuk mengembangkan perangkat lunak. Dan sebaiknya ditangani oleh tim yang memahami pekerjaan proyek tersebut.
Jika dalam situasi ini ada satu orang yang dilempar ke dalam pengawasan, maka bencana akan terjadi. Hal itulah yang terjadi dimana-mana.

Misalnya saja ada beberapa layanan yang berkomunikasi satu sama lain melalui Kafka. Pesanan sudah sampai, kami mengirimkan pesan tentang pesanan tersebut ke Kafka. Ada layanan yang mendengarkan informasi tentang pesanan dan mengirimkan barang. Ada layanan yang mendengarkan informasi tentang pesanan dan mengirimkan surat kepada pengguna. Dan kemudian lebih banyak layanan muncul, dan kami mulai bingung.

Dan jika Anda juga memberikan ini kepada admin dan pengembang pada tahap ketika waktu tersisa sedikit sebelum rilis, orang tersebut perlu memahami keseluruhan protokol ini. Itu. Proyek sebesar ini memerlukan banyak waktu, dan hal ini harus diperhitungkan dalam pengembangan sistem.
Namun sering kali, terutama di startup, kita melihat bagaimana pemantauan ditunda hingga nanti. “Sekarang kita akan membuat Proof of Concept, kita akan meluncurkannya, membiarkannya jatuh – kita siap berkorban. Dan kemudian kami akan memantau semuanya.” Ketika (atau jika) proyek mulai menghasilkan uang, bisnis tersebut ingin menambahkan lebih banyak fitur lagi - karena proyek tersebut sudah mulai berfungsi, sehingga perlu diluncurkan lebih lanjut! Dan Anda berada pada titik di mana Anda harus terlebih dahulu memantau semua hal sebelumnya, yang tidak memakan waktu 1%, tetapi lebih banyak lagi. Dan omong-omong, pengembang akan dibutuhkan untuk memantau, dan lebih mudah membiarkan mereka mengerjakan fitur-fitur baru. Akibatnya, fitur-fitur baru ditulis, semuanya menjadi kacau, dan Anda berada dalam kebuntuan tanpa akhir.

Lalu bagaimana cara memantau suatu proyek mulai dari awal, dan apa yang harus dilakukan jika Anda mendapatkan proyek yang perlu dipantau, tetapi Anda tidak tahu harus mulai dari mana?

Pertama, Anda perlu membuat rencana.

Penyimpangan liris: seringkali dimulai dengan pemantauan infrastruktur. Misalnya, kami memiliki Kubernetes. Mari kita mulai dengan menginstal Prometheus dengan Grafana, menginstal plugin untuk memantau “kubus”. Tidak hanya pengembang, tetapi juga administrator memiliki praktik yang tidak menguntungkan: “Kami akan memasang plugin ini, tetapi plugin tersebut mungkin tahu cara melakukannya.” Orang-orang lebih suka memulai dengan hal yang sederhana dan lugas, dibandingkan dengan tindakan yang penting. Dan pemantauan infrastruktur itu mudah.

Pertama, putuskan apa dan bagaimana Anda ingin memantau, lalu pilih alat, karena orang lain tidak dapat berpikir untuk Anda. Dan haruskah mereka melakukannya? Orang lain berpikir sendiri, tentang sistem universal - atau tidak berpikir sama sekali kapan plugin ini ditulis. Dan hanya karena plugin ini memiliki 5 ribu pengguna bukan berarti tidak ada gunanya. Mungkin Anda akan menjadi yang ke-5001 hanya karena sebelumnya sudah ada 5000 orang di sana.

Jika Anda mulai memantau infrastruktur dan backend aplikasi Anda berhenti merespons, semua pengguna akan kehilangan koneksi dengan aplikasi seluler. Sebuah kesalahan akan muncul. Mereka akan mendatangi Anda dan berkata, “Aplikasi tidak berfungsi, apa yang kamu lakukan di sini?” - “Kami sedang memantau.” — “Bagaimana cara memantau jika Anda tidak melihat aplikasi tidak berfungsi?!”

1. Saya yakin Anda perlu mulai memantau secara tepat dari titik masuk pengguna. Jika pengguna tidak melihat bahwa aplikasinya berfungsi, itu saja, itu kegagalan. Dan sistem pemantauan harus memperingatkan hal ini terlebih dahulu.
2. Barulah kita bisa memantau infrastrukturnya. Atau lakukan secara paralel. Lebih mudah dengan infrastruktur - di sini kita akhirnya bisa menginstal zabbix.
3. Dan sekarang Anda perlu membuka akar aplikasi untuk memahami di mana ada hal-hal yang tidak berfungsi.

Gagasan utama saya adalah bahwa pemantauan harus dilakukan secara paralel dengan proses pembangunan. Jika Anda mengalihkan perhatian tim pemantauan untuk tugas-tugas lain (membuat CI/CD, sandboxing, reorganisasi infrastruktur), pemantauan akan mulai melambat dan Anda mungkin tidak akan pernah bisa mengejar perkembangan (atau cepat atau lambat Anda harus menghentikannya).

Semuanya berdasarkan level

Beginilah cara saya melihat organisasi sistem pemantauan.

1) Tingkat aplikasi:

• memantau logika bisnis aplikasi;
• memantau metrik kesehatan layanan;
• pemantauan integrasi.

2) Tingkat infrastruktur:

• pemantauan tingkat orkestrasi;
• pemantauan perangkat lunak sistem;
• pemantauan kadar zat besi.

3) Sekali lagi tingkat aplikasi - tetapi sebagai produk rekayasa:

• mengumpulkan dan memantau log aplikasi;
• APM;
• pelacakan.

4) Peringatan:

• organisasi sistem peringatan;
• organisasi sistem tugas;
• organisasi "basis pengetahuan" dan alur kerja untuk pemrosesan insiden.

Ini penting: kita mendapat peringatan bukan setelahnya, tapi segera! Tidak perlu meluncurkan pemantauan dan “entah bagaimana nanti” mencari tahu siapa yang akan menerima peringatan. Lagi pula, apa tugas pemantauan: memahami di bagian mana dalam sistem ada sesuatu yang salah, dan memberi tahu orang yang tepat mengenai hal tersebut. Jika Anda membiarkan ini sampai akhir, maka orang yang tepat akan mengetahui bahwa ada sesuatu yang tidak beres hanya dengan mengatakan “tidak ada yang berhasil untuk kami”.

Lapisan Aplikasi - Pemantauan Logika Bisnis

Di sini kita berbicara tentang memeriksa fakta bahwa aplikasi tersebut berfungsi untuk pengguna.

Level ini harus dilakukan selama fase pengembangan. Misalnya, kita memiliki Prometheus bersyarat: Prometheus pergi ke server yang melakukan pemeriksaan, menarik titik akhir, dan titik akhir pergi dan memeriksa API.

Ketika sering diminta untuk memantau halaman beranda untuk memastikan situs berfungsi, pemrogram memberikan pegangan yang dapat ditarik setiap kali mereka perlu memastikan bahwa API berfungsi. Dan programmer saat ini masih mengambil dan menulis /api/test/helloworld
Satu-satunya cara untuk memastikan semuanya berfungsi? - TIDAK!

• Membuat pemeriksaan semacam itu pada dasarnya adalah tugas pengembang. Tes unit harus ditulis oleh pemrogram yang menulis kode. Karena kalau dibocorkan ke admin, “Bung, ini daftar protokol API untuk 25 fungsi tersebut, mohon dimonitor semuanya!” - tidak ada yang berhasil.
• Jika Anda mencetak “halo dunia”, tidak akan ada seorang pun yang tahu bahwa API tersebut seharusnya dan memang berfungsi. Setiap perubahan API harus menyebabkan perubahan dalam pemeriksaan.
• Jika Anda sudah mengalami masalah seperti itu, hentikan fitur dan alokasikan pengembang yang akan menulis pemeriksaan ini, atau terima kerugiannya, terimalah bahwa tidak ada yang diperiksa dan akan gagal.

Kiat Teknis:

• Pastikan untuk mengatur server eksternal untuk mengatur pemeriksaan - Anda harus yakin bahwa proyek Anda dapat diakses oleh dunia luar.
• Atur pemeriksaan di seluruh protokol API, bukan hanya titik akhir individual.
• Buat titik akhir prometheus dengan hasil tes.

Lapisan aplikasi - pemantauan metrik kesehatan

Sekarang kita berbicara tentang metrik layanan kesehatan eksternal.

Kami memutuskan untuk memantau semua “pegangan” aplikasi menggunakan pemeriksaan eksternal, yang kami panggil dari sistem pemantauan eksternal. Tapi ini adalah "pegangan" yang "dilihat" oleh pengguna. Kami ingin memastikan bahwa layanan kami berfungsi dengan baik. Ada cerita yang lebih baik di sini: K8 memiliki pemeriksaan kesehatan, sehingga setidaknya “kubus” itu sendiri dapat diyakinkan bahwa layanannya berfungsi. Tapi setengah dari cek yang saya lihat adalah cetakan yang sama “hello world”. Itu. Jadi dia menariknya sekali setelah penerapan, dia menjawab bahwa semuanya baik-baik saja - itu saja. Dan layanan tersebut, jika menyediakan API-nya sendiri, memiliki sejumlah besar titik masuk untuk API yang sama, yang juga perlu dipantau, karena kami ingin mengetahui apakah layanan tersebut berfungsi. Dan kami sudah memantaunya di dalam.

Cara menerapkannya dengan benar secara teknis: setiap layanan memperlihatkan titik akhir tentang kinerjanya saat ini, dan dalam grafik Grafana (atau aplikasi lainnya) kita melihat status semua layanan.

• Setiap perubahan API harus menyebabkan perubahan dalam pemeriksaan.
• Buat layanan baru segera dengan metrik kesehatan.
• Seorang admin dapat mendatangi pengembang dan meminta “tambahkan saya beberapa fitur sehingga saya memahami segalanya dan menambahkan informasi tentang ini ke sistem pemantauan saya.” Namun pengembang biasanya menjawab, “Kami tidak akan menambahkan apa pun dua minggu sebelum rilis.”
  Biar manajer pengembangan tahu bahwa akan ada kerugian seperti itu, beri tahu juga manajemen manajer pengembangan. Karena ketika semuanya jatuh, seseorang akan tetap menelepon dan meminta untuk memantau “layanan yang terus menurun” (c)
• Omong-omong, alokasikan pengembang untuk menulis plugin untuk Grafana - ini akan sangat membantu admin.

Lapisan Aplikasi - Pemantauan Integrasi

Pemantauan integrasi berfokus pada pemantauan komunikasi antara sistem penting bisnis.

Misalnya ada 15 layanan yang saling berkomunikasi. Ini bukan lagi situs yang terpisah. Itu. kita tidak dapat menarik layanan itu sendiri, mendapatkan /helloworld dan memahami bahwa layanan tersebut sedang berjalan. Karena layanan web pemesanan harus mengirimkan informasi tentang pesanan ke bus - dari bus, layanan gudang harus menerima pesan ini dan mengerjakannya lebih lanjut. Dan layanan distribusi email harus memprosesnya lebih jauh, dll.

Oleh karena itu, kami tidak dapat memahami, dengan memeriksa masing-masing layanan, bahwa semuanya berfungsi. Karena kami memiliki bus tertentu yang melaluinya segala sesuatu berkomunikasi dan berinteraksi.
Oleh karena itu, tahap ini harus menandai tahap pengujian layanan untuk berinteraksi dengan layanan lain. Tidak mungkin mengatur pemantauan komunikasi dengan memantau perantara pesan. Jika ada layanan yang mengeluarkan data dan ada layanan yang menerimanya, maka saat memantau broker kita hanya akan melihat data yang terbang dari sisi ke sisi. Meskipun kami entah bagaimana berhasil memantau interaksi data ini secara internal - bahwa produser tertentu memposting data, seseorang membacanya, aliran ini terus masuk ke Kafka - ini tetap tidak akan memberi kami informasi jika satu layanan mengirim pesan dalam satu versi , tetapi layanan lain tidak mengharapkan versi ini dan melewatkannya. Kami tidak akan mengetahui hal ini, karena layanan akan memberi tahu kami bahwa semuanya berfungsi.

Apa yang saya sarankan lakukan:

• Untuk komunikasi sinkron: titik akhir membuat permintaan ke layanan terkait. Itu. kita mengambil titik akhir ini, menarik skrip di dalam layanan, yang menuju ke semua titik dan mengatakan "Saya dapat menarik ke sana, dan menarik ke sana, saya dapat menarik ke sana..."
• Untuk komunikasi asinkron: pesan masuk - titik akhir memeriksa bus untuk pesan uji dan menampilkan status pemrosesan.
• Untuk komunikasi asinkron: pesan keluar - titik akhir mengirimkan pesan uji ke bus.

Seperti yang biasanya terjadi: kami memiliki layanan yang memasukkan data ke dalam bus. Kami datang ke layanan ini dan meminta Anda memberi tahu kami tentang kesehatan integrasinya. Dan jika layanan perlu menghasilkan pesan di suatu tempat lebih jauh (WebApp), maka layanan akan menghasilkan pesan pengujian ini. Dan jika kita menjalankan layanan di sisi OrderProcessing, pertama-tama layanan tersebut memposting apa yang dapat diposting secara independen, dan jika ada beberapa hal yang bergantung, kemudian ia membaca serangkaian pesan pengujian dari bus, memahami bahwa layanan tersebut dapat memprosesnya, melaporkannya dan , jika perlu, posting lebih lanjut, dan tentang ini dia berkata - semuanya baik-baik saja, saya masih hidup.

Seringkali kita mendengar pertanyaan “bagaimana kita bisa mengujinya pada data pertempuran?” Misalnya, kita berbicara tentang layanan pemesanan yang sama. Pesanan mengirimkan pesan ke gudang tempat barang dihapuskan: kami tidak dapat mengujinya pada data pertempuran, karena “barang saya akan dihapuskan!” Solusi: Rencanakan seluruh pengujian ini sejak awal. Anda juga memiliki unit test yang membuat tiruan. Jadi, lakukan pada tingkat yang lebih dalam di mana Anda memiliki saluran komunikasi yang tidak merugikan operasional bisnis.

Lapisan infrastruktur

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

• Pemantauan infrastruktur dapat dan harus diluncurkan sebagai proses terpisah.
• Anda tidak boleh memulai dengan pemantauan infrastruktur pada proyek yang sedang berjalan, meskipun Anda benar-benar menginginkannya. Ini menyusahkan semua devops. “Pertama saya akan memantau clusternya, saya akan memantau infrastrukturnya” – mis. Pertama, ia akan memantau apa yang ada di bawah, tetapi tidak akan masuk ke dalam aplikasi. Karena aplikasi merupakan suatu hal yang tidak dapat dipahami oleh para devops. Itu bocor kepadanya, dan dia tidak mengerti cara kerjanya. Dan dia memahami infrastruktur dan memulainya. Tapi tidak - Anda selalu perlu memantau aplikasinya terlebih dahulu.
• Jangan berlebihan dengan jumlah peringatan. Mengingat kompleksitas sistem modern, peringatan terus-menerus dikirimkan, dan Anda harus hidup dengan kumpulan peringatan ini. Dan orang yang bertugas, setelah melihat ratusan peringatan berikutnya, akan memutuskan, “Saya tidak ingin memikirkannya.” Peringatan seharusnya hanya memberi tahu tentang hal-hal penting.

Tingkat aplikasi sebagai unit bisnis

Poin kunci:

• RUSA BESAR. Ini adalah standar industri. Jika karena alasan tertentu Anda tidak mengumpulkan log, segera mulai melakukannya.
• APM. APM eksternal sebagai cara untuk menutup pemantauan aplikasi dengan cepat (NewRelic, BlackFire, Datadog). Anda dapat menginstal hal ini sementara untuk setidaknya memahami apa yang terjadi dengan Anda.
• Pelacakan. Di lusinan layanan mikro, Anda harus melacak semuanya, karena permintaan tidak lagi berjalan dengan sendirinya. Sangat sulit untuk menambahkannya nanti, jadi lebih baik segera menjadwalkan penelusuran dalam pengembangan - ini adalah pekerjaan dan kegunaan pengembang. Jika Anda belum menerapkannya, terapkanlah! Lihat Jaeger/Zipkin

Memperingatkan

• Organisasi sistem notifikasi: dalam kondisi memantau banyak hal, harus ada sistem terpadu untuk mengirimkan notifikasi. Anda bisa di Grafana. Di Barat, semua orang menggunakan PagerDuty. Peringatan harus jelas (misalnya dari mana asalnya...). Dan disarankan untuk mengontrol agar notifikasi diterima sama sekali
• Organisasi sistem tugas: peringatan tidak boleh dikirimkan ke semua orang (semua orang akan bereaksi di tengah kerumunan, atau tidak ada yang akan bereaksi). Pengembang juga harus siap dihubungi: pastikan untuk menentukan bidang tanggung jawab, buat instruksi yang jelas dan tuliskan di dalamnya siapa sebenarnya yang harus dihubungi pada hari Senin dan Rabu, dan siapa yang harus dihubungi pada hari Selasa dan Jumat (jika tidak, mereka tidak akan menelepon siapa pun bahkan di hari kerja). jika terjadi masalah besar - mereka akan takut membangunkan atau mengganggu Anda : orang pada umumnya tidak suka menelepon dan membangunkan orang lain, terutama di malam hari). Dan jelaskan bahwa meminta bantuan bukanlah indikator ketidakmampuan (“Saya meminta bantuan, itu berarti saya pekerja yang buruk”), dorong permintaan bantuan.
• Pengorganisasian “basis pengetahuan” dan alur kerja untuk pemrosesan insiden: untuk setiap insiden serius, pemeriksaan mayat harus direncanakan, dan sebagai tindakan sementara, tindakan yang akan menyelesaikan insiden tersebut harus dicatat. Dan jadikanlah kebiasaan bahwa peringatan berulang-ulang adalah dosa; mereka perlu diperbaiki dalam kode atau pekerjaan infrastruktur.

Tumpukan teknologi

Bayangkan tumpukan kita adalah sebagai berikut:

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

Pemilihan opsi tidaklah penting. Karena jika pada awalnya Anda memahami cara memantau sistem dan menuliskan rencana, maka Anda mulai memilih alat yang sesuai dengan kebutuhan Anda. Pertanyaannya adalah apa yang Anda pilih untuk dipantau. Karena mungkin alat yang Anda pilih di awal tidak sesuai dengan kebutuhan Anda sama sekali.

Beberapa poin teknis yang saya lihat di mana-mana akhir-akhir ini:

Prometheus didorong ke dalam Kubernetes - siapa yang mencetuskan ini?! Jika cluster Anda mogok, apa yang akan Anda lakukan? Jika Anda memiliki cluster yang kompleks di dalam, maka harus ada semacam sistem pemantauan di dalam cluster, dan beberapa di luar, yang akan mengumpulkan data dari dalam cluster.

Di dalam cluster kami mengumpulkan log dan yang lainnya. Tapi sistem pengawasannya harus di luar. Sangat sering, dalam sebuah cluster di mana Promtheus diinstal secara internal, terdapat juga sistem yang melakukan pemeriksaan eksternal terhadap operasi situs. Bagaimana jika koneksi Anda ke dunia luar terputus dan aplikasi tidak berfungsi? Ternyata semuanya baik-baik saja di dalam, tetapi ini tidak membuat segalanya lebih mudah bagi pengguna.

Temuan

• Pemantauan pengembangan bukanlah instalasi utilitas, tetapi pengembangan produk perangkat lunak. 98% dari pemantauan saat ini adalah pengkodean. Pengkodean dalam layanan, pengkodean pemeriksaan eksternal, pemeriksaan layanan eksternal, dan itu saja.
• Jangan buang waktu pengembang Anda untuk memantau: ini bisa menghabiskan hingga 30% pekerjaan mereka, tapi itu sepadan.
• Teman-teman, jangan khawatir Anda tidak dapat memantau sesuatu, karena beberapa hal memiliki cara berpikir yang sangat berbeda. Anda bukan seorang programmer, dan pekerjaan pemantauan adalah tugas mereka.
• Jika proyek sudah berjalan dan tidak dipantau (dan Anda adalah manajernya), alokasikan sumber daya untuk pemantauan.
• Jika produk sudah dalam produksi, dan Anda adalah seorang pengembang yang diminta untuk "mengatur pemantauan" - coba jelaskan kepada manajemen tentang apa saya menulis semua ini.

Ini adalah versi laporan yang diperluas pada konferensi Saint Highload++.

Jika Anda tertarik dengan ide dan pemikiran saya tentangnya serta topik terkait, maka di sini Anda bisa membaca salurannya 🙂

Sumber: www.habr.com