VictoriaMetrics - хуткая і якая маштабуецца СКБД для захоўвання і апрацоўкі дадзеных у форме часавага шэрагу (запіс утворыць час і набор адпаведных гэтаму часу значэнняў, напрыклад, атрыманых праз перыядычнае апытанне стану датчыкаў або збор метрык).
Мяне клічуць Калабаеў Павел. DevOps, SRE, LeroyMerlin, усё як код - гэта ўсё пра нас: пра мяне і пра іншых супрацоўнікаў LeroyMerlin.
Ёсць воблака на базе OpenStack. Там невялікая спасылка на тэхарадар.
Пабудавана яно на базе жалеза Kubernetes, а таксама на ўсіх спадарожных сэрвісах да OpenStack і лагіраванні.
Схема вось такая ў нас была на распрацоўцы. Калі мы ўсё гэта распрацоўвалі ў нас быў аператар Prometheus, які захоўваў дадзеныя ўсярэдзіне самога кластара K8s. Ён аўтаматычна знаходзіць тое, што трэба адскрабіць і складае сабе пад ногі, груба кажучы.
Усе дадзеныя нам трэба будзе вынесці за межы кластара Kubernetes, бо калі нешта здарыцца, то мы павінны разумець, што і дзе.
Першае рашэнне - мы выкарыстоўваем federation, калі ў нас ёсць іншы Prometheus, калі мы ходзім у кластар Kubernetes праз механізм federation.
Але тут атрымліваюцца невялікія праблемы. У нашым выпадку праблемы пачаліся, калі ў нас было 250 метрык, а калі стала 000 метрык, зразумелі, што так працаваць не можам. Мы павялічылі scrape_timeout да 400 секунд.
Чаму нам гэта прыйшлося зрабіць? Prometheus пачынае адлічваць час тайм-аўту з пачатку моманту плота. І не важна, што дадзеныя ўсё яшчэ льюцца. Калі за гэты ўказаны прамежак часу дадзеныя не зліліся і сесія не будзе зачынена па http, то лічыцца, што сесія правальная і дадзеныя не трапляюць у сам Prometheus.
Усім знаёмыя графікі, якія мы атрымліваем, калі частка звестак адсутнічаюць. Графікі ірваныя і нас гэта не задавальняе.
Наступны варыянт - гэта шардаванне на аснове двух розных Prometheus праз той жа механізм federation.
Напрыклад, проста ўзяць і па імені іх адшардаваць. Гэта можна таксама выкарыстоўваць, але мы вырашылі рухацца далей.
Нам давядзецца цяпер гэтыя шарды неяк апрацоўваць. Можна ўзяць promxy, які сыходзіць у вобласць шарда, зультыплікуе дадзеныя. Ён працуе з двума шардамі як з адзінай кропкай уваходу. Такое можна рэалізаваць праз promxy, але занадта пакуль складана.
Першы варыянт - мы жадаем адмовіцца ад механізму federation, таму што ён вельмі павольны.
Распрацоўнікі Prometheus відавочна кажуць: «Хлопцы, выкарыстоўвайце іншыя TimescaleDB, таму што мы не будзем падтрымліваць доўгае захоўванне метрык». Гэта не іх задача.
Мы сабе на паперку запісваем, што нам усё ж такі патрабуецца выгрузка вонкі, каб не захоўваць усё ў адным месцы.
Другі недахоп - гэта спажыванне памяці. Так, я разумею, што многія скажуць, што ў 2020-ым годзе пару гігабайт памяці - гэта каштуе капейкі, але тым не менш.
Цяпер у нас ёсць dev і prod-асяроддзе. У dev гэта каля 9 гігабайтаў на 350 000 метрык. У prod гэта 14 гігабайтаў з невялікім на 780 000 метрык. Пры гэтым retention time у нас усяго 30 хвілін. Гэта дрэнна. І зараз растлумачу чаму.
Мы робім разлік, т. е. пры паўтара мільёнах метрык, а мы ўжо блізкія да іх, на этапе яшчэ праектавання мы атрымліваем 35-37 гігабайт памяці. Але ўжо да 4 мільёнаў метрык патрабуецца ўжо каля 90 гігабайтаў памяці. Т. е. гэта было разлічана па той формуле, якую падаюць распрацоўшчыкі Prometheus. Мы паглядзелі карэляцыю і зразумелі, што мы не жадаем плаціць пару мільёнаў за сервер проста пад маніторынг.
У нас не проста павялічыцца колькасць машын, мы яшчэ маніторым і самі віртуальныя машыны. Таму чым больш віртуальных машын, тым больш метрык рознага роду і г. д. У нас будзе спецыяльны рост нашага кластара ў плане метрык.
З дыскавай прасторай тут не ўсё так сумна, але хацелася б палепшыць. Мы атрымалі за 15 дзён сумарна 120 гігабайтаў, з якіх 100 - гэта сціснутыя дадзеныя, 20 - гэта не сціснутыя дадзеныя, але заўсёды хочацца менш.
Адпаведна, мы запісваем яшчэ адзін пункт - гэта вялікае спажыванне рэсурсаў, якія хочацца ўсё ж эканоміць, таму што мы не хочам, каб наш кластар маніторынгу з'еў рэсурсаў больш, чым наш кластар, які займаецца кіраваннем OpenStack.
Ёсць яшчэ адзін недахоп у Prometheus, які мы сабе выявілі, гэта хоць нейкае абмежаванне па памяці. З Prometheus тут усё значна горш, таму што ў яго наогул такіх круцілак няма. Выкарыстоўваць абмежаванне ў докеры таксама не варыянт. Калі раптам у вас RAF упаў і там 20-30 гігабайтаў, то паднімацца ён будзе вельмі доўга.
Гэта яшчэ адна прычына, чаму нам не падыходзіць Prometheus, т. е. нельга абмежаваць спажыванне памяці.
Можна было б выйсці на такую схему. Гэтая схема нам патрэбна для таго, каб арганізаваць HA кластар. Мы жадаем, каб нашы метрыкі былі даступныя заўсёды і ўсюды, нават пры падзенні сервера, які захоўвае гэтыя метрыкі. І тым самым нам давядзецца вось такую схему пабудаваць.
Гэтая схема кажа, што ў нас будзе дубляванне шардаў, а, адпаведна, і дубліраванне выдаткаў спажываных рэсурсаў. Яе можна амаль гарызантальна маштабаваць, але тым не менш спажыванне рэсурсаў будзе пякельнае.
Недахопы па парадку ў тым выглядзе, у якім мы для сябе іх выпісалі:
- Патрабуецца выгрузка метрык вонкі.
- Вялікае спажыванне рэсурсаў.
- Нельга абмежаваць спажыванне памяці.
- Складаная і рэсурсаёмістая рэалізацыя HA.
Для сябе мы вырашылі, што мы адыходзім ад Prometheus як ад сховішча.
Мы для сябе вызначылі яшчэ дадатковыя патрабаванні, якія нам патрэбны. Гэта:
- Гэта падтрымка promql, таму што ўжо шмат усяго напісана пад Prometheus: запыты, алерты.
- І далей у нас ёсць Grafana, якая ўжо сапраўды гэтак жа напісана пад Prometheus як бэкэнд. Не хочацца перапісваць дашборды.
- Мы хочам пабудаваць нармальную HA архітэктуру.
- Мы хочам зменшыць спажыванне любых рэсурсаў.
- Ёсць яшчэ невялікі нюанс. Мы не можам выкарыстоўваць рознага роду cloud сістэмы збору метрык. Мы не ведаем, што ў нас паляціць у гэтыя метрыкі пакуль. І бо туды можа паляцець усё, што заўгодна, нам даводзіцца абмяжоўвацца лакальным размяшчэннем.
Выбар быў невялікі. Мы сабралі ўсё, па чым у нас быў досвед. Паглядзелі на старонку Prometheus у раздзеле integration, прачыталі кучу артыкулаў, паглядзелі, што ўвогуле ёсць. І для сябе мы абралі VictoriaMetrics у якасці замены Prometheus.
Чаму? Таму што:
- Умее promql.
- Ёсць модульная архітэктура.
- Не патрабуе змен у Grafana.
- І самае галоўнае - мы, магчыма, будзем падаваць сховішча метрык усярэдзіне сваёй кампаніі як сэрвіс, таму мы загадзя глядзім у бок абмежавання рознага роду, каб карыстачы маглі ў нейкім абмежаваным выглядзе выкарыстаць усе рэсурсы кластара, таму што ёсць шанец, што ён будзе multitenancy.
Які робіцца першае параўнанне. Мы бярэм той жа самы Prometheus ўнутры кластара, да яго ходзіць знешні Prometheus. Дадаем праз remoteWrite VictoriaMetrics.
Адразу абмоўлюся, што вось тут мы злавілі невялікае павелічэнне па спажыванні CPU са боку VictoriaMetrics. На VictoriaMetrics wiki напісана, якія параметры лепш падыходзяць. Мы іх праверылі. Яны вельмі добрае паменшылі спажыванне менавіта па CPU.
У нашым выпадку спажыванне памяці Prometheus, які знаходзіцца ў кластары Kubernetes, узрасла не значна.
Параўноўваем два data source адных і тых жа дадзеных. У Prometheus мы бачым усё тыя ж адсутнічаюць дадзеныя. У VictoriaMetrics усё добра.
Вынікі тэстаў з дыскавай прасторай. Мы ў Prometheus атрымалі 120 гігабайтаў сумарна. У VictoriaMetrics мы атрымліваем ужо 4 гігабайта ў дзень. Там крыху іншы механізм, чым чым прывыклі бачыць у Prometheus. Т. е. дадзеныя ўжо дастаткова добра ціснуцца за дзень, за паўгадзіны. Яны ўжо добра паціснутыя за дзень, за паўгадзіны, нягледзячы на тое, што яшчэ потым будзе мержыць дадзеныя. У выніку мы зэканомілі на дыскавай прасторы.
Яшчэ мы эканомім на спажыванні рэсурсаў памяці. У нас Prometheus быў на момант тэстаў разгорнуты на віртуальнай машыне - 8 ядраў, 24 гігабайта. Prometheus ад'ядае практычна ўсё. Ён упаў па OOM Killer. Пры гэтым у яго лілося ўсяго 900 актыўных метрык. Гэта каля 000 25-000 27 метрык у секунду.
VictoriaMetrics у нас была запушчана на двух'ядравай віртуальнай машыне з 8 гігабайтамі RAM. Нам удалося прымусіць VictoriaMetrics добра працаваць, пакруціўшы некаторыя рэчы на 8-гігабайтнай машыне. У выніку мы ўклаліся ў 7 гігабайт. Пры гэтым атрымалі хуткасць аддачы кантэнту, т. е. метрык, нават вышэй, чым у Prometheus.
У CPU стала значна лепш адносна Prometheus. Тут Prometheus спажывае 2,5 ядра, а VictoriaMetrics за ўсё - 0,25 ядра. На старце - 0,5 ядра. Па меры мержа яна даходзіць да аднаго ядра, але гэта вельмі-вельмі рэдка.
У нашым выпадку выбар упаў на VictoriaMetrics па зразумелых прычынах, мы хацелі зэканоміць і зэканомілі.
Выкрэсліваем з ходу два пункты - гэта выгрузка метрык і вялікае спажыванне рэсурсаў. І нам застаецца вырашыць два пункты, якія мы для сябе яшчэ пакінулі.
Тут я абмоўлюся адразу, мы VictoriaMetrics разглядаем як сховішча метрык. Але так як мы будзем падаваць, хутчэй за ўсё, VictoriaMetrics як сховішча для ўсяго Leroy, нам трэба тых, хто будзе выкарыстоўваць гэты кластар, абмежаваць, каб яны нам яго не паклалі.
Ёсць выдатны параметр, які дазваляе абмяжоўваць па часе, па аб'ёме дадзеных і па часе выканання.
А таксама ёсць выдатная опцыя, якая дазваляе абмяжоўваць спажыванне памяці, тым самым мы можам знайсці той самы баланс, які дазволіць нам атрымаць звычайную хуткасць працы і адэкватнае спажыванне рэсурсаў.
Мінус яшчэ адзін пункт, т. е. закрэсліваем пункт - нельга абмежаваць спажыванне памяці.
У першых ітэрацыях мы тэставалі VictoriaMetrics Single Node. Далей мы пераходзім да VictoriaMetrics Cluster Version.
Тут у нас развязваюцца рукі на прадмет разнясення розных сэрвісаў у VictoriaMetrics у залежнасці ад таго, на чым яны будуць круціцца і якія рэсурсы спажываць. Гэтае вельмі гнуткае і зручнае рашэнне. Мы на сабе гэта выкарыстоўвалі.
Асноўныя кампаненты VictoriaMetrics Cluster Version - гэта vmstsorage. Іх можа быць N колькасць. У нашым выпадку пакуль іх 2.
І есць vminsert. Гэта проксі-сервер, які дазваляе нам: задаволіць шардаванне паміж усімі storages, пра якія мы яму распавялі, і ён дазваляе яшчэ рэпліку, т. е. у вас будзе і шардаванне, і рэпліка.
Vminsert падтрымлівае пратаколы OpenTSDB, Graphite, InfluxDB і remoteWrite ад Prometheus.
Ёсць яшчэ vmselect. Яго асноўная задача - гэта схадзіць у vmstorage, атрымаць ад іх дадзеныя, дэдуплікаваць гэтыя дадзеныя і аддаць кліенту.
Ёсць выдатная штука як vmagent. Нам вельмі падабаецца яна. Яна дазваляе канфігураваць сапраўды гэтак жа як Prometheus і пры гэтым рабіць усё сапраўды гэтак жа як Prometheus. Т. е. ён збірае з розных сутнасцяў, сэрвісаў метрыкі і адпраўляе іх у vminsert. Далей усё ўжо залежыць ад вас.
Яшчэ адзін выдатны сэрвіс - гэта vmalert, які дазваляе ў якасці бэкенда выкарыстоўваць VictoriaMetrics, атрымліваць ад vminsert і адпраўляць у vmselect апрацаваныя дадзеныя. Апрацоўвае ен самі алерты, а таксама rules. У выпадку алертаў мы атрымліваем алерт праз alertmanager.
Ёсць кампанент wmauth. Ён у нас будзе, магчыма, выкарыстоўвацца, а, магчыма, і не (мы яшчэ не вызначыся з гэтым) у якасці сістэмы аўтарызацыі пры multitenancy версіі кластараў. Ён падтрымлівае remoteWrite для Prometheus і можа аўтарызаваць на аснове url, а дакладней другой яго часткі, куды вам можна ці нельга пісаць.
Ёсць яшчэ vmbackup, vmrestore. Гэта, у сутнасці, аднаўленне і бэкап усіх дадзеных. Умее S3, GCS, file.
Першая ітэрацыя нашага кластара была зроблена падчас каранціну. На той момант не было рэплікі, таму наша ітэрацыя ўяўляла сабой два розныя і незалежныя кластары, у якія праз remoteWrite мы атрымлівалі дадзеныя.
Тут абмоўлюся, што, калі мы пераходзілі з VictoriaMetrics Single Node на VictoriaMetrics Cluster Version, мы ўсё гэтак жа засталіся ў тых жа спажываных рэсурсах, т. е. асноўная гэта памяць. Прыкладна такім чынам размеркаваліся нашы даныя, г. зн. спажыванне рэсурсаў.
Тут ужо была дададзена рэпліка. Мы аб'ядналі ўсё гэта ў адзін адносна вялікі кластар. Усе дадзеныя ў нас як шаруюцца, так і рэпліцыруюцца.
Ва ўсяго кластара ёсць N кропак уваходу, т. е. Prometheus можа дадаваць дадзеныя праз HAPROXY. Вось у нас гэты пункт уваходу. І праз гэты пункт уваходу можна заходзіць з Grafana.
У нашым выпадку HAPROXY - гэта адзіны порт, які праксіруе select, insert і астатнія сэрвісы ўнутр гэтага кластара. У нашым выпадку нельга было зрабіць адзін адрас, нам прыйшлося зрабіць некалькі кропак уваходу, таму што самі віртуалкі, на якіх круціцца VictoriaMetrics-кластар, знаходзяцца ў нас у розных зонах аднаго хмарнага правайдэра, т. е. не ўсярэдзіне нашага аблокі, а звонку.
У нас ёсць алертынг. Мы яго выкарыстоўваем. Мы выкарыстоўваем alertmanager ад Prometheus. Мы ў якасці канала дастаўкі алертаў выкарыстоўваем Opsgenie і Telegram. У Telegram сыплюцца ад dev, можа быць, нешта ад prod, але больш нешта такое статыстычнае, патрэбнае інжынерам. А Opsgenie - critical. Гэта званкі, кіраванне інцыдэнтамі.
Адвечнае пытанне: "Хто ж маніторыць маніторынг?". У нашым выпадку маніторынг маніторыць сам маніторынг, таму што мы выкарыстоўваем vmagent на кожнай нодзе. А паколькі нашыя ноды разнесеныя па розных дата-цэнтрах аднаго правайдэра, у кожнага дата-цэнтра ў нас свой канал, яны незалежныя і нават калі прыйдзе split brain, то мы ўсё роўна атрымаеце алерты. Так, іх будзе больш, але лепш атрымаць больш алертаў, чым ніводнага.
Мы заканчваем наш спіс з рэалізацыяй HA.
І далей жадаў бы адзначыць досвед зносін з кам'юніці VictoriaMetrics. Яно атрымалася вельмі пазітыўнае. Рабяты спагадныя. Яны спрабуюць углыбіцца ў кожны кейс, які прапануецца.
Я заводзіў issues на GitHub. Яны вельмі хутка былі вырашаны. Ёсць яшчэ парачка issues, якія не да канца зачыненыя, але я ўжо па кодзе бачу, што праца ў гэтым кірунку ідзе.
Асноўны боль падчас ітэрацый для мяне быў у тым, што калі высячу ноду, то першыя 30 секунд у мяне vminsert не мог зразумець, што бэкенда няма. Цяпер гэта ўжо вырашана. І літаральна за секунду ці дзве дадзеныя залазяць ужо з усіх пакінутых нод, і запыт перастае чакаць тую адсутную ноду.
Мы хацелі ў нейкі момант ад VictoriaMetrics, каб гэта быў VictoriaMetrics operator. Мы яго дачакаліся. Мы зараз у актыўным пабудове абвязкі над VictoriaMetrics operator, каб узяць усе pre-calculating rules і г. д. Prometheus, таму што мы дастаткова актыўна выкарыстоўваем rules, якія ідуць разам з аператарам Prometheus.
Ёсць прапановы па паляпшэнні кластарнай рэалізацыі. Я іх выклаў вышэй.
І яшчэ вельмі жадаецца downsampling. У нашым выпадку downsampling патрэбен выключна для праглядаў трэндаў. Грубіянска кажучы, мне адной метрыкі на працягу дня хопіць. Гэтыя трэнды патрэбны на год, на тры, на пяць, на дзесяць гадоў. І аднаго значэння метрыкі дастаткова.
- Мы спазналі боль, як і некаторыя нашы калегі, пры выкарыстанні Prometheus.
- Мы выбралі для сябе VictoriaMetrics.
- Яна дастаткова добра маштабуецца як вертыкальна, так і гарызантальна.
- Мы можам разносіць розныя кампаненты на розную колькасць вузлоў у кластары, лімітаваць іх па аб'ёме памяці, накідваць памяць і т. д.
Мы будзем у сябе выкарыстоўваць VictoriaMetrics, таму што яна нам вельмі спадабалася. Вось што было і што стала.
Пара qr-кодаў на чат VictoriaMetrics, мае кантакты, тэхрадар LeroyMerlin.
Крыніца: habr.com