Hari ini, sebagai tambahan kepada kod monolitik, projek kami termasuk berpuluh-puluh perkhidmatan mikro. Setiap daripada mereka perlu dipantau. Melakukan ini pada skala sedemikian menggunakan jurutera DevOps adalah bermasalah. Kami telah membangunkan sistem pemantauan yang berfungsi sebagai perkhidmatan untuk pembangun. Mereka boleh menulis metrik secara bebas ke dalam sistem pemantauan, menggunakannya, membina papan pemuka berdasarkannya dan melampirkan makluman kepada mereka yang akan dicetuskan apabila nilai ambang dicapai. Untuk jurutera DevOps, hanya infrastruktur dan dokumentasi.
Jawatan ini adalah transkrip ucapan saya dengan kami di RIT++. Ramai orang meminta kami membuat versi teks laporan dari sana. Jika anda berada di persidangan atau menonton video, anda tidak akan menemui sesuatu yang baharu. Dan orang lain - selamat datang ke kucing. Saya akan memberitahu anda bagaimana kami datang ke sistem sedemikian, cara ia berfungsi dan cara kami merancang untuk mengemas kininya.
Masa lalu: skim dan rancangan
Bagaimanakah kami sampai pada sistem pemantauan semasa? Untuk menjawab soalan ini, anda perlu pergi ke 2015. Inilah rupanya ketika itu:
Kami mempunyai kira-kira 24 nod yang bertanggungjawab untuk memantau. Terdapat satu pek mahkota, skrip, daemon berbeza yang entah bagaimana memantau sesuatu, menghantar mesej dan melaksanakan fungsi. Kami berpendapat bahawa semakin jauh kami pergi, semakin kurang berdaya maju sistem sedemikian. Tidak ada gunanya mengembangkannya: ia terlalu rumit.
Kami memutuskan untuk memilih elemen pemantauan yang akan kami simpan dan bangunkan, dan elemen yang akan kami tinggalkan. Terdapat 19 daripadanya. Hanya grafit, agregator dan Grafana sebagai papan pemuka yang tinggal. Tetapi bagaimanakah rupa sistem baharu itu? seperti ini:
Kami mempunyai storan metrik: ini adalah grafit, yang akan berdasarkan pemacu SSD pantas, ini adalah agregator tertentu untuk metrik. Seterusnya - Grafana untuk memaparkan papan pemuka dan Moira untuk memberi amaran. Kami juga ingin membangunkan sistem untuk mencari anomali.
Standard: Pemantauan 2.0
Inilah rupa rancangan pada tahun 2015. Tetapi kami perlu menyediakan bukan sahaja infrastruktur dan perkhidmatan itu sendiri, tetapi juga dokumentasi untuknya. Kami telah membangunkan standard korporat untuk diri kami sendiri, yang kami panggil pemantauan 2.0. Apakah keperluan untuk sistem tersebut?
- ketersediaan berterusan;
- selang storan metrik = 10 saat;
- penyimpanan berstruktur bagi metrik dan papan pemuka;
- SLA > 99,99%
- pengumpulan metrik acara melalui UDP (!).
Kami memerlukan UDP kerana kami mempunyai aliran trafik dan peristiwa yang besar yang menjana metrik. Jika anda menulis kesemuanya ke dalam grafit sekaligus, storan akan runtuh. Kami juga memilih awalan peringkat pertama untuk semua metrik.
Setiap awalan mempunyai beberapa sifat. Terdapat metrik untuk pelayan, rangkaian, bekas, sumber, aplikasi dan sebagainya. Penapisan yang jelas, ketat dan ditaip telah dilaksanakan, di mana kami menerima metrik peringkat pertama dan hanya menggugurkan yang lain. Beginilah cara kami merancang sistem ini pada tahun 2015. Apa yang ada pada masa kini?
Sekarang: gambar rajah interaksi komponen pemantauan
Pertama sekali, kami memantau aplikasi: kod PHP, aplikasi dan perkhidmatan mikro kami - ringkasnya, semua yang ditulis oleh pembangun kami. Semua aplikasi menghantar metrik melalui UDP ke pengagregat Brubeck (statsd, ditulis semula dalam C). Ia ternyata menjadi yang terpantas dalam ujian sintetik. Dan ia menghantar metrik yang telah diagregatkan kepada Graphite melalui TCP.
Ia mempunyai jenis metrik yang dipanggil pemasa. Ini adalah perkara yang sangat mudah. Sebagai contoh, untuk setiap sambungan pengguna kepada perkhidmatan, anda menghantar metrik dengan masa tindak balas kepada Brubeck. Sejuta respons masuk, tetapi pengagregat hanya mengembalikan 10 metrik. Anda mempunyai bilangan orang yang datang, masa tindak balas maksimum, minimum dan purata, median dan 4 persentil. Kemudian data dipindahkan ke Grafit dan kami melihat semuanya secara langsung.
Kami juga mempunyai pengagregatan untuk metrik pada perkakasan, perisian, metrik sistem dan sistem pemantauan Munin lama kami (ia berfungsi untuk kami sehingga 2015). Kami mengumpul semua ini melalui C daemon CollectD (ia mempunyai sejumlah besar pemalam yang berbeza terbina di dalamnya, ia boleh meninjau semua sumber sistem hos yang dipasangnya, hanya nyatakan dalam konfigurasi tempat untuk menulis data) dan tulis data kepada Grafit melaluinya. Ia juga menyokong pemalam python dan skrip shell, jadi anda boleh menulis penyelesaian tersuai anda sendiri: CollectD akan mengumpulkan data ini daripada hos tempatan atau jauh (dengan andaian Curl) dan menghantarnya ke Graphite.
Kemudian kami menghantar semua metrik yang kami kumpulkan ke Carbon-c-relay. Ini ialah penyelesaian Carbon Relay daripada Graphite, diubah suai dalam C. Ini ialah penghala yang mengumpulkan semua metrik yang kami hantar daripada pengagregat kami dan mengarahkannya ke nod. Juga pada peringkat penghalaan, ia menyemak kesahihan metrik. Pertama, ia mesti sepadan dengan skema awalan yang saya tunjukkan sebelum ini dan, kedua, ia sah untuk grafit. Jika tidak, mereka akan jatuh.
Carbon-c-relay kemudian menghantar metrik ke gugusan Grafit. Kami menggunakan Carbon-cache, ditulis semula dalam Go, sebagai storan utama metrik. Go-carbon, kerana multithreadingnya, jauh mengatasi Carbon-cache. Ia menerima data dan menulisnya ke cakera menggunakan pakej bisikan (standard, ditulis dalam python). Untuk membaca data daripada storan kami, kami menggunakan API Grafit. Ia jauh lebih pantas daripada WEB Graphite standard. Apakah yang berlaku kepada data seterusnya?
Mereka pergi ke Grafana. Kami menggunakan kelompok grafit kami sebagai sumber data utama, ditambah pula dengan Grafana sebagai antara muka web untuk memaparkan metrik dan membina papan pemuka. Untuk setiap perkhidmatan mereka, pembangun mencipta papan pemuka mereka sendiri. Kemudian mereka membina graf berdasarkannya, yang memaparkan metrik yang mereka tulis daripada aplikasi mereka. Selain Grafana, kami juga ada SLAM. Ini ialah syaitan python yang mengira SLA berdasarkan data daripada grafit. Seperti yang telah saya katakan, kami mempunyai beberapa dozen perkhidmatan mikro, setiap satunya mempunyai keperluannya sendiri. Menggunakan SLAM, kami pergi ke dokumentasi dan membandingkannya dengan apa yang ada dalam Grafit dan membandingkan sejauh mana keperluan sepadan dengan ketersediaan perkhidmatan kami.
Mari pergi lebih jauh: memberi amaran. Ia dianjurkan menggunakan sistem yang kukuh - Moira. Ia bebas kerana ia mempunyai Grafit sendiri di bawah tudung. Dibangunkan oleh lelaki dari SKB "Kontur", ditulis dalam python dan Go, sumber terbuka sepenuhnya. Moira menerima aliran yang sama yang masuk ke dalam grafit. Jika atas sebab tertentu storan anda mati, makluman anda masih akan berfungsi.
Kami menggunakan Moira dalam Kubernetes; ia menggunakan sekumpulan pelayan Redis sebagai pangkalan data utama. Hasilnya ialah sistem toleransi kesalahan. Ia membandingkan strim metrik dengan senarai pencetus: jika tiada sebutan di dalamnya, maka ia menjatuhkan metrik. Jadi ia mampu mencerna gigabait metrik seminit.
Kami juga melampirkan LDAP korporat padanya, dengan bantuan setiap pengguna sistem korporat boleh membuat pemberitahuan untuk diri mereka sendiri berdasarkan pencetus sedia ada (atau yang baru dibuat). Memandangkan Moira mengandungi Grafit, ia menyokong semua cirinya. Jadi anda mula-mula mengambil baris dan menyalinnya ke Grafana. Lihat bagaimana data dipaparkan pada graf. Dan kemudian anda mengambil baris yang sama dan menyalinnya ke Moira. Anda menggantungnya dengan had dan mendapat makluman pada output. Untuk melakukan semua ini, anda tidak memerlukan pengetahuan khusus. Moira boleh memaklumkan melalui SMS, e-mel, Jira, Slack... Ia juga menyokong pelaksanaan skrip tersuai. Apabila pencetus berlaku kepadanya, dan dia melanggan skrip tersuai atau binari, dia menjalankannya dan menghantar JSON ke stdin untuk binari ini. Sehubungan itu, program anda mesti menghuraikannya. Perkara yang akan anda lakukan dengan JSON ini terpulang kepada anda. Jika mahu, hantar ke Telegram, jika mahu, buka tugas di Jira, buat apa sahaja.
Kami juga menggunakan pembangunan kami sendiri untuk memberi amaran - Imagotag. Kami menyesuaikan panel, yang biasanya digunakan untuk tanda harga elektronik di kedai, untuk memenuhi keperluan kami. Kami membawa pencetus daripada Moira kepadanya. Ia menunjukkan keadaan mereka berada dan bila ia berlaku. Beberapa orang pembangunan meninggalkan pemberitahuan dalam Slack dan e-mel memihak kepada panel ini.
Oleh kerana kami adalah syarikat yang progresif, kami juga memantau Kubernetes dalam sistem ini. Kami memasukkannya ke dalam sistem menggunakan Heapster, yang kami pasang dalam kelompok, ia mengumpul data dan menghantarnya ke Graphite. Hasilnya, rajah kelihatan seperti ini:
Komponen Pemantauan
Berikut ialah senarai pautan ke komponen yang kami gunakan untuk tugasan ini. Kesemuanya adalah sumber terbuka.
Grafit:
- go-carbon:
- berbisik:
- grafit-api:
geganti karbon-c:
Brubeck:
Dikumpul:
Moira:
Grafana:
Heapster:
statistik
Dan berikut ialah beberapa nombor tentang cara sistem berfungsi untuk kami.
Agregator (brubeck)
Bilangan metrik: ~300/saat
Selang untuk menghantar metrik ke Grafit: 30 saat
Penggunaan sumber pelayan: ~ 6% CPU (kita bercakap tentang pelayan penuh); ~ 1Gb RAM; ~3 Mbps LAN
Grafit (go-carbon)
Bilangan metrik: ~ 1 / min
Selang kemas kini metrik: 30 saat
Skim storan metrik: 30sec 35h, 5min 90h, 10min 365d (memberi anda pemahaman tentang perkara yang berlaku kepada perkhidmatan dalam tempoh masa yang panjang)
Penggunaan sumber pelayan: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN
Fleksibiliti
Kami di Avito sangat menghargai fleksibiliti dalam perkhidmatan pemantauan kami. Kenapa dia jadi begini sebenarnya? Pertama, komponennya boleh ditukar ganti: kedua-dua komponen itu sendiri dan versinya. Kedua, kebolehdukungan. Memandangkan keseluruhan projek adalah sumber terbuka, anda boleh mengedit kod sendiri, membuat perubahan dan melaksanakan fungsi yang tidak tersedia di luar kotak. Tindanan yang agak biasa digunakan, terutamanya Go dan Python, jadi ini dilakukan dengan mudah.
Berikut adalah contoh masalah sebenar. Metrik dalam Grafit ialah fail. Ia mempunyai nama. Nama fail = nama metrik. Dan ada cara untuk ke sana. Nama fail dalam Linux adalah terhad kepada 255 aksara. Dan kami mempunyai (sebagai "pelanggan dalaman") dari jabatan pangkalan data. Mereka memberitahu kami: "Kami mahu memantau pertanyaan SQL kami. Dan mereka bukan 255 aksara, tetapi 8 MB setiap satu. Kami mahu memaparkannya dalam Grafana, melihat parameter untuk permintaan ini, dan lebih baik lagi, kami mahu melihat bahagian atas permintaan sedemikian. Ia akan menjadi hebat jika ia dipaparkan dalam masa nyata. Ia akan menjadi sangat bagus untuk meletakkan mereka dalam keadaan berjaga-jaga.β
Contoh pertanyaan SQL diambil sebagai contoh daripada
Kami menyediakan pelayan Redis dan menggunakan pemalam Collectd kami, yang pergi ke Postgres dan mengambil semua data dari sana, menghantar metrik ke Graphite. Tetapi kami menggantikan nama metrik dengan cincang. Kami menghantar cincang yang sama secara serentak kepada Redis sebagai kunci, dan keseluruhan pertanyaan SQL sebagai nilai. Apa yang perlu kita lakukan ialah memastikan Grafana boleh pergi ke Redis dan mengambil maklumat ini. Kami membuka API Grafit kerana... ini adalah antara muka utama untuk interaksi semua komponen pemantauan dengan grafit, dan kami memasukkan fungsi baharu di sana dipanggil aliasByHash() - daripada Grafana kami mendapat nama metrik, dan menggunakannya dalam permintaan kepada Redis sebagai kunci, dalam respons kami mendapat nilai kunci, iaitu "pertanyaan SQL" kami " Oleh itu, kami memaparkan dalam Grafana paparan pertanyaan SQL, yang secara teori adalah mustahil untuk dipaparkan di sana, bersama-sama dengan statistik padanya (panggilan, baris, total_time, ...).
Keputusan
Ketersediaan Perkhidmatan pemantauan kami tersedia 24/7 dari mana-mana aplikasi dan mana-mana kod. Jika anda mempunyai akses kepada kemudahan storan, anda boleh menulis data kepada perkhidmatan tersebut. Bahasa tidak penting, keputusan tidak penting. Anda hanya perlu tahu cara membuka soket, meletakkan metrik di sana dan menutup soket.
Kebolehpercayaan Semua komponen adalah tahan terhadap kerosakan dan mengendalikan beban kami dengan baik.
Penghalang masuk yang rendah. Untuk menggunakan sistem ini, anda tidak perlu mempelajari bahasa pengaturcaraan dan pertanyaan dalam Grafana. Cuma buka aplikasi anda, masukkan soket ke dalamnya yang akan menghantar metrik kepada Grafit, tutupnya, buka Grafana, buat papan pemuka di sana dan lihat gelagat metrik anda, menerima pemberitahuan melalui Moira.
Kemerdekaan. Anda boleh melakukan semua ini sendiri, tanpa bantuan jurutera DevOps. Dan ini adalah kelebihan, kerana anda boleh memantau projek anda sekarang, anda tidak perlu meminta sesiapa - sama ada untuk memulakan kerja atau membuat perubahan.
Apa yang kita sasarkan?
Semua yang disenaraikan di bawah bukan hanya pemikiran abstrak, tetapi sesuatu ke arah yang sekurang-kurangnya langkah pertama telah diambil.
- Pengesan anomali. Kami ingin mencipta perkhidmatan yang akan pergi ke storan Grafit kami dan menyemak setiap metrik menggunakan pelbagai algoritma. Sudah ada algoritma yang kita mahu lihat, ada data, kita tahu bagaimana untuk bekerja dengannya.
- Metadata. Kami mempunyai banyak perkhidmatan, ia berubah mengikut masa, sama seperti orang yang bekerja dengan mereka. Mengekalkan dokumentasi secara manual secara berterusan bukanlah satu pilihan. Itulah sebabnya kami kini membenamkan metadata ke dalam perkhidmatan mikro kami. Ia menyatakan siapa yang membangunkannya, bahasa yang berinteraksi dengannya, keperluan SLA, di mana dan kepada siapa pemberitahuan harus dihantar. Apabila menggunakan perkhidmatan, semua data entiti dibuat secara bebas. Hasilnya, anda mendapat dua pautan - satu untuk pencetus, satu lagi ke papan pemuka dalam Grafana.
- Pemantauan di setiap rumah. Kami percaya bahawa semua pembangun harus menggunakan sistem sedemikian. Dalam kes ini, anda sentiasa memahami di mana trafik anda, apa yang berlaku padanya, di mana ia jatuh, di mana kelemahannya. Jika, sebagai contoh, sesuatu datang dan ranap perkhidmatan anda, maka anda akan belajar mengenainya bukan semasa panggilan daripada pengurus, tetapi daripada makluman, dan anda boleh segera membuka log terkini dan melihat apa yang berlaku di sana.
- Prestasi tinggi. Projek kami sentiasa berkembang, dan hari ini ia memproses kira-kira 2 nilai metrik seminit. Setahun yang lalu, angka ini adalah 000. Dan pertumbuhan berterusan, dan ini bermakna selepas beberapa lama Grafit (bisikan) akan mula memuatkan subsistem cakera dengan banyak. Seperti yang telah saya katakan, sistem pemantauan ini agak universal disebabkan oleh pertukaran komponen. Seseorang mengekalkan dan sentiasa mengembangkan infrastruktur mereka khusus untuk Graphite, tetapi kami memutuskan untuk pergi ke laluan yang berbeza: gunakan sebagai repositori untuk metrik kami. Peralihan ini hampir selesai, dan tidak lama lagi saya akan memberitahu anda dengan lebih terperinci bagaimana ini dilakukan: apakah kesukaran yang ada dan bagaimana ia diatasi, bagaimana proses migrasi berjalan, saya akan menerangkan komponen yang dipilih sebagai mengikat dan konfigurasinya.
Terima kasih kerana memberi perhatian! Tanya soalan anda mengenai topik tersebut, saya akan cuba jawab di sini atau dalam jawatan berikut. Mungkin seseorang mempunyai pengalaman membina sistem pemantauan yang serupa atau bertukar kepada Clickhouse dalam situasi yang sama - kongsikannya dalam ulasan.
Sumber: www.habr.com