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

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

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

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

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

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

• лице
• среден офис
• заден офис

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

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

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

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

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

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

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

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

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

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

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

Така че, по отношение на стека.

Използваме софтуер с отворен код. В центъра е Zabbix, който използваме предимно като система за известия. Всички знаем, че той е идеален за мониторинг на инфраструктурата. Какво се има предвид тук? Това са нискоуровневите метрики, които всяка компания, притежаваща свой ЦОД (а Спортмастера има свои ЦОД-ове), следи — температура на сървъра, състояние на паметта, RAID, метрики на мрежовите устройства.

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

Какво още. Освен Zabbix, използваме Prometheus, който позволява мониторинг на метрики в приложение с динамична среда. Тоест, можем да получаваме метрики на приложението по HTTP endpoint и да не се тревожим за това, какви метрики да зареждаме, а какви не. На базата на тези данни можем да формулираме аналитични заявки.

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

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

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

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

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

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

Още един незаменим атрибут на мониторинга е визуализацията. При нас тя се изгражда на базата на Grafana. Сред другите системи за визуализация, тя се отличава с това, че на таблото може да визуализира метрики от различни източници на данни. Можем да съберем висшите метрики на интернет магазина, например, броя на поръчките, направени през последния час, от СУБД, метрики за производителността на ОС, на която е стартиран този интернет магазин, от Zabbix, а метрики на инстансите на това приложение — от Prometheus. И всичко това ще бъде на едно табло. Нагледно и достъпно.

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

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

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

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

Чрез метриките виждаме тенденцията на потребление на ресурси от нашите информационни системи. И на базата на тях можем да планираме нещо. На ниво виртуализация събираме данни и виждаме информация за наличното количество ресурси по ЦОД-ове. А вътре в ЦОД-а е видима и утилизацията, и фактическото разпределение, потребление на ресурси. Това става както със standalone сървъри, така и с виртуални машини и клъстери от физически сървъри, на които всички тези виртуалки активно работят.

Перспективи

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

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

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

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

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

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

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

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

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

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

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

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

Ако и вие следите големи проекти с много интеграции – напишете в коментарите каква сребърна куршума сте намерили за това.

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