Монитор Спортмастер - как и с какво

Мислехме да създадем система за мониторинг на етапа на формиране на продуктови екипи. Стана ясно, че нашият бизнес – експлоатацията – не попада в тези екипи. Защо така?

Факт е, че всички наши екипи са изградени около отделни информационни системи, микроуслуги и фронтове, така че екипите не виждат цялостното здраве на цялата система като цяло. Например, те може да не знаят как някоя малка част в дълбокия бекенд влияе на предния край. Техният обхват на интерес е ограничен до системите, с които тяхната система е интегрирана. Ако един екип и неговата услуга A нямат почти никаква връзка с услуга B, тогава такава услуга е почти невидима за екипа.

Нашият екип от своя страна работи със системи, които са много силно интегрирани една с друга: има много връзки между тях, това е много голяма инфраструктура. И работата на онлайн магазина зависи от всички тези системи (от които между другото имаме огромен брой).

Така се оказва, че нашият отдел не принадлежи към нито един екип, а е разположен малко встрани. В цялата тази история нашата задача е да разберем цялостно как работят информационните системи, тяхната функционалност, интеграции, софтуер, мрежа, хардуер и как всичко това е свързано помежду си.

Платформата, на която работят нашите онлайн магазини изглежда така:

• фронт
• среден офис
• бек офис

Колкото и да ни се иска, не се случва всички системи да работят гладко и безупречно. Въпросът отново е в броя на системите и интеграциите - при нещо като нашето някои инциденти са неизбежни, въпреки качеството на тестване. При това както в рамките на отделна система, така и по отношение на тяхната интеграция. И вие трябва да наблюдавате цялостно състоянието на цялата платформа, а не само на отделна част от нея.

В идеалния случай мониторингът на здравето в цялата платформа трябва да бъде автоматизиран. И стигнахме до мониторинга като неизбежна част от този процес. Първоначално той беше изграден само за частта от първа линия, докато мрежовите специалисти, софтуерните и хардуерните администратори имаха и все още имат свои собствени системи за мониторинг слой по слой. Всички тези хора следяха мониторинга само на собствено ниво, никой също нямаше цялостно разбиране.

Например, ако виртуална машина се срине, в повечето случаи само администраторът, отговорен за хардуера и виртуалната машина, знае за това. В такива случаи екипът на първа линия вижда самия факт на срива на приложението, но не разполага с данни за срива на виртуалната машина. И администраторът може да знае кой е клиентът и да има груба представа какво се изпълнява в момента на тази виртуална машина, при условие че това е някакъв вид голям проект. Той най-вероятно не знае за малките. Във всеки случай администраторът трябва да отиде при собственика и да попита какво е имало на тази машина, какво трябва да се възстанови и какво трябва да се промени. И ако нещо наистина сериозно се повреди, те започнаха да се въртят в кръг - защото никой не виждаше системата като цяло.

В крайна сметка такива различни истории засягат целия интерфейс, потребителите и нашата основна бизнес функция - онлайн продажбите. Тъй като не сме част от екип, а сме ангажирани с работата на всички приложения за електронна търговия като част от онлайн магазин, ние се заехме със задачата да създадем цялостна система за мониторинг на платформата за електронна търговия.

Структура и стек на системата

Започнахме, като идентифицирахме няколко нива за наблюдение за нашите системи, в рамките на които ще трябва да събираме показатели. И всичко това трябваше да се комбинира, което направихме на първия етап. Сега на този етап финализираме най-висококачествената колекция от показатели във всички наши слоеве, за да изградим корелация и да разберем как системите си влияят една на друга.

Липсата на цялостен мониторинг в началните етапи на стартиране на приложението (тъй като започнахме да го изграждаме, когато повечето системи бяха в производство) доведе до факта, че имахме значителен технически дълг, за да настроим мониторинг на цялата платформа. Не можехме да си позволим да се съсредоточим върху настройването на мониторинг за една ИС и разработването на мониторинг за него в детайли, тъй като останалите системи щяха да останат без мониторинг за известно време. За да разрешим този проблем, ние идентифицирахме списък с най-необходимите показатели за оценка на състоянието на информационната система по слой и започнахме да го прилагаме.

Затова решили да изядат слона на части.

Нашата система се състои от:

• хардуер;
• операционна система;
• софтуер;
• UI части в приложението за наблюдение;
• бизнес показатели;
• интеграционни приложения;
• информационна сигурност;
• мрежи;
• балансьор на трафика.

В центъра на тази система е самият мониторинг. За да разберете като цяло състоянието на цялата система, трябва да знаете какво се случва с приложенията на всички тези слоеве и в целия набор от приложения.

И така, относно стека.

Използваме софтуер с отворен код. В центъра имаме Zabbix, който използваме предимно като система за предупреждение. Всеки знае, че е идеален за наблюдение на инфраструктурата. Какво означава това? Точно тези метрики от ниско ниво, които има всяка компания, която поддържа собствен център за данни (и Sportmaster има свои центрове за данни) - температура на сървъра, състояние на паметта, raid, показатели за мрежови устройства.

Интегрирахме Zabbix с месинджъра Telegram и Microsoft Teams, които се използват активно в екипи. Zabbix покрива слоя на действителната мрежа, хардуер и софтуер, но не е панацея. Ние обогатяваме тези данни от някои други услуги. Например на хардуерно ниво ние директно се свързваме чрез API с нашата система за виртуализация и събираме данни.

Какво друго. В допълнение към Zabbix, ние използваме Prometheus, което ни позволява да наблюдаваме показатели в приложение за динамична среда. Това означава, че можем да получаваме показатели на приложението чрез HTTP крайна точка и да не се притесняваме кои показатели да заредим в него и кои не. Въз основа на тези данни могат да се разработят аналитични запитвания.

Източниците на данни за други слоеве, например бизнес показатели, са разделени на три компонента.

Първо, това са външни бизнес системи, Google Analytics, ние събираме показатели от регистрационни файлове. От тях получаваме данни за активни потребители, конверсии и всичко останало свързано с бизнеса. Второ, това е система за наблюдение на потребителския интерфейс. Трябва да се опише по-подробно.

Преди време започнахме с ръчно тестване и то прерасна в автоматични тестове на функционалност и интеграции. От това направихме мониторинг, оставяйки само основната функционалност, и разчитахме на маркери, които са възможно най-стабилни и не се променят често във времето.

Новата екипна структура означава, че всички дейности по приложението са ограничени до продуктови екипи, така че спряхме да правим чисто тестване. Вместо това направихме UI мониторинг от тестовете, написани на Java, Selenium и Jenkins (използвани като система за стартиране и генериране на отчети).

Имахме много тестове, но в крайна сметка решихме да отидем на главния път, показателят от най-високо ниво. И ако имаме много специфични тестове, ще бъде трудно да поддържаме данните актуални. Всяка следваща версия значително ще счупи цялата система и всичко, което ще направим, е да я поправим. Затова се фокусирахме върху много фундаментални неща, които рядко се променят и ние само ги наблюдаваме.

И накрая, трето, източникът на данни е централизирана система за регистриране. Използваме Elastic Stack за регистрационни файлове и след това можем да изтеглим тези данни в нашата система за наблюдение за бизнес показатели. В допълнение към всичко това, ние имаме собствена услуга API за мониторинг, написана на Python, която прави заявки за всякакви услуги чрез API и събира данни от тях в Zabbix.

Друг незаменим атрибут на мониторинга е визуализацията. Нашата е базирана на Графана. Той се откроява сред другите системи за визуализация с това, че ви позволява да визуализирате показатели от различни източници на данни на таблото за управление. Можем да събираме показатели от най-високо ниво за онлайн магазин, например броя на поръчките, направени през последния час от СУБД, показатели за производителността за операционната система, на която работи този онлайн магазин от Zabbix, и показатели за екземпляри на това приложение от Прометей. И всичко това ще бъде на едно табло. Ясно и достъпно.

За сигурността да отбележа - в момента финализираме системата, която по-късно ще интегрираме с глобалната система за мониторинг. Според мен основните проблеми, с които се сблъсква електронната търговия в областта на информационната сигурност, са свързани с ботовете, парсерите и грубата сила. Трябва да следим това, защото всичко това може критично да повлияе както на работата на нашите приложения, така и на репутацията ни от бизнес гледна точка. И с избрания стек ние успешно покриваме тези задачи.

Друг важен момент е, че приложният слой се сглобява от Prometheus. Самият той също е интегриран със Zabbix. Освен това имаме sitespeed, услуга, която ни позволява да преглеждаме параметри като скоростта на зареждане на нашата страница, тесни места, рендиране на страница, скриптове за зареждане и т.н., тя също е интегрирана с API. Така че нашите показатели се събират в Zabbix и съответно ние също предупреждаваме от там. Всички сигнали в момента се изпращат до основните методи за изпращане (засега това са имейл и телеграма, MS Teams също наскоро беше свързан). Има планове за надграждане на предупрежденията до такова състояние, че интелигентните ботове да работят като услуга и да предоставят информация за наблюдение на всички заинтересовани продуктови екипи.

За нас метриките са важни не само за отделните информационни системи, но и общите метрики за цялата инфраструктура, която приложенията използват: клъстери от физически сървъри, на които работят виртуални машини, балансьори на трафика, балансьори на натоварването на мрежата, самата мрежа, използване на комуникационни канали . Плюс показатели за нашите собствени центрове за данни (имаме няколко от тях и инфраструктурата е доста голяма).

Предимствата на нашата система за мониторинг са, че с нейна помощ виждаме здравословното състояние на всички системи и можем да оценим тяхното въздействие една върху друга и върху споделените ресурси. И в крайна сметка ни позволява да се ангажираме с планирането на ресурсите, което също е наша отговорност. Ние управляваме сървърни ресурси - пул в рамките на електронната търговия, пускаме и извеждаме от експлоатация ново оборудване, закупуваме допълнително ново оборудване, извършваме одит на използването на ресурсите и др. Всяка година екипи планират нови проекти, развиват своите системи и за нас е важно да им осигурим ресурси.

И с помощта на показатели виждаме тенденцията в потреблението на ресурси от нашите информационни системи. И въз основа на тях можем да планираме нещо. На ниво виртуализация събираме данни и виждаме информация за наличното количество ресурси по центрове за данни. И вече вътре в центъра за данни можете да видите рециклирането, действителното разпределение и потреблението на ресурси. Освен това, както със самостоятелни сървъри, така и с виртуални машини и клъстери от физически сървъри, на които всички тези виртуални машини се въртят енергично.

Перспективи

Сега имаме готово ядрото на системата като цяло, но има още много неща, върху които трябва да се работи. Като минимум това е слой за информационна сигурност, но също така е важно да се достигне до мрежата, да се разработи предупреждение и да се разреши проблемът с корелацията. Имаме много слоеве и системи и на всеки слой има много повече показатели. Оказва се матрьошка до степен на матрьошка.

Нашата задача е в крайна сметка да направим правилните сигнали. Например, ако имаше проблем с хардуера, отново с виртуална машина и имаше важно приложение и услугата не беше архивирана по никакъв начин. Откриваме, че виртуалната машина е умряла. Тогава бизнес показателите ще ви предупредят: потребителите са изчезнали някъде, няма преобразуване, потребителският интерфейс в интерфейса е недостъпен, софтуерът и услугите също са умрели.

В тази ситуация ще получаваме спам от сигнали и това вече не се вписва във формата на правилна система за наблюдение. Възниква въпросът за корелацията. Следователно в идеалния случай нашата система за наблюдение трябва да каже: „Момчета, вашата физическа машина е умряла, а заедно с нея и това приложение и тези показатели“ с помощта на един сигнал, вместо яростно да ни бомбардира със стотици сигнали. Той трябва да докладва основното - причината, която помага за бързото отстраняване на проблема поради локализацията му.

Нашата система за уведомяване и обработка на сигнали е изградена около XNUMX-часова гореща линия. Там се изпращат всички сигнали, които се считат за задължителни и са включени в списъка за проверка. Всеки сигнал трябва да има описание: какво се е случило, какво всъщност означава, какво засяга. А също и връзка към таблото и инструкции какво да правя в този случай.

Това е всичко относно изискванията за изграждане на предупреждение. Тогава ситуацията може да се развие в две посоки - или има проблем и трябва да се реши, или е възникнал срив в системата за наблюдение. Но във всеки случай трябва да отидете и да го разберете.

Средно сега получаваме около сто сигнала на ден, като вземем предвид факта, че корелацията на сигналите все още не е правилно конфигурирана. И ако трябва да извършим техническа работа и принудително изключим нещо, броят им се увеличава значително.

В допълнение към наблюдението на системите, които управляваме, и събирането на показатели, които се считат за важни от наша страна, системата за наблюдение ни позволява да събираме данни за продуктовите екипи. Те могат да повлияят на състава на показателите в информационните системи, които наблюдаваме.

Наш колега може да дойде и да поиска да добавим някакъв показател, който ще бъде полезен както за нас, така и за екипа. Или, например, екипът може да няма достатъчно от основните показатели, които имаме; те трябва да проследят някои специфични. В Grafana създаваме пространство за всеки екип и предоставяме администраторски права. Освен това, ако даден екип има нужда от табла за управление, но самите те не могат/не знаят как да го направят, ние им помагаме.

Тъй като сме извън потока на създаването на стойност на екипа, техните издания и планиране, ние постепенно стигаме до заключението, че изданията на всички системи са безпроблемни и могат да се пускат ежедневно без координация с нас. И за нас е важно да наблюдаваме тези версии, защото те потенциално биха могли да повлияят на работата на приложението и да счупят нещо, а това е критично. За да управляваме версиите, ние използваме Bamboo, откъдето получаваме данни чрез API и можем да видим кои версии са пуснати в кои информационни системи и техния статус. И най-важното е по кое време. Ние наслагваме маркери за освобождаване върху основните критични показатели, което е визуално много показателно в случай на проблеми.

По този начин можем да видим връзката между новите версии и възникващите проблеми. Основната идея е да разберете как работи системата на всички нива, бързо да локализирате проблема и да го поправите също толкова бързо. В крайна сметка често се случва това, което отнема най-много време, да не е решаването на проблема, а търсенето на причината.

И в тази област в бъдеще искаме да се фокусираме върху проактивността. В идеалния случай бих искал да знам за наближаващия проблем предварително, а не след факта, така че да мога да го предотвратя, вместо да го разреша. Понякога възникват фалшиви аларми на системата за наблюдение, както поради човешка грешка, така и поради промени в приложението. И ние работим върху това, отстраняваме грешки и се опитваме да предупредим потребителите, които я използват с нас, за това, преди всяка манипулация на системата за наблюдение. , или извършете тези дейности в техническия прозорец.

И така, системата е пусната и от началото на пролетта работи успешно... и показва съвсем реални печалби. Разбира се, това не е окончателната му версия; ще въведем още много полезни функции. Но точно сега, с толкова много интеграции и приложения, автоматизацията на мониторинга е наистина неизбежна.

Ако също така наблюдавате големи проекти със значителен брой интеграции, напишете в коментарите какъв сребърен куршум сте намерили за това.

Източник: www.habr.com