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

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

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

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

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

Имахме около 24 възела, които отговаряха за мониторинга. Има цял куп различни crons, скриптове, демони, които наблюдават нещо някъде, изпращат съобщения, изпълняват функции. Смятахме, че колкото по-нататък, толкова по-малко ще бъде жизнеспособна такава система. Няма смисъл да се развива: твърде е тромаво.
Решихме да изберем тези елементи на мониторинг, които ще оставим и развием, и тези, които ще изоставим. Бяха 19. Останаха само графити, агрегатори и Графана като табло. Но как ще изглежда новата система? Като този:

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

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

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

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

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

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

Настояще: схемата на взаимодействие на компонентите за мониторинг

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

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

Имаме и агрегиране за хардуер, софтуер, системни показатели и старата ни система за наблюдение Munin (работеше с нас до 2015 г.). Събираме всичко това чрез C'ish daemon 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 като уеб интерфейс за показване на показатели, изграждане на табла за управление. За всяка своя услуга разработчиците създават собствено табло за управление. След това те изграждат графики въз основа на тях, които показват показателите, които записват от своите приложения. Освен Графана имаме и SLAM. Това е питоничен демон, който изчислява SLA въз основа на данни от графит. Както казах, имаме няколко дузини микроуслуги, всяка от които има свои собствени изисквания. С помощта на SLAM отиваме в документацията и я сравняваме с това, което е в Graphite, и сравняваме как изискванията съответстват на наличността на нашите услуги.

Продължавайки по-нататък: алармиране. Организиран е със силна система - Мойра. Тя е независима, защото има собствен графит под капака. Разработено от момчетата от SKB Kontur, написано на python и Go, напълно отворен код. Мойра получава същия поток, който отива в графитите. Ако по някаква причина вашето хранилище умре, вашето предупреждение ще работи.

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

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

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

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

Компоненти за наблюдение

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

Графит:

• въглероден: github.com/lomik/go-carbon
• прошепвам: github.com/graphite-project/whisper
• графит-api: github.com/brutasse/graphite-api

Carbon-c-реле:

github.com/grobian/carbon-c-relay

Брубек:

github.com/github/brubeck

Събран:

collectd.org

Мойра:

github.com/moira-alert

Графана:

grafana.com

купчина:

github.com/kubernetes/heapster

статистика

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

Агрегатор (брубек)

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

Графит (go-carbon)

Брой показатели: ~ 1 600 000 / мин
Интервал за актуализиране на показателите: 30 сек
Схема за съхранение на показатели: 30sec 35d, 5min 90d, 10min 365d (дава разбиране какво се случва с услугата за дълъг период от време)
Използване на сървърни ресурси: ~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, защото това е основният интерфейс за взаимодействие на всички компоненти за наблюдение с графит и ние въвеждаме нова функция там, наречена aliasByHash () - получаваме името на показателя от Grafana и го използваме в заявка към Redis като ключ, в отговор получаваме стойността на ключа, който е нашата „SQL заявка“. Така донесохме в Grafana показването на SQL заявка, която на теория не можеше да се покаже там, заедно със статистика за нея (обаждания, редове, total_time, ...).

Резултати от

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

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

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

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

Към какво се стремим?

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

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

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

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