Saat ini, selain kode monolitik, proyek kami mencakup lusinan layanan mikro. Masing-masing dari mereka perlu diawasi. Melakukan hal ini dalam skala besar menggunakan teknisi DevOps merupakan suatu masalah. Kami telah mengembangkan sistem pemantauan yang berfungsi sebagai layanan bagi pengembang. Mereka dapat secara mandiri menulis metrik ke dalam sistem pemantauan, menggunakannya, membuat dasbor berdasarkan metrik tersebut, dan melampirkan peringatan kepada metrik tersebut yang akan dipicu ketika nilai ambang batas tercapai. Untuk insinyur DevOps, hanya infrastruktur dan dokumentasi.
Postingan ini adalah transkrip pidato saya dengan kami di RIT++. Banyak orang meminta kami membuat laporan versi teks dari sana. Jika Anda menghadiri konferensi atau menonton video, Anda tidak akan menemukan sesuatu yang baru. Dan yang lainnya - selamat datang di kucing. Saya akan memberi tahu Anda bagaimana kami sampai pada sistem seperti itu, cara kerjanya, dan bagaimana kami berencana memperbaruinya.
Masa lalu: skema dan rencana
Bagaimana kita sampai pada sistem pemantauan saat ini? Untuk menjawab pertanyaan ini, Anda harus pergi ke tahun 2015. Ini penampakannya saat itu:
Kami memiliki sekitar 24 node yang bertanggung jawab untuk pemantauan. Ada sekumpulan mahkota, skrip, daemon berbeda yang entah bagaimana memantau sesuatu, mengirim pesan, dan menjalankan fungsi. Kami berpikir bahwa semakin jauh kami melangkah, sistem seperti itu akan semakin tidak dapat dijalankan. Tidak ada gunanya mengembangkannya: terlalu rumit.
Kami memutuskan untuk memilih elemen pemantauan yang akan kami pertahankan dan kembangkan, dan elemen yang akan kami tinggalkan. Jumlahnya 19. Yang tersisa hanyalah grafit, agregator, dan Grafana sebagai dashboard. Tapi seperti apa sistem barunya? Seperti ini:
Kami memiliki penyimpanan metrik: ini adalah grafit, yang akan didasarkan pada drive SSD cepat, ini adalah agregator tertentu untuk metrik. Berikutnya - Grafana untuk menampilkan dasbor dan Moira untuk peringatan. Kami juga ingin mengembangkan sistem untuk mencari anomali.
Standar: Pemantauan 2.0
Seperti inilah rencananya di tahun 2015. Namun kami tidak hanya harus mempersiapkan infrastruktur dan layanannya sendiri, tetapi juga dokumentasinya. Kami telah mengembangkan standar perusahaan untuk diri kami sendiri, yang kami sebut pemantauan 2.0. Apa saja persyaratan sistemnya?
- ketersediaan konstan;
- interval penyimpanan metrik = 10 detik;
- penyimpanan terstruktur dari metrik dan dasbor;
- SLA > 99,99%
- kumpulan metrik peristiwa melalui UDP (!).
Kami memerlukan UDP karena kami memiliki arus lalu lintas dan peristiwa yang besar yang menghasilkan metrik. Jika Anda menulis semuanya ke dalam grafit sekaligus, penyimpanannya akan runtuh. Kami juga memilih awalan tingkat pertama untuk semua metrik.
Masing-masing awalan memiliki beberapa properti. Ada metrik untuk server, jaringan, kontainer, sumber daya, aplikasi, dan sebagainya. Pemfilteran yang jelas, ketat, dan terketik telah diterapkan, di mana kami menerima metrik tingkat pertama dan membuang sisanya. Ini adalah bagaimana kami merencanakan sistem ini pada tahun 2015. Apa yang ada di masa sekarang?
Hadir: diagram interaksi komponen pemantauan
Pertama-tama, kami memantau aplikasi: kode PHP kami, aplikasi, dan layanan mikro - singkatnya, semua yang ditulis oleh pengembang kami. Semua aplikasi mengirimkan metrik melalui UDP ke agregator Brubeck (statsd, ditulis ulang dalam C). Ternyata menjadi yang tercepat dalam pengujian sintetik. Dan itu mengirimkan metrik yang sudah dikumpulkan ke Graphite melalui TCP.
Ini memiliki jenis metrik yang disebut pengatur waktu. Ini adalah hal yang sangat nyaman. Misalnya, untuk setiap koneksi pengguna ke layanan, Anda mengirimkan metrik dengan waktu respons ke Brubeck. Satu juta tanggapan masuk, namun agregator hanya mengembalikan 10 metrik. Anda memiliki jumlah orang yang datang, waktu respons maksimum, minimum dan rata-rata, median dan 4 persentil. Kemudian data ditransfer ke Graphite dan kita melihat semuanya secara langsung.
Kami juga memiliki agregasi metrik pada perangkat keras, perangkat lunak, metrik sistem, dan sistem pemantauan Munin lama kami (yang berfungsi hingga tahun 2015). Kami mengumpulkan semua ini melalui daemon C CollectD (ia memiliki banyak plugin berbeda yang terpasang di dalamnya, ia dapat melakukan polling semua sumber daya sistem host tempat ia diinstal, cukup tentukan di konfigurasi tempat menulis data) dan tulis data ke Graphite melaluinya. Ini juga mendukung plugin python dan skrip shell, sehingga Anda dapat menulis solusi khusus Anda sendiri: CollectD akan mengumpulkan data ini dari host lokal atau jarak jauh (dengan asumsi Curl) dan mengirimkannya ke Graphite.
Kemudian kami mengirimkan semua metrik yang kami kumpulkan ke Carbon-c-relay. Ini adalah solusi Carbon Relay dari Graphite, dimodifikasi dalam C. Ini adalah router yang mengumpulkan semua metrik yang kami kirim dari agregator kami dan mengarahkannya ke node. Juga pada tahap perutean, ia memeriksa validitas metrik. Pertama, harus sesuai dengan skema awalan yang saya tunjukkan sebelumnya dan, kedua, valid untuk grafit. Kalau tidak, mereka akan terjatuh.
Carbon-c-relay kemudian mengirimkan metrik ke cluster Grafit. Kami menggunakan Carbon-cache, yang ditulis ulang di Go, sebagai penyimpanan utama metrik. Go-carbon, karena multithreadingnya, jauh mengungguli Carbon-cache. Ia menerima data dan menulisnya ke disk menggunakan paket bisikan (standar, ditulis dengan python). Untuk membaca data dari penyimpanan kami, kami menggunakan API Grafit. Ini jauh lebih cepat daripada WEB Grafit standar. Apa yang terjadi selanjutnya dengan data tersebut?
Mereka pergi ke Grafana. Kami menggunakan cluster grafit sebagai sumber data utama, ditambah lagi kami memiliki Grafana sebagai antarmuka web untuk menampilkan metrik dan membuat dasbor. Untuk setiap layanannya, pengembang membuat dasbornya sendiri. Kemudian mereka membuat grafik berdasarkan data tersebut, yang menampilkan metrik yang mereka tulis dari aplikasi mereka. Selain Grafana, kami juga punya SLAM. Ini adalah setan python yang menghitung SLA berdasarkan data dari grafit. Seperti yang sudah saya katakan, kami memiliki beberapa lusin layanan mikro, yang masing-masing memiliki persyaratannya sendiri. Dengan menggunakan SLAM, kami membuka dokumentasi dan membandingkannya dengan apa yang ada di Graphite dan membandingkan seberapa cocok persyaratan dengan ketersediaan layanan kami.
Mari melangkah lebih jauh: memperingatkan. Itu diatur menggunakan sistem yang kuat - Moira. Ia independen karena memiliki Grafit sendiri di bawah kapnya. Dikembangkan oleh orang-orang dari SKB "Kontur", ditulis dengan python dan Go, sepenuhnya open source. Moira menerima aliran yang sama dengan yang masuk ke grafit. Jika karena alasan tertentu penyimpanan Anda mati, peringatan Anda akan tetap berfungsi.
Kami menerapkan Moira di Kubernetes; ia menggunakan sekelompok server Redis sebagai database utama. Hasilnya adalah sistem yang toleran terhadap kesalahan. Ini membandingkan aliran metrik dengan daftar pemicu: jika tidak ada penyebutan di dalamnya, maka metrik tersebut akan dihilangkan. Sehingga mampu mencerna gigabyte metrik per menit.
Kami juga melampirkan LDAP perusahaan ke dalamnya, yang dengannya setiap pengguna sistem perusahaan dapat membuat pemberitahuan untuk dirinya sendiri berdasarkan pemicu yang ada (atau yang baru dibuat). Karena Moira mengandung Grafit, ia mendukung semua fiturnya. Jadi pertama-tama Anda mengambil garisnya dan menyalinnya ke Grafana. Lihat bagaimana data ditampilkan pada grafik. Dan kemudian Anda mengambil baris yang sama dan menyalinnya ke Moira. Anda menggantungnya dengan batasan dan mendapatkan peringatan di output. Untuk melakukan semua ini, Anda tidak memerlukan pengetahuan khusus. Moira dapat memberi peringatan melalui SMS, email, Jira, Slack... Ini juga mendukung eksekusi skrip khusus. Ketika pemicu terjadi padanya, dan dia berlangganan skrip atau biner khusus, dia menjalankannya dan mengirimkan JSON ke stdin untuk biner ini. Oleh karena itu, program Anda harus menguraikannya. Apa yang akan Anda lakukan dengan JSON ini terserah Anda. Kalau mau kirim ke Telegram, kalau mau buka task di Jira, terserah.
Kami juga menggunakan pengembangan kami sendiri untuk peringatan - Imagotag. Kami menyesuaikan panel, yang biasanya digunakan untuk label harga elektronik di toko, agar sesuai dengan kebutuhan kami. Kami membawa pemicu dari Moira ke dalamnya. Ini menunjukkan di negara bagian mana mereka berada dan kapan terjadinya. Beberapa orang pengembang mengabaikan notifikasi di Slack dan email demi panel ini.
Karena kami adalah perusahaan progresif, kami juga memantau Kubernetes di sistem ini. Kami memasukkannya ke dalam sistem menggunakan Heapster, yang kami instal di cluster, mengumpulkan data dan mengirimkannya ke Graphite. Hasilnya, diagramnya terlihat seperti ini:
Komponen Pemantauan
Berikut adalah daftar tautan ke komponen yang kami gunakan untuk tugas ini. Semuanya bersumber terbuka.
Grafit:
- go-karbon:
- bisikan:
- grafit-api:
Relai karbon-c:
Brubeck:
Dikumpulkan:
moira:
Grafana:
tumpukan:
statistika
Dan berikut beberapa angka tentang cara kerja sistem untuk kami.
Agregator (brubeck)
Jumlah metrik: ~300/dtk
Interval pengiriman metrik ke Grafit: 30 detik
Penggunaan sumber daya server: ~ 6% CPU (kita berbicara tentang server lengkap); ~RAM 1Gb; ~LAN 3Mbps
Grafit (go-karbon)
Jumlah metrik: ~1/mnt
Interval pembaruan metrik: 30 detik
Skema penyimpanan metrik: 30 detik 35 hari, 5 menit 90 hari, 10 menit 365 hari (memberi Anda pemahaman tentang apa yang terjadi pada layanan dalam jangka waktu lama)
Penggunaan sumber daya server: ~10% CPU; ~RAM 20Gb; ~LAN 30Mbps
Keluwesan
Kami di Avito sangat menghargai fleksibilitas dalam layanan pemantauan kami. Kenapa dia malah menjadi seperti ini? Pertama, komponen-komponennya dapat dipertukarkan: baik komponen itu sendiri maupun versinya. Kedua, dukungan. Karena keseluruhan proyek bersifat open source, Anda dapat mengedit kodenya sendiri, membuat perubahan, dan mengimplementasikan fungsi yang tidak tersedia secara langsung. Tumpukan yang cukup umum digunakan, terutama Go dan Python, jadi ini dilakukan dengan cukup sederhana.
Berikut adalah contoh masalah nyata. Metrik dalam Grafit adalah file. Itu punya nama. Nama file = nama metrik. Dan ada cara untuk mencapainya. Nama file di Linux dibatasi hingga 255 karakter. Dan kami memiliki (sebagai βpelanggan internalβ) orang-orang dari departemen database. Mereka memberi tahu kami: βKami ingin memantau kueri SQL kami. Dan itu bukan 255 karakter, tapi masing-masing 8 MB. Kami ingin menampilkannya di Grafana, melihat parameter untuk permintaan ini, dan bahkan lebih baik lagi, kami ingin melihat bagian atas permintaan tersebut. Akan lebih bagus jika ditampilkan secara real time. Akan sangat keren untuk membuat mereka waspada.β
Contoh kueri SQL diambil sebagai contoh dari
Kami menyiapkan server Redis dan menggunakan plugin Collectd kami, yang masuk ke Postgres dan mengambil semua data dari sana, mengirimkan metrik ke Graphite. Namun kami mengganti nama metrik dengan hash. Kami secara bersamaan mengirimkan hash yang sama ke Redis sebagai kunci, dan seluruh kueri SQL sebagai nilai. Yang harus kita lakukan adalah memastikan Grafana bisa pergi ke Redis dan mengambil informasi ini. Kami membuka API Grafit karena... ini adalah antarmuka utama untuk interaksi semua komponen pemantauan dengan grafit, dan kami memasukkan fungsi baru di sana yang disebut aliasByHash() - dari Grafana kami mendapatkan nama metrik, dan menggunakannya dalam permintaan ke Redis sebagai kunci, di respon kita mendapatkan nilai kuncinya, yaitu βkueri SQLβ kita " Jadi, kami menampilkan di Grafana tampilan kueri SQL, yang secara teori tidak mungkin ditampilkan di sana, bersama dengan statistik di dalamnya (panggilan, baris, total_waktu, ...).
Hasil
Ketersediaan Layanan pemantauan kami tersedia 24/7 dari aplikasi apa pun dan kode apa pun. Jika Anda memiliki akses ke fasilitas penyimpanan, Anda dapat menulis data ke layanan tersebut. Bahasanya tidak penting, keputusannya tidak penting. Anda hanya perlu mengetahui cara membuka soket, meletakkan metrik di sana, dan menutup soket.
Keandalan Semua komponen toleran terhadap kesalahan dan menangani beban kami dengan baik.
Ambang masuk rendah. Untuk menggunakan sistem ini, Anda tidak perlu mempelajari bahasa pemrograman dan query di Grafana. Buka saja aplikasi Anda, masukkan soket ke dalamnya yang akan mengirimkan metrik ke Graphite, tutup, buka Grafana, buat dasbor di sana dan lihat perilaku metrik Anda, terima pemberitahuan melalui Moira.
Kemerdekaan. Anda dapat melakukan semua ini sendiri, tanpa bantuan teknisi DevOps. Dan ini merupakan keuntungan, karena Anda dapat memantau proyek Anda sekarang, Anda tidak perlu meminta siapa pun - baik untuk mulai bekerja atau melakukan perubahan.
Apa yang kita perjuangkan?
Segala sesuatu yang tercantum di bawah ini bukan hanya pemikiran abstrak, tetapi sesuatu yang setidaknya telah diambil langkah pertamanya.
- Detektor anomali. Kami ingin membuat layanan yang akan masuk ke penyimpanan Grafit kami dan memeriksa setiap metrik menggunakan berbagai algoritma. Sudah ada algoritma yang ingin kami lihat, sudah ada datanya, kami tahu cara bekerja dengannya.
- Metadata. Kami memiliki banyak layanan, layanan tersebut berubah seiring berjalannya waktu, sama seperti orang yang bekerja dengan layanan tersebut. Menyimpan dokumentasi secara manual secara terus-menerus bukanlah suatu pilihan. Itu sebabnya kami sekarang menyematkan metadata ke dalam layanan mikro kami. Ini menyatakan siapa yang mengembangkannya, bahasa yang berinteraksi dengannya, persyaratan SLA, ke mana dan kepada siapa pemberitahuan harus dikirim. Saat menyebarkan layanan, semua data entitas dibuat secara independen. Hasilnya, Anda mendapatkan dua tautan - satu ke pemicu, yang lain ke dasbor di Grafana.
- Pemantauan di setiap rumah. Kami percaya bahwa semua pengembang harus menggunakan sistem seperti itu. Dalam hal ini, Anda selalu memahami di mana lalu lintas Anda, apa yang terjadi, di mana jatuhnya, di mana kelemahannya. Jika, misalnya, ada sesuatu yang datang dan membuat layanan Anda mogok, maka Anda akan mengetahuinya bukan selama panggilan dari manajer, tetapi dari peringatan, dan Anda dapat segera membuka log terbaru dan melihat apa yang terjadi di sana.
- Kinerja tinggi. Proyek kami terus berkembang dan saat ini memproses sekitar 2 nilai metrik per menit. Setahun yang lalu, angkanya adalah 000. Dan pertumbuhannya terus berlanjut, yang berarti bahwa setelah beberapa waktu, Grafit (berbisik) akan mulai membebani subsistem disk. Seperti yang sudah saya katakan, sistem pemantauan ini cukup universal karena komponennya dapat dipertukarkan. Seseorang memelihara dan terus-menerus memperluas infrastruktur mereka khusus untuk Grafit, tetapi kami memutuskan untuk mengambil jalan lain: penggunaan sebagai tempat penyimpanan metrik kami. Transisi ini hampir selesai, dan segera saya akan memberi tahu Anda lebih detail bagaimana hal ini dilakukan: kesulitan apa yang ada dan bagaimana cara mengatasinya, bagaimana proses migrasi berjalan, saya akan menjelaskan komponen yang dipilih sebagai pengikat dan konfigurasinya.
Terima kasih atas perhatian Anda! Ajukan pertanyaan Anda tentang topik tersebut, saya akan mencoba menjawabnya di sini atau di postingan berikut. Mungkin seseorang memiliki pengalaman membangun sistem pemantauan serupa atau beralih ke Clickhouse dalam situasi serupa - bagikan di komentar.
Sumber: www.habr.com