Өнөөдөр манай төсөлд цул кодоос гадна олон арван бичил үйлчилгээ багтсан. Тэд тус бүрийг хянах шаардлагатай. Үүнийг DevOps инженерүүдийг ашиглан ийм хэмжээнд хийх нь асуудалтай юм. Бид хөгжүүлэгчдэд зориулсан үйлчилгээ болох хяналтын системийг боловсруулсан. Тэд хяналтын системд бие даан хэмжүүр бичиж, тэдгээрийг ашиглаж, тэдгээрийн үндсэн дээр хяналтын самбар үүсгэж, босго утгад хүрсэн үед дохио өгөх боломжтой. DevOps инженерүүдийн хувьд зөвхөн дэд бүтэц, баримт бичиг.
Энэ нийтлэл нь миний бидэнтэй хийсэн ярианы бичлэг юм RIT++ дээр. Олон хүмүүс биднээс тайлангийн текст хувилбарыг гаргахыг хүссэн. Хэрэв та хурал дээр байсан эсвэл видеог үзсэн бол шинэ зүйл олж харахгүй. Мөн бусад бүх хүмүүс - мууранд тавтай морилно уу. Бид хэрхэн ийм системд хүрсэн, энэ нь хэрхэн ажилладаг, хэрхэн шинэчлэхээр төлөвлөж байгаагаа танд хэлэх болно.
Өнгөрсөн үе: схем ба төлөвлөгөө
Одоогийн хяналтын системд бид хэрхэн хүрсэн бэ? Энэ асуултад хариулахын тулд та 2015 он руу явах хэрэгтэй. Тэр үед иймэрхүү харагдаж байсан:
Бид хяналт тавих үүрэгтэй 24 орчим зангилаатай байсан. Ямар нэгэн байдлаар ямар нэг зүйлийг хянаж, мессеж илгээж, үүрэг гүйцэтгэдэг янз бүрийн титэм, скрипт, демонуудын бүхэл бүтэн багц байдаг. Бид цааш явах тусам ийм тогтолцоо нь амьдрах чадваргүй болно гэж бодсон. Үүнийг хөгжүүлэх нь утгагүй юм: энэ нь хэтэрхий төвөгтэй юм.
Бид хадгалах, хөгжүүлэх, орхих хяналтын элементүүдийг сонгохоор шийдсэн. Тэдгээрийн тоо 19 байсан. Зөвхөн бал чулуу, агрегатор, хяналтын самбар болох Графана л үлдсэн. Харин шинэ систем ямар байх бол? Үүн шиг:
Бидэнд хэмжүүр хадгалах сан бий: эдгээр нь хурдан SSD хөтчүүд дээр суурилсан бал чулуунууд бөгөөд эдгээр нь хэмжүүрийн тодорхой нэгтгэгч юм. Дараа нь - Хяналтын самбарыг харуулах Графана, дохио өгөх Moira. Бид мөн гажиг хайх системийг хөгжүүлэхийг хүссэн.
Стандарт: Хяналт 2.0
2015 онд ийм төлөвлөгөөтэй байсан.Гэхдээ бид зөвхөн дэд бүтэц, үйлчилгээ төдийгүй бичиг баримтыг нь бэлтгэх ёстой байсан. Бид өөрсдөдөө зориулж корпорацийн стандартыг боловсруулсан бөгөөд үүнийг бид мониторинг 2.0 гэж нэрлэдэг. Системд ямар шаардлага тавигдсан бэ?
- байнгын бэлэн байдал;
- хэмжүүр хадгалах интервал = 10 секунд;
- хэмжигдэхүүн болон хяналтын самбарын бүтэцтэй хадгалалт;
- SLA > 99,99%
- UDP (!) -ээр дамжуулан үйл явдлын хэмжүүрүүдийг цуглуулах.
Бидэнд хэмжигдэхүүн үүсгэдэг урсгал, үйл явдлын асар их урсгал байдаг тул бидэнд UDP хэрэгтэй байсан. Хэрэв та бүгдийг нэг дор бал чулуунд бичвэл хадгалалт нурах болно. Мөн бид бүх хэмжигдэхүүнд эхний түвшний угтваруудыг сонгосон.
Угтвар бүр нь тодорхой шинж чанартай байдаг. Сервер, сүлжээ, контейнер, нөөц, програм гэх мэт үзүүлэлтүүд байдаг. Тодорхой, хатуу, шивсэн шүүлтүүрийг хэрэгжүүлсэн бөгөөд бид нэгдүгээр түвшний хэмжүүрүүдийг хүлээн авч, үлдсэнийг нь зүгээр л хаядаг. Бид 2015 онд энэ системийг ингэж төлөвлөж байсан. Одоогийн байдлаар юу байгаа вэ?
Одоогийн байдлаар: хяналтын бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлийн диаграм
Юуны өмнө бид програмуудыг хянадаг: бидний PHP код, програмууд болон микро үйлчилгээнүүд - товчхондоо манай хөгжүүлэгчдийн бичсэн бүх зүйл. Бүх програмууд Brubeck агрегатор руу UDP-ээр дамжуулан хэмжүүрүүдийг илгээдэг (statsd, C хэлээр дахин бичсэн). Энэ нь синтетик туршилтуудын хамгийн хурдан нь болсон. Энэ нь аль хэдийн нэгтгэсэн хэмжигдэхүүнийг TCP-ээр дамжуулан Графит руу илгээдэг.
Энэ нь таймер гэж нэрлэгддэг хэмжүүрийн төрөлтэй. Энэ бол маш тохиромжтой зүйл юм. Жишээлбэл, хэрэглэгч тус үйлчилгээнд холбогдохын тулд хариу өгөх хугацаа бүхий хэмжүүрийг Brubeck руу илгээдэг. Нэг сая хариулт ирсэн боловч нэгтгэгч зөвхөн 10 хэмжигдэхүүнийг буцаасан. Танд ирсэн хүмүүсийн тоо, хамгийн их, хамгийн бага, дундаж хариу өгөх хугацаа, медиан ба 4 хувь байна. Дараа нь өгөгдлийг Graphite руу шилжүүлж, бид бүгдийг шууд харж байна.
Бидэнд мөн техник хангамж, программ хангамж, системийн хэмжүүр болон хуучин Мунин хяналтын систем (энэ нь 2015 он хүртэл ажилласан) хэмжигдэхүүнүүдийг нэгтгэдэг. Бид энэ бүгдийг C demon CollectD-ээр дамжуулан цуглуулдаг (үүнд олон янзын залгаасуудыг суулгасан байдаг, энэ нь суулгасан хост системийн бүх нөөцийг сонгох боломжтой, тохиргоонд өгөгдөл бичих газрыг зааж өгөхөд л хангалттай) ба түүгээр дамжуулан Graphite руу өгөгдлийг бичнэ. Энэ нь мөн python залгаасууд болон бүрхүүлийн скриптүүдийг дэмждэг тул та өөрийн тохируулсан шийдлүүдийг бичих боломжтой: CollectD нь энэ өгөгдлийг локал эсвэл алсын хостоос (Curl гэж үзвэл) цуглуулж, Graphite руу илгээнэ.
Дараа нь бид цуглуулсан бүх хэмжигдэхүүнийг Carbon-c-relay руу илгээдэг. Энэ бол C хэл дээр өөрчилсөн Graphite-ийн Carbon Relay шийдэл юм. Энэ нь бидний нэгтгэгчээс илгээсэн бүх хэмжигдэхүүнийг цуглуулж, зангилаа руу чиглүүлдэг чиглүүлэгч юм. Мөн чиглүүлэлтийн үе шатанд хэмжүүрүүдийн хүчинтэй эсэхийг шалгадаг. Нэгдүгээрт, тэдгээр нь миний өмнө үзүүлсэн угтвар схемтэй тохирч байх ёстой, хоёрдугаарт, тэдгээр нь бал чулуунд хүчинтэй байна. Үгүй бол тэд унах болно.
Нүүрстөрөгч-c-релей нь хэмжигдэхүүнийг Графит кластер руу илгээдэг. Бид Go-д дахин бичсэн Carbon-cache-г хэмжүүрийн үндсэн хадгалалт болгон ашигладаг. Go-carbon нь олон урсгалтай учраас Carbon-cache-ээс хамаагүй илүү байдаг. Энэ нь шивнэх багц (стандарт, python хэл дээр бичигдсэн) ашиглан өгөгдлийг хүлээн авч диск рүү бичдэг. Манай сангаас өгөгдлийг уншихын тулд бид Graphite API ашигладаг. Энэ нь стандарт Graphite WEB-ээс хамаагүй хурдан юм. Дараа нь өгөгдөлд юу тохиолдох вэ?
Тэд Графана руу явдаг. Бид графит кластеруудаа өгөгдлийн үндсэн эх сурвалж болгон ашигладаг ба хэмжигдэхүүнийг харуулах, хяналтын самбар үүсгэх вэб интерфэйс болгон Grafana-тай. Үйлчилгээ бүрийн хувьд хөгжүүлэгчид өөрсдийн хяналтын самбарыг бий болгодог. Дараа нь тэдгээрт тулгуурлан графикуудыг бүтээдэг бөгөөд энэ нь программаасаа бичсэн хэмжигдэхүүнээ харуулдаг. Графанагаас гадна манайд SLAM бас бий. Энэ бол бал чулуунаас авсан өгөгдөл дээр үндэслэн SLA-г тооцдог питон чөтгөр юм. Би аль хэдийн хэлсэнчлэн бид хэдэн арван микро үйлчилгээтэй бөгөөд тус бүр өөрийн гэсэн шаардлага тавьдаг. SLAM-ийг ашигласнаар бид баримт бичигт очиж, үүнийг Graphite-д байгаа зүйлтэй харьцуулж, шаардлага нь манай үйлчилгээний хүртээмжтэй хэр нийцэж байгааг харьцуулдаг.
Цааш үргэлжлүүлье: анхааруулах. Энэ нь хүчирхэг системийг ашиглан зохион байгуулагдсан - Moira. Бүрээсний доор өөрийн гэсэн Графит байдаг тул бие даасан. SKB "Kontur"-ийн залуусын боловсруулсан, python болон Go дээр бичигдсэн, бүрэн нээлттэй эх сурвалж. Мойра нь бал чулуу руу ордог урсгалыг хүлээн авдаг. Хэрэв ямар нэг шалтгааны улмаас таны хадгалах сан үхвэл анхааруулга ажилласаар байх болно.
Бид Moira-г Kubernetes-д байрлуулсан; энэ нь Redis серверүүдийн кластерийг үндсэн мэдээллийн сан болгон ашигладаг. Үүний үр дүнд алдааг тэсвэрлэх чадвартай систем бий болсон. Энэ нь хэмжүүрийн урсгалыг триггерүүдийн жагсаалттай харьцуулдаг: хэрэв үүн дээр дурдаагүй бол хэмжигдэхүүнийг хасна. Тиймээс минутанд гигабайт хэмжигдэхүүнийг шингээх чадвартай.
Бид мөн үүнд корпорацийн LDAP-г хавсаргасан бөгөөд үүний тусламжтайгаар корпорацийн системийн хэрэглэгч бүр одоо байгаа (эсвэл шинээр үүсгэсэн) триггер дээр үндэслэн өөрсөддөө мэдэгдэл үүсгэх боломжтой. Moira нь Графит агуулсан тул түүний бүх функцийг дэмждэг. Тиймээс та эхлээд мөрийг аваад Grafana руу хуулна. График дээр өгөгдөл хэрхэн харагдаж байгааг харна уу. Дараа нь та ижил мөрийг аваад Moira руу хуулна. Та үүнийг хязгаартай өлгөж, гаралт дээр дохио авах болно. Энэ бүхнийг хийхийн тулд танд тодорхой мэдлэг хэрэггүй. Moira нь SMS, цахим шуудан, Jira, Slack-ээр дамжуулан сэрэмжлүүлэх боломжтой ... Энэ нь мөн захиалгат скриптүүдийн гүйцэтгэлийг дэмждэг. Түүнд гох тохиолдоход тэр захиалгат скрипт эсвэл хоёртын файлд бүртгүүлсэн бол тэр үүнийг ажиллуулж JSON-г энэ хоёртын файлд зориулж stdin руу илгээдэг. Үүний дагуу таны програм үүнийг задлан шинжлэх ёстой. Энэ JSON-тэй юу хийх нь танаас хамаарна. Хэрэв та хүсвэл Telegram руу илгээгээрэй, хэрэв хүсвэл Jira-д даалгавруудыг нээнэ үү, юу ч хий.
Бид мөн өөрийн хөгжүүлэлтийг анхааруулахад ашигладаг - Imagotag. Дэлгүүрт ихэвчлэн цахим үнийн шошго хийдэг самбарыг бид өөрсдийн хэрэгцээнд нийцүүлэн тохируулсан. Бид Мойрагаас гохыг авчирсан. Энэ нь тэд ямар байдалд байгаа, хэзээ үүссэнийг заадаг. Хөгжүүлэгчдийн зарим нь энэ самбарыг ашиглахын тулд Slack болон имэйл дэх мэдэгдлүүдийг орхисон.
За, бид дэвшилтэт компани учраас бид энэ системд Kubernetes-ийг бас хянаж байсан. Бид үүнийг кластерт суулгасан Heapster ашиглан системд оруулсан бөгөөд энэ нь өгөгдөл цуглуулж, Graphite руу илгээдэг. Үүний үр дүнд диаграмм дараах байдалтай байна.
Хяналтын бүрэлдэхүүн хэсгүүд
Энэ даалгаварт бидний ашигласан бүрэлдэхүүн хэсгүүдийн холбоосуудын жагсаалт энд байна. Тэд бүгд нээлттэй эх сурвалж юм.
Графит:
- нүүрстөрөгч:
- шивнэх:
- бал чулуу-апи:
Нүүрстөрөгч-с-реле:
Брубек:
Цуглуулсан:
Мойра:
Графана:
Хэпстер:
Статистик
Мөн систем нь бидний хувьд хэрхэн ажилладаг тухай зарим тоо энд байна.
Агрегатор (брюбек)
Хэмжилтийн тоо: ~300/сек
Графит руу хэмжигдэхүүн илгээх интервал: 30 сек
Серверийн нөөцийн хэрэглээ: ~ 6% CPU (бид бүрэн хэмжээний серверүүдийн тухай ярьж байна); ~ 1 Гб RAM; ~3 Mbps LAN
Графит (нүүрстөрөгч)
Хэмжих тоо: ~ 1 / мин
Метрик шинэчлэх интервал: 30 сек
Метрик хадгалах схем: 30 секунд 35d, 5 мин 90d, 10 мин 365d (удаан хугацааны туршид үйлчилгээнд юу тохиолдохыг ойлгох боломжийг танд олгоно)
Серверийн нөөцийн хэрэглээ: ~10% CPU; ~ 20 Гб RAM; ~30 Mbps LAN
Уян хатан байдал
Avito-д бид хяналтын үйлчилгээнийхээ уян хатан байдлыг үнэхээр үнэлдэг. Тэр яагаад үнэхээр ийм болсон юм бэ? Нэгдүгээрт, түүний бүрэлдэхүүн хэсгүүдийг сольж болно: бүрэлдэхүүн хэсгүүд нь өөрсдөө болон тэдгээрийн хувилбарууд. Хоёрдугаарт, дэмжлэг үзүүлэх чадвар. Төсөл бүхэлдээ нээлттэй эх сурвалжтай тул та кодыг өөрөө засварлаж, өөрчлөлт хийж, хайрцагнаас гарах боломжгүй функцүүдийг хэрэгжүүлэх боломжтой. Голдуу Go болон Python стекийг ихэвчлэн ашигладаг тул үүнийг маш энгийнээр хийдэг.
Бодит асуудлын жишээ энд байна. Графит дахь хэмжүүр нь файл юм. Энэ нь нэртэй. Файлын нэр = хэмжүүрийн нэр. Мөн тэнд хүрэх арга зам бий. Линукс дээрх файлын нэрс 255 тэмдэгтээр хязгаарлагддаг. Мөн бидэнд мэдээллийн сангийн хэлтсийн залуус (“дотоод үйлчлүүлэгчид”) бий. Тэд бидэнд: "Бид өөрсдийн SQL асуулгад хяналт тавихыг хүсч байна. Мөн тэдгээр нь 255 тэмдэгт биш, харин тус бүр нь 8 МБ байна. Бид тэдгээрийг Графана дээр харуулахыг хүсч байна, энэ хүсэлтийн параметрүүдийг харахыг хүсч байна, тэр ч байтугай илүү дээр нь бид ийм хүсэлтийн дээд хэсгийг харахыг хүсч байна. Бодит цагт үзүүлбэл маш сайн байх болно. Тэднийг сэрэмжлүүлэг болгох нь үнэхээр сайхан байх болно."
Жишээ SQL асуулгыг жишээ болгон авсан болно
Бид Redis серверийг байгуулж, Postgres руу орж бүх өгөгдлийг тэндээс авч, Graphite руу хэмжигдэхүүнийг илгээдэг Collectd залгаасуудыг ашигладаг. Гэхдээ бид хэмжүүрийн нэрийг хэшээр солино. Бид нэгэн зэрэг ижил хэшийг Redis руу түлхүүр болгон илгээж, SQL асуулгыг бүхэлд нь утга болгон илгээдэг. Бидний хийх ёстой зүйл бол Графана Редис рүү очиж энэ мэдээллийг авах боломжтой эсэхийг шалгах явдал юм. Бид Graphite API-г нээж байна, учир нь... Энэ бол бүх хяналтын бүрэлдэхүүн хэсгүүдийн бал чулуутай харьцах үндсэн интерфейс бөгөөд бид тэнд aliasByHash() хэмээх шинэ функцийг оруулдаг - Графанагаас бид хэмжүүрийн нэрийг авч, Redis-ийн хүсэлтэд түлхүүр болгон ашигладаг. Хариуд нь бид түлхүүрийн утгыг авдаг бөгөөд энэ нь бидний "SQL асуулга" юм. Тиймээс бид Grafana дээр онолын хувьд харуулах боломжгүй байсан SQL асуулгын дэлгэцийг түүн дээрх статистикийн хамт (дуудлага, мөр, нийт цаг, ...) харуулсан.
Үр дүн
Бэлэн байдал Манай хяналтын үйлчилгээ ямар ч программ болон ямар ч кодоос 24/7 цагийн турш боломжтой. Хэрэв та хадгалах байгууламжид хандах боломжтой бол үйлчилгээнд өгөгдөл бичиж болно. Хэл чухал биш шийдвэр чухал биш. Та зөвхөн залгуурыг хэрхэн онгойлгох, тэнд хэмжүүр тавьж, залгуурыг хаах талаар мэдэх хэрэгтэй.
Найдвартай байдал. Бүх бүрэлдэхүүн хэсгүүд нь гэмтэлд тэсвэртэй бөгөөд бидний ачааллыг сайн зохицуулдаг.
Нэвтрэх саад багатай. Энэ системийг ашиглахын тулд та Grafana дахь програмчлалын хэл, асуулга сурах шаардлагагүй. Зүгээр л програмаа нээгээд, Graphite руу хэмжигдэхүүн илгээх залгуур оруулаад, хааж, Grafana-г нээж, тэнд хяналтын самбар үүсгэж, Moira-ээр дамжуулан мэдэгдэл хүлээн авч, хэмжүүрийнхээ үйл ажиллагааг хараарай.
Тусгаар тогтнол. Та DevOps инженерүүдийн тусламжгүйгээр энэ бүхнийг өөрөө хийж чадна. Мөн энэ нь давуу тал юм, учир нь та яг одоо төслөө хянах боломжтой тул хэнээс ч асуух шаардлагагүй - ажил эхлэх эсвэл өөрчлөлт оруулах.
Бид юуг зорьж байна вэ?
Доор жагсаасан бүх зүйл бол хийсвэр бодол биш, харин хамгийн багадаа эхний алхмуудыг хийсэн зүйл юм.
- Аномали илрүүлэгч. Бид Графит хадгалах сан руугаа орж хэмжигдэхүүн бүрийг янз бүрийн алгоритм ашиглан шалгах үйлчилгээг бий болгохыг хүсч байна. Бидний үзэхийг хүссэн алгоритмууд аль хэдийн байгаа, өгөгдөл байгаа, бид түүнтэй хэрхэн ажиллахаа мэддэг.
- Мета өгөгдөл. Манайд олон үйлчилгээ байдаг, тэдэнтэй ажилладаг хүмүүс шиг цаг хугацааны явцад өөрчлөгддөг. Баримт бичгийг гараар байнга хөтлөх нь сонголт биш юм. Тийм ч учраас бид одоо мета өгөгдлийг микро үйлчилгээндээ оруулж байна. Энэ нь үүнийг хэн боловсруулсан, харилцдаг хэл, SLA шаардлага, хаана, хэнд мэдэгдэл илгээх ёстойг заадаг. Үйлчилгээг ашиглах үед аж ахуйн нэгжийн бүх өгөгдлийг бие даан үүсгэдэг. Үүний үр дүнд та хоёр холбоосыг авах болно - нэг нь триггер, нөгөө нь Графана дахь хяналтын самбар.
- Айл бүрт хяналт тавьдаг. Бүх хөгжүүлэгчид ийм системийг ашиглах ёстой гэж бид үзэж байна. Энэ тохиолдолд та замын хөдөлгөөн хаана байгаа, түүнд юу тохиолдох, хаана унах, сул тал нь хаана байгааг үргэлж ойлгодог. Жишээлбэл, ямар нэг зүйл ирж, таны үйлчилгээ эвдэрсэн бол та менежерийн дуудлагын үеэр биш харин сэрэмжлүүлгээс энэ талаар мэдэж авах бөгөөд та хамгийн сүүлийн үеийн бүртгэлийг нэн даруй нээж, тэнд юу болсныг харах боломжтой.
- Маш сайн гүйцэтгэл. Манай төсөл байнга хөгжиж байгаа бөгөөд өнөөдөр минутанд 2 метрийн утгыг боловсруулж байна. Жилийн өмнө энэ тоо 000 байсан бөгөөд өсөлт үргэлжилсээр байгаа бөгөөд энэ нь хэсэг хугацааны дараа Графит (шивнэх) дискний дэд системийг их хэмжээгээр ачаалж эхэлнэ гэсэн үг юм. Би аль хэдийн хэлсэнчлэн энэхүү хяналтын систем нь бүрэлдэхүүн хэсгүүдийг сольж чаддаг тул нэлээд түгээмэл байдаг. Хэн нэгэн нь графитад зориулж дэд бүтцээ хадгалж, байнга өргөжүүлдэг боловч бид өөр замаар явахаар шийдсэн: ашиглах бидний хэмжүүрүүдийн агуулах болгон. Энэ шилжилт нь бараг дуусч байгаа бөгөөд тун удахгүй би үүнийг хэрхэн яаж хийснийг илүү нарийвчлан хэлэх болно: ямар бэрхшээл тулгарсан, тэдгээрийг хэрхэн даван туулсан, шилжих үйл явц хэрхэн явагдсан, би сонгосон бүрэлдэхүүн хэсгүүд болон тэдгээрийн тохиргоог тайлбарлах болно.
Анхаарал тавьсанд баярлалаа! Сэдвийн талаар асуулт асуугаарай, би энд эсвэл дараах нийтлэлүүдэд хариулахыг хичээх болно. Магадгүй хэн нэгэн ижил төстэй хяналтын системийг бий болгох эсвэл үүнтэй төстэй нөхцөл байдалд Clickhouse руу шилжих туршлагатай байж магадгүй - үүнийг сэтгэгдэл дээр хуваалцаарай.
Эх сурвалж: www.habr.com