Макаланын котормосу курстун студенттери үчүн атайын даярдалган .
программалык камсыздоону иштеп чыгуучу, Go фанаты жана көйгөйдү чечүүчү. Ал ошондой эле Prometheus тейлөөчүсү жана Kubernetes SIG приборлорунун тең негиздөөчүсү. Мурда ал SoundCloudда өндүрүш инженери болгон жана CoreOSта мониторинг тобун жетектеген. Учурда Google'да иштейт.
- Мүмкүн эмес инфраструктура боюнча инженер. Аны жаңы технологиялар жана бөлүштүрүлгөн системалардын көйгөйлөрү кызыктырат. Анын Intelде төмөн деңгээлдеги программалоо тажрыйбасы, Mesosдо салым кошуу тажрыйбасы жана Improbable компаниясында дүйнөлүк деңгээлдеги SRE өндүрүш тажрыйбасы бар. Микросервис дүйнөсүн жакшыртууга арналган. Анын үч сүйүүсү: Голанг, ачык булак жана волейбол.
Биздин SpatialOS флагмандык продуктубузду карап, сиз Improbable үчүн ондогон Kubernetes кластерлери менен өтө динамикалуу, глобалдык масштабдагы булут инфраструктурасын талап кыла аласыз. Мониторинг системасын биринчилерден болуп колдондук . Prometheus реалдуу убакытта миллиондогон метрикага көз салууга жөндөмдүү жана сизге керектүү маалыматты чыгарууга мүмкүндүк берүүчү күчтүү суроо тили менен келет.
Прометейдин жөнөкөйлүгү жана ишенимдүүлүгү анын негизги артыкчылыктарынын бири болуп саналат. Бирок, белгилүү бир масштабдан өткөндөн кийин, биз бир нече кемчиликтерге туш болдук. Бул көйгөйлөрдү чечүү үчүн биз иштеп чыктык учурдагы Prometheus кластерлерин чексиз тарыхый маалыматтарды сактоо менен бирдиктүү мониторинг системасына айландыруу үчүн Improbable тарабынан түзүлгөн ачык булак долбоору. Thanos Githubда жеткиликтүү .
Thanos менен биздин максаттарыбыз
Белгилүү бир масштабда ваниль Прометейдин мүмкүнчүлүктөрүнө жетпеген көйгөйлөр пайда болот. Тарыхый маалыматтардын петабайттарын кантип ишенимдүү жана үнөмдүү сактоо керек? Муну жооп убактысын бузбай жасоого болобу? Бир API сурамы менен ар кандай Prometheus серверлеринде жайгашкан бардык метрикага кирүү мүмкүнбү? Prometheus HA аркылуу чогултулган репликацияланган маалыматтарды бириктирүүнүн кандайдыр бир жолу барбы?
Бул маселелерди чечүү үчүн биз Thanos түздүк. Кийинки бөлүмдөр бул маселелерге кандай мамиле кылганыбызды жана максаттарыбызды түшүндүрөт.
Бир нече Prometheus инстанцияларынан маалыматтарды суроо (глобалдык суроо)
Prometheus sharding үчүн функционалдык ыкманы сунуш кылат. Атүгүл бир эле Prometheus сервери дээрлик бардык колдонуу учурларында колдонуучуларды горизонталдуу бөлүү татаалдыктарынан бошотуу үчүн жетиштүү масштабдуулукту камсыз кылат.
Бул эң сонун жайгаштыруу модели болсо да, көп учурда бир API же UI аркылуу ар кандай Prometheus серверлериндеги маалыматтарга жетүү керек - глобалдык көрүнүш. Албетте, бир Grafana панелинде бир нече суроону көрсөтүүгө болот, бирок ар бир суроо бир гана Prometheus серверинде аткарылышы мүмкүн. Башка жагынан алганда, Thanos менен сиз бир нече Prometheus серверлеринен маалыматтарды сурап, бириктире аласыз, анткени алардын бардыгы бир акыркы чекиттен жеткиликтүү.
Мурда Мүмкүн эместе глобалдык көрүнүшкө ээ болуу үчүн биз Prometheus инстанцияларыбызды көп деңгээлдүү кылып уюштурганбыз. . Бул ар бир жалбырак серверинен кээ бир көрсөткүчтөрдү чогултуучу бир Prometheus мета серверин түзүүнү билдирген.
Бул ыкма көйгөйлүү болуп чыкты. Мунун натыйжасында татаал конфигурациялар пайда болду, кошумча мүмкүн болуучу бузулуу чекити кошулду жана федеративдүү акыркы чекит өзүнө керектүү маалыматтарды гана кабыл алуусун камсыз кылуу үчүн татаал эрежелерди колдонууга алып келди. Мындан тышкары, федерациянын бул түрү чыныгы глобалдык көрүнүштү алууга мүмкүндүк бербейт, анткени бир эле API сурамынан бардык маалыматтар жеткиликтүү эмес.
Жогорку жеткиликтүүлүк (HA) Prometheus серверлеринде чогултулган маалыматтардын бирдиктүү көрүнүшү ушуну менен тыгыз байланыштуу. Прометейдин HA модели өз алдынча эки жолу маалыматтарды чогултат, бул ушунчалык жөнөкөй, андан жөнөкөй болушу мүмкүн эмес. Бирок, эки агымдын бириккен жана дедупликацияланган көрүнүшүн колдонуу алда канча ыңгайлуу болмок.
Албетте, жеткиликтүү Prometheus серверлерине муктаждык бар. Мүмкүн эмес, биз мүнөт сайын берилиштерге мониторинг жүргүзүүгө чындап эле олуттуу карайбыз, бирок ар бир кластерде бир Prometheus инстанциясы болушу - бул бир эле ката. Ар кандай конфигурация катасы же аппараттык камсыздоонун бузулушу маанилүү маалыматтардын жоголушуна алып келиши мүмкүн. Жөнөкөй жайгаштыруу да метрикаларды чогултууда кичине үзгүлтүккө алып келиши мүмкүн, анткени кайра иштетүү кыргыч аралыгынан кыйла узак болушу мүмкүн.
Тарыхый маалыматтарды ишенимдүү сактоо
Арзан, тез, узак мөөнөттүү көрсөткүчтөрдү сактоо биздин кыялыбыз (Прометейдин көпчүлүк колдонуучулары бөлүшөт). Мүмкүн эмес, биз метрикаларды сактоо мөөнөтүн тогуз күнгө конфигурациялоого аргасыз болдук (Prometheus 1.8 үчүн). Бул биз канчалык артка карай ала турганыбыздын ачык чегин кошот.
Бул жагынан Prometheus 2.0 жакшырды, анткени убакыт серияларынын саны сервердин жалпы иштешине мындан ары таасир этпейт (караңыз. ). Бирок, Prometheus жергиликтүү дискте маалыматтарды сактайт. Маалыматтарды жогорку эффективдүү кысуу жергиликтүү SSD колдонууну бир топ азайтышы мүмкүн болсо да, акырында сактала турган тарыхый маалыматтардын көлөмүнө чек бар.
Кошумчалай кетсек, Improbable компаниясында биз ишенимдүүлүк, жөнөкөйлүк жана баага кам көрөбүз. Чоң локалдык дисктерди иштетүү жана резервдик көчүрүү кыйыныраак. Алар кымбатка турат жана көбүрөөк камдык куралдарды талап кылат, натыйжада ашыкча татаалдык пайда болот.
Үлгүлөрдү төмөндөтүү
Тарыхый маалыматтар менен иштей баштагандан кийин, биз жумалар, айлар жана жылдар менен иштөөдө сурамдарды жайыраак жана жайыраак кылган big-O менен негизги кыйынчылыктар бар экенин түшүндүк.
Бул маселенин стандарттуу чечими болмок (төмөндөтүү) - сигналды тандоо жыштыгын азайтуу. Төмөндөтүү менен биз чоңураак убакыт диапазонуна чейин "кичирейте алабыз" жана сурамдарга жооп берип, үлгүлөрдүн бирдей санын сактай алабыз.
Эски маалыматтардын үлгүсүн төмөндөтүү ар кандай узак мөөнөттүү сактоо чечимдеринин сөзсүз талабы болуп саналат жана ваниль Прометейинин алкагына кирбейт.
Кошумча максаттар
Thanos долбоорунун түпкү максаттарынын бири болгон Prometheus инсталляциялары менен үзгүлтүксүз интеграциялоо. Экинчи максат - кирүү үчүн минималдуу тоскоолдуктар менен иштөөнүн жеңилдиги. Ар кандай көз карандылык кичинекей жана чоң колдонуучулар үчүн оңой канааттандырылышы керек, бул дагы төмөн базалык чыгымды билдирет.
Thanos архитектурасы
Мурунку бөлүмдө максаттарыбызды тизмектегенден кийин, келгиле, аларды карап көрөлү жана Thanos бул көйгөйлөрдү кантип чечерин карап көрөлү.
Глобалдык көрүнүш
Учурдагы Prometheus инстанцияларынын үстүнөн глобалдык көрүнүшкө ээ болуу үчүн, биз бардык серверлерге бир гана суроо-талаптын кирүү пунктун байланыштырышыбыз керек. Thanos компоненти дал ушундай кылат. . Ал ар бир Prometheus серверинин жанында жайгаштырылат жана gRPC Store API аркылуу жергиликтүү Prometheus маалыматтарын тейлеген прокси катары иштейт, убакыт сериясынын маалыматтарын тег жана убакыт диапазону боюнча алууга мүмкүндүк берет.
Башка тарапта масштабдуу, жарандыгы жок Querier компоненти болуп саналат, ал Prometheus HTTP API стандарты аркылуу PromQL сурамдарына жооп берүү менен гана чектелбейт. Querier, Sidecar жана башка Thanos компоненттери аркылуу байланышат .
- Querier, суроо-талапты алгандан кийин, тиешелүү Store API серверине, башкача айтканда, биздин Sidecars менен туташып, тиешелүү Prometheus серверлеринен убакыт серияларынын маалыматтарын алат.
- Андан кийин, ал жоопторду бириктирип, аларга PromQL сурамын аткарат. Querier Prometheus HA серверлеринен бөлүнгөн маалыматтарды да, кайталанма берилиштерди да бириктире алат.
Бул биздин баш катырмабыздын негизги бөлүгүн чечет - обочолонгон Prometheus серверлериндеги маалыматтарды бир көрүнүшкө бириктирүү. Чынында, Thanos бул функция үчүн гана колдонулушу мүмкүн. Учурдагы Prometheus серверлерине эч кандай өзгөртүүлөрдү киргизүүнүн кереги жок!
Чексиз сактоо мөөнөтү!
Бирок, эртеби-кечпи биз маалыматтарды кадимки Prometheus сактоо убактысынан ашык сактагыбыз келет. Тарыхый маалыматтарды сактоо үчүн объект сактагычты тандадык. Ал ар кандай булуттарда, ошондой эле жергиликтүү маалымат борборлорунда кеңири жеткиликтүү жана өтө үнөмдүү. Мындан тышкары, дээрлик бардык объект сактагыч белгилүү S3 API аркылуу жеткиликтүү.
Прометей болжол менен эки саат сайын RAMдан дискке маалыматтарды жазат. Сакталган маалымат блогу белгиленген убакыттын ичинде бардык маалыматтарды камтыйт жана өзгөрүлбөйт. Бул абдан ыңгайлуу, анткени Thanos Sidecar жөн гана Prometheus маалымат каталогун карап, жаңы блоктор жеткиликтүү болгондон кийин, аларды объект сактоочу чакаларга жүктөй алат.
Объекттин сактагычына дискке жазгандан кийин дароо жүктөө, ошондой эле кыргычтын (Prometheus жана Thanos Sidecar) жөнөкөйлүгүн сактоого мүмкүндүк берет. Бул колдоо, наркы жана система дизайнын жөнөкөйлөтөт.
Көрүнүп тургандай, маалыматтардын камдык көчүрмөсү абдан жөнөкөй. Бирок объект сактагычтагы маалыматтарды суроо жөнүндө эмне айтууга болот?
Thanos Store компоненти объект сактагычтан маалыматтарды алуу үчүн прокси катары иштейт. Thanos Sidecar сыяктуу эле, ал ушак кластерине катышып, Store API ишке ашырат. Ушундай жол менен, учурдагы Querier аны Sidecar сыяктуу, убакыттын сериясы маалыматтарынын дагы бир булагы катары карай алат - эч кандай атайын конфигурация талап кылынбайт.
Убакыт сериясынын маалымат блоктору бир нече чоң файлдардан турат. Аларды суроо-талап боюнча жүктөө кыйла натыйжасыз болмок жана аларды локалдуу кэштөө абдан чоң көлөмдөгү эстутум жана диск мейкиндигин талап кылат.
Анын ордуна, Store Gateway Prometheus сактагыч форматын кантип иштетүүнү билет. Акылдуу сурамдарды пландаштыргычтын жана блоктордун керектүү индекс бөлүктөрүн гана кэштөөнүн аркасында татаал суроо-талаптарды объект сактагыч файлдарына HTTP сурамдарынын минималдуу санына чейин кыскартууга болот. Ушундай жол менен, сиз сурамдардын санын төрттөн алтыга чейин кыскарта аласыз жана сурамдардан жергиликтүү SSDдеги маалыматтарга чейин айырмалоо кыйын болгон жооп убакыттарына жетише аласыз.
Жогорудагы диаграммада көрсөтүлгөндөй, Thanos Querier Prometheus сактагыч форматын колдонуу жана тиешелүү маалыматтарды жанаша жайгаштыруу аркылуу объект сактагыч маалыматтарынын бир суроосуна кеткен чыгымды кыйла азайтат. Бул ыкманы колдонуу менен биз көптөгөн жалгыз сурамдарды эң аз сандагы жапырт операцияларга бириктире алабыз.
Тығыздоо жана ылдый үлгүлөрдү алуу
Убакыт сериясынын маалыматтарынын жаңы блогу объекттин сактагычына ийгиликтүү жүктөлгөндөн кийин, биз аны "тарыхый" маалымат катары карайбыз, ал дароо Store Gateway аркылуу жеткиликтүү.
Бирок, бир аз убакыт өткөндөн кийин, бир булактан алынган блоктор (Прометей менен Sidecar) топтолуп, толук индекстөө потенциалын колдонбойт. Бул көйгөйдү чечүү үчүн биз Compactor деп аталган дагы бир компонентти киргиздик. Ал жөн гана Прометейдин локалдык тыгыздоочу кыймылдаткычын объект сактагычтагы тарыхый маалыматтарга колдонот жана жөнөкөй мезгилдүү партиялык жумуш катары иштетилиши мүмкүн.
Натыйжалуу кысуунун аркасында сактагычты узак убакыт бою суроо маалымат көлөмү жагынан көйгөй жаратпайт. Бирок, миллиарддаган баалуулуктарды ачуунун жана аларды суроо процессору аркылуу иштетүүнүн потенциалдуу баасы суроону аткаруу убактысынын кескин көбөйүшүнө алып келет. Башка жагынан алганда, экранда бир пикселде жүздөгөн маалымат чекиттери болгондуктан, ал тургай, маалыматтарды толук чечимде элестетүү мүмкүн эмес болуп калат. Ошентип, ылдый тандоо гана мүмкүн эмес, ошондой эле тактык байкаларлык жоготууга алып келбейт.
Берилиштерди төмөндөтүү үчүн, Compactor маалыматтарды беш мүнөт жана бир сааттык токтомдо тынымсыз топтойт. TSDB XOR кысуу аркылуу коддолгон ар бир чийки кесек үчүн бир блок үчүн мин, максимум же сумма сыяктуу ар кандай типтеги жалпы маалыматтар сакталат. Бул Querierге берилген PromQL сурамына ылайыктуу агрегатты автоматтык түрдө тандоого мүмкүндүк берет.
Колдонуучуга кыскартылган тактыктагы маалыматтарды колдонуу үчүн атайын конфигурация талап кылынбайт. Колдонуучу чоңойтуп жана кичирейткен сайын Querier автоматтык түрдө ар кандай резолюциялар менен чийки дайындардын ортосунда которулат. Кааласа, колдонуучу муну түздөн-түз суроо-талаптагы "кадам" параметри аркылуу көзөмөлдөй алат.
Бир ГБ сактоонун баасы төмөн болгондуктан, демейки боюнча Thanos чийки маалыматтарды, беш мүнөттүк жана бир сааттык чечүүчү маалыматтарды сактайт. Түпнуска маалыматтарды жок кылуунун кереги жок.
Жазуу эрежелери
Thanos менен да, жазуу эрежелери мониторинг стекинин маанилүү бөлүгү болуп саналат. Алар суроонун татаалдыгын, күтүү убактысын жана баасын азайтат. Алар ошондой эле колдонуучуларга метрика боюнча топтолгон маалыматтарды алуу үчүн ыңгайлуу. Thanos ваниль Прометей инстанцияларына негизделген, андыктан учурдагы Prometheus серверинде жазуу эрежелерин жана эскертүү эрежелерин сактоо толугу менен алгылыктуу. Бирок, кээ бир учурларда бул жетишсиз болушу мүмкүн:
- Глобалдык эскертүү жана эреже (мисалы, кызмат үч кластердин экөөнөн ашык иштебей калганда эскертүү).
- Жергиликтүү сактагычтан тышкаркы маалыматтар үчүн эреже.
- Бардык эрежелерди жана эскертүүлөрдү бир жерде сактоо каалоосу.
Бардык ушул учурларда, Thanos Thanos Queries аркылуу эрежени жана эскертүүнү эсептеген Ruler деп аталган өзүнчө компонентти камтыйт. Белгилүү StoreAPI камсыз кылуу менен, Query түйүнү жаңы эсептелген метрикага кире алат. Кийинчерээк алар объект сактагычында сакталат жана Store Gateway аркылуу жеткиликтүү болот.
Таностун күчү
Thanos сиздин муктаждыктарыңызга ылайыкташтырылган ийкемдүү. Бул жөнөкөй Прометейден көчүп барганда өзгөчө пайдалуу. Келгиле, Thanos компоненттери жөнүндө билгендерибизди кыскача мисал менен кайталап көрөлү. Бул жерде ваниль Прометейиңизди "чексиз метрикалык сактоо" дүйнөсүнө кантип алып баруу керек:
- Prometheus серверлериңизге Thanos Sidecar кошуңуз - мисалы, Kubernetes подъездиндеги каптал контейнери.
- Маалыматтарды көрө алуу үчүн бир нече Thanos Querier репликасын орнотуңуз. Бул этапта ал Scraper жана Querier ортосунда ушак орнотуу үчүн жеңил болот. Компоненттердин өз ара аракеттенүүсүн текшерүү үчүн 'thanos_cluster_members' метрикасын колдонуңуз.
Потенциалдуу Prometheus HA репликаларынан глобалдык көрүнүштү жана үзгүлтүксүз берилиштерди өчүрүү үчүн ушул эки кадам жетиштүү! Жөн гана башкаруу такталарыңызды Querier HTTP акыркы чекитине туташтырыңыз же түздөн-түз Thanos UI колдонуңуз.
Бирок, эгер сизге метрикалык көчүрмөнү жана узак мөөнөттүү сактоону талап кылсаңыз, дагы үч кадамды аткарышыңыз керек болот:
- AWS S3 же GCS чакасын түзүңүз. Бул чакаларга маалыматтарды көчүрүү үчүн Sidecarды конфигурациялаңыз. Жергиликтүү маалыматтын сактагычын эми азайтууга болот.
- Store Gatewayди орнотуп, аны учурдагы ушак кластериңизге туташтырыңыз. Эми сиз камдык көчүрмөсүн сурай аласыз!
- Ыкчамдоо жана төмөндөтүүнү колдонуу менен узак убакыт бою суроонун натыйжалуулугун жогорулатуу үчүн Compactor орнотуңуз.
Көбүрөөк билгиңиз келсе, тартынбаңыз и !
Болгону беш кадам менен биз Prometheusти глобалдык көрүнүшү, чексиз сактоо убактысы жана метрикалардын потенциалдуу жогорку жеткиликтүүлүгү бар ишенимдүү мониторинг системасына айлантты.
Сураныч: бизге керексиз!
башынан бери ачык булак долбоору болуп саналат. Prometheus менен үзгүлтүксүз интеграция жана Thanosтун бир бөлүгүн колдонуу мүмкүнчүлүгү аны мониторинг тутумуңузду оңой эле масштабдоо үчүн эң сонун тандоо кылат.
Биз ар дайым GitHub тартуу өтүнүчтөрүн жана көйгөйлөрүн кабыл алабыз. Ошол эле учурда, Github Issues же Slack аркылуу биз менен байланышуудан тартынбаңызсуроолоруңуз же пикириңиз болсо же аны колдонуу тажрыйбаңыз менен бөлүшкүңүз келсе! Эгерде сизге "Improbable" компаниясында жасаган ишибиз жакса, биз менен байланышуудан тартынбаңыз - !
Source: www.habr.com