Nama saya Anton Baderin. Saya bekerja di Pusat Teknologi Tinggi dan melakukan pentadbiran sistem. Sebulan yang lalu, persidangan korporat kami telah berakhir, di mana kami berkongsi pengalaman terkumpul kami dengan komuniti IT di bandar kami. Saya bercakap tentang memantau aplikasi web. Bahan ini bertujuan untuk peringkat junior atau pertengahan, yang tidak membina proses ini dari awal.
Asas yang mendasari mana-mana sistem pemantauan ialah menyelesaikan masalah perniagaan. Pemantauan demi pemantauan tidak ada kepentingan sesiapa pun. Apa yang perniagaan mahukan? Supaya semuanya berfungsi dengan cepat dan tanpa kesilapan. Perniagaan mahu menjadi proaktif, supaya kami sendiri mengenal pasti masalah dalam perkhidmatan dan menyelesaikannya secepat mungkin. Ini, sebenarnya, adalah masalah yang saya selesaikan sepanjang tahun lepas pada projek untuk salah seorang pelanggan kami.
mengenai
Projek itu merupakan salah satu program kesetiaan terbesar di negara ini. Kami membantu rangkaian runcit meningkatkan kekerapan jualan melalui pelbagai alat pemasaran seperti kad bonus. Secara keseluruhan, projek itu merangkumi 14 aplikasi yang dijalankan pada sepuluh pelayan.
Semasa proses temu duga, saya berulang kali menyedari bahawa pentadbir tidak selalu mendekati aplikasi web pemantauan dengan betul: ramai yang masih menumpukan pada metrik sistem pengendalian dan kadangkala memantau perkhidmatan.
Dalam kes saya, sistem pemantauan pelanggan sebelum ini berdasarkan Icinga. Ia tidak menyelesaikan masalah di atas dalam apa cara sekalipun. Selalunya pelanggan sendiri memaklumkan kepada kami tentang masalah, dan lebih kerap daripada tidak, kami tidak mempunyai data yang mencukupi untuk sampai ke bahagian bawah sebabnya.
Di samping itu, terdapat pemahaman yang jelas tentang sia-sia perkembangan selanjutnya. Saya rasa mereka yang biasa dengan Icinga akan memahami saya. Jadi, kami memutuskan untuk mereka bentuk semula sepenuhnya sistem pemantauan aplikasi web untuk projek itu.
Prometheus
Kami memilih Prometheus berdasarkan tiga petunjuk utama:
- Sebilangan besar metrik yang tersedia. Dalam kes kami terdapat 60 ribu daripadanya. Sudah tentu, perlu diingat bahawa kami tidak menggunakan sebahagian besar daripada mereka (mungkin kira-kira 95%). Sebaliknya, semuanya agak murah. Bagi kami, ini adalah satu lagi ekstrem berbanding Icinga yang digunakan sebelum ini. Di dalamnya, menambah metrik adalah sesuatu yang menyakitkan: yang sedia ada adalah mahal (lihat sahaja kod sumber mana-mana pemalam). Sebarang pemalam ialah skrip dalam Bash atau Python, yang pelancarannya mahal dari segi sumber yang digunakan.
- Sistem ini menggunakan jumlah sumber yang agak kecil. 600 MB RAM, 15% daripada satu teras dan beberapa dozen IOPS sudah memadai untuk semua metrik kami. Sudah tentu, anda perlu menjalankan pengeksport metrik, tetapi semuanya ditulis dalam Go dan juga tidak terlalu lapar kuasa. Saya tidak fikir dalam realiti moden ini adalah masalah.
- Menyediakan keupayaan untuk berhijrah ke Kubernetes. Memandangkan rancangan pelanggan, pilihannya jelas.
ELK
Sebelum ini, kami tidak mengumpul atau memproses log. Kekurangannya jelas kepada semua orang. Kami memilih ELK kerana kami sudah mempunyai pengalaman dengan sistem ini. Kami hanya menyimpan log aplikasi di sana. Kriteria pemilihan utama ialah carian teks penuh dan kelajuannya.
Π‘lickhouse
Pada mulanya, pilihan jatuh pada InfluxDB. Kami menyedari keperluan untuk mengumpul log Nginx, statistik daripada pg_stat_statements, dan menyimpan data sejarah Prometheus. Kami tidak menyukai Influx kerana ia secara berkala mula menggunakan sejumlah besar memori dan ranap. Di samping itu, saya ingin mengumpulkan pertanyaan mengikut remote_addr, tetapi mengumpulkan dalam DBMS ini hanya dengan teg. Tag adalah mahal (memori), bilangannya terhad secara bersyarat.
Kami memulakan pencarian semula. Apa yang diperlukan ialah pangkalan data analitik dengan penggunaan sumber yang minimum, sebaik-baiknya dengan pemampatan data pada cakera.
Clickhouse memenuhi semua kriteria ini, dan kami tidak pernah menyesali pilihan kami. Kami tidak menulis sebarang jumlah data yang luar biasa ke dalamnya (bilangan sisipan hanya kira-kira lima ribu seminit).
NewRelic
NewRelic telah lama bersama kami kerana ia adalah pilihan pelanggan. Kami menggunakannya sebagai APM.
Zabbix
Kami menggunakan Zabbix secara eksklusif untuk memantau Kotak Hitam pelbagai API.
Mentakrifkan Pendekatan Pemantauan
Kami mahu menguraikan tugas itu dan dengan itu mensistemkan pendekatan pemantauan.
Untuk melakukan ini, saya membahagikan sistem kami kepada tahap berikut:
- perkakasan dan VMS;
- sistem operasi;
- perkhidmatan sistem, timbunan perisian;
- permohonan;
- logik perniagaan.
Mengapa pendekatan ini mudah:
- kami tahu siapa yang bertanggungjawab untuk kerja setiap peringkat dan, berdasarkan ini, kami boleh menghantar makluman;
- kita boleh menggunakan struktur apabila menyekat amaran - adalah pelik untuk menghantar amaran tentang ketiadaan pangkalan data apabila mesin maya secara keseluruhannya tidak tersedia.
Memandangkan tugas kami adalah untuk mengenal pasti pelanggaran dalam pengendalian sistem, kami mesti pada setiap peringkat menyerlahkan set metrik tertentu yang patut diberi perhatian semasa menulis peraturan amaran. Seterusnya, mari kita melalui tahap "VMS", "Sistem pengendalian" dan "Perkhidmatan sistem, timbunan perisian".
Mesin maya
Pengehosan memperuntukkan kita pemproses, cakera, memori dan rangkaian. Dan kami menghadapi masalah dengan dua yang pertama. Jadi, metrik:
Masa yang dicuri CPU - apabila anda membeli mesin maya di Amazon (t2.micro, contohnya), anda harus faham bahawa anda tidak diperuntukkan keseluruhan teras pemproses, tetapi hanya kuota masanya. Dan apabila anda habis, pemproses akan diambil daripada anda.
Metrik ini membolehkan anda menjejaki detik sedemikian dan membuat keputusan. Sebagai contoh, adakah perlu untuk mengambil tarif yang lebih gemuk atau mengagihkan pemprosesan tugas latar belakang dan permintaan API kepada pelayan yang berbeza?
IOPS + CPU iowait time - atas sebab tertentu, banyak pengehosan awan berdosa kerana tidak menyediakan IOPS yang mencukupi. Selain itu, jadual dengan IOPS rendah bukanlah hujah bagi mereka. Oleh itu, adalah bernilai mengumpul CPU iowait. Dengan pasangan graf ini - dengan IOPS rendah dan menunggu I/O tinggi - anda sudah boleh bercakap dengan pengehosan dan menyelesaikan masalah.
Sistem operasi
Metrik sistem pengendalian:
- jumlah memori yang tersedia dalam %;
- aktiviti penggunaan swap: vmstat swapin, swapout;
- bilangan inod yang tersedia dan ruang kosong pada sistem fail dalam %
- beban purata;
- bilangan sambungan dalam keadaan tw;
- kenyang meja conntrack;
- Kualiti rangkaian boleh dipantau menggunakan utiliti ss, pakej iproute2 - dapatkan penunjuk sambungan RTT daripada outputnya dan kumpulkannya mengikut port dest.
Juga pada peringkat sistem pengendalian kami mempunyai entiti seperti proses. Adalah penting untuk mengenal pasti dalam sistem satu set proses yang memainkan peranan penting dalam operasinya. Jika, sebagai contoh, anda mempunyai beberapa pgpool, maka anda perlu mengumpul maklumat untuk setiap pgpool.
Set metrik adalah seperti berikut:
- CPU;
- ingatan terutamanya bermastautin;
- IO - sebaik-baiknya dalam IOPS;
- FileFd - buka dan had;
- kegagalan halaman yang ketara - dengan cara ini anda boleh memahami proses yang sedang ditukar.
Kami menggunakan semua pemantauan dalam Docker dan kami menggunakan Penasihat untuk mengumpul data metrik. Pada mesin lain kami menggunakan pengeksport proses.
Perkhidmatan sistem, timbunan perisian
Setiap aplikasi mempunyai spesifikasi tersendiri dan sukar untuk memilih set metrik tertentu.
Set universal ialah:
- kadar permintaan;
- bilangan kesilapan;
- kependaman;
- ketepuan.
Contoh pemantauan kami yang paling menarik pada tahap ini ialah Nginx dan PostgreSQL.
Perkhidmatan yang paling dimuatkan dalam sistem kami ialah pangkalan data. Pada masa lalu, kami sering menghadapi masalah untuk mengetahui apa yang dilakukan oleh pangkalan data.
Kami melihat beban yang tinggi pada cakera, tetapi log perlahan tidak benar-benar menunjukkan apa-apa. Kami menyelesaikan masalah ini menggunakan pg_stat_statements, paparan yang mengumpulkan statistik pertanyaan.
Itu sahaja yang admin perlukan.
Kami membina graf aktiviti permintaan baca dan tulis:
Semuanya mudah dan jelas, setiap permintaan mempunyai warna tersendiri.
Contoh yang sama menarik ialah log Nginx. Tidak menghairankan bahawa beberapa orang menghuraikannya atau menyebutnya dalam senarai yang mesti dimiliki. Format standard tidak begitu bermaklumat dan perlu diperluaskan.
Secara peribadi, saya menambah request_time, upstream_response_time, body_bait_sent, request_length, request_id. Kami merancang masa respons dan bilangan ralat:
Kami membina graf masa tindak balas dan bilangan ralat. Ingat? Adakah saya bercakap tentang tugas perniagaan? Dengan cepat dan tanpa kesilapan? Kami telah membincangkan isu ini dengan dua carta. Dan anda sudah boleh menghubungi pentadbir yang bertugas menggunakan mereka.
Tetapi satu lagi masalah kekal - untuk memastikan penghapusan cepat punca kejadian.
Penyelesaian insiden
Keseluruhan proses daripada mengenal pasti hingga menyelesaikan masalah boleh dibahagikan kepada beberapa langkah:
- mengenal pasti masalah;
- pemberitahuan kepada pentadbir bertugas;
- tindak balas kepada kejadian;
- penghapusan punca.
Adalah penting bahawa kita mesti melakukan ini secepat mungkin. Dan jika pada peringkat mengenal pasti masalah dan menghantar pemberitahuan kami tidak dapat memperoleh banyak masa - dua minit akan dibelanjakan untuk mereka dalam apa jua keadaan, maka yang berikutnya hanyalah medan yang dibajak untuk penambahbaikan.
Cuba kita bayangkan telefon pegawai bertugas itu berbunyi. Apa yang akan dia lakukan? Cari jawapan kepada soalan - apa yang pecah, di mana ia pecah, bagaimana untuk bertindak balas? Begini cara kami menjawab soalan ini:
Kami hanya memasukkan semua maklumat ini dalam teks pemberitahuan, memberikannya pautan ke halaman wiki yang menerangkan cara bertindak balas kepada masalah ini, cara menyelesaikannya dan meningkatkannya.
Saya masih belum mengatakan apa-apa tentang lapisan aplikasi dan logik perniagaan. Malangnya, aplikasi kami belum lagi melaksanakan pengumpulan metrik. Satu-satunya sumber maklumat daripada peringkat ini ialah log.
Beberapa mata.
Pertama, tulis log berstruktur. Tidak perlu memasukkan konteks dalam teks mesej. Ini menjadikan mereka sukar untuk dikumpulkan dan dianalisis. Logstash mengambil masa yang lama untuk menormalkan semua ini.
Kedua, gunakan tahap keterukan dengan betul. Setiap bahasa mempunyai standard tersendiri. Secara peribadi, saya membezakan empat peringkat:
- tiada kesilapan;
- ralat pihak pelanggan;
- kesilapan ada di pihak kami, kami tidak kehilangan wang, kami tidak menanggung risiko;
- Kesilapan di pihak kita, kita rugi.
Biar saya ringkaskan. Anda perlu cuba membina pemantauan berdasarkan logik perniagaan. Cuba pantau aplikasi itu sendiri dan beroperasi dengan metrik seperti bilangan jualan, bilangan pendaftaran pengguna baharu, bilangan pengguna aktif pada masa ini dan sebagainya.
Jika keseluruhan perniagaan anda adalah satu butang dalam penyemak imbas, anda perlu memantau sama ada ia mengklik dan berfungsi dengan betul. Semua yang lain tidak penting.
Jika anda tidak mempunyai ini, anda boleh cuba mengejarnya dalam log aplikasi, log Nginx dan sebagainya, seperti yang kami lakukan. Anda harus berada sedekat mungkin dengan aplikasi.
Metrik sistem pengendalian sudah tentu penting, tetapi perniagaan tidak berminat dengannya, kami tidak dibayar untuknya.
Sumber: www.habr.com