Nama saya Anton Baderin. Saya bekerja di Pusat Teknologi Tinggi dan terlibat dalam administrasi sistem. Sebulan yang lalu, konferensi perusahaan kami berakhir, di mana kami berbagi pengalaman kami dengan komunitas TI kota kami. Saya berbicara tentang memonitor aplikasi web. Materi itu dimaksudkan untuk tingkat junior atau menengah, yang tidak membangun proses ini dari awal.
Landasan yang mendasari sistem pemantauan adalah solusi untuk masalah bisnis. Pemantauan demi pemantauan tidak menarik bagi siapa pun. Apa yang diinginkan bisnis? Sehingga semuanya bekerja dengan cepat dan tanpa kesalahan. Bisnis menginginkan proaktif, sehingga kami sendiri mengidentifikasi masalah dalam layanan dan menghilangkannya secepat mungkin. Ini, sebenarnya, adalah tugas yang telah saya selesaikan sepanjang tahun lalu pada proyek salah satu pelanggan kami.
Tentang proyek
Proyek ini adalah salah satu program loyalitas terbesar di negara ini. Kami membantu pengecer meningkatkan frekuensi penjualan mereka melalui berbagai alat pemasaran seperti kartu bonus. Secara total, proyek ini mencakup 14 aplikasi yang berjalan di sepuluh server.
Dalam proses melakukan wawancara, saya telah berulang kali memperhatikan bahwa admin tidak selalu yang tepat untuk memonitor aplikasi web: sejauh ini, banyak yang berkutat pada metrik sistem operasi, dan kadang-kadang memantau layanan.
Dalam kasus saya, Icinga adalah dasar dari sistem pemantauan pelanggan sebelumnya. Dia tidak memecahkan masalah di atas. Seringkali klien sendiri memberi tahu kami tentang masalah dan setidaknya kami tidak punya cukup data untuk sampai ke dasar alasannya.
Selain itu, ada pemahaman yang jelas tentang kesia-siaan pengembangan selanjutnya. Saya pikir mereka yang akrab dengan Icinga akan mengerti saya. Jadi, kami memutuskan untuk sepenuhnya mendesain ulang sistem pemantauan untuk aplikasi web pada proyek.
Prometheus
Kami memilih Prometheus berdasarkan tiga indikator utama:
- Sejumlah besar metrik yang tersedia. Dalam kasus kami, ada 60 ribu dari mereka. Tentu saja, perlu dicatat bahwa sebagian besar dari mereka tidak kita gunakan (mungkin sekitar 95%). Di sisi lain, semuanya relatif murah. Bagi kami, ini adalah ekstrim lain dibandingkan dengan Icinga yang sebelumnya digunakan. Di dalamnya, menambahkan metrik sangat menyusahkan: yang tersedia mahal (lihat saja kode sumber plugin apa pun). Setiap plug-in adalah skrip Bash atau Python, yang peluncurannya tidak murah dalam hal sumber daya yang dikonsumsi.
- Sistem ini mengkonsumsi sumber daya yang relatif sedikit. Semua metrik kami memiliki 600 MB RAM, 15% dari satu inti dan beberapa lusin IOPS. Tentu saja, Anda harus menjalankan pengekspor metrik, tetapi semuanya ditulis dalam Go dan juga tidak berbeda dalam kerakusan. Saya tidak berpikir bahwa dalam kenyataan modern ini adalah masalah.
- Itu memungkinkan untuk beralih ke Kubernetes. Mengingat rencana pelanggan, pilihannya jelas.
RUSA
Sebelumnya, kami tidak mengumpulkan atau memproses log. Kekurangannya jelas bagi semua orang. Kami memilih ELK, karena kami sudah memiliki pengalaman dengan sistem ini. Kami hanya menyimpan log aplikasi di sana. Kriteria pemilihan utama adalah pencarian teks lengkap dan kecepatannya.
Clickhouse
Awalnya, pilihan jatuh pada InfluxDB. Kami menyadari kebutuhan untuk mengumpulkan log Nginx, statistik dari pg_stat_statements, dan menyimpan data historis Prometheus. Kami tidak suka Influx, karena secara berkala mulai mengkonsumsi banyak memori dan jatuh. Selain itu, saya ingin mengelompokkan permintaan dengan remote_addr, dan mengelompokkan dalam DBMS ini hanya dengan tag. Tag jalan (memori), jumlahnya terbatas dengan syarat.
Kami memulai pencarian lagi. Kami membutuhkan basis analitik dengan konsumsi sumber daya minimal, lebih disukai dengan kompresi data pada disk.
Clickhouse memenuhi semua kriteria ini, dan kami tidak pernah menyesali pilihannya. Kami tidak menulis jumlah data yang luar biasa ke dalamnya (jumlah sisipan hanya sekitar lima ribu per menit).
NewRelic
NewRelic secara historis bersama kami karena itu adalah pilihan pelanggan. Kami menggunakannya sebagai APM.
Zabbix
Kami menggunakan Zabbix secara eksklusif untuk memantau Black Box dari berbagai API.
Mendefinisikan pendekatan pemantauan
Kami ingin menguraikan tugas dan dengan demikian mensistematisasikan pendekatan pemantauan.
Untuk melakukan ini, saya membagi sistem kami ke level berikut:
- Perangkat Keras dan VMS;
- sistem operasi
- layanan sistem, tumpukan perangkat lunak;
- aplikasi
- logika bisnis.
Apa yang membuat pendekatan ini nyaman:
- kami tahu siapa yang bertanggung jawab atas pekerjaan masing-masing level dan, berdasarkan ini, kami dapat mengirimkan peringatan;
- kita dapat menggunakan struktur ketika menekan peringatan - akan aneh untuk mengirimkan peringatan tentang tidak dapat diaksesnya database ketika mesin virtual umumnya tidak dapat diakses.
Karena tugas kita adalah untuk mendeteksi penyimpangan dalam sistem, kita harus pada setiap level memilih serangkaian metrik tertentu yang harus diperhatikan ketika menulis aturan peringatan. Selanjutnya, kita akan melewati level “VMS”, “Sistem Operasi” dan “Layanan Sistem, tumpukan perangkat lunak”.
Mesin virtual
Hosting memberi kita prosesor, disk, memori, dan jaringan. Dan dengan dua yang pertama kami punya masalah. Jadi metrik:
Waktu yang dicuri CPU - saat Anda membeli mesin virtual di Amazon (t2.micro, misalnya), Anda harus memahami bahwa Anda tidak mengalokasikan seluruh inti prosesor, tetapi hanya kuota waktunya. Dan ketika Anda mengurasnya, prosesor akan diambil dari Anda.
Metrik ini memungkinkan Anda untuk melacak momen seperti itu dan membuat keputusan. Sebagai contoh, apakah perlu untuk mengambil tarif lebih gemuk atau mendistribusikan pemrosesan tugas latar belakang dan permintaan di API ke server yang berbeda.
IOPS + CPU waktu iowait - untuk beberapa alasan, banyak perusahaan cloud hosting berdosa dengan tidak memberikan IOPS. Selain itu, jadwal dengan IOPS rendah bukanlah argumen untuk mereka. Karena itu, ada baiknya mengumpulkan CPU iowait. Dengan pasangan grafik ini - dengan IOPS rendah dan harapan I / O tinggi - Anda sudah dapat berbicara dengan hosting dan menyelesaikan masalah.
Sistem operasi
Metrik sistem operasi:
- jumlah memori yang tersedia dalam%;
- aktivitas menggunakan swap: vmstat swapin, swapout;
- jumlah inode yang tersedia dan ruang kosong pada sistem file dalam%
- beban rata-rata;
- jumlah koneksi dalam dua kondisi;
- tabel conntrack kepenuhan;
- kinerja jaringan dapat dimonitor menggunakan utilitas ss, paket iproute2 - dapatkan indikator RTT-koneksi dari outputnya dan kelompokkan dengan dest-port.
Juga di tingkat sistem operasi, kami memiliki entitas seperti proses. Penting untuk menyoroti dalam sistem serangkaian proses yang memainkan peran penting dalam pekerjaannya. Jika, misalnya, Anda memiliki beberapa pgpool, maka Anda perlu mengumpulkan informasi untuk masing-masingnya.
Rangkaian metrik adalah sebagai berikut:
- CPU
- memori terutama penduduk;
- IO - lebih disukai di IOPS;
- FileFd - buka dan batasi;
- kegagalan halaman yang signifikan - sehingga Anda dapat memahami proses apa yang ditukar.
Semua pemantauan dikerahkan di Docker, kami menggunakan advisor untuk mengumpulkan data metrik. Di mesin lain, kami menggunakan proses-eksportir.
Layanan Sistem, Stack Perangkat Lunak
Setiap aplikasi memiliki spesifiknya sendiri, dan sulit untuk membedakan beberapa set metrik.
Set universal adalah:
- tingkat permintaan;
- jumlah kesalahan;
- latensi
- saturasi.
Contoh pemantauan yang paling mencolok di level ini adalah Nginx dan PostgreSQL.
Layanan yang paling banyak dimuat di sistem kami adalah database. Kami dulu sering mengalami masalah untuk mengetahui apa yang dilakukan database.
Kami melihat beban tinggi pada disk, tetapi slogan tidak benar-benar menunjukkan apa-apa. Kami memecahkan masalah ini dengan pg_stat_statements, tampilan yang mengumpulkan statistik berdasarkan permintaan.
Ini semua yang dibutuhkan admin.
Kami memplot aktivitas permintaan baca dan tulis:
Semuanya sederhana dan jelas, setiap permintaan memiliki warna tersendiri.
Contoh yang sama mencoloknya adalah Nginx log. Tidak mengherankan, sedikit yang mem-parsing mereka atau menyebutkannya dalam daftar yang diperlukan. Format standar tidak terlalu informatif dan perlu diperluas.
Secara pribadi, saya menambahkan request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Kami memplot waktu respons dan jumlah kesalahan:
Kami memplot waktu respons dan jumlah kesalahan. Apakah kamu ingat? Apakah saya berbicara tentang tujuan bisnis? Untuk dengan cepat dan tanpa kesalahan? Kami telah menutup masalah ini dengan dua grafik. Dan pada mereka Anda sudah dapat memanggil administrator tugas.
Tapi masalah lain tetap ada - untuk memastikan penghapusan cepat penyebab insiden tersebut.
Manajemen insiden
Seluruh proses mulai dari mengidentifikasi hingga menyelesaikan masalah dapat dibagi menjadi beberapa langkah:
- identifikasi masalah;
- pemberitahuan dari administrator yang bertugas;
- reaksi atas insiden tersebut;
- penghapusan penyebabnya.
Adalah penting bahwa kita melakukan ini secepat mungkin. Dan jika kita tidak dapat memenangkan banyak waktu pada tahap mengidentifikasi masalah dan mengirim pemberitahuan - mereka akan pergi selama dua menit dalam hal apa pun, maka yang berikutnya hanyalah bidang yang belum tersentuh untuk peningkatan.
Bayangkan saja telepon berdering saat bertugas. Apa yang akan dia lakukan? Cari jawaban atas pertanyaan - apa yang rusak, di mana rusak, bagaimana bereaksi? Inilah cara kami menjawab pertanyaan-pertanyaan ini:
Kami cukup memasukkan semua informasi ini dalam teks notifikasi, memberikan tautan ke halaman wiki yang menjelaskan bagaimana menanggapi masalah ini, bagaimana menyelesaikannya dan meningkatkannya.
Saya masih belum mengatakan apa-apa tentang lapisan aplikasi dan logika bisnis. Sayangnya, pengumpulan metrik belum diterapkan di aplikasi kami. Satu-satunya sumber setidaknya beberapa informasi dari level ini adalah log.
Beberapa poin.
Pertama, tulis log terstruktur. Tidak perlu memasukkan konteks dalam isi pesan. Ini membuatnya sulit untuk dikelompokkan dan dianalisis. Logstash membutuhkan waktu lama untuk menormalkan semua ini.
Kedua, gunakan tingkat keparahan dengan benar. Setiap bahasa memiliki standarnya sendiri. Secara pribadi, saya membedakan empat level:
- tidak ada kesalahan;
- kesalahan sisi klien;
- kesalahan ada di pihak kita, kita tidak kehilangan uang, kita tidak menanggung risiko;
- kesalahan ada di pihak kita, kita kehilangan uang.
Saya meringkas. Penting untuk mencoba membangun pemantauan secara tepat dari logika bisnis. Cobalah untuk memantau aplikasi itu sendiri dan beroperasi dengan metrik seperti jumlah penjualan, jumlah pendaftaran pengguna baru, jumlah pengguna yang saat ini aktif, dan sebagainya.
Jika seluruh bisnis Anda adalah satu tombol di browser Anda, Anda perlu memantau apakah itu diperas dan berfungsi dengan baik. Segala sesuatu yang lain tidak penting.
Jika Anda tidak memiliki ini, Anda dapat mencoba untuk mengejarnya di log aplikasi, log Nginx, dan sebagainya, seperti yang kami lakukan. Anda harus sedekat mungkin dengan aplikasi.
Metrik sistem operasi tentu saja penting, tetapi mereka tidak menarik untuk bisnis, kami tidak dibayar untuk itu.