Өгүүллийн орчуулгыг тус курсын оюутнуудад зориулж тусгайлан бэлтгэсэн .
програм хангамж хөгжүүлэгч, Go фанат, асуудал шийдэгч юм. Тэрээр мөн Prometheus-ийн засварчин, Kubernetes SIG багаж хэрэгслийн үүсгэн байгуулагч юм. Өмнө нь тэрээр SoundCloud-д үйлдвэрлэлийн инженер байсан бөгөөд CoreOS-ийн хяналтын багийг удирдаж байсан. Одоогоор Google-д ажилладаг.
- Improbable-д дэд бүтцийн инженер. Тэрээр шинэ технологи, тархсан системийн асуудлуудыг сонирхож байна. Тэрээр Intel-д бага түвшний програмчлалын туршлагатай, Mesos-д хувь нэмэр оруулсан туршлагатай, Improbable-д дэлхийн хэмжээний SRE үйлдвэрлэлийн туршлагатай. Микро үйлчилгээний ертөнцийг сайжруулахад зориулагдсан. Түүний гурван дуртай зүйл: Голанг, нээлттэй эх сурвалж, волейбол.
Манай шилдэг бүтээгдэхүүн болох SpatialOS-ийг харахад "Их магадлалтай" нь олон арван Kubernetes кластер бүхий дэлхийн хэмжээний үүлэн дэд бүтэцтэй, өндөр динамик шаарддаг гэдгийг тааварлаж болно. Бид хамгийн түрүүнд хяналтын системийг ашигласан . Prometheus нь олон сая хэмжигдэхүүнийг бодит цаг хугацаанд хянах чадвартай бөгөөд танд хэрэгтэй мэдээллийг задлах боломжийг олгодог хүчирхэг хайлтын хэлээр ирдэг.
Prometheus-ийн энгийн бөгөөд найдвартай байдал нь түүний гол давуу талуудын нэг юм. Гэсэн хэдий ч бид тодорхой хэмжүүрийг давж гарахад хэд хэдэн сул талуудтай тулгарсан. Эдгээр асуудлыг шийдэхийн тулд бид боловсруулсан нь одоо байгаа Prometheus кластеруудыг хязгааргүй түүхэн өгөгдөл хадгалах нэг хяналтын систем болгон хувиргах боломж олгох нээлттэй эхийн төсөл юм. Thanos нь Github дээр байдаг .
Thanos-тай хийсэн бидний зорилго
Тодорхой хэмжээгээр ванилийн Прометейгийн чадвараас давсан асуудлууд гарч ирдэг. Петабайт түүхийн өгөгдлийг хэрхэн найдвартай, хэмнэлттэй хадгалах вэ? Үүнийг хариу өгөх хугацааг алдагдуулахгүйгээр хийж болох уу? Нэг API хүсэлтээр өөр өөр Prometheus сервер дээр байрлах бүх хэмжигдэхүүнд хандах боломжтой юу? Prometheus HA ашиглан цуглуулсан хуулбарласан өгөгдлийг нэгтгэх арга бий юу?
Эдгээр асуудлыг шийдвэрлэхийн тулд бид Thanos-ийг бүтээсэн. Дараах хэсгүүдэд бид эдгээр асуудалд хэрхэн хандсан, зорилгоо тайлбарлах болно.
Prometheus-ийн олон тохиолдлоос өгөгдөл асуух (дэлхийн асуулга)
Prometheus нь sharding хийх функциональ хандлагыг санал болгодог. Нэг Prometheus сервер ч гэсэн бараг бүх ашиглалтын тохиолдлуудад хэрэглэгчдийг хэвтээ хуваалтын нарийн төвөгтэй байдлаас чөлөөлөх хангалттай хэмжээний өргөтгөл хийх боломжийг олгодог.
Хэдийгээр энэ нь маш сайн байршуулалтын загвар боловч ихэвчлэн нэг API эсвэл UI-ээр дамжуулан өөр өөр Prometheus серверүүд дээрх өгөгдөлд хандах шаардлагатай байдаг - дэлхийн харагдах байдал. Мэдээжийн хэрэг, нэг Grafana самбар дээр олон асуулга харуулах боломжтой боловч асуулга бүрийг зөвхөн нэг Prometheus сервер дээр гүйцэтгэх боломжтой. Нөгөөтэйгүүр, Thanos-ийн тусламжтайгаар та Prometheus-ийн олон серверээс мэдээлэл авах, нэгтгэх боломжтой, учир нь тэдгээр нь бүгд нэг цэгээс хандах боломжтой.
Өмнө нь бид Боломжгүй программыг дэлхий даяар харахын тулд Prometheus instances-ээ олон түвшний байдлаар зохион байгуулсан. . Энэ нь навч сервер бүрээс зарим хэмжигдэхүүнийг цуглуулдаг нэг Prometheus мета сервер үүсгэсэн гэсэн үг юм.
Энэ арга нь асуудалтай байсан. Энэ нь илүү төвөгтэй тохиргоог бий болгож, эвдрэлийн нэмэлт цэгийг нэмж, нэгдсэн төгсгөлийн цэг нь зөвхөн шаардлагатай өгөгдлийг хүлээн авахын тулд нарийн төвөгтэй дүрмийг хэрэгжүүлэхэд хүргэсэн. Нэмж дурдахад, ийм төрлийн холбоо нь бүх өгөгдлийг нэг API хүсэлтээс авах боломжгүй тул дэлхийн жинхэнэ дүр төрхийг олж авах боломжийг олгодоггүй.
Үүнтэй нягт холбоотой нь өндөр хүртээмжтэй (HA) Prometheus серверүүд дээр цуглуулсан мэдээллийн нэгдсэн дүр төрх юм. Prometheus-ийн HA загвар нь өгөгдлийг хоёр удаа бие даан цуглуулдаг бөгөөд энэ нь маш энгийн тул илүү хялбар байж болохгүй. Гэсэн хэдий ч, хоёр урсгалын хосолсон болон давхардсан харагдах байдлыг ашиглах нь илүү тохиромжтой байх болно.
Мэдээжийн хэрэг, өндөр боломжтой Prometheus серверүүд хэрэгтэй. Improbable-д бид минут тутамд өгөгдөл хянахад үнэхээр нухацтай ханддаг ч кластер бүрт нэг Prometheus instance байх нь алдаа дутагдалтай байдаг. Аливаа тохиргооны алдаа эсвэл техник хангамжийн доголдол нь чухал өгөгдлийг алдахад хүргэж болзошгүй. Энгийн байршуулалт ч гэсэн хэмжигдэхүүнийг цуглуулахад бага зэргийн саатал үүсгэж болзошгүй тул дахин эхлүүлэх нь хусах интервалаас хамаагүй урт байж болно.
Түүхийн мэдээллийг найдвартай хадгалах
Хямд, хурдан, урт хугацааны хэмжүүр хадгалах нь бидний мөрөөдөл юм (ихэнх Prometheus хэрэглэгчид хуваалцдаг). Improbable-д бид хэмжигдэхүүнийг хадгалах хугацааг есөн хоног болгон тохируулахаас өөр аргагүй болсон (Prometheus 1.8-ийн хувьд). Энэ нь бид хэр хол эргэж харах боломжтой болох тодорхой хязгаарыг нэмж өгдөг.
Прометей 2.0 нь энэ талаар сайжирсан, учир нь цагийн цувааны тоо нь серверийн ерөнхий гүйцэтгэлд нөлөөлөхөө больсон (харна уу. ). Гэсэн хэдий ч Prometheus нь өгөгдлийг дотоод диск дээр хадгалдаг. Хэдийгээр өндөр үр ашигтай өгөгдөл шахах нь орон нутгийн SSD-ийн хэрэглээг мэдэгдэхүйц бууруулж болох ч эцсийн дүндээ хадгалагдах түүхэн өгөгдлийн хэмжээ хязгаарлагдмал хэвээр байна.
Нэмж дурдахад Improbable-д бид найдвартай байдал, энгийн байдал, өртөг зардалд санаа тавьдаг. Орон нутгийн том дискийг ажиллуулах, нөөцлөхөд илүү төвөгтэй байдаг. Тэд илүү үнэтэй бөгөөд илүү их нөөц хэрэгсэл шаарддаг тул шаардлагагүй төвөгтэй байдлыг бий болгодог.
Доорх түүвэрлэлт
Түүхэн өгөгдөлтэй ажиллаж эхэлмэгц бид долоо хоног, сар, жилийн өгөгдөлтэй ажиллахад асуулгыг удаашруулж, удаашруулдаг big-O-д үндсэн хүндрэлүүд байдгийг ойлгосон.
Энэ асуудлыг шийдэх стандарт шийдэл байх болно (доод түүвэрлэлт) - дохионы дээж авах давтамжийг багасгах. Дээжийг бууруулснаар бид илүү том хугацааны хүрээнд "багасгаж" мөн ижил тооны дээжийг хадгалж, асуулгад хариу үйлдэл үзүүлэх боломжтой.
Хуучин өгөгдлийг багасгах нь аливаа урт хугацааны хадгалалтын шийдлийн зайлшгүй шаардлага бөгөөд ванилийн Prometheus-ийн хамрах хүрээнээс гадуур юм.
Нэмэлт зорилго
Thanos төслийн анхны зорилгын нэг нь одоо байгаа Prometheus суулгацуудтай саадгүй нэгтгэх явдал байв. Хоёрдахь зорилго нь нэвтрэхэд хамгийн бага саад бэрхшээлгүйгээр үйл ажиллагааны хялбар байдал байв. Аливаа хамаарал нь жижиг, том хэрэглэгчдийн аль алинд нь хялбархан хангагдсан байх ёстой бөгөөд энэ нь суурь зардал багатай гэсэн үг юм.
Thanos архитектур
Өмнөх хэсэгт зорилгуудаа жагсаасны дараа тэдгээрийг судалж, Thanos эдгээр асуудлыг хэрхэн шийдэж байгааг харцгаая.
Дэлхий нийтийн үзэл бодол
Одоо байгаа Prometheus instances дээр дэлхийг харахын тулд бид бүх серверүүдтэй нэг хүсэлт оруулах цэгийг холбох хэрэгтэй. Энэ бол Thanos бүрэлдэхүүн хэсэг яг ийм зүйл юм. . Энэ нь Prometheus сервер бүрийн хажууд байрладаг бөгөөд gRPC Store API-ээр дамжуулан локал Prometheus өгөгдөлд үйлчилж, цаг хугацааны цувралын өгөгдлийг шошго болон хугацааны мужаар олж авах боломжийг олгодог прокси үүрэг гүйцэтгэдэг.
Нөгөө талд нь стандарт Prometheus HTTP API-ээр дамжуулан PromQL асуулгад хариулахаас өөр зүйл хийдэггүй, өргөтгөсөн, харьяалалгүй Querier бүрэлдэхүүн хэсэг юм. 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 хүсэлтийг хамгийн бага тоо болгон нарийн төвөгтэй асуулгад багасгах боломжтой. Ийм байдлаар та хүсэлтийн тоог 4-6 дарааллаар багасгаж, локал SSD дээрх өгөгдөл хүртэлх хүсэлтээс ялгахад хэцүү хариу өгөх хугацааг олж авах боломжтой.
Дээрх диаграммд харуулсны дагуу Thanos Querier нь Prometheus хадгалах форматыг ашиглаж, холбогдох өгөгдлийг зэрэгцүүлэн байрлуулах замаар объект хадгалах өгөгдлийн асуулгад ногдох зардлыг эрс багасгадаг. Энэ аргыг ашигласнаар бид олон дан хүсэлтийг нэгтгэж, хамгийн бага тооны бөөнөөр ажиллах боломжтой.
Нягтруулах ба түүвэрлэх
Цагийн цувралын шинэ блок объектын санд амжилттай ачаалагдсаны дараа бид үүнийг "түүхэн" өгөгдөл гэж үздэг бөгөөд үүнийг Дэлгүүрийн гарцаар дамжуулан шууд авах боломжтой.
Гэсэн хэдий ч хэсэг хугацааны дараа нэг эх сурвалжаас (Prometheus with Sidecar) блокууд хуримтлагдаж, индексжүүлэлтийг бүрэн ашиглахаа больсон. Энэ асуудлыг шийдэхийн тулд бид Compactor хэмээх өөр нэг бүрэлдэхүүн хэсгийг нэвтрүүлсэн. Энэ нь зүгээр л Prometheus-ийн орон нутгийн нягтруулах хөдөлгүүрийг объектын хадгалалтын түүхэн өгөгдөлд ашигладаг бөгөөд энгийн үечилсэн багц ажил болгон ажиллуулж болно.
Үр дүнтэй шахалтын ачаар хадгалах санг удаан хугацаанд асуух нь өгөгдлийн хэмжээтэй холбоотой асуудал үүсгэдэггүй. Гэсэн хэдий ч тэрбум утгыг задлах, асуулгын процессороор дамжуулан ажиллуулах зардал нь асуулгын гүйцэтгэлийн хугацааг эрс нэмэгдүүлэхэд хүргэдэг. Нөгөө талаас, дэлгэцэн дээр нэг пикселд хэдэн зуун өгөгдлийн цэг байдаг тул өгөгдлийг бүрэн нарийвчлалтайгаар дүрслэх боломжгүй болдог. Тиймээс доош түүвэрлэх нь зөвхөн боломжтой төдийгүй нарийвчлалын мэдэгдэхүйц алдагдалд хүргэхгүй.
Өгөгдлийг багасгахын тулд Compactor нь өгөгдлийг таван минут, нэг цагийн нарийвчлалтайгаар тасралтгүй нэгтгэдэг. TSDB XOR шахалтыг ашиглан кодлогдсон түүхий хэсэг бүрийн хувьд нэг блокийн хамгийн бага, хамгийн их эсвэл нийлбэр гэх мэт өөр өөр төрлийн нэгтгэсэн өгөгдлийг хадгалдаг. Энэ нь Querier-д өгөгдсөн PromQL асуулгад тохирох агрегатыг автоматаар сонгох боломжийг олгодог.
Хэрэглэгч бага нарийвчлалтай өгөгдлийг ашиглахын тулд тусгай тохиргоо хийх шаардлагагүй. Querier нь хэрэглэгчийг томруулж, жижигрүүлэх үед өөр өөр нягтрал болон түүхий өгөгдөл хооронд автоматаар шилжинэ. Хэрэв хүсвэл хэрэглэгч хүсэлтийн "алхам" параметрээр дамжуулан үүнийг шууд хянах боломжтой.
Нэг ГБ хадгалах зардал бага тул анхдагч байдлаар Thanos нь түүхий өгөгдөл, таван минут, нэг цагийн нарийвчлалтай өгөгдлийг хадгалдаг. Анхны өгөгдлийг устгах шаардлагагүй.
Бичлэг хийх дүрэм
Thanos-тэй байсан ч бичлэг хийх дүрэм нь хяналтын стекийн чухал хэсэг юм. Эдгээр нь асуулгын нарийн төвөгтэй байдал, хоцролт, зардлыг бууруулдаг. Эдгээр нь хэрэглэгчдэд хэмжүүрээр нэгтгэсэн өгөгдлийг олж авахад тохиромжтой. Thanos нь ванилийн Prometheus жишээн дээр суурилдаг тул одоо байгаа Prometheus сервер дээр бичлэг хийх дүрэм болон анхааруулах дүрмийг хадгалах нь төгс төгөлдөр юм. Гэсэн хэдий ч зарим тохиолдолд энэ нь хангалтгүй байж болно:
- Глобал сэрэмжлүүлэг ба дүрэм (жишээ нь, үйлчилгээ нь гурван кластерын хоёроос илүү ажиллахгүй байх үед дохио өгөх).
- Дотоод санах ойн гаднах өгөгдөлд зориулсан дүрэм.
- Бүх дүрэм, сэрэмжлүүлгийг нэг дор хадгалах хүсэл.
Эдгээр бүх тохиолдлуудын хувьд Thanos нь Ruler хэмээх тусдаа бүрэлдэхүүн хэсгийг агуулдаг бөгөөд энэ нь Thanos Queries-ээр дамжуулан дүрэм, дохиололыг тооцдог. Алдартай StoreAPI-г хангаснаар Query зангилаа нь шинээр тооцоолсон хэмжигдэхүүнд хандах боломжтой. Дараа нь тэдгээрийг объектын санд хадгалж, Дэлгүүрийн гарцаар дамжуулан ашиглах боломжтой болно.
Таносын хүч
Thanos нь таны хэрэгцээнд нийцүүлэн өөрчлөхөд хангалттай уян хатан байдаг. Энэ нь энгийн Прометейгээс нүүж ирэхэд ялангуяа ашигтай байдаг. Thanos-ын бүрэлдэхүүн хэсгүүдийн талаар олж мэдсэн зүйлээ хурдан жишээгээр товчлон хэлье. "Хязгааргүй хэмжигдэхүүн"-ийн ертөнцөд өөрийн ванилийн Prometheus-ийг хэрхэн авчрах талаар эндээс үзнэ үү:
- Thanos Sidecar-ийг Prometheus серверүүддээ нэмнэ үү - жишээлбэл, Kubernetes pod дахь хажуугийн сав.
- Өгөгдлийг харах боломжтой байхын тулд олон Thanos Querier хуулбарыг байрлуул. Энэ үе шатанд Scraper болон Querier хоёрын хооронд хов жив суулгахад хялбар байдаг. Бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлийг шалгахын тулд 'thanos_cluster_members' хэмжигдэхүүнийг ашиглана уу.
Прометей HA-ийн боломжит хуулбаруудаас дэлхийг харах, өгөгдлийг үл тоомсорлоход энэ хоёр алхам хангалттай! Хяналтын самбараа Querier HTTP төгсгөлийн цэг рүү холбох эсвэл Thanos UI-г шууд ашиглана уу.
Гэсэн хэдий ч, хэрэв танд хэмжигдэхүүнийг нөөцлөх, урт хугацааны хадгалах шаардлагатай бол гурван алхамыг хийх шаардлагатай болно:
- AWS S3 эсвэл GCS хувин үүсгэ. Эдгээр хувин руу өгөгдлийг хуулахын тулд Sidecar-г тохируулна уу. Орон нутгийн мэдээллийн хадгалалтыг одоо багасгах боломжтой.
- Дэлгүүрийн гарцыг байрлуулж, одоо байгаа хов живийн кластерт холбоно уу. Одоо та нөөцлөгдсөн өгөгдлийг асууж болно!
- Ашиглалтын үр ашгийг нягтруулах, түүвэрлэх аргыг ашиглан урт хугацааны туршид сайжруулахын тулд Compactor-ийг суулгаарай.
Хэрэв та илүү ихийг мэдэхийг хүсвэл манайхаас бүү эргэлз и !
Бид ердөө тавхан алхмаар Prometheus-ийг дэлхийг харах боломжтой, хязгааргүй хадгалах хугацаа, хэмжигдэхүүнийг ашиглах боломжтой найдвартай хяналтын систем болгон хувиргасан.
Хүсэлт татах: бидэнд та хэрэгтэй байна!
анхнаасаа нээлттэй эхийн төсөл байсан. Prometheus-тай саадгүй нэгдэх, Thanos-ийн зөвхөн нэг хэсгийг ашиглах чадвар нь хяналтын системийг хялбархан өргөжүүлэх маш сайн сонголт болгодог.
Бид үргэлж GitHub татах хүсэлт болон асуудлуудыг хүлээн авна. Энэ хооронд Github Issues эсвэл slack-ээр бидэнтэй холбогдооройХэрэв танд асуулт, санал хүсэлт байвал эсвэл үүнийг ашиглах туршлагаасаа хуваалцахыг хүсвэл! Improbable-д бидний хийдэг зүйл танд таалагдаж байвал бидэнтэй холбоо барина уу - !
Эх сурвалж: www.habr.com