Анхаарна уу. орчуулга.: Grafana-г бүтээгчдийн үүлэн үйлчилгээнд сүүлийн үед саатал гарсан шалтгаануудын талаарх техникийн дэлгэрэнгүй мэдээллийг бид та бүхэнд толилуулж байна. Энэ бол дэд бүтцийн чанарыг сайжруулахад зориулагдсан шинэ бөгөөд маш хэрэгтэй мэт санагдах боломж нь үйлдвэрлэлийн бодит байдалд ашиглах олон нарийн ширийн зүйлийг анхаарч үзэхгүй бол хор хөнөөл учруулж болохыг харуулсан сонгодог жишээ юм. Зөвхөн алдаанаасаа суралцах боломжийг олгодог ийм материал гарч ирэхэд үнэхээр сайхан байдаг. Дэлгэрэнгүй мэдээллийг Grafana Labs-ийн бүтээгдэхүүн хариуцсан дэд ерөнхийлөгчийн орчуулгад оруулсан болно.
19-р сарын 30-ний Баасан гарагт Grafana Cloud дахь Hosted Prometheus үйлчилгээ XNUMX минут орчим ажиллахаа больсон. Би тасалдсан бүх үйлчлүүлэгчдээс хүлцэл өчье. Бидний ажил бол танд хэрэгтэй хяналтын хэрэгслээр хангах явдал бөгөөд тэдгээр нь байхгүй байх нь таны амьдралыг улам хүндрүүлнэ гэдгийг бид ойлгож байна. Бид энэ үйл явдлыг маш нухацтай авч үздэг. Энэ тэмдэглэлд юу болсон, бид хэрхэн хариу үйлдэл үзүүлсэн, дахин ийм зүйл тохиолдохгүйн тулд юу хийж байгааг тайлбарласан болно.
Эрьт урьдын түүх
Grafana Cloud Hosted Prometheus үйлчилгээ нь дээр суурилсан — Хэвтээ байдлаар өргөтгөх боломжтой, өндөр хүртээмжтэй, олон түрээслэгчтэй Prometheus үйлчилгээг бий болгох CNCF төсөл. Cortex архитектур нь бие даасан микро үйлчилгээний багцаас бүрддэг бөгөөд тус бүр нь өөрийн гэсэн функцийг гүйцэтгэдэг: хуулбарлах, хадгалах, асуулга гэх мэт. Cortex идэвхтэй хөгжиж байгаа бөгөөд байнга шинэ функцуудыг нэмж, гүйцэтгэлийг сайжруулж байдаг. Хэрэглэгчид эдгээр боломжуудыг ашиглахын тулд бид шинэ Cortex хувилбаруудыг кластеруудад тогтмол байрлуулдаг - аз болоход Cortex-ийг сул зогсолтгүйгээр шинэчлэх боломжтой.
Тохиромжгүй шинэчлэлтүүдийн хувьд Ingester Cortex үйлчилгээ нь шинэчлэлтийн явцад нэмэлт Ingester хуулбарыг шаарддаг. (Анхаарна уу. орчуулга.: - Cortex-ийн үндсэн бүрэлдэхүүн хэсэг. Түүний ажил нь дээжийн тогтмол урсгалыг цуглуулж, Prometheus хэсгүүдэд бүлэглэж, DynamoDB, BigTable эсвэл Cassandra зэрэг мэдээллийн санд хадгалах явдал юм.) Энэ нь хуучин Ingester-д одоогийн өгөгдлийг шинэ Ingester-д дамжуулах боломжийг олгодог. Ingesters нь нөөц баялаг шаарддаг гэдгийг тэмдэглэх нь зүйтэй. Тэдгээрийг ажиллуулахын тулд та нэг pod 4 цөм, 15 ГБ санах ойтой байх ёстой. Манай Kubernetes кластеруудын хувьд үндсэн машины боловсруулах хүчин чадал, санах ойн 25%. Ерөнхийдөө бид кластерт 4 цөм, 15 ГБ санах ойноос хамаагүй их ашиглагдаагүй нөөцтэй байдаг тул шинэчлэлт хийх явцад бид эдгээр нэмэлт залгууруудыг хялбархан эргүүлэх боломжтой.
Гэсэн хэдий ч, хэвийн ажиллагааны явцад аль ч машинд ашиглагдаагүй нөөцийн 25% байдаггүй нь ихэвчлэн тохиолддог. Тиймээ, бид хичээхгүй: CPU болон санах ой нь бусад процессуудад үргэлж хэрэгтэй байх болно. Энэ асуудлыг шийдэхийн тулд бид ашиглахаар шийдсэн . Энэ санаа нь Ingesters-д бусад (харьяалалгүй) бичил үйлчилгээнээс илүү давуу эрх олгох явдал юм. Бид нэмэлт (N+1) Ingester ажиллуулах шаардлагатай үед бусад жижиг хонхорцогуудыг түр орлуулдаг. Эдгээр хонхорцогуудыг бусад машинууд дээрх үнэгүй нөөцөд шилжүүлж, нэмэлт Ingester ажиллуулах хангалттай том "нүх" үлдээдэг.
18-р сарын XNUMX-ны Пүрэв гарагт бид кластерууддаа тэргүүлэх ач холбогдолтой дөрвөн шинэ түвшинг гаргалаа. чухал, өндөр, дундаж и бага байна. Тэднийг нэг долоо хоног орчим үйлчлүүлэгчийн урсгалгүй дотоод кластер дээр туршиж үзсэн. Өгөгдмөлөөр, заасан давуу эрхгүй pods хүлээн авсан дундаж тэргүүлэх ач холбогдол, анги хамт Ingesters тогтоосон өндөр тэргүүлэх ач холбогдол. Шүүмжтэй хяналтанд зориулж нөөцөлсөн (Prometheus, Alertmanager, node-exporter, kube-state-meterics гэх мэт). Манай тохиргоо нээлттэй байгаа бөгөөд та PR-г үзэх боломжтой .
Сүйрлийн
19-р сарын XNUMX-ний Баасан гарагт инженерүүдийн нэг нь томоохон үйлчлүүлэгчдэд зориулсан шинэ Cortex кластерийг эхлүүлсэн. Энэ кластерын тохиргоонд шинэ подволкийн тэргүүлэх чиглэлүүд ороогүй тул бүх шинэ pods-д өгөгдмөл тэргүүлэх ач холбогдол өгсөн - дундаж.
Kubernetes кластерт шинэ Cortex кластерт хангалттай нөөц байхгүй байсан бөгөөд одоо байгаа үйлдвэрлэлийн Cortex кластер шинэчлэгдээгүй байна (Ингэстерүүд үлдэв. өндөр тэргүүлэх ач холбогдол). Анхдагчаар шинэ кластерийн Ingesters байсан тул дундаж тэргүүлэх ач холбогдол өгч, үйлдвэрлэлд одоо байгаа хонхорцог ямар ч давуу талгүйгээр ажиллаж байсан тул шинэ кластерын Ingesters нь одоо байгаа Cortex үйлдвэрлэлийн кластераас Ingesters-ийг сольсон.
Үйлдвэрлэлийн кластер дахь хөөгдсөн Ingester-д зориулсан ReplicaSet нь хөөгдсөн pod-ыг илрүүлж, заасан тооны хуулбарыг хадгалахын тулд шинээр үүсгэсэн. Шинэ pod-г анхдагчаар оноосон дундаж тэргүүлэх ач холбогдол өгч, үйлдвэрлэлийн өөр нэг "хуучин" Ingester нөөцөө алдсан. Үр дүн нь байсан нуранги үйл явц, энэ нь Ingester for Cortex үйлдвэрлэлийн кластеруудаас бүх хонхорцогуудыг нүүлгэн шилжүүлэхэд хүргэсэн.
Залгигч нь төлөв бөгөөд өмнөх 12 цагийн өгөгдлийг хадгалдаг. Энэ нь бидэнд тэдгээрийг урт хугацааны хадгалалтад бичихээс өмнө илүү үр дүнтэй шахах боломжийг олгодог. Үүнд хүрэхийн тулд Cortex нь Distributed Hash Table (DHT) ашиглан өгөгдлийг цуврал болгон хувааж, Динамо маягийн чуулгын тогтвортой байдлыг ашиглан цуврал бүрийг гурван Ingester дээр хуулбарладаг. Cortex нь идэвхгүй болсон Ingester-д өгөгдөл бичихгүй. Тиймээс олон тооны Ingesters DHT-ээс гарах үед Cortex нь оруулгуудыг хангалттай хуулбарлаж чадахгүй бөгөөд тэдгээр нь сүйрдэг.
Илрүүлэх, арилгах
"Алдааны төсөв" дээр үндэслэсэн шинэ Prometheus мэдэгдлүүд (алдаа төсөвт суурилсан - дэлгэрэнгүй мэдээллийг ирээдүйн нийтлэлд харуулах болно) унтрааж эхэлснээс хойш 4 минутын дараа дохиолол дуугарч эхлэв. Дараагийн таван минутын хугацаанд бид зарим оношлогоо хийж, шинэ болон одоо байгаа үйлдвэрлэлийн кластеруудыг хоёуланг нь байрлуулахын тулд үндсэн Кубернетес кластерыг өргөжүүлсэн.
Дахин таван минутын дараа хуучин Ingester-ууд өөрсдийн мэдээллээ амжилттай бичиж, шинэ нь ажиллаж эхэлсэн бөгөөд Cortex кластерууд дахин боломжтой болсон.
Өөр 10 минутыг Cortex-ийн урд байрлах урвуу баталгаажуулалтын проксигийн санах ойгүй (OOM) алдааг оношлох, засахад зарцуулсан. OOM алдаа нь QPS арав дахин нэмэгдсэнээс үүдэлтэй (бид үйлчлүүлэгчийн Prometheus серверүүдийн хэт түрэмгий хүсэлтээс үүдэлтэй гэж үзэж байна).
Үр дагавар
Нийт 26 минут зогссон. Ямар ч өгөгдөл алдагдаагүй. Ingesters санах ойн бүх өгөгдлийг урт хугацааны хадгалалтад амжилттай ачааллаа. Унтраах үед клиент Prometheus серверүүд буферт устгагдсан (алсын) ашиглан бичлэг хийх WAL дээр үндэслэсэн (зохиогч Grafana Labs) болон ослын дараа бүтэлгүйтсэн бичвэрүүдийг давтав.
Үйлдвэрлэлийн кластер бичих үйлдлүүд
үр дүн нь
Энэ явдлаас сургамж авч, дахин давтагдахгүйн тулд шаардлагатай арга хэмжээг авах нь чухал.
Эргээд бодоход бид анхдагч тохиргоог хийх ёсгүй байсан дундаж үйлдвэрлэлд байгаа бүх Ingesters хүлээн авах хүртэл тэргүүлэх ач холбогдол өндөр тэргүүлэх чиглэл. Үүнээс гадна тэднийг урьдчилан халамжлах шаардлагатай байв өндөр тэргүүлэх ач холбогдол. Одоо бүх зүйл тогтсон. Бидний туршлага Kubernetes дахь pod нэн тэргүүнд ашиглах талаар бодож буй бусад байгууллагуудад тусална гэж найдаж байна.
Бид кластерт глобал тохиргоотой аливаа нэмэлт объектыг байршуулах хяналтын нэмэлт түвшинг нэмнэ. Үүнээс хойш ийм өөрчлөлтийг үнэлнэ bоилүү олон хүн. Нэмж дурдахад, ослын шалтгаан болсон өөрчлөлтийг тусдаа төслийн баримт бичигт хэтэрхий бага гэж үзсэн - энэ нь зөвхөн GitHub дугаарт яригдсан. Одооноос эхлэн тохиргоонд хийсэн ийм өөрчлөлтийг зохих төслийн баримт бичиг дагалдана.
Эцэст нь бид гэрчлэгдсэн OOM-ийн хэт ачааллаас урьдчилан сэргийлэхийн тулд баталгаажуулалтын урвуу проксины хэмжээг автоматжуулж, ирээдүйд ижил төстэй асуудлаас урьдчилан сэргийлэхийн тулд буцаах, масштаблахтай холбоотой Prometheus-ийн анхдагч тохиргоог хянана.
Алдаа нь мөн эерэг үр дагавартай байсан: шаардлагатай нөөцийг хүлээн авснаар Cortex нэмэлт хөндлөнгийн оролцоогүйгээр автоматаар сэргэсэн. Мөн бид хамтран ажиллаж үнэ цэнэтэй туршлага хуримтлуулсан - манай шинэ бүртгэл нэгтгэх систем нь бүтэлгүйтлийн үед болон дараа нь бүх Ingesters зөв ажиллахад тусалсан.
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com