Kami berfikir tentang mewujudkan sistem pemantauan pada peringkat membentuk pasukan produk. Ia menjadi jelas bahawa perniagaan kami - eksploitasi - tidak termasuk dalam pasukan ini. Kenapa begitu?
Hakikatnya ialah semua pasukan kami dibina berdasarkan sistem maklumat individu, perkhidmatan mikro dan bahagian hadapan, jadi pasukan tidak melihat kesihatan keseluruhan keseluruhan sistem secara keseluruhan. Contohnya, mereka mungkin tidak tahu bagaimana sebahagian kecil di bahagian belakang dalam mempengaruhi bahagian hadapan. Skop kepentingan mereka terhad kepada sistem yang sistem mereka disepadukan. Jika pasukan dan perkhidmatan Anya hampir tiada kaitan dengan perkhidmatan B, maka perkhidmatan sedemikian hampir tidak dapat dilihat oleh pasukan itu.
Pasukan kami pula bekerja dengan sistem yang sangat terintegrasi antara satu sama lain: terdapat banyak sambungan antara mereka, ini adalah infrastruktur yang sangat besar. Dan operasi kedai dalam talian bergantung pada semua sistem ini (yang kami ada, dengan cara itu, sejumlah besar).
Jadi ternyata jabatan kami bukan milik mana-mana pasukan, tetapi terletak sedikit di tepi. Dalam keseluruhan cerita ini, tugas kami adalah untuk memahami secara menyeluruh cara sistem maklumat berfungsi, fungsinya, penyepaduan, perisian, rangkaian, perkakasan dan cara semua ini disambungkan antara satu sama lain.
Platform di mana kedai dalam talian kami beroperasi kelihatan seperti ini:
- depan
- pejabat tengah
- pejabat belakang
Tidak kira berapa banyak yang kita mahu, ia tidak berlaku bahawa semua sistem berfungsi dengan lancar dan sempurna. Intinya, sekali lagi, ialah bilangan sistem dan penyepaduan - dengan sesuatu seperti kami, beberapa insiden tidak dapat dielakkan, walaupun kualiti ujian. Selain itu, kedua-duanya dalam sistem yang berasingan dan dari segi integrasi mereka. Dan anda perlu memantau keadaan keseluruhan platform secara menyeluruh, dan bukan hanya mana-mana bahagian individu daripadanya.
Sebaik-baiknya, pemantauan kesihatan seluruh platform harus diautomasikan. Dan kami datang untuk memantau sebagai bahagian yang tidak dapat dielakkan dalam proses ini. Pada mulanya, ia dibina hanya untuk bahagian barisan hadapan, manakala pakar rangkaian, pentadbir perisian dan perkakasan mempunyai dan masih mempunyai sistem pemantauan lapisan demi lapisan mereka sendiri. Semua orang ini mengikuti pemantauan hanya pada tahap mereka sendiri; tiada sesiapa pun yang mempunyai pemahaman yang menyeluruh.
Sebagai contoh, jika mesin maya ranap, dalam kebanyakan kes hanya pentadbir yang bertanggungjawab untuk perkakasan dan mesin maya mengetahuinya. Dalam kes sedemikian, pasukan barisan hadapan melihat hakikat ranap aplikasi, tetapi ia tidak mempunyai data tentang ranap mesin maya. Dan pentadbir boleh mengetahui siapa pelanggan itu dan mempunyai idea kasar tentang apa yang sedang berjalan pada mesin maya ini, dengan syarat ia adalah sejenis projek besar. Dia kemungkinan besar tidak tahu tentang anak-anak kecil. Walau apa pun, pentadbir perlu pergi ke pemilik dan bertanya apa yang ada pada mesin ini, apa yang perlu dipulihkan dan apa yang perlu diubah. Dan jika sesuatu yang benar-benar serius rosak, mereka mula berlari dalam bulatan - kerana tiada siapa yang melihat sistem secara keseluruhan.
Akhirnya, cerita yang berbeza itu menjejaskan keseluruhan bahagian hadapan, pengguna dan fungsi perniagaan teras kami - jualan dalam talian. Memandangkan kami bukan sebahagian daripada pasukan, tetapi terlibat dalam pengendalian semua aplikasi e-dagang sebagai sebahagian daripada kedai dalam talian, kami mengambil tugas untuk mencipta sistem pemantauan yang komprehensif untuk platform e-dagang.
Struktur sistem dan timbunan
Kami bermula dengan mengenal pasti beberapa lapisan pemantauan untuk sistem kami, di mana kami perlu mengumpul metrik. Dan semua ini perlu digabungkan, itulah yang kami lakukan pada peringkat pertama. Kini pada peringkat ini kami sedang memuktamadkan koleksi metrik berkualiti tinggi merentas semua lapisan kami untuk membina korelasi dan memahami cara sistem mempengaruhi satu sama lain.
Kekurangan pemantauan menyeluruh pada peringkat awal pelancaran aplikasi (sejak kami mula membinanya apabila kebanyakan sistem sedang dalam pengeluaran) membawa kepada fakta bahawa kami mempunyai hutang teknikal yang besar untuk menyediakan pemantauan ke atas seluruh platform. Kami tidak mampu untuk menumpukan pada menyediakan pemantauan untuk satu IS dan menjalankan pemantauan untuknya secara terperinci, kerana sistem yang lain akan dibiarkan tanpa pemantauan untuk beberapa lama. Untuk menyelesaikan masalah ini, kami mengenal pasti senarai metrik yang paling diperlukan untuk menilai keadaan sistem maklumat mengikut lapisan dan mula melaksanakannya.
Oleh itu, mereka memutuskan untuk memakan gajah itu secara berpecah-belah.
Sistem kami terdiri daripada:
- perkakasan;
- sistem operasi;
- perisian;
- Bahagian UI dalam aplikasi pemantauan;
- metrik perniagaan;
- aplikasi integrasi;
- keselamatan maklumat;
- rangkaian;
- pengimbang trafik.
Di tengah-tengah sistem ini adalah memantau dirinya sendiri. Untuk memahami secara am keadaan keseluruhan sistem, anda perlu mengetahui perkara yang berlaku dengan aplikasi pada semua lapisan ini dan merentas keseluruhan set aplikasi.
Jadi, mengenai timbunan.
Kami menggunakan perisian sumber terbuka. Di pusat kami mempunyai Zabbix, yang kami gunakan terutamanya sebagai sistem amaran. Semua orang tahu bahawa ia sesuai untuk pemantauan infrastruktur. Apakah maksud ini? Persis metrik peringkat rendah yang dimiliki oleh setiap syarikat yang mengekalkan pusat datanya sendiri (dan Sportmaster mempunyai pusat data sendiri) - suhu pelayan, status memori, serbuan, metrik peranti rangkaian.
Kami telah menyepadukan Zabbix dengan messenger Telegram dan Microsoft Teams, yang digunakan secara aktif dalam pasukan. Zabbix merangkumi lapisan rangkaian sebenar, perkakasan dan beberapa perisian, tetapi ia bukan ubat penawar. Kami memperkayakan data ini daripada beberapa perkhidmatan lain. Sebagai contoh, pada peringkat perkakasan, kami menyambung terus melalui API ke sistem virtualisasi kami dan mengumpul data.
Apa lagi. Selain Zabbix, kami menggunakan Prometheus, yang membolehkan kami memantau metrik dalam aplikasi persekitaran dinamik. Maksudnya, kami boleh menerima metrik aplikasi melalui titik akhir HTTP dan tidak bimbang tentang metrik yang hendak dimuatkan ke dalamnya dan yang tidak. Berdasarkan data ini, pertanyaan analisis boleh dibangunkan.
Sumber data untuk lapisan lain, contohnya, metrik perniagaan, dibahagikan kepada tiga komponen.
Pertama, ini adalah sistem perniagaan luaran, Google Analytics, kami mengumpul metrik daripada log. Daripada mereka, kami mendapat data tentang pengguna aktif, penukaran dan semua perkara lain yang berkaitan dengan perniagaan. Kedua, ini adalah sistem pemantauan UI. Ia harus diterangkan dengan lebih terperinci.
Pada suatu masa dahulu kami bermula dengan ujian manual dan ia berkembang menjadi ujian automatik kefungsian dan penyepaduan. Daripada ini kami membuat pemantauan, hanya meninggalkan fungsi utama dan bergantung pada penanda yang sestabil mungkin dan tidak sering berubah dari semasa ke semasa.
Struktur pasukan baharu bermakna semua aktiviti aplikasi terhad kepada pasukan produk, jadi kami berhenti melakukan ujian tulen. Sebaliknya, kami membuat pemantauan UI daripada ujian, yang ditulis dalam Java, Selenium dan Jenkins (digunakan sebagai sistem untuk melancarkan dan menjana laporan).
Kami mempunyai banyak ujian, tetapi akhirnya kami memutuskan untuk pergi ke jalan utama, metrik peringkat teratas. Dan jika kita mempunyai banyak ujian khusus, sukar untuk memastikan data dikemas kini. Setiap keluaran berikutnya akan memecahkan keseluruhan sistem dengan ketara, dan apa yang akan kami lakukan ialah membetulkannya. Oleh itu, kami memberi tumpuan kepada perkara yang sangat asas yang jarang berubah, dan kami hanya memantaunya.
Akhir sekali, ketiga, sumber data ialah sistem pembalakan berpusat. Kami menggunakan Tindanan Elastik untuk log, dan kemudian kami boleh menarik data ini ke dalam sistem pemantauan kami untuk metrik perniagaan. Sebagai tambahan kepada semua ini, kami mempunyai perkhidmatan API Pemantauan kami sendiri, yang ditulis dalam Python, yang menanyakan sebarang perkhidmatan melalui API dan mengumpul data daripadanya ke dalam Zabbix.
Satu lagi sifat pemantauan yang sangat diperlukan ialah visualisasi. Kami adalah berdasarkan Grafana. Ia menonjol antara sistem visualisasi lain kerana ia membolehkan anda memvisualisasikan metrik daripada sumber data yang berbeza pada papan pemuka. Kami boleh mengumpulkan metrik peringkat atas untuk kedai dalam talian, contohnya, bilangan pesanan yang dibuat dalam sejam terakhir daripada DBMS, metrik prestasi untuk OS yang kedai dalam talian ini dijalankan dari Zabbix dan metrik untuk contoh aplikasi ini daripada Prometheus. Dan semua ini akan berada pada satu papan pemuka. Jelas dan boleh diakses.
Biar saya ambil perhatian tentang keselamatan - kami sedang memuktamadkan sistem, yang kemudiannya akan kami sepadukan dengan sistem pemantauan global. Pada pendapat saya, masalah utama yang dihadapi oleh e-dagang dalam bidang keselamatan maklumat adalah berkaitan dengan bot, parser dan brute force. Kami perlu memerhatikan perkara ini, kerana semua ini boleh menjejaskan operasi aplikasi kami dan reputasi kami secara kritikal dari sudut perniagaan. Dan dengan timbunan yang dipilih kami berjaya menampung tugasan ini.
Satu lagi perkara penting ialah lapisan aplikasi dipasang oleh Prometheus. Dia sendiri juga diintegrasikan dengan Zabbix. Dan kami juga mempunyai kelajuan tapak, perkhidmatan yang membolehkan kami melihat parameter seperti kelajuan pemuatan halaman kami, kesesakan, pemaparan halaman, pemuatan skrip, dll., ia juga disepadukan dengan API. Jadi metrik kami dikumpulkan dalam Zabbix, dan sewajarnya, kami juga memberi amaran dari sana. Semua makluman kini dihantar ke kaedah penghantaran utama (buat masa ini ia adalah e-mel dan telegram, MS Teams juga baru-baru ini telah disambungkan). Terdapat rancangan untuk meningkatkan amaran kepada keadaan sedemikian bahawa bot pintar berfungsi sebagai perkhidmatan dan menyediakan maklumat pemantauan kepada semua pasukan produk yang berminat.
Bagi kami, metrik adalah penting bukan sahaja untuk sistem maklumat individu, tetapi juga metrik umum untuk keseluruhan infrastruktur yang digunakan oleh aplikasi: kelompok pelayan fizikal di mana mesin maya dijalankan, pengimbang trafik, Pengimbang Beban Rangkaian, rangkaian itu sendiri, penggunaan saluran komunikasi . Ditambah metrik untuk pusat data kami sendiri (kami mempunyai beberapa daripadanya dan infrastrukturnya agak besar).
Kelebihan sistem pemantauan kami ialah dengan bantuannya kami melihat status kesihatan semua sistem dan boleh menilai kesannya terhadap satu sama lain dan pada sumber yang dikongsi. Dan akhirnya, ia membolehkan kami melibatkan diri dalam perancangan sumber, yang juga merupakan tanggungjawab kami. Kami menguruskan sumber pelayan - kumpulan dalam e-dagang, komisen dan penyahtauliahan peralatan baharu, membeli peralatan baharu tambahan, menjalankan audit penggunaan sumber, dsb. Setiap tahun, pasukan merancang projek baharu, membangunkan sistem mereka, dan adalah penting untuk kami menyediakan sumber kepada mereka.
Dan dengan bantuan metrik, kami melihat arah aliran dalam penggunaan sumber oleh sistem maklumat kami. Dan berdasarkan mereka kita boleh merancang sesuatu. Pada peringkat virtualisasi, kami mengumpul data dan melihat maklumat tentang jumlah sumber yang tersedia oleh pusat data. Dan sudah di dalam pusat data anda boleh melihat kitar semula, pengedaran sebenar dan penggunaan sumber. Lebih-lebih lagi, kedua-duanya dengan pelayan kendiri dan mesin maya dan kelompok pelayan fizikal di mana semua mesin maya ini berputar dengan kuat.
Prospek
Kini kami mempunyai teras sistem secara keseluruhannya bersedia, tetapi masih banyak perkara yang masih perlu diusahakan. Sekurang-kurangnya, ini adalah lapisan keselamatan maklumat, tetapi ia juga penting untuk mencapai rangkaian, membangunkan amaran dan menyelesaikan isu korelasi. Kami mempunyai banyak lapisan dan sistem, dan pada setiap lapisan terdapat lebih banyak metrik. Ia ternyata menjadi matryoshka kepada tahap matryoshka.
Tugas kami adalah untuk membuat makluman yang betul. Sebagai contoh, jika terdapat masalah dengan perkakasan, sekali lagi, dengan mesin maya, dan terdapat aplikasi penting, dan perkhidmatan itu tidak disandarkan dalam apa jua cara. Kami mendapati bahawa mesin maya telah mati. Kemudian metrik perniagaan akan memaklumkan anda: pengguna telah hilang entah ke mana, tiada penukaran, UI dalam antara muka tidak tersedia, perisian dan perkhidmatan juga telah mati.
Dalam keadaan ini, kami akan menerima spam daripada makluman, dan ini tidak lagi sesuai dengan format sistem pemantauan yang betul. Persoalan korelasi timbul. Oleh itu, sebaik-baiknya, sistem pemantauan kami harus berkata: "Kawan-kawan, mesin fizikal anda telah mati, dan bersama-sama dengannya aplikasi ini dan metrik ini," dengan bantuan satu amaran, dan bukannya menyerang kami dengan seratus amaran. Ia harus melaporkan perkara utama - punca, yang membantu dengan cepat menghapuskan masalah kerana penyetempatannya.
Sistem pemberitahuan dan pemprosesan amaran kami dibina di sekitar perkhidmatan talian hotline XNUMX jam. Semua makluman yang dianggap mesti ada dan termasuk dalam senarai semak dihantar ke sana. Setiap makluman mesti mempunyai penerangan: apa yang berlaku, maksud sebenarnya, kesannya. Dan juga pautan ke papan pemuka dan arahan tentang perkara yang perlu dilakukan dalam kes ini.
Ini semua tentang keperluan untuk membina amaran. Kemudian keadaan boleh berkembang dalam dua arah - sama ada terdapat masalah dan perlu diselesaikan, atau terdapat kegagalan dalam sistem pemantauan. Tetapi dalam apa jua keadaan, anda perlu pergi dan memikirkannya.
Secara purata, kami kini menerima kira-kira seratus makluman setiap hari, dengan mengambil kira hakikat bahawa korelasi makluman masih belum dikonfigurasikan dengan betul. Dan jika kita perlu menjalankan kerja teknikal, dan kita mematikan sesuatu secara paksa, bilangan mereka meningkat dengan ketara.
Selain memantau sistem yang kami kendalikan dan mengumpul metrik yang dianggap penting di pihak kami, sistem pemantauan membolehkan kami mengumpul data untuk pasukan produk. Mereka boleh mempengaruhi komposisi metrik dalam sistem maklumat yang kami pantau.
Rakan sekerja kami mungkin datang dan meminta untuk menambah beberapa metrik yang berguna untuk kami dan pasukan. Atau, sebagai contoh, pasukan mungkin tidak mempunyai cukup metrik asas yang kita ada; mereka perlu menjejaki beberapa metrik tertentu. Dalam Grafana, kami mencipta ruang untuk setiap pasukan dan memberikan hak pentadbir. Selain itu, jika pasukan memerlukan papan pemuka, tetapi mereka sendiri tidak boleh/tidak tahu cara melakukannya, kami membantu mereka.
Memandangkan kami berada di luar aliran penciptaan nilai pasukan, keluaran dan perancangan mereka, kami secara beransur-ansur membuat kesimpulan bahawa keluaran semua sistem adalah lancar dan boleh dilancarkan setiap hari tanpa penyelarasan dengan kami. Dan adalah penting bagi kami untuk memantau keluaran ini, kerana ia boleh menjejaskan pengendalian aplikasi dan merosakkan sesuatu, dan ini adalah kritikal. Untuk mengurus keluaran, kami menggunakan Bamboo, dari mana kami menerima data melalui API dan boleh melihat keluaran yang telah dikeluarkan dalam sistem maklumat dan statusnya. Dan yang paling penting ialah pada pukul berapa. Kami meletakkan penanda keluaran pada metrik kritikal utama, yang secara visual sangat menunjukkan sekiranya berlaku masalah.
Dengan cara ini kita dapat melihat perkaitan antara keluaran baharu dan masalah yang muncul. Idea utama adalah untuk memahami cara sistem berfungsi pada semua lapisan, menyetempatkan masalah dengan cepat dan membetulkannya dengan cepat. Lagipun, sering berlaku bahawa apa yang paling banyak mengambil masa bukanlah menyelesaikan masalah, tetapi mencari punca.
Dan dalam bidang ini pada masa akan datang kami ingin memberi tumpuan kepada proaktif. Sebaik-baiknya, saya ingin mengetahui tentang masalah yang menghampiri lebih awal, dan bukan selepas fakta, supaya saya boleh mencegahnya daripada menyelesaikannya. Kadangkala penggera palsu sistem pemantauan berlaku, kedua-duanya disebabkan oleh kesilapan manusia dan disebabkan oleh perubahan dalam aplikasi. Dan kami mengusahakannya, menyahpepijatnya dan cuba memberi amaran kepada pengguna yang menggunakannya bersama kami tentang perkara ini sebelum sebarang manipulasi sistem pemantauan , atau jalankan aktiviti ini dalam tetingkap teknikal.
Jadi, sistem ini telah dilancarkan dan telah berfungsi dengan jayanya sejak awal musim bunga... dan menunjukkan keuntungan yang sangat nyata. Sudah tentu, ini bukan versi terakhirnya; kami akan memperkenalkan lebih banyak ciri berguna. Tetapi sekarang, dengan begitu banyak penyepaduan dan aplikasi, pemantauan automasi benar-benar tidak dapat dielakkan.
Jika anda juga memantau projek besar dengan bilangan integrasi yang ketara, tulis dalam komen apakah peluru perak yang anda temui untuk ini.
Sumber: www.habr.com