Мониторинг като услуга: модулна система за микросервизна архитектура

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

Този пост е разшифровка на моето изложение от нашата секция на РИТ++. Много хора ни помолиха да направим текстови версии на докладите оттам. Ако сте били на конференцията или сте гледали видеото, няма да намерите нищо ново. А на всички останали - добро дошли под кат. Ще разкажа как стигнахме до такава система, как работи и как планираме да я обновяваме.

Миналото: схеми и планове

Как стигнахме до съществуващата система за мониторинг? За да отговорим на този въпрос, трябва да се върнем в 2015 година. Ето как изглеждаше тогава:

Имаме около 24 възела, които отговарят за мониторинга. Тук има цяло множество от различни кронове, скриптове и демони, които нещо някъде по някакъв начин мониторят, изпращат съобщения, извършват функции. Помислихме си, че колкото по-далече отиваме, толкова по-малко жизнеспособна ще бъде такава система. Няма смисъл да я развиваме: твърде тромава е.
Решихме да изберем елементите на мониторинга, които ще запазим и ще развиваме, и тези, от които ще се откажем. Оказаха се 19. Останаха само графити, агрегатори и Grafana като табло за управление. Но как ще изглежда новата система? Ето така:

Имаме хранилище на метрики: това са графити, които ще бъдат базирани на бързи SSD дискове, това са определени агрегатори за метрики. Следва - Grafana за показване на таблата за управление и Moira за алармирания. Също така искахме да разработим система за търсене на аномалии.

Стандарт: Мониторинг 2.0

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

• постоянна наличност;
• интервал на съхранение на метрики = 10 секунди;
• структурирано съхранение на метрики и табла за управление;
• SLA > 99,99%
• събиране на събитийни метрики чрез UDP (!).

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

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

Актуално: схема на взаимодействие между компонентите за мониторинг.

На първо място, наблюдаваме приложенията: нашия PHP код, приложенията и микросервизите — с други думи, всичко, което пишат нашите разработчици. Всички приложения изпращат метрики към агрегатора Brubeck (statsd, пренаписан на C) чрез UDP. Той се оказа най-бързият на база синтетичните тестове. И той изпраща вече агрегирани метрики в Graphite чрез TCP.

Има такъв тип метрики, като таймерите. Това е много удобен инструмент. Например, за всяко свързване на потребителя със сервиса изпращате в Brubeck метрика със времето за отговор. Получавате милион отговора, а агрегаторът излиза само с 10 метрики. Имате брой на дошлите хора, максимално, минимално и средно време за отговор, медиана и 4 персентиля. След това данните се предават в Graphite и виждаме всичко в реално време.

Имаме също агрегация за метрики по хардуер, софтуер, системни метрики и нашата стара система за мониторинг Munin (която функционираше при нас до 2015 година). Всичко това събираме чрез C демона CollectD (в него е вградена цяла партида различни плъгини, способен е да опитва всички ресурси на хост системата, на която е инсталиран, просто посочете в конфигурацията къде да запише данните) и записваме данни в Graphite чрез него. Освен това той поддържа плъгини за python и shell скриптове, така че можете да пишете свои собствени решения: CollectD ще събира тези данни от локален или отдалечен хост (да предположим, че има Curl) и да ги изпраща в Graphite.

След това всички метрики, които събрахме, изпращаме в Carbon-c-relay. Това решение Carbon Relay от Graphite е доработено на C. Това е рутер, който събира всички метрики, които изпращаме от нашите агрегатори, и ги маршрутизира по нодове. Освен това, на етапа на маршрутизация проверява валидността на метриките. Те трябва първо да отговарят на схемата с префиксите, която показах по-рано, и второ, да са валидни за графита. В противен случай, те ще бъдат отхвърлени.

След това Carbon-c-relay изпраща метриките в кластера Graphite. Използваме Carbon-cache, пренаписан на Go, като основно хранилище на метриките. Go-carbon поради многопоточността си значително превъзхожда по производителност Carbon-cache. Той приема данни и ги записва на дискове с помощта на пакета whisper (стандартен, написан на python). За да прочетем данните от нашите хранилища, използваме Graphite API. Той работи значително по-бързо в сравнение със стандартния Graphite WEB. Какво се случва с данните по-нататък?

Те отиват в Grafana. Като основен източник на данни използваме нашите графитни кластери, а също така имаме Grafana като уеб интерфейс за визуализация на метриките и строене на табла. За всеки свой сервис разработчиците създават собствено табло. След това те изграждат графики, на които се показват метриките, които пишат от своите приложения. Освен Grafana, имаме и SLAM. Това е демон на python, който изчислява SLA на базата на данни от графита. Както казах, имаме няколко десетки микросервиса, всеки от които има свои изисквания. С помощта на SLAM проверяваме документацията и я сравняваме с наличното в Graphite и сравняваме в каква степен изискванията отговарят на наличността на нашите услуги.

Продължаваме: алертингът. Той е организиран с помощта на силна система – Moira. Тя е независима, тъй като под капака има собствен Graphite. Разработена е от момчетата от СКБ "Контур", написана е на python и Go, напълно опенсорсна. Moira получава същия поток, който отива в графитите. Ако по някаква причина вашето хранилище умре, вашият алертинг ще продължи да работи.

Moira е внедрена в Kubernetes и използва кластер от Redis-сървъри като основна база данни. В крайна сметка това доведе до създаването на отказоустойчива система. Тя сравнява потока от метрики със списъка с тригери: ако в него няма упоминания, метриката се отхвърля. Така е способна да обработва гигабайти метрики в минута.

Също така сме свързали корпоративния LDAP, чрез който всеки потребител на корпоративната система може да създава нотификации за съществуващи (или новосъздадени) тригери. Понеже Moira включва Graphite, тя поддържа всички негови функции. Първо копирате реда в Grafana и наблюдавате как се визуализират данните на графиките. След това взимате същия ред и го копирате в Moira. Добавяте лимити и получавате алертиране на изхода. За всичко това не са ви нужни никакви специфични знания. Moira може да изпраща алерти чрез SMS, email, в Jira, Slack… Тя също така поддържа изпълнението на персонализирани скриптове. Когато се задейства тригер и тя е подписана на персонализиран скрипт или бинарен файл, го стартира и предава JSON на stdin на този бинарник. Следователно, вашата програма трябва да го парсва. Какво ще правите с този JSON — решавате сами. Искате — изпращайте в Telegram, искате — отваряйте задачи в Jira, правете каквото искате.

За алертиране ние използваме и собствена разработка — Imagotag. Адаптирахме панел, който обикновено се използва за електронни ценници в магазини, за нашите нужди. Изнесохме тригерите от Moira на него. Там е посочено в какво състояние се намират и кога са се случили. Част от екипа се отказа от уведомленията в Slack и email в полза на този панел.

Тъй като сме прогресивна компания, също така мониторираме Kubernetes в тази система. Включихме го в системата чрез Heapster, който инсталирахме в кластера, той събира данни и ги изпраща в Graphite. В крайна сметка схемата изглежда така:

Компоненти за мониторинг

Ето списък с връзки към компонентите, които използвахме за тази задача. Всички те са с отворен код.

Graphite:

• go-carbon: github.com/lomik/go-carbon
• whisper: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

Carbon-c-relay:

github.com/grobian/carbon-c-relay

Brubeck:

github.com/github/brubeck

Collectd:

collectd.org

Moira:

github.com/moira-alert

Grafana:

grafana.com

Heapster:

github.com/kubernetes/heapster

Статистика

И ето малко факти за това как системата работи при нас.

Агрегатор (brubeck)

Брой метрики: ~ 300 000 / сек
Интервал на изпращане на метрики в Graphite: 30 сек
Използване на ресурсите на сървъра: ~ 6% CPU (става въпрос за пълноценни сървъри); ~ 1Gb RAM; ~ 3 Mbps LAN

Graphite (go-carbon)

Брой метрики: ~ 1 600 000 / мин
Интервал на обновяване на метрики: 30 сек
Схема за съхранение на метрики: 30сек 35д, 5мин 90д, 10мин 365д (дава представа за това, което се случва със сервиза в продължителен период от време)
Използване на ресурсите на сървъра: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN

Гъвкавост

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

Ето пример за реално възникнала проблема. Метриката в Graphite е файл. Тя има име. Името на файла = името на метриката. И има път до него. Имената на файловете в Linux са ограничени до 255 символа. А при нас имаме (като “вътрешни клиенти”) момчета от отдела за бази данни. Те ни казват: "Искаме да мониторираме нашите SQL запитвания. А те не са 255 символа, а 8 MB всяко. Искаме да ги показваме в Grafana, да виждаме параметри за това запитване, а още по-добре, искаме да виждаме топ на такива запитвания. Ще е чудесно, ако се показват в реално време. А е наистина страхотно, ако ги запъхнем в алертинг".

Примерът с SQL-запитването е взет за пример от сайта postgrespro.ru

Ние стартираме Redis сървър и нашите Collectd плъгини, които се свързват с Postgres и извлекат всички данни, изпращаме метриките в Graphite. Но заменяме името на метриката с хешове. Този хеш в същото време се изпраща в Redis като ключ, а целият SQL заявка като стойност. Остава ни само да направим така, че Grafana да може да получава информация от Redis. Отваряме Graphite API, тъй като това е основния интерфейс за взаимодействие на всички компоненти на мониторинга с Graphite, и добавяме нова функция, наречена aliasByHash() — от Grafana получаваме името на метриката и го използваме в заявката към Redis като ключ, а в отговор получаваме стойността на ключа, която е нашият 'SQL заявка'. По този начин постигаме визуализация в Grafana на SQL заявката, която по идеята не беше възможно да се покаже там, заедно със статистика за нея (извиквания, редове, общо време и др.).

Итог

Наличие. Нашият мониторинг сервиз е достъпен 24/7 от всякакви приложения и всеки код. Ако имате достъп до хранилищата, можете да изпращате данни в сервиза. Езикът на програмиране не е важен, решенията не са важни. Нужно е само да знаете как да отворите сокет, да изпратите там метриката и да затворите сокета.

Надеждност. Всички компоненти са отказоустойчиви и се справят отлично с нашите натоварвания.

Нисък праг за навлизане. За да използвате тази система, не е необходимо да изучавате програмни езици и заявки в Grafana. Просто отворете вашето приложение, въведете сокета, който ще изпраща метрики в Graphite, затворете го, отворете Grafana, създайте там дашборди и наблюдавайте поведението на вашите метрики, получавайки известия чрез Moira.

Самостоятелност. Всичко това можете да правите сами, без помощта на DevOps инженери. И това наистина е излишно, защото можете да мониторите проекта си веднага, без да молите никого — нито за започване на работа, нито за промени.

Какво целим?

Всичко изброено по-долу не са просто абстрактни мисли, а това, за което са направени поне първите стъпки.

1. Детектор на аномалии. Искаме да внедрим услуга, която ще проверява всяка метрика в нашите Graphite хранилища по различни алгоритми. Вече имаме алгоритми, които искаме да наблюдаваме, имаме данни и знаем как да работим с тях.
2. Метаданни. Имаме много услуги, които с времето се променят, както и хората, които работят с тях. Постоянното ръчно поддържане на документация не е вариант. Затова сега в нашите микросервизи се вграждат метаданни. Там е записано кой ги е разработил, езиците, с които взаимодействат, изискванията по SLA, къде и на кого да се изпращат уведомления. При деплой на услугата всички данни на същността се създават автоматично. В крайна сметка получавате две връзки - една за тригерите, а другата - за дашбордите в Grafana.
3. Мониторинг в всеки дом. Считаме, че такава система трябва да се ползва от всички разработчици. В този случай винаги разбирате къде е вашият трафик, какво става с него, къде пада, къде са слабите му места. Ако, да кажем, дойде нещо и срине услугата ви, ще разберете за това не по време на обаждане от мениджъра, а от алерта, и веднага ще можете да отворите свежите логове и да видите какво е станало.
4. Висока производителност. Нашият проект постоянно расте и днес в него се обработват около 2 000 000 стойности на метрики в минута. Преди година този показател беше 500 000. А ръстът продължава, и това означава, че след време Graphite (whisper) ще започне да натоварва много силно дисковата система. Както вече споменах, тази система за мониторинг е доста универсална благодарение на взаимозаменяемостта на компонентите. Някои специално обслужват Graphite и постоянно разширяват инфраструктурата си, но ние решихме да тръгнем по друг път: да използваме ClickHouse като хранилище на нашите метрики. Този преход практически е завършен и съвсем скоро ще разкажа по-подробно как беше направен: какви трудности имаше и как бяха преодолени, как протичаше процесът на миграция, ще опиша избраните за обвивки компоненти и тяхната конфигурация.

Благодаря за вниманието! Задавайте своите въпроси по темата, ще се постарая да отговоря тук или в следващите постове. Възможно е някой да има опит с изграждането на подобна система за мониторинг или прехода към Clickhouse в подобна ситуация — споделяйте го в коментарите.

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