VictoriaMetrics бол өгөгдлийг цаг хугацааны цуваа хэлбэрээр хадгалах, боловсруулахад зориулагдсан хурдан бөгөөд өргөтгөх боломжтой DBMS юм (бичлэг нь цаг хугацаа болон энэ цагтай харгалзах утгуудын багцаас бүрдэнэ, жишээлбэл, мэдрэгч эсвэл мэдрэгчийн төлөвийг үе үе санал асуулга явуулах замаар олж авсан. хэмжүүрийн цуглуулга).
Намайг Колобаев Павел гэдэг. DevOps, SRE, LeroyMerlin, бүх зүйл код шиг байдаг - энэ бүхэн бидний тухай: миний тухай болон LeroyMerlin-ийн бусад ажилчдын тухай.
OpenStack дээр суурилсан үүл байдаг. Техникийн радартай жижиг холбоос байдаг.
Энэ нь Kubernetes техник хангамж, мөн OpenStack болон бүртгэл хөтлөхтэй холбоотой бүх үйлчилгээн дээр бүтээгдсэн.
Энэ бол бидний боловсруулж буй схем юм. Бид энэ бүхнийг боловсруулж байх үед K8s кластер дотор өгөгдөл хадгалдаг Prometheus оператортой байсан. Угаах шаардлагатай зүйлээ автоматаар олоод хөл доороо тавиад, бүдүүлэгээр хэлбэл.
Бид бүх өгөгдлийг Кубернетес кластераас гадагш зөөх шаардлагатай болно, учир нь ямар нэг зүйл тохиолдвол бид хаана, юу болохыг ойлгох хэрэгтэй.
Эхний шийдэл нь бид гуравдагч этгээдийн Prometheus-тэй үед, холбооны механизмаар дамжуулан Кубернетес кластерт очихдоо холбоог ашигладаг.
Гэхдээ энд зарим жижиг асуудлууд бий. Бидний хувьд 250 хэмжигдэхүүнтэй байхад асуудал эхэлсэн бөгөөд 000 хэмжигдэхүүн байхад бид ингэж ажиллах боломжгүй гэдгийг ойлгосон. Бид scrape_timeout-ийг 400 секунд хүртэл нэмэгдүүлсэн.
Бид яагаад үүнийг хийх ёстой байсан бэ? Прометей хашааны эхэн үеэс хойш цагийг тоолж эхэлдэг. Өгөгдөл урсаж байгаа нь хамаагүй. Хэрэв заасан хугацаанд өгөгдлийг нэгтгэж, http-ээр дамжуулан сессийг хаагаагүй бол сесс амжилтгүй болсонд тооцогдох бөгөөд өгөгдөл Prometheus-д өөрөө орохгүй.
Зарим өгөгдөл байхгүй үед бидний олж авдаг графикийг хүн бүр мэддэг. Хуваарь нь урагдсан, бид үүнд сэтгэл хангалуун бус байна.
Дараагийн сонголт бол нэг холбооны механизмаар дамжуулан хоёр өөр Prometheus дээр суурилсан sharding юм.
Жишээлбэл, тэдгээрийг аваад нэрээр нь хэлээрэй. Үүнийг бас ашиглаж болно, гэхдээ бид цаашаа явахаар шийдсэн.
Одоо бид эдгээр хэлтэрхийг ямар нэгэн байдлаар боловсруулах хэрэгтэй болно. Та shard талбарт очиж өгөгдлийг үржүүлдэг promxy-г авч болно. Энэ нь нэг нэвтрэх цэг болгон хоёр хэлтэрхийтэй ажилладаг. Үүнийг promxy-ээр дамжуулан хэрэгжүүлж болох ч энэ нь хэтэрхий хэцүү хэвээр байна.
Нэгдүгээр хувилбар нь холбооны механизм маш удаан байгаа учраас бид татгалзмаар байна.
Prometheus хөгжүүлэгчид "Залуус аа, өөр TimescaleDB ашигла, учир нь бид хэмжүүрийн урт хугацааны хадгалалтыг дэмжихгүй" гэж тодорхой хэлж байна. Энэ бол тэдний даалгавар биш.
Бид бүгдийг нэг газар хадгалахгүйн тулд гадаа буулгах шаардлагатай хэвээр байгаа цаасан дээр бичдэг.
Хоёр дахь дутагдал нь санах ойн зарцуулалт юм. Тийм ээ, 2020 онд хоёр гигабайт санах ой нь нэг пенни үнэтэй гэж олон хүн хэлэх болно гэдгийг би ойлгож байна.
Одоо бид хөгжүүлэгч болон үйлдвэрлэлийн орчинтой болсон. Хөгжүүлэгчид энэ нь 9 хэмжигдэхүүнд 350 гигабайт байдаг. Үйлдвэрлэлийн хувьд энэ нь 000 гигабайт бөгөөд 14 гаруй хэмжигдэхүүн юм. Үүний зэрэгцээ бидний хадгалах хугацаа ердөө 780 минут байна. Энэ муу байна. Тэгээд одоо би яагаад гэдгийг тайлбарлах болно.
Бид тооцооллыг хийдэг, өөрөөр хэлбэл нэг сая хагас хэмжигдэхүүнтэй, бид аль хэдийн ойрхон байгаа бөгөөд дизайны үе шатанд бид 35-37 гигабайт санах ой авдаг. Гэхдээ аль хэдийн 4 сая хэмжигдэхүүн нь 90 гигабайт санах ой шаарддаг. Энэ нь Prometheus-ийн хөгжүүлэгчдийн өгсөн томъёогоор тооцоолсон болно. Бид уялдаа холбоог хараад зөвхөн хяналт тавихын тулд серверт хэдэн сая төлөхийг хүсэхгүй байгаагаа ойлгосон.
Бид зөвхөн машинуудын тоог нэмэгдүүлээд зогсохгүй виртуал машинуудыг өөрсдөө хянаж байна. Тиймээс, илүү олон виртуал машин, олон төрлийн хэмжигдэхүүн гэх мэт. Бид хэмжүүрийн хувьд кластерын онцгой өсөлттэй байх болно.
Дискний зайтай бол энд бүх зүйл тийм ч муу биш, гэхдээ би үүнийг сайжруулахыг хүсч байна. Бид 15 хоногийн дотор нийт 120 гигабайт хүлээн авсан бөгөөд үүнээс 100 нь шахсан өгөгдөл, 20 нь шахагдаагүй өгөгдөл боловч бид үргэлж бага байхыг хүсдэг.
Үүний дагуу бид дахин нэг зүйлийг тэмдэглэж байна - энэ бол нөөцийн асар их хэрэглээ бөгөөд бид үүнийг хадгалахыг хүсч байна, учир нь манай хяналтын кластер OpenStack-ийг удирддаг кластераас илүү их нөөц ашиглахыг хүсэхгүй байна.
Прометейгийн бас нэг дутагдалтай тал бий, үүнийг бид өөрсдөө олж тогтоосон бөгөөд энэ нь ядаж санах ойн хязгаарлалт юм. Прометейгийн хувьд энд бүх зүйл илүү дорддог, учир нь түүнд ийм мушгиа огт байдаггүй. Докер дээр хязгаарыг ашиглах нь бас сонголт биш юм. Хэрэв таны RAF гэнэт унаж, 20-30 гигабайт байвал энэ нь өсөхөд маш их хугацаа шаардагдана.
Энэ нь Prometheus бидэнд тохирохгүй байгаагийн бас нэг шалтгаан, өөрөөр хэлбэл бид санах ойн хэрэглээг хязгаарлаж чадахгүй.
Ийм схемийг гаргаж ирэх боломжтой байсан. HA кластерийг зохион байгуулахын тулд бидэнд энэ схем хэрэгтэй. Эдгээр хэмжигдэхүүнүүдийг хадгалдаг сервер гацсан ч хэмжүүрүүд маань үргэлж, хаа сайгүй бэлэн байхыг бид хүсэж байна. Тиймээс бид ийм схемийг бий болгох хэрэгтэй болно.
Энэ схемд бид хэлтэрхийний давхардал, үүний дагуу хэрэглэсэн нөөцийн зардлыг давхардуулах болно гэж хэлж байна. Үүнийг бараг хэвтээ байдлаар өргөжүүлж болох боловч нөөцийн хэрэглээ нь аймшигтай байх болно.
Сул талуудыг бид өөрсдөө бичсэн хэлбэрээр нь дарааллаар нь авч үзвэл:
- Хэмжилтийг гаднаас байршуулахыг шаарддаг.
- Өндөр нөөцийн хэрэглээ.
- Санах ойн хэрэглээг хязгаарлах арга байхгүй.
- ХА-ийн цогц, нөөц ихтэй хэрэгжилт.
Бид өөрсдийнхөө хувьд Прометейг хадгалах газар болгон холдуулахаар шийдсэн.
Бид өөрсдөдөө хэрэгтэй нэмэлт шаардлагуудыг тодорхойлсон. Энэ:
- Энэ бол promql дэмжлэг юм, учир нь Prometheus-д зориулж маш олон зүйлийг аль хэдийн бичсэн байдаг: асуулга, сэрэмжлүүлэг.
- Тэгээд дараа нь бид Prometheus-д зориулж яг ижил аргаар бичсэн Графана байгаа. Би хяналтын самбарыг дахин бичихийг хүсэхгүй байна.
- Бид ердийн HA архитектурыг бий болгохыг хүсч байна.
- Аливаа нөөцийн хэрэглээг багасгамаар байна.
- Өөр нэг жижиг нюанс бий. Бид янз бүрийн төрлийн үүлэн хэмжүүр цуглуулах системийг ашиглах боломжгүй. Эдгээр хэмжигдэхүүнд юу орохыг бид хараахан мэдэхгүй байна. Тэнд юу ч нисэх боломжтой тул бид орон нутгийн байршилд өөрсдийгөө хязгаарлах ёстой.
Сонголт бага байсан. Бид туршлага хуримтлуулсан бүх зүйлээ цуглуулсан. Бид интеграцийн хэсэг дэх Prometheus хуудсыг үзэж, олон нийтлэл уншиж, тэнд юу байгааг харлаа. Бид өөрсдийнхөө хувьд Prometheus-ийн оронд VictoriaMetrics-ийг сонгосон.
Яагаад? Учир нь:
- promql хийж болно.
- Модульчлагдсан архитектур байдаг.
- Grafana-д өөрчлөлт оруулах шаардлагагүй.
- Хамгийн гол нь бид компанидаа хэмжүүрийн хадгалалтыг үйлчилгээ хэлбэрээр өгөх болно, тиймээс хэрэглэгчид кластерын бүх нөөцийг хязгаарлагдмал байдлаар ашиглах боломжтой байхын тулд янз бүрийн төрлийн хязгаарлалтыг урьдчилан хайж байна, учир нь боломж бий. Энэ нь олон түрээслэх болно.
Эхний харьцуулалтыг хийцгээе. Бид ижил Прометейг кластер дотор авдаг, гаднах Прометей түүн рүү явдаг. RemoteWrite VictoriaMetrics-ээр нэмнэ үү.
Энд бид VictoriaMetrics-ээс CPU-ийн хэрэглээ бага зэрэг өссөнийг би даруй анхааруулах болно. VictoriaMetrics вики нь аль параметрүүдийг хамгийн сайн болохыг хэлж өгдөг. Бид тэднийг шалгасан. Тэд CPU-ийн хэрэглээг маш сайн бууруулсан.
Манай тохиолдолд Kubernetes кластерт байрладаг Prometheus-ийн санах ойн хэрэглээ төдийлөн нэмэгдээгүй.
Бид ижил өгөгдлийн хоёр мэдээллийн эх сурвалжийг харьцуулж үздэг. Прометейд бид ижил дутуу өгөгдлийг олж хардаг. VictoriaMetrics дээр бүх зүйл сайхан байна.
Дискний зайны туршилтын үр дүн. Бид Prometheus-д нийтдээ 120 гигабайт хүлээн авсан. VictoriaMetrics дээр бид аль хэдийн өдөрт 4 гигабайт хүлээн авдаг. Прометейд бидний харж дассан механизмаас арай өөр механизм бий. Өөрөөр хэлбэл, өгөгдлийг нэг өдрийн дотор, хагас цагийн дотор аль хэдийн маш сайн шахдаг. Өгөгдөл нь дараа нь алдагдах болно гэсэн хэдий ч хагас цагийн дотор тэдгээрийг аль хэдийн сайн хурааж авсан. Үүний үр дүнд бид дискний зайг хэмнэсэн.
Мөн бид санах ойн нөөцийн зарцуулалтыг хэмнэдэг. Туршилтын үеэр бид Prometheus-ийг виртуал машин дээр байрлуулсан - 8 цөм, 24 гигабайт. Прометей бараг бүх зүйлийг иддэг. Тэр OOM Killer дээр унасан. Үүний зэрэгцээ зөвхөн 900 идэвхтэй хэмжигдэхүүнийг цутгасан. Энэ нь секундэд 000-25 хэмжигдэхүүн юм.
Бид VictoriaMetrics-ийг 8 гигабайт RAM-тай хоёр цөмт виртуал машин дээр ажиллуулсан. Бид VictoriaMetrics-ийг 8 ГБ багтаамжтай машин дээр цөөн хэдэн зүйлээр эргэлзэж байж сайн ажиллуулж чадсан. Эцэст нь бид үүнийг 7 гигабайт хүртэл хадгалсан. Үүний зэрэгцээ контентыг хүргэх хурд, өөрөөр хэлбэл хэмжүүр нь Прометейгийнхээс ч өндөр байв.
Прометейтэй харьцуулахад CPU нь хамаагүй дээр болсон. Энд Prometheus 2,5 цөм, VictoriaMetrics зөвхөн 0,25 цөм хэрэглэдэг. Эхэндээ - 0,5 цөм. Энэ нь нэгдэж, нэг цөмд хүрдэг, гэхдээ энэ нь маш ховор тохиолддог.
Бидний хувьд сонголт нь тодорхой шалтгааны улмаас VictoriaMetrics дээр унасан; бид мөнгө хэмнэхийг хүссэн бөгөөд бид үүнийг хийсэн.
Хоёр цэгийг нэн даруй хасъя - хэмжүүр байршуулах, нөөцийн өндөр хэрэглээ. Бид өөрсдөдөө үлдээсэн хоёр цэгийг л шийдэх хэрэгтэй.
Энд би шууд захиалга хийх болно, бид VictoriaMetrics-ийг хэмжүүрийн хадгалалт гэж үздэг. Гэхдээ бид VictoriaMetrics-ийг бүх Леройд хадгалах газар болгон өгөх магадлалтай тул энэ кластерийг ашиглах хүмүүсийг бидэнд өгөхгүйн тулд хязгаарлах хэрэгтэй.
Цаг хугацаа, өгөгдлийн хэмжээ, гүйцэтгэлийн хугацаагаар хязгаарлах боломжийг олгодог гайхалтай параметр байдаг.
Мөн санах ойн хэрэглээг хязгаарлах боломжийг олгодог маш сайн сонголт байдаг бөгөөд ингэснээр бид хэвийн үйл ажиллагааны хурд, хангалттай нөөцийн зарцуулалтыг олж авах боломжийг олгодог.
Хасах өөр нэг цэг, өөрөөр хэлбэл цэгийг хасах - та санах ойн хэрэглээг хязгаарлаж чадахгүй.
Эхний давталтуудад бид VictoriaMetrics Single Node-ийг туршиж үзсэн. Дараа нь бид VictoriaMetrics Cluster Version руу шилжинэ.
Энд бид VictoriaMetrics-ийн өөр өөр үйлчилгээнүүдийг юунд ашиглах, ямар нөөцийг ашиглахаас хамааран салгах эрх чөлөөтэй болно. Энэ бол маш уян хатан, тохиромжтой шийдэл юм. Үүнийг бид өөрсдөө ашигласан.
VictoriaMetrics Cluster Version-ийн үндсэн бүрэлдэхүүн хэсэг нь vmstsorage юм. Тэдний N тоо байж болно. Манайд одоогоор 2 байна.
Мөн vminsert байна. Энэ нь бидэнд дараах боломжийг олгодог прокси сервер юм: бидний хэлсэн бүх хадгалалтын хооронд хуваалт хийх, мөн хуулбарлах боломжийг олгодог, өөрөөр хэлбэл танд хуваалт болон хуулбар хоёулаа байх болно.
Vminsert нь Prometheus-ийн OpenTSDB, Graphite, InfluxDB болон remoteWrite протоколуудыг дэмждэг.
Мөн vmselect байдаг. Үүний гол ажил бол vmstorage руу орох, тэднээс өгөгдөл хүлээн авах, энэ өгөгдлийг хуулбарлаж, үйлчлүүлэгчид өгөх явдал юм.
Vmagent гэж гайхалтай зүйл байдаг. Бид түүнд үнэхээр дуртай. Энэ нь танд Prometheus-тай яг адилхан тохиргоо хийх боломжийг олгодог бөгөөд бүх зүйлийг яг Prometheus шиг хийх боломжийг олгодог. Өөрөөр хэлбэл, энэ нь өөр өөр байгууллага, үйлчилгээнээс хэмжигдэхүүнийг цуглуулж, vminsert руу илгээдэг. Тэгвэл бүх зүйл чамаас шалтгаална.
Өөр нэг гайхалтай үйлчилгээ бол VictoriaMetrics-ийг backend болгон ашиглах, vminsert-ээс боловсруулсан өгөгдлийг хүлээн авч, vmselect руу илгээх боломжийг олгодог vmalert юм. Энэ нь сэрэмжлүүлэг, дүрмийг өөрөө боловсруулдаг. Сэрэмжлүүлэг гарсан тохиолдолд бид дохиоллын менежерээр дамжуулан сэрэмжлүүлэг хүлээн авдаг.
wmauth бүрэлдэхүүн хэсэг байдаг. Бид үүнийг кластерын олон түрээсийн хувилбарт зөвшөөрлийн систем болгон ашиглаж болно, үгүй ч байж болно (бид үүнийг хараахан шийдээгүй байна). Энэ нь Prometheus-д зориулсан remoteWrite програмыг дэмждэг бөгөөд url хаягаар, эсхүл үүний хоёр дахь хэсэгт үндэслэн бичих боломжтой, эсвэл бичих боломжгүй газар дээр үндэслэн зөвшөөрөл өгөх боломжтой.
Мөн vmbackup, vmrestore байдаг. Энэ нь үндсэндээ бүх өгөгдлийг сэргээх, нөөцлөх явдал юм. S3, GCS, файл хийх боломжтой.
Манай кластерын анхны давталт нь хорио цээрийн дэглэмийн үед хийгдсэн. Тэр үед хуулбар байхгүй байсан тул бидний давталт нь remoteWrite-ээр дамжуулан өгөгдөл хүлээн авсан хоёр өөр, бие даасан кластераас бүрдсэн байв.
Энд би VictoriaMetrics Single Node-ээс VictoriaMetrics Cluster Version руу шилжихэд бид ижил ашигласан нөөц, өөрөөр хэлбэл гол зүйл нь санах ойтой хэвээр байсан гэдгийг тэмдэглэх болно. Энэ нь ойролцоогоор бидний өгөгдөл, өөрөөр хэлбэл нөөцийн хэрэглээг хэрхэн хуваарилсан юм.
Хуулбарыг энд аль хэдийн нэмсэн байна. Бид энэ бүгдийг нэг харьцангуй том кластер болгон нэгтгэсэн. Бидний бүх өгөгдөл хуваасан, хуулбарлагдсан байдаг.
Бүх кластер нь N нэвтрэх цэгтэй бөгөөд Prometheus нь HAPROXY-ээр дамжуулан өгөгдөл нэмэх боломжтой гэсэн үг юм. Энд бид ийм нэвтрэх цэгтэй байна. Мөн энэ нэвтрэх цэгээр дамжуулан та Grafana-аас нэвтэрч болно.
Манай тохиолдолд HAPROXY нь энэ кластер доторх прокси сонгох, оруулах болон бусад үйлчилгээг ашигладаг цорын ганц порт юм. Манай тохиолдолд нэг хаяг хийх боломжгүй байсан, бид хэд хэдэн нэвтрэх цэг хийх шаардлагатай болсон, учир нь VictoriaMetrics кластер ажилладаг виртуал машинууд нь нэг үүлэн үйлчилгээ үзүүлэгчийн өөр өөр бүсэд байрладаг, өөрөөр хэлбэл манай үүлэн дотор биш, харин гадна талд байрладаг. .
Бидэнд анхааруулга байна. Бид үүнийг ашигладаг. Бид Prometheus-ийн alertmanager ашигладаг. Бид Opsgenie болон Telegram-ийг дохио өгөх суваг болгон ашигладаг. Telegram дээр тэд хөгжүүлэгчээс, магадгүй бүтээгдэхүүнээс ямар нэгэн зүйл оруулдаг, гэхдээ ихэнхдээ инженерүүдэд шаардлагатай статистикийн зүйл байдаг. Мөн Опсгени шүүмжлэлтэй ханддаг. Эдгээр нь дуудлага, ослын менежмент юм.
Мөнхийн асуулт: "Хяналтад хэн хяналт тавьдаг вэ?" Манай тохиолдолд мониторинг нь өөрөө хяналтыг хянадаг, учир нь бид зангилаа бүр дээр vmagent ашигладаг. Манай зангилаанууд нэг үйлчилгээ үзүүлэгчийн өөр өөр мэдээллийн төвүүдэд тархсан тул дата төв бүр өөрийн гэсэн сувагтай, тэдгээр нь бие даасан байдаг бөгөөд тархи хуваагдсан ч гэсэн бид сэрэмжлүүлэг хүлээн авах болно. Тийм ээ, тэд илүү олон байх болно, гэхдээ байхгүй байснаас илүү олон дохио авах нь дээр.
Бид жагсаалтаа HA хэрэгжүүлэлтээр төгсгөдөг.
Цаашид би VictoriaMetrics нийгэмлэгтэй харилцах туршлагыг тэмдэглэхийг хүсч байна. Энэ нь маш эерэг болсон. Залуус хариу үйлдэл үзүүлж байна. Тэд санал болгож буй тохиолдол бүрийг нарийвчлан судлахыг хичээдэг.
Би GitHub дээр асуудал эхлүүлсэн. Тэд маш хурдан шийдэгдсэн. Бүрэн хаагдаагүй хэд хэдэн асуудал байгаа ч энэ чиглэлээр ажиллаж байгаа кодоос би аль хэдийн харж байна.
Давталт хийх үед миний хувьд гол өвдөлт нь хэрэв би зангилаа унтраавал эхний 30 секундын турш vminsert арын хэсэг байхгүй гэдгийг ойлгохгүй байх явдал байв. Үүнийг одоо шийдсэн. Тэгээд шууд утгаараа нэг юмуу хоёр секундын дотор өгөгдөл нь үлдсэн бүх зангилаанаас авч, хүсэлт нь тэр дутуу зангилааг хүлээхээ болино.
Хэзээ нэгэн цагт бид VictoriaMetrics-ийг VictoriaMetrics оператор болгохыг хүссэн. Бид түүнийг хүлээсэн. Одоо бид VictoriaMetrics операторын бүх урьдчилсан тооцооллын дүрмийг авах хүрээг идэвхтэй байгуулж байна. Prometheus, учир нь бид Prometheus оператортой хамт ирдэг дүрмийг нэлээд идэвхтэй ашиглаж байна.
Кластерийн хэрэгжилтийг сайжруулах саналууд байгаа. Би тэдгээрийг дээр дурдсан.
Мөн би түүврээ багасгахыг үнэхээр хүсч байна. Манай тохиолдолд зөвхөн чиг хандлагыг харахын тулд доош түүвэрлэх шаардлагатай. Ойролцоогоор нэг хэмжүүр өдрийн турш надад хангалттай. Эдгээр чиг хандлага нь нэг жил, гурав, тав, арван жил шаардлагатай. Мөн нэг хэмжүүрийн утга хангалттай.
- Прометейг хэрэглэх үед бид зарим нэг хамт олонтой адил өвдөлтийг мэддэг байсан.
- Бид өөрсдөө VictoriaMetrics-ийг сонгосон.
- Энэ нь босоо болон хэвтээ байдлаар маш сайн масштабтай.
- Бид өөр өөр бүрэлдэхүүн хэсгүүдийг кластерын өөр өөр тооны зангилаанд хуваарилах, санах ойгоор хязгаарлах, санах ой нэмэх гэх мэт боломжтой.
Бид VictoriaMetrics-ийг маш их таалагдсан тул гэртээ ашиглах болно. Энэ бол юу байсан, юу болсон юм.
VictoriaMetrics чатын хэд хэдэн QR код, миний харилцагчид, LeroyMerlin техникийн радар.
Эх сурвалж: www.habr.com