VictoriaMetrics - бул убакыт сериясы түрүндө маалыматтарды сактоо жана иштетүү үчүн тез жана масштабдалуучу СББ (жазуу убакытты жана ушул убакытка туура келген маанилердин топтомун түзөт, мисалы, сенсорлордун абалын мезгил-мезгили менен сурамжылоо аркылуу алынган. же көрсөткүчтөрдү чогултуу).
Менин атым Павел Колобаев. DevOps, SRE, LeroyMerlin, баары код сыяктуу - бул биз жөнүндө: мен жана башка LeroyMerlin кызматкерлери жөнүндө.
OpenStack негизинде булут бар. Техникалык радарга кичинекей шилтеме бар.
Ал Kubernetes темиринин негизинде, ошондой эле OpenStack жана логингге тиешелүү бардык кызматтарда курулган.
Бул биз иштеп чыгууда болгон схема. Мунун баарын иштеп чыкканда, бизде Prometheus оператору болгон, ал K8s кластеринин ичинде маалыматтарды сактаган. Ал автоматтык түрдө тазалануу керек нерсени таап, одоно айтканда бутунун астына коёт.
Биз бардык маалыматтарды Kubernetes кластеринин сыртына жылдырышыбыз керек, анткени бир нерсе болуп кетсе, анда эмнени жана кайда экенин түшүнүшүбүз керек.
Биринчи чечим - биз федерация механизми аркылуу Kubernetes кластерине барганда үчүнчү тарап Prometheus болгондо федерацияны колдонобуз.
Бирок бул жерде анча-мынча көйгөйлөр бар. Биздин учурда, көйгөйлөр бизде 250 метрика болгондо башталган жана 000 метрика болгондо, биз мындай иштей албасыбызды түшүндүк. Биз scrape_timeout 400 секундага чейин көбөйттүк.
Эмне үчүн биз муну кылышыбыз керек эле? Прометей тайм-аутту кабыл алуу учурунун башталышынан баштап санай баштайт. Маалыматтар дагы эле агылып жатканы маанилүү эмес. Эгерде бул көрсөтүлгөн убакыттын ичинде маалыматтар бириктирилбесе жана сессия http аркылуу жабылбаса, анда сессия ишке ашпай калды деп эсептелет жана маалыматтар Прометейдин өзүнө кирбейт.
Дайындардын бир бөлүгү жок болгондо биз алган графиктерди баары билет. Графика жыртылып калган, биз ага ыраазы эмеспиз.
Кийинки вариант бир эле федерация механизми аркылуу эки башка Prometheus негизинде sharding болуп саналат.
Мисалы, жөн гана алып, аларды аты менен бөлүңүз. Муну да колдонсо болот, бирок биз улантууну чечтик.
Эми бул сыныктарды кандайдыр бир жол менен иштетүүгө туура келет. Сиз promxy ала аласыз, ал сынык аймагына түшүп, маалыматтарды көбөйтөт. Ал бир кирүү чекити катары эки сынык менен иштейт. Бул promxy аркылуу ишке ашырылышы мүмкүн, бирок ал азыр өтө татаал.
Биринчи вариант - биз федерация механизминен баш тарткыбыз келет, анткени ал өтө жай.
Prometheus иштеп чыгуучулары ачык айтышат: "Балдар, башка TimescaleDB колдонуңуз, анткени биз метрикалардын узак мөөнөттүү сакталышын колдобойбуз." Бул алардын милдети эмес.
Баарын бир жерге топтоп албаш үчүн дагы эле сыртка түшүрүш керек экенин кагазга жазабыз.
Экинчи кемчилик - эстутум керектөө. Ооба, мен түшүнөм, көптөр 2020-жылы бир нече гигабайт эстутум бир тыйынга арзыйт деп айтышат, бирок ошентсе да.
Азыр бизде иштеп чыгуучу жана продюсердик чөйрө бар. Иштеп чыгууда бул 9 350 метрикага 000 гигабайтты түзөт. Продукцияда бул 14 гигабайт жана кичинекей 780 000 метрика. Ошол эле учурда бизде 30 мүнөт гана убакыт бар. Бул жаман. Эми мунун себебин түшүндүрөм.
Биз эсептеп чыгабыз, башкача айтканда, бир жарым миллион метрика менен жана биз аларга жакындап калдык, долбоорлоо баскычында биз 35-37 гигабайт эстутумду алабыз. Бирок буга чейин эле 4 миллион метрикага, болжол менен 90 гигабайт эстутум талап кылынат. Башкача айтканда, Prometheus иштеп чыгуучулар тарабынан берилген формула боюнча эсептелген. Биз корреляцияны карап көрдүк жана жөн гана мониторинг үчүн серверге бир нече миллион төлөгүбүз келбейт.
Биз машиналардын санын гана көбөйтпөстөн, виртуалдык машиналарды да көзөмөлдөйбүз. Ошондуктан, виртуалдык машиналар канчалык көп болсо, ошончолук ар кандай типтеги метрикалар жана башкалар. Биздин кластерибиз метрика жагынан өзгөчө өсүшкө ээ болот.
Диск мейкиндиги менен, бул жерде баары кайгылуу эмес, бирок мен аны өркүндөткүм келет. Биз 15 күндүн ичинде жалпысынан 120 гигабайт алдык, анын 100ү кысылган маалымат, 20сы кысылбаган маалымат, бирок сиз дайыма азыраак каалайсыз.
Демек, биз дагы бир пунктту жазабыз - бул биз дагы эле үнөмдөлгөн ресурстардын чоң керектөөсү, анткени биз мониторинг кластерибиздин OpenStackти башкарган кластерибизге караганда көбүрөөк ресурстарды жешин каалабайбыз.
Прометейдин дагы бир кемчилиги бар, аны биз өзүбүз аныктадык, бул жок дегенде кандайдыр бир эс тутумдун чектөөсү. Прометей менен бул жерде баары алда канча начар, анткени анын мындай бурмалоолор такыр жок. Докердин чегин колдонуу да вариант эмес. Эгер күтүлбөгөн жерден RAF түшүп кетсе жана 20-30 гигабайт болсо, анда анын көтөрүлүшү үчүн абдан көп убакыт талап кылынат.
Бул Прометейдин бизге ылайыктуу эместигинин дагы бир себеби, б.а. биз эстутумду колдонууну чектей албайбыз.
Мындай схеманы ойлоп табууга болот эле. HA кластерин уюштуруу үчүн бизге бул схема керек. Биздин көрсөткүчтөр каалаган убакта, каалаган жерде жеткиликтүү болушун каалайбыз, атүгүл бул көрсөткүчтөрдү сактаган сервер бузулуп калса да. Ошентип, биз ушундай схеманы түзүшүбүз керек.
Бул схема бизде сыныктардын кайталанышын, демек, керектелүүчү ресурстардын чыгымдарынын кайталанышын айтат. Бул дээрлик горизонталдуу масштабда болушу мүмкүн, бирок ошого карабастан, ресурстарды керектөө тозок болот.
Кемчиликтер, аларды биз өзүбүз үчүн жазган формада:
- Көрсөткүчтөрдү сыртка жүктөп берүүнү талап кылат.
- Ресурстарды жогорку керектөө.
- Сиз эстутум керектөөсүн чектей албайсыз.
- Татаал жана ресурстарды көп талап кылуучу ХА ишке ашыруу.
Өзүбүз үчүн биз Прометейден репозиторий катары кетип жатабыз деп чечтик.
Биз өзүбүзгө керектүү кошумча талаптарды аныктадык. Бул:
- Бул promql колдоосу, анткени Prometheus үчүн көп нерсе жазылган: сурамдар, эскертүүлөр.
- Анан бизде Grafana бар, ал буга чейин эле Прометейдин астында backend катары жазылган. Мен башкаруу такталарын кайра жазгым келбейт.
- Биз кадимки HA архитектурасын кургубуз келет.
- Биз ар кандай ресурстарды керектөөнү азайткыбыз келет.
- Дагы бир кичинекей нюанс бар. Биз метрикаларды чогултуу үчүн ар кандай булут системаларын колдоно албайбыз. Азырынча бул көрсөткүчтөргө эмне кирерин билбейбиз. Ал жерде бардык нерсе уча алгандыктан, биз өзүбүздү жергиликтүү жайгаштыруу менен чектешибиз керек.
Тандоо аз болду. Биз тажрыйба топтогон нерселердин баарын чогулттук. Биз интеграция бөлүмүндөгү Prometheus барагын карадык, бир топ макалаларды окудук, жалпысынан эмне бар экенин карап чыктык. Ал эми өзүбүз үчүн, биз Prometheus ордуна VictoriaMetrics тандап алган.
Неге? Себеби:
- promql кыла алат.
- Модулдук архитектура бар.
- Grafana эч кандай өзгөртүүлөрдү талап кылбайт.
- Эң негизгиси, биз, балким, биздин компаниянын ичинде метрикалык сактагычты кызмат катары камсыз кылабыз, ошондуктан колдонуучулар кластердин бардык ресурстарын кандайдыр бир чектелген түрдө пайдалана алышы үчүн, биз алдын ала ар кандай чектөөлөрдү карап жатабыз, анткени мүмкүнчүлүк бар. ал көп ижаралык болот.
Биз биринчи салыштырууну жасайбыз. Ошол эле Прометейди кластердин ичине алабыз, сырткы Прометей ага барат. Биз remoteWrite VictoriaMetrics аркылуу кошобуз.
Мен дароо эскертип коём, бул жерде VictoriaMetricsден CPU керектөө бир аз көбөйдү. VictoriaMetrics викиде кайсы параметрлер эң ылайыктуу экени айтылат. Биз аларды текшердик. Алар CPU керектөөсүн абдан жакшы азайтты.
Биздин учурда, Kubernetes кластеринде жайгашкан Prometheus эстутум керектөө олуттуу өскөн жок.
Бир эле маалыматтардын эки маалымат булагын салыштырабыз. Прометейде биз бирдей жетишпеген маалыматтарды көрөбүз. VictoriaMetricsте баары жакшы.
Диск мейкиндиги менен тесттердин натыйжалары. Прометейде бизде жалпысынан 120 гигабайт бар. VictoriaMetricsте биз күнүнө 4 гигабайт алып жатабыз. Сиз Прометейде көргөнгө караганда бир аз башкача механизм бар. Башкача айтканда, маалыматтар бир күн, жарым саат бою жакшы кысылган. Алар кийинчерээк маалыматтар бириге турганына карабастан, бир күндө, жарым саатта жакшы оруп алышты. Натыйжада, биз дисктеги мейкиндикти үнөмдөп алдык.
Биз эстутум ресурстарын керектөөдөн да үнөмдөйбүз. Сыноолор учурунда бизде Prometheus виртуалдык машинага орнотулган - 8 ядро, 24 гигабайт. Прометей дээрлик бардыгын жейт. Ал OOM Killerin үстүнө жыгылды. Ошол эле учурда ага болгону 900 000 активдүү метрика куюлган. Бул секундасына 25 000-27 000 метрге жакын.
VictoriaMetrics 8 гигабайт оперативдик эс тутуму бар эки ядролуу виртуалдык машинада иштеген. Биз VictoriaMetrics 8 ГБ машинада кээ бир нерселерди оңдоп, жакшы иштешине жетише алдык. Натыйжада биз 7 гигабайттын чегинде сакталып калдык. Ошол эле учурда, биз мазмунду жеткирүү ылдамдыгын, башкача айтканда, метрикага Prometheus караганда да жогору алдык.
CPU Prometheus караганда алда канча жакшыраак. Бул жерде Prometheus 2,5 өзөктү, ал эми VictoriaMetrics болгону 0,25 ядрону керектейт. Башында - 0,5 өзөк. Ал биригип, бир өзөккө жетет, бирок бул өтө сейрек кездешет.
Биздин учурда, тандоо ачык себептерден улам VictoriaMetricsке түштү, биз акчаны үнөмдөп, сактап калгыбыз келди.
Биз дароо эле эки пунктту чийип салабыз - бул метрикаларды түшүрүү жана ресурстарды көп керектөө. Ал эми биз өзүбүзгө калтырган эки пунктту чечишибиз керек.
Бул жерде мен дароо ээлеп коём, биз VictoriaMetricsти метрика репозиторийси катары карайбыз. Бирок биз VictoriaMetricsти бардык Лерой үчүн сактагыч катары бере тургандыктан, биз бул кластерди колдоно тургандарды чектешибиз керек, алар аны бизге койбошу керек.
Убакыт, маалыматтардын көлөмү жана аткаруу убактысы боюнча чектөөгө мүмкүндүк берген сонун параметр бар.
Жана ошондой эле эстутум керектөөсүн чектөөгө мүмкүндүк берген сонун вариант бар, ошондуктан биз нормалдуу ылдамдыкты жана адекваттуу ресурс керектөөнү алууга мүмкүндүк берген балансты таба алабыз.
Минус дагы бир пункт, башкача айтканда, биз чекитти чийип салабыз - эстутум керектөөсүн чектей албайсыз.
Биринчи итерацияларда биз VictoriaMetrics Single Node'ду сынап көрдүк. Андан кийин VictoriaMetrics кластердик версиясына өтөбүз.
Бул жерде биз VictoriaMetricsте ар кандай кызматтарды бөлүү темасында эркин колубуз бар, алар эмнеге жана кандай ресурстарды керектей турганына жараша. Бул абдан ийкемдүү жана ыңгайлуу чечим болуп саналат. Өзүбүз колдондук.
VictoriaMetrics Cluster Version негизги компоненттери vmstsorage болуп саналат. N саны болушу мүмкүн. Биздин учурда алардын 2си бар.
Жана vminsert бар. Бул прокси сервер, ал бизге төмөнкүлөргө мүмкүндүк берет: биз ага айткан бардык сактагычтардын ортосунда бөлүштүрүүнү уюштуруу жана ал башка репликага мүмкүндүк берет, б.а. сизде бөлүү да, реплика да болот.
Vminsert Prometheusдан OpenTSDB, Graphite, InfluxDB жана remoteWrite протоколдорун колдойт.
vmselect да бар. Анын негизги милдети - vmstorage'ге өтүү, алардан маалыматтарды алуу, бул маалыматтарды дедупировкалоо жана кардарга берүү.
vmagent сыяктуу сонун нерсе бар. Биз аны абдан жакшы көрөбүз. Бул сизге Прометейдей конфигурациялоого жана дагы эле Прометейге окшоп баарын жасоого мүмкүндүк берет. Башкача айтканда, ал ар кандай субъекттерден жана кызматтардан метрикаларды чогултуп, аларды vminsertке жөнөтөт. Анда баары сенден көз каранды.
Дагы бир сонун кызмат - vmalert, ал сизге VictoriaMetrics'ти бэкенд катары колдонууга, vminsertтен иштетилген маалыматтарды алууга жана иштетилген маалыматтарды vmselect'ке жөнөтүүгө мүмкүндүк берет. Ал эскертүүлөрдүн өздөрүн, ошондой эле эрежелерди иштетет. Эскертүүлөр болгон учурда, биз alertmanager аркылуу эскертүү алабыз.
wmauth компоненти бар. Биз аны, балким, кластерлердин көп ижаралык версиялары үчүн авторизациялоо системасы катары колдонбойбуз (биз азырынча чече элекпиз). Бул Prometheus үчүн remoteWrite колдойт жана url негизинде авторизациялай алат, тагыраак айтканда, анын экинчи бөлүгү, сиз жаза турган же жаза албайсыз.
Ошондой эле vmbackup, vmrestore бар. Бул, чынында, калыбына келтирүү жана бардык маалыматтардын камдык көчүрмөсү. S3, GCS, файлды колдоно алат.
Биздин кластердин биринчи итерациясы карантин учурунда жасалган. Ал убакта эч кандай реплика болгон эмес, ошондуктан биздин итерация эки башка жана көз карандысыз кластерден турган, аларга биз remoteWrite аркылуу маалыматтарды алганбыз.
Бул жерде мен VictoriaMetrics Single Node'ден VictoriaMetrics Cluster Version'ка өткөндө дагы эле ошол эле керектелген ресурстарда калганбыз, б.а. негизгиси - эс тутум. Болжол менен ушундай жол менен биздин маалыматтар бөлүштүрүлгөн, б.а. ресурстарды керектөө.
Бул жерде реплика мурунтан эле кошулган. Мунун баарын биз салыштырмалуу чоң кластерге бириктирдик. Бардык маалыматтар бөлүштүрүлөт жана кайталанат.
Бүткүл кластерде N кирүү чекити бар, башкача айтканда, Prometheus HAPROXY аркылуу маалыматтарды кошо алат. Бул жерде биздин кирүү пункту болуп саналат. Жана бул кирүү чекити аркылуу сиз Grafana менен кире аласыз.
Биздин учурда, HAPROXY бул кластерге прокси тандап, киргизген жана башка кызматтарды көрсөткөн жалгыз порт. Биздин учурда, бир даректи жасоо мүмкүн эмес болчу, биз бир нече кирүү пункттарын түзүшүбүз керек болчу, анткени VictoriaMetrics кластери иштеп жаткан виртуалдык машиналар бир эле булут провайдеринин ар кандай зонасында жайгашкан, б.а. биздин булуттун ичинде эмес. , бирок сыртта.
Бизде эскертүү бар. Биз аны колдонобуз. Прометейден alertmanager колдонобуз. Биз Opsgenie жана Telegramды эскертүүлөрдү жеткирүү каналы катары колдонобуз. Телеграмда алар иштеп чыгуучулардан, балким өндүрүштөн бир нерсе, бирок инженерлерге керек болгон статистикалык нерсеге окшош. Ал эми Опсгени сынчыл. Бул чалуулар, инциденттерди башкаруу.
Байыркы суроо: "Мониторингди ким көзөмөлдөйт?". Биздин учурда, мониторинг мониторингдин өзүн көзөмөлдөйт, анткени биз ар бир түйүндө vmagent колдонобуз. Ал эми биздин түйүндөр бир провайдердин ар кандай маалымат борборлорунда жайгашкандыктан, ар бир маалымат борборунун өзүнүн каналы бар, алар көз карандысыз жана бөлүнгөн мээ келсе дагы, биз эскертүүлөрдү алабыз. Ооба, алар көбүрөөк болот, бирок эч кимге караганда көбүрөөк эскертүү алган жакшы.
Биз тизмебизди HA ишке ашыруу менен аяктайбыз.
Анан дагы VictoriaMetrics коомчулугу менен баарлашуу тажрыйбасын белгилегим келет. Бул абдан позитивдүү болуп чыкты. Жигиттер жооп беришет. Алар сунуш кылынган ар бир ишти териштирүүгө аракет кылышат.
Мен GitHubда көйгөйлөрдү жараттым. Алар абдан тез чечилди. Толугу менен жабыла элек дагы бир-эки маселе бар, бирок бул багытта иш жүрүп жатканын кодекстен көрүп турам.
Мен үчүн итерациялар учурунда негизги оору, мен түйүн кесип болсо, анда биринчи 30 секунд vminsert эч кандай backend бар экенин түшүнө алган жок. Эми буга чейин эле чечилген. Ал эми түзмө-түз бир же эки секунданын ичинде, маалыматтар бардык калган түйүндөрдөн алынат жана сурам ошол жетишпеген түйүндү күтүүнү токтотот.
Биз VictoriaMetrics компаниясынан VictoriaMetrics оператору болууну каалаганбыз. Биз аны күттүк. Биз азыр VictoriaMetrics операторунун үстүнөн бардык алдын ала эсептөө эрежелерин ж.б. алуу үчүн активдүү куруп жатабыз. Прометей, анткени биз Prometheus оператору менен келген эрежелерди активдүү колдонуп жатабыз.
Кластерди ишке ашырууну жакшыртуу боюнча сунуштар бар. Мен аларды жогоруда белгилеп өттүм.
Ошондой эле мен чындап эле төмөндөтүүнү каалайм. Биздин учурда, ылдый тандоо тенденцияларды көрүү үчүн гана керек. Болжол менен айтканда, бир метрика мага күндүз жетиштүү. Бул тенденциялар бир жылга, үч, беш, он жылга керек. Жана бир метрикалык маани жетиштүү.
- Кээ бир кесиптештерибиз сыяктуу эле, биз Прометейди колдонууда ооруну билебиз.
- Биз өзүбүз үчүн VictoriaMetrics тандадык.
- Ал тигинен да, туурасынан да жакшы масштабдалат.
- Биз кластердеги башка сандагы түйүндөргө ар кандай компоненттерди тарата алабыз, аларды эс тутум жагынан чектей алабыз, эстутумду кошо алабыз ж.б.
VictoriaMetricsти үйдө колдонобуз, анткени ал бизге абдан жакты. Бул жерде эмне болду жана эмне болду.
VictoriaMetrics чаты үчүн бир нече qr коддору, менин байланыштарым, LeroyMerlin техникалык радары.
Source: www.habr.com