Di blog kami, kami berbicara banyak tentang solusi asing untuk pemantauan dan audit, dan sekarang saatnya untuk pembangunan dalam negeri. MONQ adalah sistem payung dengan konektor untuk sistem pemantauan umum, model layanan sumber daya, analisis data, potensi AI tinggi dan model lisensi khusus. Kami diberi distribusi untuk melihat dan kami memutuskan untuk berbagi bagaimana itu ada di bawah tenda dan apakah semuanya nanoteknologi seperti kata vendor (proyek, setelah semua, adalah penduduk Skolkovo). Kehormatan pengujian jatuh kepada saya dan saya akan memberi tahu Anda tentang instalasi, kemampuan sistem dan sedikit tentang perizinan. Saya minta kucing.

Pendahuluan

Pada 2018, Gartner memperkenalkan istilah baru untuk menggambarkan bagaimana kecerdasan buatan (AI) dapat diterapkan untuk dukungan TI. "AIOps (Kecerdasan Buatan untuk Operasi TI) berjanji untuk menghemat waktu dan upaya layanan TI dalam mengidentifikasi berbagai masalah di lingkungan yang semakin kompleks di mana mereka harus bekerja." Gartner menyarankan bahwa AI akan digunakan untuk secara otomatis mengidentifikasi masalah dan memperbaikinya. Pada tahun 2019, ini seperti dongeng, dan saya belum melihat kasus nyata dari dukungan TI yang sepenuhnya otomatis.

Saya mendapatkan platform MONQ dari lab MONQ Digital . Pengembang sendiri memposisikannya sebagai solusi AIOps. Tapi saya akan menyebutnya sistem pemantauan payung, manajemen acara, dan meluncurkan skrip otomatisasi. Belum ada banyak kecerdasan di dalamnya.

Saat bertugas, saya mendukung lebih dari 100 sistem, server, layanan, layanan yang berbeda. Alat pemantauan kasual saya adalah Zabbix dan Prometheus, sebagai mereka mencakup sebagian besar tugas pemantauan kinerja. Beberapa sistem dalam loop pemantauan kadang-kadang berhenti merespons, diperlakukan dengan me-reboot server (tidak ada cara lain, tidak ada yang akan menulis ulang kode kurva). Saya selalu ingin mencoba menerapkan kasus ketika sistem pemantauan mengidentifikasi masalah dari dua sumber independen dan me-restart server itu sendiri. Untuk tugas-tugas seperti itu, sistem payung dengan subsistem scripting biasanya digunakan, karena sekarang modis disebut RPA (Robotic Process Automation). Saya tidak tahu sistem gratis, tetapi yang komersial seperti jembatan besi.

Hari ini kita akan mencoba menginstal MONQ bersama-sama, menghubungkan Zabbix dan Prometheus, mengkonfigurasi peringatan dan menulis skrip reboot server. Sehingga besok Anda bisa dengan tenang melemparkan kaki Anda di atas meja, hanya sesekali menyaksikan proses merawat satu mesin dengan mesin lain dan minum kopi dengan croissant.

Arsitektur Solusi

Arsitektur MONQ

Sistem ini digunakan dalam wadah buruh pelabuhan di kluster kubernetes. Perangkat microservice digabungkan menjadi beberapa blok fungsional. Semua data dari pengguna, informasi teknis, peristiwa, log setelah pengayaan dengan berbagai tag berguna terbang ke danau data di ClickHouse, maka proses perhitungan dan analisis berlangsung. Pola, peristiwa penting terdeteksi, pemicu komposit terbentuk dan berbagai proses penting dapat diluncurkan untuk peristiwa penting: mulai dari peringatan dan insiden hingga skrip pengguna yang rumit.

Membongkar

Youtube penuh dengan video yang membongkar sesuatu. Sekarang saya akan mencoba melakukan hal yang sama, tetapi dalam format teks-gambar dan bukan dengan produk fisik, tetapi dengan distribusi. Untuk memulai, siapkan - instal cluster kubernetes.

Anda dapat membaca tentang menyiapkan cluster kubernetes, misalnya, di sini . Saya akan memberi tahu Anda tentang fitur konfigurasi:

• coredns digunakan sebagai DNS cluster;
• nginx-ingress-controller;
• otorisasi rbac dalam sebuah cluster;
• penyimpanan bersama (pv / pvc) digunakan.

Untuk setiap proyek, vendor menyediakan persyaratan teknis untuk perangkat keras. Konfigurasi minimum untuk instalasi adalah 4 server. Ini cukup untuk melakukan uji coba, dapat diintegrasikan dengan satu sistem pemantauan. Untuk tujuan saya, memeriksa fungsionalitas sistem, opsi ini juga akan berfungsi.

Dalam kondisi pertempuran, seperti yang saya katakan, sistem menyesuaikan dengan kebutuhan pelanggan tergantung pada beban dan toleransi kesalahan yang diperlukan.

Konfigurasi saya untuk sistem minimal:

Setelah platform siap, saya meluncurkan playbook yang memungkinkan vendor untuk menginstal infrastruktur dasar dan meluncurkan sistem. Playbook melakukan hal berikut:

• menginstal paket yang diperlukan di server;
• meluncurkan kubernetes;
• menginstal dan mengkonfigurasi aplikasi di server database. Diantaranya: Clickhouse, RabbitMQ, PostgreSQL, ArangoDB, Redis dan semua ini dalam wadah buruh pelabuhan;
• menginstal Konsul untuk penyimpanan terpusat dari konfigurasi layanan-mikro;
• menambahkan titik akhir, entitas pemasukan layanan untuk DBMS dan bagian infrastruktur sistem;
• menghasilkan tabel dengan data otorisasi.

Agar tidak memulai aplikasi microservice secara manual, vendor telah menyiapkan registri microservice bawaan yang menambah dan memperbarui layanan microser, mengkonfigurasi DBMS, dan otorisasi antar layanan.

Mulai sistem bermuara pada tindakan berikut:

• installer sistem diluncurkan dengan file konfigurasi yang sudah disiapkan sebelumnya (berisi data otorisasi dalam kubernetes, DBMS, dan Konsul, nama domain sistem);
• installer memulai registri microservice;
• menggunakan registri, layanan microser dimulai satu per satu, registri menghasilkan konfigurasi layanan microser di konsul, penyebaran entitas, layanan, masuknya kubernet;
• saat startup, setiap layanan microser memuat skema untuk databasenya sendiri.

Hasil penginstal yang saya luncurkan adalah pada gambar di bawah ini.


Dashboard Kubernetes: hasil penginstal

Setelah proses instalasi selesai, MONQ akan tersedia dengan nama domain yang saya tentukan di file konfigurasi installer. Dan ini dia.


Antarmuka Login MONQ

Kustomisasi

Pada pengaturan awal sistem, sudah ada pengguna dengan hak kontrol penuh. Saya masuk di bawahnya dan melihat apa yang mampu dilakukan MONQ.

Menciptakan pengguna dalam sistem dan mengatur kelompok kerja

Ada dua metode otorisasi pengguna dalam sistem:

• Direktori Aktif
• Dibangun pada.

Untuk kenalan pertama, otorisasi bawaan cocok.


Pengguna Sistem Preset

Hak akses ke objek dan sumber daya sistem (integrasi, unit konfigurasi (KE), pemicu sintetis, skrip, dll.) Dikeluarkan pada tingkat kelompok kerja (Pokja). Setiap WG dapat menjadi pemilik objek atau memiliki hak untuk membaca atau menulis. Ada beberapa tingkat akses:

• Anggota WG dengan tingkat hak pemilik dapat melakukan tindakan apa pun dengan objek (WG dengan tingkat hak ini, objek hanya dapat memiliki satu);
• Seorang WG dengan hak untuk merekam dapat mengelola objek, tetapi tidak dapat menghapusnya dan memberikannya hak kepada WG lain;
• WG read-only dapat melihat informasi tentang suatu objek;
• Seorang WG tanpa hak akses ke suatu objek sama sekali tidak menyadari keberadaannya.

Secara default, sistem telah dibuat WP "Administrator ruang", yang baru saja mengatur pengguna saya. WG ini memiliki hak penuh untuk semua objek yang akan dibuat dalam entitas ini. Untuk kolega yang juga ingin melihat sistem, buat WP Super Administrators tambahan.


Kelompok kerja, peran dan peserta

Hak-hak pengguna tertentu dikonfigurasikan dalam kerangka WG dalam bentuk peran.

Pengaturan PCM

Ini tentang model layanan sumber daya. Ini adalah model layanan logis yang menggambarkan komposisi dan hubungan KEs dengan sumber daya KE, yang bersama-sama menyediakan layanan pada tingkat yang disepakati. PCM diperlukan untuk menyimpan informasi tentang objek, entitas, dan hubungan di antara mereka. PCM di MONQ adalah grafik jaringan yang berisi informasi tentang KEs dan hubungannya.

Perbedaan utama dan, menurut pendapat saya, keuntungan menerapkan PCM dalam sistem adalah fokus pada layanan bisnis. Ini membantu untuk menyajikan struktur lengkap dari layanan atau layanan yang digunakan pengguna akhir, dan tidak fokus pada sistem infrastruktur yang menjadi dasar layanan atau layanan tersebut.

Untuk tujuan pengujian, saya membuat "Akun Pribadi Pengguna" PCM yang disederhanakan.


PCM "Akun pribadi pengguna"

Setelah mengatur pemantauan, saya akan menunjukkan bagaimana itu akan diubah.

Komposisi PCM:

• Mesin virtual tempat sistem informasi (IS) SRVe3_VM15 berjalan;
• STR: Nginx_LK, PHP-fpm_LK, MySQL_LK;
• Layanan kami (SI) - LK (akun pribadi);
• Modul IP: Otorisasi, Pencarian, Manajemen Dokumen, Pembayaran. Sebenarnya, ada lebih banyak dari mereka, tetapi sejauh ini hanya menciptakan ini.

Pengaturan Integrasi

MONQ menyediakan koneksi dari berbagai jenis sistem:

• Sistem pemantauan (Zabbix, Prometheus, SCOM dan lainnya);
• Sistem pengumpulan log (Splunk, Logstash, dan lainnya);
• Sistem peluncuran autotest (Jenkins, Gitlab CI dan lainnya)
• Meja layanan, pelacak tugas (Microfocus SM, Jira, Redmine, Naumen, dan lainnya).

Saya menghubungkan sistem pemantauan Zabbix, Prometheus. Konektor ini dikonfigurasikan di bagian Integrasi.


Integrasi dengan sistem pemantauan

Metrik dan acara berasal dari Zabbix dan Prometheus ke MONQ.

Koneksi pemantauan sintetis (pengujian fungsional otomatis)

Di MONQ, Anda juga dapat mengonfigurasi pengujian fungsional aplikasi. Dalam contoh saya, ini adalah akun pribadi. Saya telah menghubungkan beberapa build autotests dari Jenkins.


Modul pemantauan fungsional “proyek FMON”

Pemantauan fungsional dalam MONQ adalah modul terpisah dengan layar "Pengujian Fungsional" sendiri. Dan berikut ini adalah contoh laporan tentang pelaksanaan salah satu pengujian saya:


Proyek Otorisasi Pengguna FMON, perakitan gagal

Konfigurasikan pemantauan dan peringatan

Menggunakan templat standar (beberapa templat siap pakai untuk pemicu sintetis untuk setiap integrasi tersedia di luar kotak) ia menciptakan pemicu sintetis untuk acara utama dari Zabbix dan Prometheus. Pemicu sintetis di sini adalah pemicu yang dibuat di dalam platform yang bekerja dengan data primer dari berbagai sumber. Selanjutnya, saya menautkan pemicu yang dihasilkan ke elemen PCM (KE).


Bagian "Pemicu Sintetis"

Dan sepertinya pemicu sintetis yang dibuat oleh template.


Contoh pemicu sintetis yang dibuat oleh templat untuk Prometheus

Di bagian "Skrip Saya", misalnya, sudah ada skrip yang me-restart server. Naskah itu sendiri ditulis dalam bahasa Lua dan dapat diubah. Berdasarkan itu, saya membuat skrip saya sendiri untuk memulai kembali layanan.


Script layanan reboot di server

Selain integrasi biasa dengan klien email, di luar kotak Anda dapat mengkonfigurasi pengiriman pemberitahuan ke berbagai pengirim pesan instan. Dalam hal ini, Anda dapat mengatur bot obrolan yang akan menulis ke grup khusus, misalnya, ke administrator obrolan dalam telegram.

Untuk menggunakan integrasi dengan messenger instan, Anda perlu membuka akses ke Microsoft Azure cloud.

Pengguna mahir dapat menulis plugin pemberitahuan mereka sendiri di Lua. Di bawah ini adalah contoh skrip saya untuk mengirim notifikasi SMS.


Plugin pengiriman SMS untuk platform MONQ

Memantau visualisasi

Setelah penyetelan, PCM saya sedikit berubah, tiga sistem lagi ditempatkan untuk pemantauan umum, keadaan yang menentukan kinerja IS "Akun Pengguna Pribadi". Juga menambahkan beberapa layanan.


"Akun Pribadi Pengguna" PCM dengan pemicu yang terlampir

Informasi umum tentang keadaan objek yang diawasi ditampilkan pada tampilan utama dalam bentuk widget khusus.


Presentasi utama untuk "Akun Pribadi" IS

Pada saat mengambil tangkapan layar, ada masalah dengan sejumlah besar pertanyaan dalam basis data, yang karenanya respons halaman di IS "Akun Pengguna Pribadi" telah meningkat. Sistem menginformasikan tentang ini di layar dan mengirim SMS.

Untuk pemantauan operasional, "Layar operasional" digunakan di mana hanya ada satu widget dengan daftar acara saat ini (acara aktif dan acara yang ditutup 15 menit yang lalu).


Presentasi Layar Langsung

Untuk pengujian, saya menghasilkan beban tinggi pada CPU mesin virtual menggunakan MySQL. Sistem menangkap peristiwa itu dan meluncurkan aksinya dengan skrip reboot layanan mysqld yang telah disiapkan sebelumnya. Jika setelah 15 menit acara masih aktif, reboot akan terjadi.


Layanan reboot dengan benar, dan saya menerima pemberitahuan bahwa semuanya OK.

Semua peristiwa dalam waktu dapat dilihat di bagian "Timeline". Dan jika sistem ITSM masih terhubung, maka ia akan menampilkan pekerjaan yang direncanakan sesuai KE.


Memantau Acara pada Tampilan Timeline

Informasi tentang ketersediaan sistem yang dipasang untuk pemantauan dapat ditemukan di tampilan "Laporan SLA".


Laporkan SLA di IP "Akun Pribadi Pengguna"

Untuk lebih jelasnya, saya membuat laporan selama dua minggu kecuali dari acara dengan prioritas 3 dan 4, tentu saja, yang diuji. Jika Anda yakin laporannya, sistem berfungsi dengan baik. Laporan ini diekspor ke PDF dan XLS.

Layar memperlihatkan informasi tentang filter yang sudah dikonfigurasikan sebelumnya oleh pengguna. Setiap peristiwa di layar dapat ditandai untuk pencarian cepat atau penyaringan.

Perizinan

Keuntungan non-fungsional, tetapi tidak kurang kunci dari MONQ saya simpan untuk akhir artikel. Ini adalah lisensi. Sebagian besar solusi pemantauan payung asing dilisensikan oleh sejumlah perangkat (biasanya disebut per titik akhir, per OS Instance atau yang lainnya) tempat peristiwa atau metrik diproses. Terlepas dari apakah Anda mengumpulkan data dari objek pemantauan akhir, atau sistem pemantauan lain melakukannya. Jika metrik dikumpulkan menggunakan sistem komersial, pembayaran ganda untuk hal yang sama tidak bisa dihindari. MONQ dilisensikan oleh jumlah konektor yang digunakan untuk sistem eksternal. Artinya, jika Anda menggunakan dua sistem, dari mana Anda ingin mengumpulkan informasi - ini adalah dua konektor yang digunakan atau dua lisensi. Jadi, dari sudut pandang "biaya pengumpulan", ketika menggunakan MONQ tidak ada yang akan berubah. Anda hanya akan membayar biaya integrasi dengan sistem ini. Dalam hal ini saya melihat keuntungan dan potensi yang luar biasa.

Seperti yang saya diberitahu, rencana untuk pengembangan sistem banyak perbaikan yang terus diperkenalkan. Dari inovasi penting dalam enam bulan ke depan akan muncul: konstruktor dashboard, master untuk menciptakan pemicu sintetis, peningkatan detail saat menghitung SLA (Anda akan melihat faktor mana dan seberapa besar mempengaruhi aksesibilitas objek) dan API publik eksternal.

Kesimpulan

Saya suka orang-orang dari perusahaan pengembang dengan mudah melakukan kontak, berbicara, dan berbagi informasi, dan saya menyukai sistem. Itu masih tidak memiliki banyak fungsi dan sulit untuk secara langsung membandingkan dengan Splunk atau AppDynamics dalam hal AIOps, tetapi, jelas, jika semua yang mereka bicarakan menjadi kenyataan, sistem ini akan mengambil tempat yang selayaknya di antara para pemimpin pasar dan kuadran Gartner.

Jika Anda ingin mengevaluasi sistem sendiri, dapatkan presentasi, tonton demo atau sudah lama mencari solusi payung dan siap untuk proyek percontohan, silakan tinggalkan permintaan dalam formulir umpan balik di situs web kami.