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

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

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

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

Как стигнахме до съществуващата система за мониторинг? За да отговорим на този въпрос, трябва да се върнем до 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. Това е рутер, който събира всички метрики, които изпращаме от нашите агрегатори, и маршрутизира тях по нодове. Освен това, по време на маршрутизацията проверява валидността на метриките. Те, от една страна, трябва да отговарят на схемата с префиксите, която показах по-рано и, от друга страна, да са валидни за Graphite. В противен случай те се отхвърлят.

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

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

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

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

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

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

Тъй като сме прогресивна компания, следим и 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

Статистика

И ето малко цифри за тоа, како системата работи кај нас.

Aggregator (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