Про створення системи моніторингу ми замислилися етапі формування продуктових команд. Стало зрозуміло, що наша справа — експлуатація — у ці команди не потрапляє. Чому так?
Справа в тому, що всі наші команди побудовані навколо окремих інформаційних систем, мікросервісів та фронтів, тому загальний стан здоров'я усієї системи загалом команди не бачать. Наприклад, вони можуть не знати, як якась невелика частина у глибокому бекенді впливає на фронтову частину. Коло їхніх інтересів обмежується системами, з якими інтегрована їхня система. Якщо ж команда та її сервіс майже ніяк не пов'язаний з сервісом Б, то такий сервіс для команди майже невидимий.
Наша команда, у свою чергу, працює з системами, які дуже сильно інтегровані між собою: між ними безліч зв'язків, це дуже велика інфраструктура. І від усіх цих систем (яких у нас, до речі, дуже багато), залежить робота інтернет-магазину.
Ось і виходить, що наш відділ не відноситься до жодної команди, а знаходиться трохи осторонь. У всій цій історії наше завдання — розуміти в комплексі, як працюють інформаційні системи, їх функціональність, інтеграція, програмне забезпечення, мережа, залізо, і як усе це пов'язано між собою.
Платформа, на якій функціонують наші інтернет-магазини, має такий вигляд:
- перед
- middle-office
- бек-офіс
Як би нам не хотілося, але не буває такого, щоб усі системи працювали гладко та бездоганно. Справа, знову ж таки, у кількості систем та інтеграцій — за такої, як у нас, якісь інциденти це неминучість, незважаючи на якість тестування. Причому як усередині якоїсь окремої системи, так і щодо їх інтеграції. І потрібно стежити за станом усієї платформи комплексно, а не якоїсь окремої її частини.
В ідеалі, спостереження за станом здоров'я всієї платформи потрібно автоматизувати. І ми дійшли моніторингу як неминучої частини цього процесу. Спочатку він був побудований тільки для фронтової частини, при цьому власні системи моніторингу за шарами були і є у мережевиків, адміністраторів та апаратного забезпечення. Всі ці люди стежили за моніторингом лише на своєму рівні, комплексного розуміння теж ніхто не мав.
Наприклад, якщо впала віртуальна машина, у більшості випадків про це знає лише адміністратор, який відповідає за hardware та віртуальну машину. Команда фронту в таких випадках бачила сам факт падіння програми, але даних про падіння віртуальної машини у неї не було. А адміністратор може знати, хто замовник, і приблизно уявляти, що саме зараз на цій віртуальній машині крутиться за умови, що це якийсь великий проект. Про малі він, швидше за все, не знає. У будь-якому випадку, адміністратору треба йти до власника, питати, що ж на цій машині було, що треба відновлювати і поміняти. А якщо щось ламалося зовсім серйозне, починалася біганина по колу — бо ніхто не бачив систему загалом.
Зрештою, такі розрізнені історії впливають на весь фронтенд, на користувачів і нашу основну бізнес-функцію — інтернет-продажу. Оскільки ми не входимо до команди, а займаємося експлуатацією всіх ecommerce-додатків у складі інтернет-магазину, ми взяли на себе завдання щодо створення комплексної системи моніторингу ecommerce-платформи.
Структура системи та стек
Ми почали з того, що виділили кілька шарів моніторингу для наших систем, у розрізі яких нам потрібно буде збирати метрики. І все це потрібно було поєднати, що ми й зробили на першому етапі. Зараз на цьому етапі ми допрацьовуємо максимально якісний збір метрик по всіх наших верствах, щоб вибудовувати кореляцію і розуміти, як системи впливають одна на одну.
Відсутність комплексного моніторингу на початкових етапах запуску додатків (оскільки ми почали будувати його, коли більшість систем була в експлуатації) призвело до того, що у нас утворився значний технічний борг з налаштування моніторингу всієї платформи. Зосереджуватися на налаштуванні моніторингу якоїсь однієї ІВ і детально опрацьовувати моніторинг для неї ми не могли собі дозволити, оскільки решта систем залишилася б на якийсь час без моніторингу. Для вирішення цього завдання ми визначили список найнеобхідніших метрик оцінки стану інформаційної системи за шарами та почали його впроваджувати.
Тому слона вирішили їсти частинами.
Наша система складається з:
- обладнання;
- операційної системи;
- програмне забезпечення;
- UI-частини у додатку моніторингу;
- бізнес-метрики;
- додатки інтеграції;
- інформаційної безпеки;
- мережі;
- балансувальника трафіку.
У центрі цієї системи – власне моніторинг. Щоб загалом розуміти стан всієї системи, треба знати, що відбувається з додатками на всіх цих шарах і в розрізі безлічі додатків.
Так ось, про стек.
Використовуємо програмне забезпечення з відкритим вихідним кодом. У центрі у нас Zabbix, який ми використовуємо насамперед як систему аллертингу. Всім відомо, що він ідеально підходить для моніторингу інфраструктури. Що тут мається на увазі? Саме ті низькорівневі метрики, які є у кожної компанії, яка містить свій ЦОД (а у Спортмайстра свої ЦОДи) — температура сервера, стан пам'яті, рейду, метрики мережевих пристроїв.
Ми інтегрували Zabbix з месенджером Telegram і Microsoft Teams, які активно використовуються в командах. Zabbix покриває шар фактичної мережі, заліза та частково ПЗ, але це не панацея. Ми ці дані збагачуємо з інших сервісів. Наприклад, за рівнем апаратного забезпечення ми безпосередньо по API коннектимося в нашій системі віртуалізації і забираємо дані.
Що ще. Крім Zabbix ми використовуємо Prometheus, який дозволяє моніторити метрики у додатку динамічного середовища. Тобто ми можемо отримувати метрики програми з HTTP endpoint і не перейматися тим, які метрики в неї завантажувати, а які ні. З цих даних можна опрацьовувати аналітичні запити.
Джерела даних для інших верств, наприклад бізнес-метрик, у нас діляться на три складові.
По-перше, це зовнішні бізнес-системи, Google Analytics, збираємо метрики з логів. З них ми отримуємо дані щодо активних користувачів, конверсії та всього іншого, пов'язаного з бізнесом. По-друге, це система UI-моніторингу. Про неї слід розповісти докладніше.
Колись ми починали з мануального тестування, і воно переросло в автотести функціоналу та інтеграцій. З нього ми і зробили моніторинг, залишивши лише основний функціонал, і зав'язалися на маркери, які максимально стабільні та не часто змінюються з часом.
Нова структура команд має на увазі, що вся діяльність з додатків замикається на продуктових командах, тому чистим тестуванням ми перестали займатися. Натомість ми з тестів зробили UI-моніторинг, написаний на Java, Selenium та Jenkins (використовується як система запуску та генерації звітів).
У нас було багато тестів, але зрештою ми вирішили виходити на головну дорогу, верхньорівневу метрику. І якщо ми матимемо багато специфічних тестів, то буде складно підтримувати актуальність даних. Кожен наступний реліз значно ламатиме всю систему, а ми тільки й займатимемося її ремонтом. Тому ми зав'язалися на дуже фундаментальні речі, які рідко змінюються, і моніторимо лише їх.
Зрештою, по-третє, джерелом даних є централізована система логування. Для логів використовуємо Elastic Stack, а потім ці дані можемо затягувати в нашу систему моніторингу бізнес-метриків. На додаток до цього працює наш власний сервіс Monitoring API, написаний на Python, який опитує по API будь-які сервіси і забирає в Zabbix дані з них.
Ще один незамінний атрибут моніторингу – візуалізація. В нас вона будується на основі Grafana. Серед інших систем візуалізації вона відрізняється тим, що на дашборді можна візуалізувати метрики з різних джерел даних. Ми можемо зібрати верхньорівневі метрики інтернет-магазину, наприклад, кількість замовлень, оформлених за останню годину, із СУБД, метрики продуктивності ОС, на якій запущено цей інтернет-магазин, із Zabbix, а метрики інстансів цієї програми — з Prometheus. І все це буде на одному дашборді. Наочно та доступно.
Зазначу про безпеку — ми зараз допиваємо систему, яку згодом інтегруватимемо з глобальною системою моніторингу. На мою думку, основні проблеми, з якими стикається e-commerce у сфері інформаційної безпеки, пов'язані з ботами, парсерами та брутфорсом. За цим потрібно стежити, бо вони все це може критично вплинути як на роботу наших додатків, так і на репутацію з погляду бізнесу. І вибраним стеком ми ці завдання успішно вкриваємо.
Ще важливий момент – рівень додатків збирається Prometheus. Сам він він у нас теж інтегрований із Zabbix. І ще у нас є sitespeed, сервіс, який дозволяє нам відповідно дивитися такі параметри, як швидкість завантаження нашої сторінки, ботлнеки, відмальовування сторінки, завантаження скриптів та інше, він теж API інтегрований. Так метрики у нас збираються в Zabbix, відповідно, алертимо ми також звідти. Всі алерти поки що йдуть на основні способи відправки (поки це email і telegram, ще нещодавно підключили MS Teams). У планах прокачати алертинг до такого стану, щоб розумні роботи працювали як сервіс і надавали інформацію з моніторингу всім бажаючим продуктовим командам.
Для нас важливі метрики не лише окремих інформаційних систем, а й загальні метрики по всій інфраструктурі, яку використовують додатки: кластери фізичних серверів, на яких крутяться віртуалки, балансувальники трафіку, Network Load Balancer, сама мережа, утилізація каналів зв'язку. Плюс метрики за нашими власними цодами (у нас їх кілька та інфраструктура досить значних розмірів).
Плюси нашої системи моніторингу в тому, що за її допомогою ми бачимо стан працездатності всіх систем, можемо оцінити їх вплив один на одного та загальні ресурси. І, зрештою, вона дозволяє займатися плануванням ресурсів, що також входить у нашу зону відповідальності. Ми керуємо серверними ресурсами – пулом у рамках e-commerce, вводимо-виводимо з експлуатації нове обладнання, докуповуємо нове, проводимо аудит утилізації ресурсів та інше. Щороку команди планують нові проекти, розвивають свої системи і нам важливо забезпечити їх ресурсами.
І з допомогою метрик бачимо тенденцію споживання ресурсів нашими інформаційними системами. І вже на їх основі можемо щось планувати. На рівні віртуалізації ми збираємо дані та бачимо інформацію щодо доступної кількості ресурсів у розрізі ЦОДів. А вже всередині ЦОДу видно і утилізацію, і фактичний розподіл, споживання ресурсів. Причому як із standalone-серверами, так і віртуальними машинами та кластерами фізичних серверів, на яких усі ці віртуалки бадьоро крутяться.
Перспективи
Зараз у нас готове ядро системи в цілому, але залишилося достатньо моментів, над якими ще доведеться працювати. Як мінімум це шар інформаційної безпеки, але важливо також дістатися мережі, розвинути алертинг і вирішити питання з кореляцією. Шарів та систем у нас багато, на кожному шарі ще безліч метрик. Виходить матрьошка у ступені матрьошки.
Наше завдання — зрештою зробити правильні алерти. Наприклад, якщо трапилася проблема з апаратною частиною, знову ж таки, з віртуальною машиною, а там була важлива програма, і сервіс був ніяк не зарезервований. Ми дізнаємось, що віртуальна машина померла. Потім алертити бізнес-метрики: користувачі кудись зникли, конверсії немає, UI в інтерфейсі недоступний, ПЗ і сервіси теж померли.
За такого розкладу ми отримаємо спам з алертів, а це вже не вкладається у формат правильної системи моніторингу. Постає питання кореляції. Тому в ідеалі наша система моніторингу повинна сказати: «Хлопці, у вас фізична машина померла, а разом з нею ось ця програма і такі метрики», за допомогою одного алерту замість того, щоб люто засипати нас сотнею алертів. Вона має повідомити про головне — причину, що сприяє оперативності усунення проблеми рахунок її локалізації.
Наша система оповіщень та обробка алертів побудована навколо цілодобової служби гарячої лінії. Усі алерти, які вважаються у нас маст-хевом і входять у чек-лист, передаються туди. Кожен алерт повинен обов'язково мати опис: що сталося, що це власне означає на що впливає. А ще посилання на дашборд та інструкцію, що ж у цьому випадку потрібно робити.
Це все, що стосується вимог щодо побудови аллертингу. Далі ситуація може розвиватись у двох напрямках — або проблема є і її потрібно вирішувати, або стався збій у системі моніторингу. Але в будь-якому випадку потрібно йти і розбиратися.
У середньому зараз за добу нам падає близько сотні алертів, це з огляду на те, що кореляція алертів ще не налаштована належним чином. І якщо потрібно провести технічні роботи, і ми щось примусово відключаємо, їхня кількість зростає в рази.
Крім моніторингу систем, які ми експлуатуємо, і збору метрик, які на нашій стороні розцінюються як важливі, система моніторингу дозволяє збирати дані для продуктових команд. Вони можуть впливати на склад метрик у рамках інформаційних систем, які моніторяться у нас.
Наш колега може прийти і попросити додати якусь метрику, яка виявиться корисною і для нас, і для команди. Або, наприклад, команді може бути недостатньо тих базових метрик, які ми маємо, їм потрібно відстежувати якусь специфічну. У Grafana ми створюємо простір для кожної команди та надаємо права адміну. Також, якщо команді потрібні дашборди, а вони самі не можуть/не знають, як це зробити, ми їм допомагаємо.
Так як ми поза потоком створення цінностей команди, їх релізів та планування, ми поступово приходимо до того, що релізи всіх систем безшовні та їх можна викочувати щодня, не узгоджуючи при цьому з нами. А нам важливо відстежувати ці релізи, бо потенційно вони можуть вплинути на роботу програми та щось зламати, а це критично. Для управління релізами ми використовуємо Bamboo, звідки API отримуємо дані і можемо бачити, які релізи в яких інформаційних системах вийшли і їх статус. І найважливіше — коли. Маркери про релізи ми накладаємо на основні критичні метрики, що візуально є дуже показовим у разі проблем.
Таким чином ми можемо бачити кореляцію між новими релізами і проблемами, що виникають. Основна ідея в тому, щоб розуміти, як працює система на всіх шарах, швидко локалізувати проблему і швидко її виправити. Адже часто буває так, що найбільше часу займає не вирішення проблеми, а пошук причини.
І в цьому напрямі в майбутньому ми хочемо сфокусуватися на проактивності. В ідеалі хотілося б заздалегідь дізнаватися про проблему, що наближається, а не постфактум, щоб займатися її попередженням, а не рішенням. Іноді трапляються помилкові спрацьовування системи моніторингу, як через людську помилку, так і через зміни в додатку. , або проводити ці заходи в тех.
Отже, система запущена та успішно працює з початку весни… і показує цілком реальний прибуток. Звичайно, це не її фінальна версія, ми впроваджуватимемо ще безліч корисностей. Але прямо зараз, за такої великої кількості інтеграцій та додатків, без автоматизації моніторингу насправді не обійтися.
Якщо ви також моніторите великі проекти із серйозною кількістю інтеграцій — напишіть у коментарях, яку срібну кулю знайшли для цього.
Джерело: habr.com