Бүгүнкү күндө, монолиттүү коддон тышкары, биздин долбоор ондогон микросервистерди камтыйт. Алардын ар бири көзөмөлгө алууну талап кылат. Муну DevOps инженерлеринин жардамы менен ушундай масштабда жасоо көйгөйлүү. Биз иштеп чыгуучулар үчүн кызмат катары иштеген мониторинг системасын иштеп чыктык. Алар мониторинг системасына метрикаларды өз алдынча жазып, аларды колдоно алышат, алардын негизинде башкаруу такталарын түзө алышат жана босого маанилерге жеткенде аларга эскертүүлөрдү тиркей алышат. DevOps инженерлери үчүн инфраструктура жана документтер гана.
Бул пост биздин сөзүмдүн стенограммасы RIT++ боюнча. Көптөр бизден отчеттордун тексттик версияларын ошол жактан жасап берүүнү суранышты. Эгер сиз конференцияда болгон болсоңуз же видеону көргөн болсоңуз, анда жаңы эч нерсе таба албайсыз. Ал эми калгандары - мышыкка кош келиңиздер. Мен мындай системага кантип келгенибизди, ал кантип иштейт жана аны кантип жаңыртууну пландап жатканыбызды айтып берем.
Өткөн: схемалар жана пландар
Биз азыркы мониторинг системасына кантип келдик? Бул суроого жооп берүү үчүн 2015-жылга барышыңыз керек. Анда мындай көрүнгөн:
Бизде мониторинг жүргүзүү үчүн жооптуу болгон 24дөй түйүн бар болчу. Кандайдыр бир жол менен бир нерсени көзөмөлдөгөн, билдирүүлөрдү жөнөтүүчү жана функцияларды аткарган ар кандай таажылардын, сценарийлердин, демондордун бүтүндөй пакети бар. Биз канчалык ары барсак, мындай система ошончолук жарамдуу болбой калат деп ойлодук. Аны иштеп чыгуунун эч кандай пайдасы жок: бул өтө түйшүктүү.
Биз сактай турган жана өнүктүрө турган жана андан баш тарта турган мониторинг элементтерин тандап алууну чечтик. Алардын саны 19. Текшерүү тактасы катары графиттер, агрегаторлор жана Графана гана калды. Бирок жаңы система кандай болот? Бул сыяктуу:
Бизде метрика сактагыч бар: бул графиттер, алар тез SSD дисктерине негизделет, булар метрика үчүн белгилүү агрегаторлор. Кийинки - башкаруу панелдерин көрсөтүү үчүн Grafana жана эскертүү үчүн Moira. Биз ошондой эле аномалияларды издөө системасын иштеп чыгууну кааладык.
Стандарт: Мониторинг 2.0
2015-жылы пландар ушундай болгон. Бирок биз инфраструктураны жана кызматтын өзүн эле эмес, ага документацияны да даярдашыбыз керек болчу. Биз өзүбүз үчүн корпоративдик стандартты иштеп чыктык, аны мониторинг 2.0 деп атайбыз. Системага кандай талаптар коюлду?
- туруктуу болушу;
- метрикалык сактоо аралыгы = 10 секунд;
- метрика жана башкаруу панелдерин структуралаштырылган сактоо;
- SLA > 99,99%
- UDP (!) аркылуу окуянын көрсөткүчтөрүн чогултуу.
Бизге UDP керек болчу, анткени бизде трафиктин жана метрикаларды жараткан окуялардын чоң агымы бар. Эгер алардын баарын бир эле учурда графитке жазсаңыз, сактагыч кыйрап калат. Ошондой эле бардык көрсөткүчтөр үчүн биринчи деңгээлдеги префикстерди тандадык.
Префикстердин ар бири кандайдыр бир касиетке ээ. Серверлердин, тармактардын, контейнерлердин, ресурстардын, тиркемелердин жана башкалар үчүн көрсөткүчтөр бар. Таза, катуу, терилген чыпкалоо ишке ашырылды, мында биз биринчи деңгээлдеги көрсөткүчтөрдү кабыл алып, калганын жөн эле таштайбыз. Биз 2015-жылы бул системаны ушинтип пландаштырганбыз. Азыркы учурда эмне бар?
Бул: мониторинг компоненттеринин өз ара аракеттенүүсүнүн диаграммасы
Биринчиден, биз тиркемелерди көзөмөлдөйбүз: биздин PHP кодубуз, тиркемелерибиз жана микросервистер - кыскасы, биздин иштеп чыгуучулар жазгандын бардыгы. Бардык колдонмолор метрикаларды UDP аркылуу Brubeck агрегаторуна жөнөтөт (statsd, C тилинде кайра жазылган). Бул синтетикалык сыноолордо эң ылдам болуп чыкты. Жана ал буга чейин топтолгон көрсөткүчтөрдү TCP аркылуу Graphiteге жөнөтөт.
Анын таймерлер деп аталган бир түрү бар. Бул абдан ыңгайлуу нерсе. Мисалы, ар бир колдонуучу кызматка туташуу үчүн, сиз Брубекке жооп берүү убактысы менен метрика жөнөтөсүз. Миллион жооп келди, бирок агрегатор болгону 10 метриканы кайтарды. Сизде келген адамдардын саны, максималдуу, минималдуу жана орточо жооп берүү убактысы, медиана жана 4-проценттил бар. Андан кийин маалыматтар Graphiteге өткөрүлүп берилет жана биз анын бардыгын жандуу көрөбүз.
Бизде ошондой эле аппараттык, программалык камсыздоо, тутумдук метрика жана эски Мунин мониторинг системабыз боюнча көрсөткүчтөрдү бириктирүү бар (ал биз үчүн 2015-жылга чейин иштеген). Биз мунун баарын C демону CollectD аркылуу чогултабыз (анын ичинде орнотулган ар кандай плагиндер бар, ал орнотулган хост тутумунун бардык ресурстарын сурай алат, жөн гана конфигурацияда маалыматтарды кайда жазууну көрсөтүңүз) жана ал аркылуу Graphiteге маалыматтарды жаз. Ал ошондой эле python плагиндерин жана кабык скрипттерин колдойт, андыктан сиз өзүңүздүн жекече чечимдериңизди жаза аласыз: CollectD бул маалыматты жергиликтүү же алыскы хосттон (Curl деп эсептегенде) чогултуп, Graphiteге жөнөтөт.
Андан кийин биз чогулткан бардык көрсөткүчтөрдү Carbon-c-relayге жөнөтөбүз. Бул C тилинде өзгөртүлгөн Graphite компаниясынын Carbon Relay чечими. Бул роутер, ал биз агрегаторлордон жөнөткөн бардык көрсөткүчтөрдү чогултуп, аларды түйүндөргө багыттайт. Ошондой эле багыттоо баскычында, ал метрикалардын жарактуулугун текшерет. Биринчиден, алар мен мурда көрсөткөн префикс схемасына туура келиши керек, экинчиден, алар графит үчүн жарактуу. Болбосо алар түшүп калат.
Андан кийин Carbon-c-релеси метрикаларды Graphite кластерине жөнөтөт. Go'до кайра жазылган Carbon-кэшти метрикалардын негизги сактагычы катары колдонобуз. Go-carbon, анын көп жиптүүлүгүнөн улам, Carbon-кэштен алда канча ашып кетет. Ал маалыматтарды кабыл алат жана шыбыш пакетинин жардамы менен дисктерге жазат (стандарт, питондо жазылган). Биздин сактагычтардагы маалыматтарды окуу үчүн, биз Graphite API колдонобуз. Бул стандарттуу Graphite WEB караганда бир топ ылдам. Кийинки маалыматтар менен эмне болот?
Алар Графанага барышат. Биз графит кластерлерибизди маалыматтардын негизги булагы катары колдонобуз, ошондой эле бизде метрикаларды көрсөтүү жана башкаруу панелдерин куруу үчүн веб-интерфейс катары Grafana бар. Ар бир кызматтары үчүн иштеп чыгуучулар өздөрүнүн башкаруу тактасын түзүшөт. Андан кийин алар өздөрүнүн тиркемелеринен жазган көрсөткүчтөрүн көрсөткөн алардын негизинде графиктерди түзүшөт. Графанадан тышкары бизде SLAM да бар. Бул графиттен алынган маалыматтардын негизинде SLA эсептеген питон жини. Мен буга чейин айткандай, бизде бир нече ондогон микросервистер бар, алардын ар биринин өзүнүн талаптары бар. SLAMди колдонуу менен биз документацияга кирип, аны Graphiteдегилер менен салыштырып, талаптардын биздин кызматтардын жеткиликтүүлүгүнө канчалык дал келерин салыштырабыз.
Андан ары баралы: эскертүү. Бул күчтүү системаны колдонуу менен уюштурулган - Moira. Ал көз карандысыз, анткени анын капоттун астында өзүнүн Графити бар. "Контур" СКБнын балдары тарабынан иштелип чыккан, python жана Go тилдеринде жазылган, толугу менен ачык булак. Мойра графиттерге кирген агымды алат. Эгер кандайдыр бир себептерден улам сактагычыңыз өлүп калса, эскертүүңүз иштей берет.
Биз Moiraны Кубернетеске жайгаштырдык; ал негизги маалымат базасы катары Redis серверлеринин кластерин колдонот. Натыйжада каталарга чыдамдуу система пайда болду. Ал көрсөткүчтөрдүн агымын триггерлердин тизмеси менен салыштырат: эгерде анда эч кандай эскертүүлөр жок болсо, анда ал метриканы түшүрөт. Ошентип, ал мүнөтүнө гигабайт метриканы сиңире алат.
Биз ошондой эле ага корпоративдик LDAP тиркедик, анын жардамы менен корпоративдик системанын ар бир колдонуучусу учурдагы (же жаңы түзүлгөн) триггерлердин негизинде өзү үчүн эскертмелерди түзө алат. Moira Graphite камтыгандыктан, анын бардык өзгөчөлүктөрүн колдойт. Ошентип, сиз адегенде сызыкты алып, аны Grafanaга көчүрөсүз. Берилиштер графиктерде кандайча чагылдырылганын караңыз. Анан ошол эле сапты алып, Мойрага көчүрөсүз. Сиз аны чектөөлөр менен илип, чыгарууда эскертүү аласыз. Мунун баарын жасоо үчүн сизге эч кандай атайын билимдин кереги жок. Мойра SMS, электрондук почта, Jira, Slack аркылуу эскерте алат ... Ошондой эле ыңгайлаштырылган скрипттердин аткарылышын колдойт. Качан ага триггер болуп, ал ыңгайлаштырылган скриптке же бинардыкга жазылганда, ал аны иштетип, бул бинардык үчүн stdin'ге JSON жөнөтөт. Демек, программаңыз аны талдоо керек. Бул JSON менен эмне кылуу сизге көз каранды. Кааласаң Telegramга жөнөт, кааласаң Жирада тапшырмаларды ач, каалаганын кыл.
Биз ошондой эле эскертүү үчүн өзүбүздүн иштеп чыгуубузду колдонобуз - Imagotag. Адатта дүкөндөрдө электрондук баалар үчүн колдонулуучу панелди муктаждыктарыбызга ылайыкташтырдык. Биз ага Мойрадан триггерлерди алып келдик. Алар кандай абалда жана качан пайда болгонун көрсөтөт. Кээ бир иштеп чыгуучулар бул панелдин пайдасына Slack жана электрондук почта эскертмелеринен баш тартышты.
Ооба, биз прогрессивдүү компания болгондуктан, биз бул системада Kubernetes да мониторинг жүргүздүк. Биз аны Heapster аркылуу системага киргиздик, аны кластерге орноттук, ал маалыматтарды чогултуп, Graphiteге жөнөтөт. Натыйжада, диаграмма төмөнкүдөй көрүнөт:
Мониторинг компоненттери
Бул жерде биз бул тапшырма үчүн колдонгон компоненттерге шилтемелердин тизмеси. Алардын баары ачык булак болуп саналат.
Графит:
- көмүртек:
- шыбырап:
- графит-апи:
Көмүртек-с-реле:
Брубек:
Чогултулган:
Мойра:
Grafana:
Heapster:
Статистика
Ал эми бул жерде система биз үчүн кандай иштээри жөнүндө кээ бир сандар.
Агрегатор (брюбек)
Метрикалардын саны: ~300/сек
Графитке метрика жөнөтүү аралыгы: 30 сек
Сервер ресурстарын колдонуу: ~ 6% CPU (сөз толук кандуу серверлер жөнүндө болуп жатат); ~ 1 Гб оперативдик эс; ~3 Mbps LAN
Графит (көмүртек)
Метрикалардын саны: ~ 1/мин
Метрикаларды жаңыртуу аралыгы: 30 сек
Метрикаларды сактоо схемасы: 30сек. 35d, 5m. 90d, 10m. 365d (узак убакыттын ичинде кызматка эмне болорун түшүнүүгө жардам берет)
Сервер ресурстарын колдонуу: ~10% CPU; ~ 20 Гб RAM; ~30 Мбит/сек LAN
ийкемдүүлүк
Авитодо биз мониторинг кызматыбыздагы ийкемдүүлүктү баалайбыз. Эмне үчүн ал чындыгында ушундай болуп чыкты? Биринчиден, анын компоненттери бири-бири менен алмаштырылат: компоненттердин өзү да, алардын версиялары да. Экинчиден, колдоо. Долбоордун баары ачык булак болгондуктан, сиз кодду өзүңүз оңдоп, өзгөртүүлөрдү киргизип, кутудан чыкпай турган функцияларды ишке ашыра аласыз. Бир топ кеңири таралган стектер колдонулат, негизинен Go жана Python, ошондуктан бул абдан жөнөкөй.
Мына чыныгы көйгөйдүн мисалы. Графиттеги метрика бул файл. Анын аты бар. Файлдын аты = метрикалык аталыш. Жана ал жакка жетүүнүн жолу бар. Linux'та файл аттары 255 белги менен чектелген. Ал эми бизде ("ички кардарлар" катары) маалымат базасы бөлүмүнүн балдары бар. Алар бизге: “Биз SQL сурамдарыбызды көзөмөлдөгүбүз келет. Жана алар 255 белги эмес, ар бири 8 МБ. Биз аларды Grafanaда көрсөтүүнү каалайбыз, бул сурамдын параметрлерин көргүбүз келет жана андан да жакшысы, биз мындай суроо-талаптардын жогору жагын көргүбүз келет. Ал реалдуу убакытта көрсөтүлсө сонун болот. Аларды эскертүүгө коюу абдан сонун болмок ».
Мисал SQL суроосу мисал катары алынган
Биз Redis серверин орнотуп, Collectd плагиндерибизди колдонобуз, алар Postgresке барып, бардык маалыматтарды ошол жерден алып, Graphiteге метрика жөнөтөбүз. Бирок биз метрикалык аталышты хэштер менен алмаштырабыз. Биз бир эле учурда бир эле хэшти Redisге ачкыч катары жана бүт SQL суроосун маани катары жөнөтөбүз. Болгону, Графана Редиске барып, бул маалыматты ала аларына ынануу керек. Биз Graphite API ачып жатабыз, анткени... бул бардык мониторинг компоненттеринин графит менен өз ара аракеттенүүсүнүн негизги интерфейси жана биз ал жерге aliasByHash() деп аталган жаңы функцияны киргизебиз - Grafanaдан биз метриканын атын алабыз жана аны Redisге ачкыч катары сурамда колдонобуз. жооп биз ачкычтын маанисин алабыз, бул биздин "SQL сурамыбыз" " Ошентип, биз Grafana'да SQL сурамынын дисплейин көрсөттүк, аны теориялык жактан ал жерде көрсөтүү мүмкүн эмес жана андагы статистика (чалуулар, саптар, жалпы_убакыт, ...).
натыйжалары
Болушу. Биздин мониторинг кызматыбыз 24/7 каалаган колдонмодон жана каалаган коддон жеткиликтүү. Эгер сизде сактоочу жайларга мүмкүнчүлүк болсо, сиз кызматка маалыматтарды жаза аласыз. Тил маанилүү эмес, чечимдер маанилүү эмес. Болгону розетка ачып, ал жерге метрика коюп, розетканы жапканды билиш керек.
Ишенимдүүлүк. Бардык компоненттер каталарга чыдамдуу жана биздин жүктөрдү жакшы көтөрөт.
Кирүү үчүн аз тоскоолдук. Бул системаны колдонуу үчүн, сиз Grafanaдагы программалоо тилдерин жана суроо-талаптарын үйрөнүүнүн кереги жок. Жөн гана колдонмоңузду ачып, ага метрикаларды Graphiteге жөнөтө турган розетка киргизиңиз, аны жаап, Grafana ачып, ал жерде башкаруу такталарын түзүп, Moira аркылуу эскертмелерди алып, метрикаңыздын жүрүм-турумун карап көрүңүз.
Көз карандысыздык. Мунун баарын DevOps инженерлеринин жардамысыз өзүңүз жасай аласыз. Жана бул артыкчылык, анткени сиз азыр өзүңүздүн долбооруңузду көзөмөлдөй аласыз, сиз эч кимден суранбайсыз - же жумуш баштоону же өзгөртүүлөрдү киргизүүнү.
Биз эмнени көздөп жатабыз?
Төмөндө саналып өткөндөрдүн баары жөн гана абстрактуу ойлор эмес, жок дегенде биринчи кадамдар жасалган нерсе.
- Аномалия детектору. Биз Graphite сактагычтарыбызга кирип, ар бир метриканы ар кандай алгоритмдерди колдонуп текшере турган кызматты түзгүбүз келет. Биз көргүбүз келген алгоритмдер бар, маалыматтар бар, биз аны менен кантип иштөөнү билебиз.
- Метадайындар. Бизде көптөгөн кызматтар бар, алар менен иштеген адамдар сыяктуу убакыттын өтүшү менен өзгөрүп турат. Документтерди дайыма кол менен жүргүзүү мүмкүн эмес. Ошондуктан биз азыр метадайындарды микросервистерибизге киргизип жатабыз. Анда аны ким иштеп чыкканы, ал тилдер менен иштешет, SLA талаптары, билдирмелер кайда жана кимге жөнөтүлүшү керектиги айтылат. Кызматты жайылтууда объекттин бардык маалыматтары өз алдынча түзүлөт. Натыйжада, сиз эки шилтеме аласыз - бири триггерлерге, экинчиси Grafanaдагы башкаруу такталарына.
- Ар бир үйдө мониторинг. Биз бардык иштеп чыгуучулар ушундай системаны колдонушу керек деп эсептейбиз. Бул учурда сиз ар дайым сиздин трафикиңиз кайда экенин, ага эмне болорун, кайда кулап жатканын, анын алсыз жактары кайда экенин түшүнөсүз. Эгер, мисалы, бир нерсе келип, кызматыңыз бузулса, анда сиз бул тууралуу менеджердин чалуу учурунда эмес, эскертүүдөн билесиз жана сиз дароо акыркы журналдарды ачып, ал жерде эмне болгонун көрө аласыз.
- Жогорку аткаруу. Биздин долбоор тынымсыз өсүп жатат жана бүгүнкү күндө ал мүнөтүнө болжол менен 2 000 000 метрикалык маанини иштетет. Бир жыл мурун бул көрсөткүч 500 000 болгон.Ал эми өсүү уланууда жана бул бир нече убакыт өткөндөн кийин Graphite (шыбыраш) дисктин подсистемасын катуу жүктөй баштайт дегенди билдирет. Мен буга чейин айткандай, бул мониторинг системасы компоненттеринин бири-бирин алмаштырууга байланыштуу абдан универсалдуу болуп саналат. Кимдир бирөө Graphite үчүн атайын инфраструктурасын кармап турат жана дайыма кеңейтет, бирок биз башка жол менен барууну чечтик: колдонуу биздин көрсөткүчтөр үчүн репозиторий катары. Бул өткөөл дээрлик аяктады жана жакында мен сизге бул кандайча жасалганын кененирээк айтып берем: кандай кыйынчылыктар болгон жана алар кантип жеңилген, миграция процесси кандай өткөн, мен милдеттүү түрдө тандалган компоненттерди жана алардын конфигурацияларын сүрөттөп берем.
Конул бурганын учун рахмат! Тема боюнча суроолоруңузду бериңиз, мен бул жерден же кийинки посттордо жооп бергенге аракет кылам. Балким, кимдир бирөө окшош мониторинг системасын куруу же окшош кырдаалда Clickhouse өтүү тажрыйбасы бар - комментарийлер менен бөлүшүү.
Source: www.habr.com