Пераклад артыкула падрыхтаваны спецыяльна для студэнтаў курса .
- распрацоўшчык праграмнага забеспячэння, фанат Go і аматар вырашаць складаныя задачы. Таксама ён мэйнтэйнер Prometheus і сузаснавальнік Kubernetes SIG instrumentation. У мінулым ён быў production-інжынерам у SoundCloud і ўзначальваў групу маніторынгу ў CoreOS. У цяперашні час працуе ў Google.
- Інфраструктурны інжынер у Improbable. Захапляецца новымі тэхналогіямі і праблемамі размеркаваных сістэм. Мае досвед нізкаўзроўневага праграмавання ў Intel, досвед кантрыб'ютара ў Mesos і production-вопыт SRE сусветнага маштабу ў Improbable. Займаецца паляпшэннем свету мікрасэрвісаў. Тры яго каханні: Golang, open source і валейбол.
Гледзячы на наш флагманскі прадукт SpatialOS, вы можаце здагадацца, што для Improbable патрэбна высокадынамічная хмарная інфраструктура глабальнага маштабу з дзясяткамі кластараў Kubernetes. Мы былі аднымі з першых, хто пачаў выкарыстоўваць сістэму маніторынгу . Prometheus здольны адсочваць мільёны метрык у рэальным часе і пастаўляецца з магутнай мовай запытаў, якія дазваляюць здабываць неабходную інфармацыю.
Прастата і надзейнасць Prometheus з'яўляецца адным з асноўных яго пераваг. Аднак, прайшоўшы пэўны маштаб, мы сутыкнуліся з некалькімі недахопамі. Для вырашэння гэтых праблем мы распрацавалі - Праект з адкрытым зыходным кодам, створаны кампаніяй Improbable, для бясшвоўнай трансфармацыі існуючых кластараў Prometheus ў адзіную сістэму маніторынгу з неабмежаваным сховішчам гістарычных дадзеных. Thanos даступны на Github .
Нашы мэты з Thanos
Пры пэўным маштабе ўзнікаюць праблемы, якія выходзяць за рамкі магчымасцей ванільнага Prometheus. Як надзейна і эканомна захоўваць петабайты гістарычных дадзеных? Ці можна гэта зрабіць без шкоды часу адказу на запыт? Ці можна атрымаць доступ да ўсіх метрыкаў, размешчаных на розных серверах Prometheus, з дапамогай аднаго API-запыту? Ці можна нейкім чынам аб'яднаць рэплікаваныя дадзеныя, сабраныя з дапамогай Prometheus HA?
Для вырашэння гэтых пытанняў мы стварылі Thanos. У наступных раздзелах апісваецца як мы падышлі да вырашэння гэтых пытанняў і тлумачацца мэты, якія мы пераследвалі.
Запыт дадзеных з некалькіх асобнікаў Prometheus (global query)
Prometheus прапануе функцыянальны падыход да шардынгу. Нават адзін Prometheus-сервер забяспечвае дастатковую маштабаванасць, каб вызваліць карыстачоў ад складанасцяў гарызантальнага шардынгу практычна ва ўсіх варыянтах выкарыстання.
Хоць гэта выдатная мадэль разгортвання, але часта патрабуецца атрымаць доступ да дадзеных на розных серверах Prometheus праз адзіны API ці UI – global view. Вядома, ёсць магчымасць адлюстраваць некалькі запытаў у адной панэлі Grafana, але кожны запыт можа быць выкананы толькі на адзін сервер Prometheus. З іншага боку, з дапамогай Thanos вы можаце запытваць і агрэгаваць дадзеныя з некалькіх сервераў Prometheus, паколькі ўсе яны даступныя з адной канчатковай кропкі.
Раней, для атрымання global view у Improbable, мы арганізавалі нашы экзэмпляры Prometheus ў шматузроўневую . Гэта азначала стварэнне аднаго мета-сервера Prometheus, які збірае частку метрык з кожнага "ліставога" сервера.
Гэты падыход аказаўся праблематычным. Ён прывёў да ўскладнення канфігурацыі, дадання дадатковай патэнцыйнай кропкі адмовы і прымянення складаных правілаў для прадастаўлення federated-канчатковай кропцы толькі патрэбных дадзеных. Акрамя таго, federation такога роду не дазваляе атрымаць сапраўднае global view, бо не ўсе дадзеныя даступныя з аднаго API-запыту.
З гэтым цесна злучана адзінае ўяўленне дадзеных, сабраных на высокадаступных (high-availability, HA) серверах Prometheus. HA-мадэль Prometheus незалежна збірае дадзеныя двойчы, што настолькі проста, што прасцей быць не можа. Аднак выкарыстоўваць аб'яднанае і дэдуплікаванае ўяўленне абодвух патокаў было б нашмат зручней.
Вядома, у высокадаступных серверах Prometheus існуе неабходнасць. У Improbable мы сапраўды сур'ёзна ставімся да штохвіліннага маніторынгу дадзеных, але наяўнасць аднаго асобніка Prometheus на кластар з'яўляецца адзінай кропкай адмовы. Любая памылка канфігурацыі ці збой абсталявання могуць патэнцыйна прывесці да страты важных дадзеных. Нават простае разгортванне можа прывесці да невялікіх збояў у зборы метрык, паколькі перазапуск можа быць значна даўжэй інтэрвалу скрапінгу.
Надзейнае захоўванне гістарычных дадзеных
Таннае, хуткае і доўгатэрміновае сховішча метрык – гэта наша мара (падзяляемая большасцю карыстальнікаў Prometheus). У Improbable мы былі змушаныя наладзіць тэрмін захоўвання метрык на дзевяць дзён (для Prometheus 1.8). Гэта дадае відавочныя абмежаванні на тое, як далёка мы можам паглядзець назад.
Prometheus 2.0 у гэтым стаўленні стаў лепш, бо колькасць time series больш не ўплывае на агульную прадукцыйнасць сервера. ). Тым не менш Prometheus захоўвае дадзеныя на лакальным дыску. Хоць высокаэфектыўны сціск дадзеных можа значна скараціць выкарыстанне лакальнага SSD, але ў канчатковым рахунку ўсё роўна існуе абмежаванне на аб'ём захоўваемых гістарычных дадзеных.
Акрамя таго, у Improbable мы клапоцімся аб надзейнасці, прастаце і кошту. Вялікія лакальныя дыскі складаней у эксплуатацыі і рэзервовым капіяванні. Яны каштуюць даражэй і патрабуюць больш прылад для рэзервовага капіявання, што прыводзіць да залішняй складанасці.
Даўнсэмплінг
Як толькі мы пачалі працаваць з гістарычнымі дадзенымі, мы зразумелі, што існуюць фундаментальныя складанасці з O-вялікім, якія робяць запыты ўсё павольней і павольней, калі мы працуем з дадзенымі за тыдні, месяцы і гады.
Стандартным вырашэннем гэтай праблемы будзе (downsampling) - памяншэнне частаты дыскрэтызацыі сігналу. З дапамогай паніжэння дыскрэтызацыі мы можам "паменшыць маштаб" да большага часавага дыяпазону і падтрымліваць ранейшую колькасць выбарак, што дазволіць захаваць спагадлівасць запытаў.
Даўнсэмплінг старых дадзеных з'яўляецца непазбежным патрабаваннем любога рашэння для доўгатэрміновага захоўвання і выходзіць за рамкі ванільнага Prometheus.
Дадатковыя мэты
Адной з першапачатковых мэт праекту Thanos была бясшвоўная інтэграцыя з любымі існымі ўсталёўкамі Prometheus. Другая мэта складалася ў простай эксплуатацыі з мінімальным уваходным бар'ерам. Любыя залежнасці павінны быць лёгка задаволены як для невялікіх, так і для буйных карыстальнікаў, што таксама мае на ўвазе нязначны базавы кошт.
Архітэктура Thanos
Пасля таго як у папярэднім раздзеле былі пералічаны нашы мэты, давайце папрацуем над імі і паглядзім, як Thanos вырашае гэтыя праблемы.
Global view
Каб атрымаць global view-над існуючых асобнікаў Prometheus, нам трэба звязаць адзіную кропку ўваходу запытаў з усімі серверамі. Менавіта гэтым і займаецца кампанент Thanos . Ён разгортваецца побач з кожным серверам Prometheus і працуе як проксі, абслугоўваючы лакальныя дадзеныя Prometheus праз gRPC-інтэрфейс Store API, які дазваляе выбіраць time series дадзеныя па пазнаках і часаваму дыяпазону.
З іншага боку знаходзіцца гарызантальна які маштабуецца кампанент Querier без захавання стану, які робіць ледзь больш, чым проста адказвае на запыты PromQL праз стандартны Prometheus HTTP API. Кампаненты Querier, Sidecar і іншыя Thanos ўзаемадзейнічаюць па .
- Querier пры атрыманні запыту падлучаецца да які адпавядае сервера Store API, гэта значыць да нашых Sidecar'ам і атрымлівае time series дадзеныя з адпаведных Prometheus-сервераў.
- Пасля гэтага ён аб'ядноўвае адказы і выконвае па іх PromQL-запыт. Querier можа аб'ядноўваць як неперасякальныя дадзеныя, так і дубляваныя дадзеныя з HA-сервераў Prometheus.
Гэта вырашае асноўную частку нашай галаваломкі - аб'яднанне дадзеных з ізаляваных сервераў Prometheus у адзінае ўяўленне. Фактычна Thanos можна выкарыстоўваць толькі дзеля гэтай магчымасці. У існуючыя сервера Prometheus не патрабуецца ўносіць якія-небудзь змены!
Неабмежаваны тэрмін захоўвання!
Аднак рана ці позна мы захочам захаваць дадзеныя, якія выходзяць за межы звычайнага часу захоўвання Prometheus. Для захоўвання гістарычных дадзеных мы абралі аб'ектнае сховішча. Яно шырока даступна ў любым воблаку, а таксама ў лакальных ЦАД і вельмі эканамічна. Акрамя таго, практычна любое аб'ектнае сховішча даступна праз добра вядомы S3 API.
Prometheus запісвае дадзеныя з аператыўнай памяці на дыск прыкладна кожныя дзве гадзіны. Блок захоўваемых дадзеных утрымоўвае ўсе дадзеныя для фіксаванага прамежку часу і з'яўляецца нязменным. Гэта вельмі зручна, бо Thanos Sidecar можа проста глядзець каталог дадзеных Prometheus і, па меры з'яўлення новых блокаў, загружаць іх у бакеты аб'ектнага сховішча.
Загрузка ў аб'ектнае сховішча адразу пасля запісу на дыск дазваляе таксама захаваць прастату "скрапера" (Prometheus і Thanos Sidecar). Што спрашчае падтрымку, кошт і дызайн сістэмы.
Як бачыце, рэзервовае капіраванне дадзеных рэалізуецца вельмі проста. Але што наконт запыту да дадзеных у аб'ектным сховішчы?
Кампанент Thanos Store дзейнічае як проксі для атрымання даных з аб'ектнага сховішча. Як і Thanos Sidecar, ён удзельнічае ў gossip-кластары і рэалізуе Store API. Такім чынам, якія існуюць Querier могуць разглядаць яго як Sidecar, у якасці яшчэ адной крыніцы time series дадзеных – ніякай спецыяльнай налады не патрабуецца.
Блокі time series даных складаюцца з некалькіх вялікіх файлаў. Загрузка іх па патрабаванні была б даволі неэфектыўнай, а лакальнае кэшаванне запатрабавала велізарнай памяці і дыскавай прасторы.
Замест гэтага Store Gateway ведае, як абыходзіцца з фарматам захоўвання Prometheus. Дзякуючы разумнаму планавальніку запытаў і кэшаванню толькі неабходных індэксных частак блокаў, стала магчымым скараціць складаныя запыты да мінімальнай колькасці HTTP-запытаў да файлаў аб'ектнага сховішча. Такім чынам, можна скараціць колькасць запытаў на чатыры-шэсць парадкаў і дасягнуць часу водгуку, якое ў цэлым цяжка адрозніць ад запытаў да дадзеных на лакальным SSD.
Як паказана на дыяграме вышэй, Thanos Querier значна зніжае выдаткі на адзін запыт да дадзеных у аб'ектным сховішчы, выкарыстоўваючы фармат захоўвання Prometheus і размяшчаючы звязаныя дадзеныя побач. Выкарыстоўваючы гэты падыход, мы можам аб'яднаць мноства адзіночных запытаў у мінімальную колькасць bulk-аперацый.
Ушчыльненне і даунсэмплінг
Пасля таго як новы блок time series дадзеных паспяхова загружаны ў аб'ектнае сховішча, мы разглядаем яго як "гістарычныя" дадзеныя, якія адразу ж становяцца даступнымі праз Store Gateway.
Аднак праз некаторы час блокі з адной крыніцы (Prometheus з Sidecar) назапашваюцца і ўжо не выкарыстоўваюць увесь патэнцыял індэксацыі. Для рашэння гэтай праблемы мы ўвялі яшчэ адзін кампанент пад назовам Compactor. Ён проста прымяняе лакальны механізм ушчыльнення Prometheus да гістарычных дадзеных у аб'ектным сховішчы і можа быць запушчаны як простае перыядычнае пакетнае заданне.
Дзякуючы эфектыўнаму сціску, запыт у сховішча за працяглы прамежак часу не ўяўляе праблем з пункту гледжання памеру даных. Аднак патэнцыйны кошт распакавання мільярда значэнняў і прагон іх праз апрацоўшчык запытаў непазбежна прывядзе да рэзкага павелічэння часу выканання запыту. З іншага боку, паколькі на кожны піксель экрана прыпадаюць сотні кропак дадзеных, становіцца немагчымым нават візуалізаваць дадзеныя ў поўным дазволе. Такім чынам, даунсэмплінг не толькі магчымы, але і не прывядзе да прыкметнай страты дакладнасці.
Для даунсемплінга дадзеных Compactor бесперапынна агрэгуе дадзеныя з дазволам у пяць хвілін і адну гадзіну. Для кожнага неапрацаванага фрагмента, закадаванага з дапамогай TSDB XOR-сціскі, захоўваюцца розныя тыпы агрэгаваных дадзеных, такія, як min, max ці sum для аднаго блока. Гэта дазваляе Querier аўтаматычна выбіраць агрэгат, які падыходзіць для дадзенага PromQL-запыту.
Для выкарыстання дадзеных з паніжанай дакладнасцю карыстачу не патрабуецца ніякай спецыяльнай канфігурацыі. Querier аўтаматычна перамыкаецца паміж рознымі дазволамі і неапрацаванымі дадзенымі па меры павелічэння і памяншэнні маштабу карыстачом. Пры жаданні карыстач можа кіраваць гэтым напроста праз параметр "step" у запыце.
Так як кошт захоўвання аднаго ГБ з'яўляецца невялікі, то па змаўчанні Thanos захоўвае зыходныя дадзеныя, дадзеныя з дазволам у пяць хвілін і ў адну гадзіну. Няма неабходнасці выдаляць зыходныя дадзеныя.
Recording rules
Нават з Thanos recording rules з'яўляюцца істотнай часткай стэка маніторынгу. Яны змяншаюць складанасць, затрымку і кошт запытаў. Яны таксама зручныя карыстальнікам для атрымання агрэгаваных дадзеных па метрыках. Thanos грунтуецца на ванільных асобніках Prometheus, таму суцэль дапушчальна захоўваць recording rules і alerting rules на існым серверы Prometheus. Аднак у некаторых выпадках гэтага можа быць нядосыць:
- Глабальныя alert і rule (напрыклад, апавяшчэнне, калі сэрвіс не працуе на больш за двух з трох кластараў).
- Rule для дадзеных па-за лакальным сховішчам.
- Імкненне захоўваць усе rule і alert у адным месцы.
Для ўсіх гэтых выпадкаў Thanos уключае ў сябе асобны кампанент, званы Ruler, які вылічае rule і alert праз Thanos Queries. Падаючы добра вядомы StoreAPI, вузел Query можа атрымаць доступ да свежых вылічаных метрыкаў. Пазней яны таксама захоўваюцца ў аб'ектным сховішчы і становяцца даступнымі праз Store Gateway.
Моц Thanos
Thanos дастаткова гнуткі, каб яго можна было наладзіць пад вашыя патрабаванні. Гэта асабліва карысна пры міграцыі з простага Prometheus. Давайце на невялікім прыкладзе хутка ўспомнім, што мы даведаліся аб кампанентах Thanos. Вось як перанесці ваш ванільны Prometheus у свет "безлімітнага захоўвання метрык":
- Дадайце Thanos Sidecar да вашых сервераў Prometheus - напрыклад, суседні кантэйнер у Kubernetes pod.
- Разгарніце некалькі рэплік Thanos Querier для магчымасці прагляду дадзеных. На дадзеным этапе лёгка наладзіць gossip паміж Scraper і Querier. Для праверкі ўзаемадзеяння кампанент выкарыстоўвайце метрыку 'thanos_cluster_members'.
Толькі гэтых двух крокаў дастаткова, каб забяспечыць global view і бясшвоўную дэдуплікацыю дадзеных ад патэнцыйных HA-рэплік Prometheus! Проста падключыце свае дашборды да канчатковай кропкі HTTP Querier або выкарыстоўвайце інтэрфейс Thanos UI напрамую.
Аднак калі вам патрабуецца рэзервовае капіраванне метрык і доўгатэрміновае захоўванне, то спатрэбіцца выканаць яшчэ тры крокі:
- Стварыце бакет AWS S3 ці GCS. Наладзьце Sidecar для капіявання дадзеных у гэтыя бакеты. Цяпер можна звесці да мінімуму лакальнае захоўванне дадзеных.
- Разгарніце Store Gateway і падлучыце яго да існага gossip-кластару. Цяпер можна адпраўляць запыты да дадзеных у рэзервовых копіях!
- Разгарніце Compactor, каб павысіць эфектыўнасць запытаў для працяглых прамежкаў часу, выкарыстоўваючы ўшчыльненне і даунсэмплінг.
Калі вы хочаце даведацца больш, не саромейцеся, паглядзіце на нашы и !
Усяго за пяць крокаў мы ператварылі Prometheus у надзейную сістэму маніторынгу з global view, неабмежаваным часам захоўвання і патэнцыйнай высокай даступнасці метрык.
Pull request: вы патрэбны нам!
з самага пачатку быў праектам з адчыненым зыходным кодам. Бясшвовая інтэграцыя з Prometheus і магчымасць выкарыстоўваць толькі частка Thanos робіць яго выдатным выбарам для маштабавання сістэмы маніторынгу без лішніх намаганняў.
Мы заўсёды рады GitHub Pull Request і Issues. У той жа час не саромейцеся звяртацца да нас праз Github Issues ці slack, калі ў вас ёсць пытанні ці водгукі, ці вы хочаце падзяліцца сваім вопытам выкарыстання! Калі вам падабаецца тое, што мы робім у Improbable, не саромейцеся звяртацца да нас !
Крыніца: habr.com