Nama saya Anton Baderin. Saya bekerja di Pusat Teknologi Tinggi dan melakukan administrasi sistem. Sebulan yang lalu, konferensi perusahaan kami berakhir, di mana kami berbagi akumulasi pengalaman kami dengan komunitas TI di kota kami. Saya berbicara tentang pemantauan aplikasi web. Materi ditujukan untuk tingkat junior atau menengah, yang tidak membangun proses ini dari awal.
Landasan yang mendasari sistem pemantauan apa pun adalah memecahkan masalah bisnis. Pemantauan demi pemantauan tidak ada gunanya bagi siapa pun. Apa yang diinginkan bisnis? Agar semuanya berjalan cepat dan tanpa kesalahan. Pelaku bisnis ingin proaktif, sehingga kami sendiri yang mengidentifikasi permasalahan dalam layanan dan memperbaikinya secepat mungkin. Faktanya, ini adalah masalah yang saya pecahkan sepanjang tahun lalu pada sebuah proyek untuk salah satu pelanggan kami.
tentang
Proyek ini adalah salah satu program loyalitas terbesar di negara ini. Kami membantu jaringan ritel meningkatkan frekuensi penjualan melalui berbagai alat pemasaran seperti kartu bonus. Secara total, proyek ini mencakup 14 aplikasi yang berjalan di sepuluh server.
Selama proses wawancara, saya berulang kali memperhatikan bahwa admin tidak selalu melakukan pendekatan pemantauan aplikasi web dengan benar: banyak yang masih fokus pada metrik sistem operasi dan terkadang memantau layanan.
Dalam kasus saya, sistem pemantauan pelanggan sebelumnya didasarkan pada Icinga. Itu tidak menyelesaikan masalah di atas dengan cara apapun. Seringkali klien sendiri yang memberi tahu kami tentang masalahnya, dan lebih sering daripada tidak, kami tidak memiliki cukup data untuk mengetahui alasannya.
Selain itu, ada pemahaman yang jelas tentang kesia-siaan pengembangan lebih lanjut. Saya rasa mereka yang akrab dengan Icinga akan memahami saya. Jadi, kami memutuskan untuk mendesain ulang sepenuhnya sistem pemantauan aplikasi web untuk proyek tersebut.
Prometheus
Kami memilih Prometheus berdasarkan tiga indikator utama:
- Sejumlah besar metrik yang tersedia. Dalam kasus kami ada 60 ribu di antaranya. Tentu saja, perlu dicatat bahwa kami tidak menggunakan sebagian besar dari mereka (mungkin sekitar 95%). Di sisi lain, semuanya relatif murah. Bagi kami, ini adalah ekstrim lain dibandingkan dengan Icinga yang digunakan sebelumnya. Di dalamnya, menambahkan metrik sangat merepotkan: metrik yang sudah ada harganya mahal (lihat saja kode sumber plugin apa pun). Plugin apa pun adalah skrip dalam Bash atau Python, yang peluncurannya mahal dalam hal sumber daya yang dikonsumsi.
- Sistem ini mengkonsumsi sumber daya yang relatif kecil. RAM 600 MB, 15% satu inti, dan beberapa lusin IOPS sudah cukup untuk semua metrik kami. Tentu saja, Anda harus menjalankan pengekspor metrik, tetapi semuanya ditulis dalam Go dan juga tidak terlalu haus kekuasaan. Saya rasa dalam realitas modern hal ini tidak menjadi masalah.
- Memberikan kemampuan untuk bermigrasi ke Kubernetes. Mengingat rencana pelanggan, pilihannya jelas.
RUSA BESAR
Sebelumnya, kami tidak mengumpulkan atau memproses log. Kekurangannya jelas bagi semua orang. Kami memilih ELK karena kami sudah mempunyai 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 perlunya mengumpulkan log Nginx, statistik dari pg_stat_statements, dan menyimpan data historis Prometheus. Kami tidak menyukai Influx karena secara berkala mulai menghabiskan banyak memori dan mogok. Selain itu, saya ingin mengelompokkan kueri berdasarkan remote_addr, tetapi pengelompokan dalam DBMS ini hanya berdasarkan tag. Tag itu mahal (memori), jumlahnya terbatas secara kondisional.
Kami memulai pencarian kami lagi. Yang dibutuhkan adalah database analitis dengan konsumsi sumber daya minimal, sebaiknya dengan kompresi data pada disk.
Clickhouse memenuhi semua kriteria ini, dan kami tidak pernah menyesali pilihan kami. Kami tidak menulis data dalam jumlah luar biasa ke dalamnya (jumlah penyisipan hanya sekitar lima ribu per menit).
NewRelic
NewRelic secara historis telah bersama kami karena merupakan 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 tersebut dan dengan demikian mensistematisasikan pendekatan pemantauan.
Untuk melakukan ini, saya membagi sistem kami ke dalam beberapa level berikut:
- perangkat keras dan VMS;
- sistem operasi;
- layanan sistem, tumpukan perangkat lunak;
- aplikasi;
- logika bisnis.
Mengapa pendekatan ini nyaman:
- kami mengetahui siapa yang bertanggung jawab atas pekerjaan di setiap level dan, berdasarkan ini, kami dapat mengirimkan peringatan;
- kita dapat menggunakan struktur ini ketika menyembunyikan peringatan - akan aneh jika mengirimkan peringatan tentang tidak tersedianya database ketika mesin virtual secara keseluruhan tidak tersedia.
Karena tugas kita adalah mengidentifikasi pelanggaran dalam pengoperasian sistem, kita harus menyoroti serangkaian metrik tertentu di setiap tingkat yang perlu diperhatikan saat menulis aturan peringatan. Selanjutnya, mari kita melalui level “VMS”, “Sistem operasi” dan “Layanan sistem, tumpukan perangkat lunak”.
Mesin virtual
Hosting memberi kita prosesor, disk, memori, dan jaringan. Dan kami punya masalah dengan dua yang pertama. Jadi, metriknya:
Waktu CPU dicuri - saat Anda membeli mesin virtual di Amazon (t2.micro, misalnya), Anda harus memahami bahwa Anda tidak dialokasikan seluruh inti prosesor, tetapi hanya kuota waktunya. Dan ketika Anda kehabisannya, prosesor tersebut akan diambil dari Anda.
Metrik ini memungkinkan Anda melacak momen tersebut dan membuat keputusan. Misalnya, apakah perlu mengambil tarif yang lebih besar atau mendistribusikan pemrosesan tugas latar belakang dan permintaan API ke server yang berbeda?
IOPS + CPU iowait time - karena alasan tertentu, banyak cloud hosting yang berdosa karena tidak menyediakan IOPS yang cukup. Apalagi jadwal dengan IOPS rendah bukanlah argumen bagi mereka. Oleh karena itu, ada baiknya mengumpulkan CPU iowait. Dengan pasangan grafik ini - dengan IOPS rendah dan tunggu I/O tinggi - Anda sudah dapat berbicara dengan hosting dan menyelesaikan masalahnya.
Sistem operasi
Metrik sistem operasi:
- jumlah memori yang tersedia dalam %;
- aktivitas penggunaan swap: vmstat swapin, swapout;
- jumlah inode yang tersedia dan ruang kosong pada sistem file dalam %
- beban rata-rata;
- jumlah koneksi di dua negara bagian;
- kepenuhan tabel penghubung;
- Kualitas jaringan dapat dipantau menggunakan utilitas ss, paket iproute2 - dapatkan indikator koneksi RTT dari outputnya dan kelompokkan berdasarkan port tujuan.
Juga pada tingkat sistem operasi kita memiliki entitas seperti proses. Penting untuk mengidentifikasi dalam sistem serangkaian proses yang memainkan peran penting dalam operasinya. Jika, misalnya, Anda memiliki beberapa pgpool, maka Anda perlu mengumpulkan informasi untuk masing-masing pgpool.
Kumpulan metriknya adalah sebagai berikut:
- CPU;
- ingatan pada dasarnya bersifat menetap;
- IO - sebaiknya di IOPS;
- FileFd - buka dan batasi;
- kegagalan halaman yang signifikan - dengan cara ini Anda dapat memahami proses apa yang sedang ditukar.
Kami menerapkan semua pemantauan di Docker, dan kami menggunakan Advisor untuk mengumpulkan data metrik. Di mesin lain kami menggunakan proses-eksportir.
Layanan sistem, tumpukan perangkat lunak
Setiap aplikasi memiliki spesifikasinya masing-masing, dan sulit untuk memilih serangkaian metrik tertentu.
Himpunan universalnya adalah:
- tingkat permintaan;
- jumlah kesalahan;
- latensi;
- kejenuhan.
Contoh pemantauan kami yang paling mencolok pada tingkat ini adalah Nginx dan PostgreSQL.
Layanan yang paling banyak dimuat di sistem kami adalah database. Di masa lalu, kita sering kesulitan mengetahui apa yang dilakukan database.
Kami melihat beban yang tinggi pada disk, tetapi log yang lambat tidak menunjukkan apa pun. Kami memecahkan masalah ini menggunakan pg_stat_statements, tampilan yang mengumpulkan statistik kueri.
Itu saja yang dibutuhkan admin.
Kami membuat grafik aktivitas permintaan baca dan tulis:
Semuanya sederhana dan jelas, setiap permintaan memiliki warna tersendiri.
Contoh yang sama mencoloknya adalah log Nginx. Tak heran jika hanya sedikit orang yang menguraikan atau menyebutkannya dalam daftar must-have. 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 membuat grafik waktu respons dan jumlah kesalahan. Ingat? Apakah saya berbicara tentang tujuan bisnis? Untuk dengan cepat dan tanpa kesalahan? Kami telah membahas masalah ini dengan dua grafik. Dan Anda sudah dapat menghubungi administrator yang bertugas menggunakannya.
Namun masih ada satu masalah lagi - untuk memastikan penghapusan penyebab insiden tersebut dengan cepat.
Resolusi insiden
Keseluruhan proses mulai dari mengidentifikasi hingga memecahkan suatu masalah dapat dibagi menjadi beberapa langkah:
- mengidentifikasi masalah;
- pemberitahuan kepada penyelenggara tugas;
- tanggapan terhadap suatu kejadian;
- penghapusan penyebab.
Penting bagi kita untuk melakukan ini secepat mungkin. Dan jika pada tahap mengidentifikasi masalah dan mengirimkan pemberitahuan kita tidak dapat memperoleh banyak waktu - dua menit akan dihabiskan untuk hal tersebut, maka tahap berikutnya hanyalah bidang yang belum dibajak untuk perbaikan.
Bayangkan saja telepon petugas jaga berdering. Apa yang akan dia lakukan? Carilah jawaban atas pertanyaan - apa yang rusak, di mana pecahnya, bagaimana bereaksi? Inilah cara kami menjawab pertanyaan-pertanyaan ini:
Kami cukup menyertakan semua informasi ini dalam teks pemberitahuan, memberikannya tautan ke halaman wiki yang menjelaskan cara menanggapi masalah ini, cara menyelesaikannya, dan mengeskalasinya.
Saya masih belum mengatakan apa pun tentang lapisan aplikasi dan logika bisnis. Sayangnya, aplikasi kami belum mengimplementasikan pengumpulan metrik. Satu-satunya sumber informasi dari level ini adalah log.
Beberapa poin.
Pertama, tulis log terstruktur. Tidak perlu menyertakan konteks dalam teks pesan. Hal ini membuat mereka sulit untuk dikelompokkan dan dianalisis. Logstash membutuhkan waktu lama untuk menormalkan semua ini.
Kedua, gunakan tingkat keparahan dengan benar. Setiap bahasa mempunyai standar tersendiri. Secara pribadi, saya membedakan empat level:
- tidak ada kesalahan;
- kesalahan sisi klien;
- kesalahan ada di pihak kami, kami tidak kehilangan uang, kami tidak menanggung risiko;
- Kesalahannya ada di pihak kita, kita kehilangan uang.
Izinkan saya meringkas. Anda perlu mencoba membangun pemantauan berdasarkan logika bisnis. Cobalah untuk memantau aplikasi itu sendiri dan beroperasi dengan metrik seperti jumlah penjualan, jumlah pendaftaran pengguna baru, jumlah pengguna aktif saat ini, dan sebagainya.
Jika seluruh bisnis Anda berada dalam satu tombol di browser, Anda perlu memantau apakah bisnis tersebut dapat diklik dan berfungsi dengan baik. Segala sesuatu yang lain tidak masalah.
Jika Anda tidak memilikinya, Anda dapat mencoba mengikutinya di log aplikasi, log Nginx, dan sebagainya, seperti yang kami lakukan. Anda harus berada sedekat mungkin dengan aplikasi.
Metrik sistem operasi tentu saja penting, namun bisnis tidak tertarik padanya, kami tidak dibayar untuk itu.
Sumber: www.habr.com