Kami berpikir untuk membuat sistem pemantauan pada tahap pembentukan tim produk. Menjadi jelas bahwa bisnis kami - eksploitasi - tidak termasuk dalam tim ini. Mengapa demikian?
Faktanya adalah bahwa semua tim kami dibangun berdasarkan sistem informasi individual, layanan mikro, dan front, sehingga tim tidak melihat kesehatan keseluruhan sistem secara keseluruhan. Misalnya, mereka mungkin tidak tahu bagaimana beberapa bagian kecil di bagian belakang mempengaruhi bagian depan. Ruang lingkup minat mereka terbatas pada sistem yang terintegrasi dengan sistem mereka. Jika sebuah tim dan layanan A-nya hampir tidak memiliki koneksi dengan layanan B, maka layanan tersebut hampir tidak terlihat oleh tim.
Tim kami, pada gilirannya, bekerja dengan sistem yang sangat terintegrasi satu sama lain: ada banyak koneksi di antara mereka, ini adalah infrastruktur yang sangat besar. Dan pengoperasian toko online bergantung pada semua sistem ini (yang kami miliki, jumlah yang sangat besar).
Jadi ternyata departemen kita bukan milik tim mana pun, melainkan letaknya agak ke samping. Dalam keseluruhan cerita ini, tugas kita adalah memahami secara komprehensif cara kerja sistem informasi, fungsinya, integrasinya, perangkat lunak, jaringan, perangkat keras, dan bagaimana semua ini terhubung satu sama lain.
Platform tempat toko online kami beroperasi terlihat seperti ini:
- depan
- kantor Tengah
- back-office
Betapapun kita menginginkannya, tidak semua sistem bekerja dengan lancar dan tanpa cacat. Intinya, sekali lagi, adalah jumlah sistem dan integrasi - dengan sistem seperti milik kita, beberapa insiden tidak dapat dihindari, terlepas dari kualitas pengujiannya. Apalagi baik dalam sistem yang terpisah maupun dalam hal integrasinya. Dan Anda perlu memantau keadaan seluruh platform secara komprehensif, dan bukan sembarang bagian saja.
Idealnya, pemantauan kesehatan seluruh platform harus dilakukan secara otomatis. Dan kami menganggap pemantauan sebagai bagian yang tak terhindarkan dari proses ini. Awalnya, ini dibangun hanya untuk bagian garis depan, sementara spesialis jaringan, administrator perangkat lunak dan perangkat keras memiliki dan masih memiliki sistem pemantauan lapis demi lapis sendiri. Semua orang ini mengikuti pemantauan hanya pada tingkat mereka sendiri; tidak ada seorang pun yang memiliki pemahaman komprehensif.
Misalnya, jika mesin virtual mogok, dalam banyak kasus hanya administrator yang bertanggung jawab atas perangkat keras dan mesin virtual yang mengetahuinya. Dalam kasus seperti itu, tim garis depan melihat fakta kerusakan aplikasi, namun tidak memiliki data tentang kerusakan mesin virtual. Dan administrator dapat mengetahui siapa pelanggannya dan memiliki gambaran kasar tentang apa yang sedang berjalan di mesin virtual ini, asalkan itu adalah proyek besar. Dia kemungkinan besar tidak tahu tentang anak-anak kecil. Bagaimanapun, administrator harus menemui pemiliknya dan menanyakan apa yang ada di mesin ini, apa yang perlu dipulihkan dan apa yang perlu diubah. Dan jika sesuatu yang sangat serius rusak, mereka mulai berlarian - karena tidak ada yang melihat sistem secara keseluruhan.
Pada akhirnya, cerita yang berbeda-beda tersebut memengaruhi keseluruhan frontend, pengguna, dan fungsi bisnis inti kami β penjualan online. Karena kami bukan bagian dari tim, namun terlibat dalam pengoperasian semua aplikasi e-niaga sebagai bagian dari toko online, kami mengambil tugas untuk menciptakan sistem pemantauan komprehensif untuk platform e-niaga.
Struktur sistem dan tumpukan
Kami memulai dengan mengidentifikasi beberapa lapisan pemantauan untuk sistem kami, yang di dalamnya kami perlu mengumpulkan metrik. Dan semua ini perlu digabungkan, itulah yang kami lakukan pada tahap pertama. Saat ini, pada tahap ini kami sedang menyelesaikan kumpulan metrik dengan kualitas terbaik di seluruh lapisan kami untuk membangun korelasi dan memahami bagaimana sistem saling memengaruhi.
Kurangnya pemantauan komprehensif pada tahap awal peluncuran aplikasi (sejak kami mulai membangunnya ketika sebagian besar sistem masih dalam produksi) menyebabkan fakta bahwa kami memiliki hutang teknis yang besar untuk menyiapkan pemantauan seluruh platform. Kami tidak dapat fokus pada pengaturan pemantauan untuk satu IS dan melakukan pemantauan secara rinci, karena sistem lainnya akan dibiarkan tanpa pemantauan selama beberapa waktu. Untuk mengatasi masalah ini, kami mengidentifikasi daftar metrik yang paling diperlukan untuk menilai keadaan sistem informasi berdasarkan lapisan dan mulai menerapkannya.
Oleh karena itu, mereka memutuskan untuk memakan gajah tersebut dalam beberapa bagian.
Sistem kami terdiri dari:
- perangkat keras;
- sistem operasi;
- perangkat lunak;
- Bagian UI dalam aplikasi pemantauan;
- metrik bisnis;
- aplikasi integrasi;
- informasi keamanan;
- jaringan;
- penyeimbang lalu lintas.
Inti dari sistem ini adalah pemantauan itu sendiri. Untuk memahami keadaan keseluruhan sistem secara umum, Anda perlu mengetahui apa yang terjadi dengan aplikasi di semua lapisan ini dan di seluruh rangkaian aplikasi.
Jadi, tentang tumpukan.
Kami menggunakan perangkat lunak sumber terbuka. Di pusatnya kami memiliki Zabbix, yang kami gunakan terutama sebagai sistem peringatan. Semua orang tahu bahwa ini ideal untuk pemantauan infrastruktur. Apa artinya ini? Metrik tingkat rendah yang dimiliki setiap perusahaan yang mengelola pusat datanya sendiri (dan Sportmaster memiliki pusat datanya sendiri) - suhu server, status memori, serangan, metrik perangkat jaringan.
Kami telah mengintegrasikan Zabbix dengan messenger Telegram dan Microsoft Teams, yang secara aktif digunakan dalam tim. Zabbix mencakup lapisan jaringan sebenarnya, perangkat keras dan beberapa perangkat lunak, namun ini bukan obat mujarab. Kami memperkaya data ini dari beberapa layanan lain. Misalnya, di tingkat perangkat keras, kami terhubung langsung melalui API ke sistem virtualisasi kami dan mengumpulkan data.
Apa lagi. Selain Zabbix, kami menggunakan Prometheus, yang memungkinkan kami memantau metrik dalam aplikasi lingkungan dinamis. Artinya, kita dapat menerima metrik aplikasi melalui titik akhir HTTP dan tidak khawatir tentang metrik mana yang akan dimuat ke dalamnya dan mana yang tidak. Berdasarkan data ini, pertanyaan analitis dapat dikembangkan.
Sumber data untuk lapisan lain, misalnya metrik bisnis, dibagi menjadi tiga komponen.
Pertama, ini adalah sistem bisnis eksternal, Google Analytics, kami mengumpulkan metrik dari log. Dari mereka kami mendapatkan data tentang pengguna aktif, konversi, dan segala hal lain yang terkait dengan bisnis. Kedua, ini adalah sistem pemantauan UI. Ini harus dijelaskan lebih terinci.
Dahulu kala kami memulai dengan pengujian manual dan berkembang menjadi pengujian fungsionalitas dan integrasi otomatis. Dari sini kami melakukan pemantauan, hanya menyisakan fungsi utama, dan mengandalkan penanda yang sestabil mungkin dan tidak sering berubah seiring waktu.
Struktur tim yang baru berarti semua aktivitas aplikasi dibatasi pada tim produk, jadi kami berhenti melakukan pengujian murni. Sebagai gantinya, kami melakukan pemantauan UI dari pengujian yang ditulis dalam Java, Selenium, dan Jenkins (digunakan sebagai sistem untuk meluncurkan dan menghasilkan laporan).
Kami menjalani banyak tes, tetapi pada akhirnya kami memutuskan untuk pergi ke jalan utama, metrik tingkat atas. Dan jika kita memiliki banyak pengujian khusus, akan sulit untuk selalu memperbarui data. Setiap rilis berikutnya akan merusak keseluruhan sistem secara signifikan, dan yang akan kami lakukan hanyalah memperbaikinya. Oleh karena itu, kami fokus pada hal-hal yang sangat mendasar yang jarang berubah, dan kami hanya memantaunya.
Terakhir, ketiga, sumber datanya adalah sistem logging terpusat. Kami menggunakan Elastic Stack untuk log, dan kemudian kami dapat menarik data ini ke dalam sistem pemantauan kami untuk metrik bisnis. Selain semua ini, kami memiliki layanan API Pemantauan kami sendiri, yang ditulis dengan Python, yang menanyakan layanan apa pun melalui API dan mengumpulkan data dari layanan tersebut ke Zabbix.
Atribut pemantauan lainnya yang sangat diperlukan adalah visualisasi. Milik kami didasarkan pada Grafana. Ini menonjol di antara sistem visualisasi lainnya karena memungkinkan Anda memvisualisasikan metrik dari berbagai sumber data di dasbor. Kami dapat mengumpulkan metrik tingkat atas untuk sebuah toko online, misalnya, jumlah pesanan yang dilakukan dalam satu jam terakhir dari DBMS, metrik kinerja untuk OS yang menjalankan toko online ini dari Zabbix, dan metrik untuk instance aplikasi ini. dari Prometheus. Dan semua ini akan ada di satu dashboard. Jelas dan mudah diakses.
Izinkan saya mencatat tentang keamanan - kami sedang menyelesaikan sistem, yang nantinya akan kami integrasikan dengan sistem pemantauan global. Menurut saya, permasalahan utama yang dihadapi e-commerce di bidang keamanan informasi terkait dengan bot, parser, dan brute force. Kita perlu mewaspadai hal ini, karena semua ini dapat berdampak buruk pada pengoperasian aplikasi kita dan reputasi kita dari sudut pandang bisnis. Dan dengan tumpukan yang dipilih kami berhasil menyelesaikan tugas-tugas ini.
Poin penting lainnya adalah lapisan aplikasi dirakit oleh Prometheus. Ia sendiri juga terintegrasi dengan Zabbix. Dan kami juga memiliki kecepatan situs, layanan yang memungkinkan kami melihat parameter seperti kecepatan memuat halaman, kemacetan, rendering halaman, memuat skrip, dll., juga terintegrasi dengan API. Jadi metrik kami dikumpulkan di Zabbix, dan karenanya, kami juga memberi peringatan dari sana. Semua peringatan saat ini dikirim ke metode pengiriman utama (untuk saat ini email dan telegram, MS Teams juga baru-baru ini terhubung). Ada rencana untuk meningkatkan peringatan sedemikian rupa sehingga bot pintar berfungsi sebagai layanan dan memberikan informasi pemantauan kepada semua tim produk yang tertarik.
Bagi kami, metrik penting tidak hanya untuk sistem informasi individual, tetapi juga metrik umum untuk seluruh infrastruktur yang digunakan aplikasi: cluster server fisik tempat mesin virtual berjalan, penyeimbang lalu lintas, Network Load Balancer, jaringan itu sendiri, pemanfaatan saluran komunikasi . Ditambah metrik untuk pusat data kami sendiri (kami memiliki beberapa di antaranya dan infrastrukturnya cukup besar).
Keuntungan dari sistem pemantauan kami adalah dengan bantuannya kami dapat melihat status kesehatan semua sistem dan dapat menilai dampaknya terhadap satu sama lain dan terhadap sumber daya bersama. Dan pada akhirnya, hal ini memungkinkan kami untuk terlibat dalam perencanaan sumber daya, yang juga merupakan tanggung jawab kami. Kami mengelola sumber daya server - kumpulan dalam e-niaga, menugaskan dan menonaktifkan peralatan baru, membeli peralatan baru tambahan, melakukan audit pemanfaatan sumber daya, dll. Setiap tahun, tim merencanakan proyek baru, mengembangkan sistem mereka, dan penting bagi kami untuk menyediakan sumber daya bagi mereka.
Dan dengan bantuan metrik, kami melihat tren konsumsi sumber daya oleh sistem informasi kami. Dan berdasarkan mereka kita bisa merencanakan sesuatu. Pada tingkat virtualisasi, kami mengumpulkan data dan melihat informasi mengenai jumlah sumber daya yang tersedia berdasarkan pusat data. Dan sudah di dalam pusat data Anda dapat melihat daur ulang, distribusi aktual, dan konsumsi sumber daya. Selain itu, baik dengan server mandiri maupun mesin virtual, serta cluster server fisik tempat semua mesin virtual ini berputar dengan penuh semangat.
Prospek
Sekarang inti sistem secara keseluruhan sudah siap, namun masih banyak hal yang masih perlu diperbaiki. Minimal, ini adalah lapisan keamanan informasi, tetapi penting juga untuk menjangkau jaringan, mengembangkan peringatan, dan menyelesaikan masalah korelasi. Kami memiliki banyak lapisan dan sistem, dan pada setiap lapisan terdapat lebih banyak metrik. Ternyata itu adalah matryoshka setingkat matryoshka.
Tugas kita pada akhirnya adalah membuat peringatan yang tepat. Misalnya, jika ada masalah dengan perangkat keras, sekali lagi, dengan mesin virtual, dan ada aplikasi penting, dan layanan tidak dicadangkan dengan cara apa pun. Kami mengetahui bahwa mesin virtual telah mati. Kemudian metrik bisnis akan mengingatkan Anda: pengguna menghilang entah kemana, tidak ada konversi, UI di antarmuka tidak tersedia, perangkat lunak dan layanan juga mati.
Dalam situasi ini, kami akan menerima spam dari peringatan, dan ini tidak lagi sesuai dengan format sistem pemantauan yang tepat. Pertanyaan tentang korelasi muncul. Oleh karena itu, idealnya, sistem pemantauan kita harus mengatakan: βTeman-teman, mesin fisik Anda telah mati, dan bersamaan dengan itu aplikasi dan metrik ini,β dengan bantuan satu peringatan, alih-alih membombardir kita dengan ratusan peringatan. Ini harus melaporkan hal utama - penyebabnya, yang membantu menghilangkan masalah dengan cepat karena lokalisasinya.
Sistem notifikasi dan pemrosesan peringatan kami dibangun berdasarkan layanan hotline XNUMX jam. Semua peringatan yang dianggap harus dimiliki dan termasuk dalam daftar periksa dikirim ke sana. Setiap peringatan harus mempunyai deskripsi: apa yang terjadi, apa arti sebenarnya, apa pengaruhnya. Dan juga tautan ke dasbor dan petunjuk tentang apa yang harus dilakukan dalam kasus ini.
Ini semua tentang persyaratan untuk membangun peringatan. Situasi kemudian dapat berkembang dalam dua arah - apakah ada masalah dan perlu diselesaikan, atau ada kegagalan dalam sistem pemantauan. Tapi bagaimanapun juga, Anda harus pergi dan mencari tahu.
Rata-rata, kami sekarang menerima sekitar seratus lansiran per hari, dengan mempertimbangkan fakta bahwa korelasi lansiran belum dikonfigurasi dengan benar. Dan jika kita perlu melakukan pekerjaan teknis, dan kita mematikan sesuatu secara paksa, jumlahnya meningkat secara signifikan.
Selain memantau sistem yang kami operasikan dan mengumpulkan metrik yang dianggap penting bagi kami, sistem pemantauan memungkinkan kami mengumpulkan data untuk tim produk. Hal ini dapat mempengaruhi komposisi metrik dalam sistem informasi yang kami pantau.
Rekan kami mungkin datang dan meminta untuk menambahkan beberapa metrik yang akan berguna bagi kami dan tim. Atau, misalnya, tim mungkin tidak memiliki cukup metrik dasar yang kita miliki; mereka perlu melacak beberapa metrik tertentu. Di Grafana, kami membuat ruang untuk setiap tim dan memberikan hak admin. Selain itu, jika sebuah tim membutuhkan dashboard, tetapi mereka sendiri tidak bisa/tidak tahu cara melakukannya, kami membantu mereka.
Karena kami berada di luar alur penciptaan nilai, rilis, dan perencanaan tim, kami secara bertahap sampai pada kesimpulan bahwa rilis semua sistem berjalan lancar dan dapat diluncurkan setiap hari tanpa koordinasi dengan kami. Dan penting bagi kami untuk memantau rilis ini, karena rilis tersebut berpotensi memengaruhi pengoperasian aplikasi dan merusak sesuatu, dan ini sangat penting. Untuk mengelola rilis, kami menggunakan Bamboo, tempat kami menerima data melalui API dan dapat melihat rilis mana yang telah dirilis, sistem informasi apa, dan statusnya. Dan yang paling penting adalah jam berapa. Kami menempatkan penanda rilis pada metrik penting utama, yang secara visual sangat indikatif jika terjadi masalah.
Dengan cara ini kita dapat melihat korelasi antara rilis baru dan masalah yang muncul. Ide utamanya adalah untuk memahami cara kerja sistem di semua lapisan, dengan cepat melokalisasi masalah dan memperbaikinya dengan cepat. Lagi pula, sering kali yang memakan waktu paling lama bukanlah menyelesaikan masalah, melainkan mencari penyebabnya.
Dan di bidang ini di masa depan kami ingin fokus pada proaktif. Idealnya, saya ingin mengetahui masalah yang akan terjadi sebelumnya, dan bukan setelah kejadiannya, sehingga saya dapat mencegahnya daripada menyelesaikannya. Terkadang alarm palsu pada sistem pemantauan terjadi, baik karena kesalahan manusia maupun karena perubahan dalam aplikasi. Dan kami mengerjakannya, men-debugnya, dan mencoba memperingatkan pengguna yang menggunakannya bersama kami tentang hal ini sebelum melakukan manipulasi apa pun pada sistem pemantauan. , atau melakukan aktivitas ini di jendela teknis.
Jadi, sistem ini telah diluncurkan dan telah bekerja dengan sukses sejak awal musim semi... dan menunjukkan keuntungan yang sangat nyata. Tentu saja, ini bukan versi finalnya; kami akan memperkenalkan lebih banyak fitur berguna. Namun saat ini, dengan banyaknya integrasi dan aplikasi, otomatisasi pemantauan benar-benar tidak dapat dihindari.
Jika Anda juga memantau proyek besar dengan sejumlah besar integrasi, tulis di komentar solusi terbaik yang Anda temukan untuk ini.
Sumber: www.habr.com