Сёння на нашым праекце, апроч маналітнага кода, функцыянуюць дзясяткі мікрасэрвісаў. Кожны з іх патрабуе таго, каб яго маніторылі. Рабіць гэта ў такіх аб'ёмах сіламі DevOps-інжынераў праблематычна. Мы распрацавалі сістэму маніторынгу, якая працуе як сэрвіс для распрацоўшчыкаў. Яны могуць самастойна пісаць метрыкі ў сістэму маніторынгу, карыстацца імі, будаваць на іх падставе дашборды, прыкручваць да іх алерты, якія будуць спрацоўваць пры дасягненні парогавых значэнняў. З DevOps-інжынераў - толькі інфраструктура і дакументацыя.
Гэты пост – расшыфроўка майго выступу з нашай. на рыт +. Многія прасілі нас зрабіць тэкставыя версіі дакладаў адтуль. Калі вы былі на канферэнцыі ці глядзелі відэа, то не знойдзеце нічога новага. А ўсім астатнім - сардэчна запрашаем пад кат. Раскажу, як мы прыйшлі да такой сістэмы, як яна працуе і як мы плануем яе абнаўляць.
Мінулае: схемы і планы
Як мы прыйшлі да існуючай сістэмы маніторынгу? Для таго каб адказаць на гэтае пытанне, трэба адправіцца ў 2015 год. Вось як гэта выглядала тады:
У нас існавала каля 24 вузлоў, якія адказвалі за маніторынг. Тут ёсць цэлы пачак розных кронаў, скрыптоў, дэманаў, якія нешта дзесьці нейкім чынам маніторыць, адпраўляюць паведамленні, выконваюць функцыі. Мы падумалі, што чым далей, тым менш такая сістэма будзе жыццяздольнай. Развіваць яе няма сэнсу: занадта грувасткая.
Мы вырашылі абраць тыя элементы маніторынгу, якія мы пакінем і будзем развіваць, і тыя, ад якіх адмовімся. Іх аказалася 19. Засталіся толькі графіты, агрэгатары і Grafana у якасці дашборда. Але як будзе выглядаць новая сістэма? Вось так:
У нас ёсць сховішча метрык: гэта графіты, якія будуць грунтавацца на хуткіх SSD-дысках, гэта пэўныя агрэгатары для метрык. Далей - Grafana для вываду дашбордаў і Moira ў якасці алертынгу. Таксама мы хацелі распрацаваць сістэму для пошуку анамалій.
Стандарт: Маніторынг 2.0
Так выглядалі планы ў 2015 годзе. Але нам трэба было рыхтаваць не толькі інфраструктуру і сам сэрвіс, але і дакументацыю да яго. Мы для сябе распрацавалі карпаратыўны стандарт, які назвалі маніторынг 2.0. Якія патрабаванні былі да сістэмы?
- пастаянная даступнасць;
- інтэрвал захоўвання метрык = 10 секунд;
- структураванае захоўванне метрык і дашбордаў;
- SLA > 99,99%
- збор івэнтавых метрык па UDP (!).
Нам быў неабходны UDP, бо ў нас вялікі паток трафіку і падзей, якія генеруюць метрыкі. Калі іх усё адразу пісаць у графіт, сховішча ляжа. Таксама мы выбралі прэфіксы першага ўзроўню для ўсіх метрык.
Кожны з прэфіксаў носіць нейкую ўласцівасць. Ёсць метрыкі па серверах, сетках, кантэйнерах, рэсурсах, прыкладанням і гэтак далей. Рэалізавана дакладнае, строгае, тыпізаванае фільтраванне, дзе мы прымаем метрыкі першага ўзроўню, а астатнія проста драпаем. Вось як мы планавалі гэтую сістэму ў 2015 годзе. Што ж у сучаснасці?
Сапраўднае: схема ўзаемадзеяння кампанентаў маніторынгу
У першую чаргу мы маніторым аплікейшны: наш PHP-код, прыкладанні і мікрасэрвісы - словам, усё, што пішуць нашы распрацоўшчыкі. Усе аплікейшны праз UDP адпраўляюць метрыкі ў агрэгатар Brubeck (statsd, перапісаны на З). Ён аказаўся самым хуткім па выніках сінтэтычных тэстаў. І ён адпраўляе ўжо агрэгаваныя метрыкі ў Graphite праз TCP.
У яго ёсць такі тып метрык, як таймеры. Гэта вельмі зручная штука. Напрыклад, на кожнае злучэнне карыстальніка з сэрвісам вы адпраўляеце ў Brubeck метрыку з response time. Прыйшоў мільён адказаў, а агрэгатар выдаў усяго 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. Гэта сілкавальны дэман, які лічыць SLA на падставе дадзеных з графіту. Як я ўжо казаў, у нас ёсць некалькі дзясяткаў мікрасэрвісаў, у кожнага з якіх ёсць свае патрабаванні. З дапамогай SLAM мы ходзім у дакументацыю і параўноўваем яе з тым, што ёсць у Graphite і параўноўваем, наколькі патрабаванні адпавядаюць даступнасці нашых сэрвісаў.
Ідзем далей: алертынг. Ён арганізаваны з дапамогай моцнай сістэмы - Moira. Яна незалежная таму, што ў яе пад капотам свой уласны Graphite. Распрацаваная хлопцамі са СКБ «Контур», напісаная на python і Go, цалкам апенсорсная. Moira атрымлівае ў сябе ўвесь той жа струмень, што сыходзіць у графіты. Калі па нейкай прычыне ў вас памрэ сховішча, то ваш алертынг будзе працаваць.
Moira мы разгарнулі ў Kubernetes, у якасці асноўнай базы дадзеных яна выкарыстоўвае кластар Redis-сервераў. У выніку атрымалася адмоваўстойлівая сістэма. Яна параўноўвае паток метрык са спісам трыгераў: калі ў ім няма згадак, то драпае метрыку. Так яна здольная пераварыць гігабайты метрык у хвіліну.
Яшчэ мы да яе прыкруцілі карпаратыўны LDAP, з дапамогай якога кожны карыстач карпаратыўнай сістэмы можа ствараць для сябе натыфікацыі па існых (ці ізноў створаным) трыгерам. Бо Moira утрымоўвае ў сабе Graphite, яна падтрымлівае ўсе яго функцыі. Таму вы спачатку бераце радок і капіюеце яе ў Grafana. Глядзіце, як адлюстроўваюцца дадзеныя на графіках. А потым бераце гэты ж радок і капіюеце яе ў Moira. Абвешваеце яе лімітамі і атрымліваеце на выхадзе алертынг. Каб усё гэта рабіць, вам не патрэбны ніякія спецыфічныя веды. Moira умее алерціць па смс, email, у Jira, Slack… Таксама яна падтрымлівае выкананне кастамных скрыптоў. Калі ў яе здараецца трыгер, і яна падпісана на кастамны скрыпт ці бінарнік, яна яго запускае, і аддае на stdin гэтаму бінарніку JSON. Адпаведна, ваша праграма павінна яго распарсіць. Што вы будзеце з гэтым JSONам рабіць - вырашайце самі. Жадаеце - адпраўляйце ў Telegram, жадаеце - адкрывайце цягі ў Jira, рабіце што заўгодна.
У нас для алертынгу выкарыстоўваецца яшчэ і ўласная распрацоўка - Imagotag. Мы адаптавалі панэль, якая прымяняецца звычайна для электронных цэннікаў у крамах, пад нашы задачы. Мы вывелі на яе трыгеры з Moira. Там пазначана, у якім яны стане, калі адбыліся. Частка рабят з распрацоўкі адмовіліся ад апавяшчэнняў у Slack і ў пошту на карысць вось гэтай панэлькі.
Ну і так як мы - прагрэсіўная кампанія, то заманіторылі ў гэтай сістэме яшчэ і Kubernetes. Уключылі яго ў сістэму з дапамогай Heapster, які мы ўсталявалі ў кластар, ён збірае дадзеныя і адпраўляе іх у Graphite. У выніку схема выглядае вось так:
Кампаненты маніторынгу
Вось спіс спасылак на тыя кампаненты, якія мы выкарыстоўвалі для гэтай задачы. Усе яны - апенсорсныя.
Графіт:
- go-carbon:
- whisper:
- graphite-api:
Carbon-c-relay:
Brubeck:
Сабрана:
Мойра:
Графана:
Heapster:
Статыстыка
І вось крыху лічбаў пра тое, як сістэма працуе ў нас.
Aggregator (brubeck)
Колькасць метрык: ~300 000 / sec
Інтэрвал адпраўкі метрык у Graphite: 30 sec
Выкарыстанне рэсурсаў сервера: ~ 6% CPU (гаворка ідзе аб паўнавартасных серверах); ~ 1Gb RAM; ~ 3 Mbps LAN
Graphite (go-carbon)
Колькасць метрык: ~1 600 000/min
Інтэрвал абнаўлення метрык: 30 sec
Схема захоўвання метрык: 30sec 35d, 5min 90d, 10min 365d (дае разуменне што адбываецца з сэрвісам на працяглым этапе часу)
Выкарыстанне рэсурсаў сервера: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Гнуткасць
Мы ў Avito вельмі шануем у нашым сэрвісе маніторынгу гнуткасць. Чаму, ён атрымаўся такім? У першых, яго складовыя часткі ўзаемазаменныя: як самі кампаненты, так і іх версіі. Па-другое - падтрымлівальнасць. Бо ўвесь праект пабудаваны на апенсорсе, вы самі можаце кіраваць код, уносіць змены, можаце рэалізоўваць функцыі, недаступныя са скрынкі. Выкарыстоўваюцца досыць распаўсюджаныя стэкі, у асноўным, Go і Python, таму гэта робіцца дастаткова проста.
Вось прыклад рэальна ўзніклай праблемы. Метрыка ў Graphite - гэта файл. У яго ёсць назва. Імя файла = імя метрыкі. І ёсць шлях да яго. Назвы файлаў у Linux абмежаваныя 255 знакамі. А ў нас ёсць (у якасці "ўнутраных заказчыкаў") хлопцы з аддзела баз даных. Яны нам гавораць: “Мы хочам маніторыць нашы SQL-запыты. А яны – не 255 сімвалаў, а 8 МБ кожны. Мы іх жадаем адлюстроўваць у Grafana, бачыць параметры па гэтым запыце, а яшчэ лепш, мы жадаем бачыць топ такіх запытаў. Будзе выдатна, калі ён будзе адлюстроўвацца ў рэальным часе. А зусім крута было б запхнуць іх у алертынг”.
Прыклад SQL-запыту ўзяты ў якасці прыкладу з
Мы падымаем сервер Redis і нашымі Collectd-плагінамі, якія ходзяць у Postgres і бяруць адтуль усе дадзеныя, адпраўляем метрыкі ў Graphite. Але заменны імя метрыкі на хэшы. Гэты ж хэш адначасова адпраўляем у Redis у якасці ключа, і ўвесь SQL-запыт у якасці значэння. Нам засталося зрабіць так, каб Grafana умела хадзіць у Redis і браць гэтую інфармацыю. Мы адчыняем Graphite API, т.к. гэта асноўны інтэрфейс узаемадзеяння ўсіх кампанентаў маніторынгу з графітам, і ўпісваем туды новую функцыю, якая называецца aliasByHash() - ад Grafana атрымліваем імя метрыкі, і выкарыстоўваем яго ў запыце да Redis як ключ, у адказ атрымліваем значэнне ключа, якім з'яўляецца наш “SQL запыт ”. Такім чынам, мы вывелі ў Grafana адлюстраванне SQL-запыту, які па ідэі адлюстраваць там было ніяк нельга, разам са статыстыкай па ім (calls, rows, total_time, …).
Вынікі
Даступнасць. Наш сэрвіс маніторынгу даступны 24 на 7 з любога аплікейшна і любога кода. Калі ў вас ёсць доступ да сховішчаў, вы можаце пісаць у сэрвіс дадзеныя. Мова няважная, рашэнні не важныя. Вам трэба толькі ведаць як адкрыць сокет, закінуць туды метрыку і закрыць сокет.
Надзейнасць. Усе кампаненты адмоваўстойлівыя і спраўляюцца з нашымі нагрузкамі добра.
Нізкі парог уваходжання. Для таго каб карыстацца гэтай сістэмай, вам не трэба вывучаць мовы праграмавання і запыты ў Grafana. Проста адчыняеце ваша прыкладанне, упісваеце ў яго сокет, які будзе адпраўляць метрыкі ў Graphite, зачыняеце яго, адчыняеце Grafana, ствараеце тамака дэшборды і гледзіце на паводзіны вашых метрык, атрымліваючы апавяшчэнні праз Moira.
Самастойнасць. Усё гэта можна рабіць самім, без дапамогі DevOps-інжынераў. І гэта аверфіча, таму што вы можаце маніторыць свой праект прама цяпер, нікога не трэба прасіць - ні для пачатку працы, ні для змен.
Да чаго мы імкнемся?
Усё пералічанае ніжэй — гэта не проста абстрактныя думкі, а тое, да чаго зроблены хаця б першыя крокі.
- Дэтэктар анамалій. Жадаем запілаваць у сябе сэрвіс, які будзе хадзіць у нашы Graphite-сховішчы і кожную метрыку правяраць па розных алгарытмах. Ужо ёсць алгарытмы, якія мы жадаем праглядаць, ёсць дадзеныя, мы ўмеем з імі працаваць.
- Метададзеныя. У нас шмат сэрвісаў, з часам яны мяняюцца, гэтак жа як і людзі, якія з імі працуюць. Пастаянна весці дакументацыю ўручную - не варыянт. Таму зараз у нашы мікрасэрвісы ўбудоўваюцца метададзеныя. Там прапісана, хто яго распрацаваў, мовы, з якімі ён узаемадзейнічае, патрабаванні па SLA, куды і каму дасылаць натыфікацыі. Пры дэплоі сэрвісу ўсе дадзеныя сутнасці ствараюцца самастойна. У выніку вы атрымліваеце дзве спасылкі - адна на трыгеры, іншая - на дэшборды ў Grafana.
- Маніторынг у кожную хату. Мы лічым, што падобнай сістэмай павінны карыстацца ўсе распрацоўшчыкі. У гэтым выпадку вы заўсёды разумееце, дзе ваш трафік, што з ім адбываецца, дзе ён падае, дзе ў яго слабыя месцы. Калі, дапусцім, прыйдзе нешта і заваліць ваш сэрвіс, то вы даведаецеся пра гэта не падчас званка ад мэнэджара, а ад алерта, і адразу зможаце адкрыць свежыя логі і паглядзець, што там адбылося.
- Высокая прадукцыйнасць. Наш праект увесь час расце, і сёння ў ім апрацоўваецца каля 2 000 000 значэнняў метрык у хвіліну. Год таму гэты паказчык складаў 500. А рост працягваецца, і гэта значыць, што праз нейкі час Graphite (whisper) пачне вельмі моцна нагружаць дыскавую падсістэму. Як я ўжо казаў, гэтая сістэма маніторынгу даволі ўніверсальная за кошт узаемазаменнасці кампанентаў. Хтосьці спецыяльна пад Graphite абслугоўвае і ўвесь час пашырае сваю інфраструктуру, але мы вырашылі пайсці іншым шляхам: выкарыстоўваць у якасці сховішча нашых метрык. Гэты пераход практычна завершаны, і зусім хутка я распавяду падрабязней, як гэта было зроблена: якія былі цяжкасці і як яны былі пераадолены, як праходзіў працэс міграцыі, апішу абраныя ў якасці абвязкі кампаненты і іх канфігурацыі.
Дзякуй за ўвагу! Задавайце свае пытанні па тэме, пастараюся адказаць тут ці ў наступных пастах. Магчыма, у кагосьці ёсць вопыт пабудовы падобнай сістэмы маніторынгу або пераходу на Clickhouse ў падобнай сітуацыі – дзяліцеся ім у каментарах.
Крыніца: habr.com