Сістэма дакументацыйнага забеспячэння ў нашым банку ўвесь час развіваецца і маштабуецца, а патрабаванні да хуткасці і адмоваўстойлівасці пры гэтым толькі ўзрастаюць. У нейкі момант абслугоўваць СДО без эфектыўнага цэнтралізаванага маніторынгу стала занадта рызыкоўна. Каб засцерагчы бізнес-працэсы ў ЗГБ і спрасціць працу адміністратараў, мы ўкаранілі рашэнне на аснове стэка адкрытых тэхналогій. З яго дапамогай мы можам проактивно рэагаваць на інцыдэнты, прадухіляючы патэнцыйныя праблемы. Пад катам - гісторыя пра наш досвед выкарыстання вольнага ПЗ для маніторынгу маштабных бізнэс-сістэм.
Навошта маніторыць сістэму дакументазвароту
Дакументацыйным забеспячэннем у банку ЗГБ з 2005 года "ведае" сістэма CompanyMedia. У СДА працуе звыш 60 тысяч карыстальнікаў, штомесяц ствараюць больш за мільён новых дакументаў. Нашы серверы павінны функцыянаваць 24 гадзіны ў суткі: практычна ў любы момант у сістэме знаходзіцца па 2500-3000 чалавек, якія падключаюцца па ўсёй краіне, ад Петрапаўлаўска-Камчацкага да Калінінграда. Кожная секунда працы СДО - гэта 10-15 змен.
Каб сістэма выразна выконвала ўскладзеныя на яе задачы, мы разгарнулі адмоваўстойлівую інфраструктуру з ужываннем сервераў праксіравання, балансаванні запытаў, абароны інфармацыі, паўнатэкставага пошуку, інтэграцыйных маршрутаў і рэзервовага капіявання. Каб падтрымліваць і адміністраваць праект такога маштабу, патрэбны каласальныя рэсурсы. Адміністратары кругласутачна адсочваюць базавую інфармацыю аб працы сервераў, загрузцы аператыўнай памяці, працэсарнага часу, падсістэмы ўводу-вываду і гэтак далей. Але, акрамя гэтага, патрэбна больш тонкая аналітыка:
- разлік часу, які траціцца на выкананне бізнес-сцэнарыяў;
- адсочванне дынамікі прадукцыйнасці сістэмы і нагрузкі на яе;
- пошук адхіленняў у кампанентах сістэмы ад зацверджаных нефункцыянальных патрабаванняў.
Праз 11 гадоў пасля ўкаранення СДО пытанне праактыўнага рэагавання на рознага роду памылкі паўстала асабліва востра. Кіраўніцтва банка ўсвядоміла, што працаваць без манітораў і кансолі жыццядзейнасці сістэмы - гэта гуляць з агнём: найменшы збой у бізнес-сістэме падобнага ўзроўню багаты мільённымі стратамі.
У 2016 годзе мы пачалі ўкараненне інструментаў для аператыўнага выяўлення праблем у функцыянаванні СДА, у тым ліку для назірання за параметрамі, якія цікавяць нас, у рэжыме рэальнага часу. Папярэдне сістэму прыкладнога маніторынгу разгортвалі і тэсціравалі ў рамках інфраструктуры кампаніі «ИнтерТраст».
З чаго ўсё пачыналася
Сёння цэнтралізаваная сістэма прыкладнога маніторынгу СДА ЗГБ, заснаваная на СПО-прадуктах, дапамагае прадухіляць большую частку памылак, звязаных з дакументазваротам, хутка і дакладна класіфікаваць праблемы, аператыўна рэагаваць на любыя інцыдэнты. Яна ўключае ў сябе дзве падсістэмы:
- для маніторынгу IT-інфраструктуры сэрвісаў сістэмы;
- для маніторынгу ўзнікнення памылак у працы СДА.
Усё пачалося з адзінага бясплатнага прыкладання для маніторынгу. Перабраўшы некалькі варыянтаў, мы спыніліся на Zabbix – вольным ПЗ, якое першапачаткова пісалася пад банкаўскія сэрвісы і абсталяванне. Гэтая сістэма з вэб-інтэрфейсам на PHP, якая можа захоўваць дадзеныя ў MySQL, PostgreSQL, SQLite або Oracle Database, ідэальна адпавядала нашым запытам.
Zabbix запускае сваіх агентаў на кожным серверы і збірае інфармацыю па метрыках, якія цікавяць, у рэжыме рэальнага часу ў адзіную базу дадзеных. Пры дапамозе прыкладання зручна збіраць дадзеныя аб нагрузцы на працэсары і аператыўную памяць, аб выкарыстанні сеткі і іншых кампанентаў, правяраць даступнасць і рэакцыю стандартных сэрвісаў (SMTP ці HTTP), выконваць вонкавыя праграмы, падтрымліваць маніторынг праз SNMP.
Разгарнуўшы Zabbix, мы наладзілі стандартныя апаратныя метрыкі, і спачатку гэтага было дастаткова. Але СДА ЗГБ пастаянна развіваецца і расце: у 2016 годзе колькасць сервераў прыкметна павялічылася, з'явіліся міграцыйныя працэсы, да сістэмы падключыліся Банк Масквы, ЗГБ Капітал, ВТБ24. Стандартных метрык стала мала, і мы навучылі Zabbix адсочваць інфармацыю аб наяўнасці чэргаў на кожным з тамоў, падлучаных да сервера (са скрынкі Zabbix адлюстроўвае толькі агульную дыскавую чаргу), а таксама пра час, які займае адпрацоўка той ці іншай працэдуры.
Акрамя таго, мы абсталявалі сістэму множнымі трыгерамі - умовамі, пры якіх адміністратару адпраўляецца апавяшчэнне (паведамленне ў «Тэлеграм», СМС на нумар тэлефона або ліст на электронную пошту). Трыгеры наладжваюцца для любога набору параметраў. Напрыклад, можна пазначыць пэўны адсотак вольнага месца на дыску, і сістэма будзе апавяшчаць адміністратара, калі зададзены парог будзе дасягнуты, ці інфармаваць, калі якая-небудзь фонавая працэдура выконваецца даўжэй звычайнага.
Падключэнне да Java і візуалізацыя дадзеных
Мы значна пашырылі спектр аналізаваных дадзеных, але неўзабаве і гэтага стала нядосыць для эфектыўнага маніторынгу. Скарыстаўшыся тым, што СДО ад CompanyMedia з'яўляецца Java-дадаткам, мы падключыліся да Java Virtual Machine праз інтэрфейс JMX і змаглі здымаць метрыкі Java напрамую. Прычым не толькі стандартныя параметры жыццядзейнасці Java, такія як інтэнсіўнасць працы GC або выдатак Heap, але і спецыфічныя пробы, якія адносяцца непасрэдна да выкананага кода прыкладання.
У 2017 годзе, прыкладна праз год пасля ўкаранення сістэмы маніторынгу, стала зразумела, што для нармальнай працы з каласальным масівам дадзеных, які збіраецца ў Zabbix, не хапае візуалізацыі - комплексных экранаў. Аптымальным варыянтам рашэння гэтай праблемы зноў стала вольнае ПА – Grafana, зручны дашборд для метрык, які дазваляе агрэгаваць усе дадзеныя на адным экране.
Інтэрфейс Grafana інтэрактыўны, нагадвае OLAP-сістэму. Падсістэма выводзіць дадзеныя, якія атрымлівае Zabbix, на адзіны экран, уяўляючы інфармацыю ў выглядзе зручных для аналізу графікаў і схем. Адміністратар лёгка настройвае пад сябе зрэзы, якія яму патрэбны.
Маніторынг і прэвентыўнае ўхіленне памылак у сістэме СДО
Фільтраваць і аналізаваць атрымоўваную падчас маніторынгу інфармацыю дапамагае СПО-платформа ELK. Гэты opensource-прадукт складаецца з трох магутных інструментаў для збору, захоўвання і аналізу даных: Elasticsearch, Logstash і Kibana. Укараненне гэтай падсістэмы дазваляе, у прыватнасці, бачыць у рэжыме рэальнага часу, колькі памылак адбылося ў сістэме, на якіх серверах і ці паўтараныя гэта памылкі.
Цяпер адміністратар можа засекчы праблему на ранняй стадыі, яшчэ да таго, як з ёй сутыкаецца карыстач. Такі праактыўны маніторынг дазваляе прадухіляць парушэнні працаздольнасці сістэмы, своечасова ўхіляючы памылкі. Акрамя таго, мы можам зразумець, як змяніліся паводзіны сістэмы пасля абнаўлення, а таксама выявіць новыя праблемы ў выпадку іх з'яўлення.
Маніторынг бізнес-аперацый
Апроч базавых функцый маніторынгу спажывання рэсурсаў, сістэма валодае магчымасцю аналізу і кантролю бізнес-аперацый.
Кантроль агульнага часу выканання бізнес-аперацый дае магчымасць выяўляць новыя фактары і разумець, які ўплыў яны аказваюць на работу сістэмы.
Кантроль часу выканання запытаў у разрэзе кожнага бізнес-сэрвісу дае магчымасць засекчы аперацыі, якія маюць адхіленне ад нормы.
На скрыншоце вышэй - прыклад маніторынгу фонавай задачы з пункту гледжання яе адхіленні ад нормы.
Пералік кантраляваных задач з пункту гледжання іх актыўнасці на пэўным серверы дазваляе выяўляць памылкі - у тым ліку дубліравання выканання задач - па ўсіх серверах.
Таксама праводзіцца маніторынг трэндаў часу выканання фонавых працэдур.
Сістэма расце, развіваецца і дапамагае спраўляцца з праблемамі
З укараненнем апісанай сістэмы маніторынг працы сервераў СДО істотна спрасціўся. Тым не менш перыядычна ўзнікаюць рознага роду канфлікты, якія ўплываюць на хуткасць дакументаабароту і выклікаюць скаргі карыстальнікаў. Так мы зразумелі, што неабходна кантраляваць і паводзіны самога дадатку, а не толькі серверы.
Для вырашэння гэтай задачы да сістэмы маніторынгу падключылі па API балансавальнік, які працуе з кластарам сервераў прыкладанняў. Дзякуючы гэтаму адміністратар можа бачыць, за які час адказвае сервер па кожным запыце карыстальніка.
Дадзеныя аб часе адказаў сервераў сталі даступныя для аналізу, што дало магчымасць звязаць запаволенне СДО з працэсамі, якія адбываюцца на серверы. Выявілася, у прыватнасці, цікавая сітуацыя: сервер працуе павольна, хаця ў гэты момант ён не загружаны. Аналізуючы анамалію, мы выявілі адхіленні ў працы Garbage Collector Java. У рэшце рэшт высветлілася, што менавіта некарэктная праца гэтага сэрвісу і прыводзіла да дадзенай сітуацыі. Узяўшы пад кантроль Garbage Collector Java, мы цалкам ухілілі праблему.
Вось так свабоднае ПЗ дапамагае развівацца і расці сістэме дакументаабароту ў банкаўскай сферы. Мы закранулі толькі асноўныя пытанні, якія тычацца сістэмы маніторынгу СДА ЗГБ. Калі вам цікавыя падрабязнасці - пытайцеся ў каментарах, мы з радасцю падзелімся з вамі сваім досведам.
Крыніца: habr.com