Намайг Антон Бадерин гэдэг. Би Өндөр технологийн төвд ажилладаг, системийн удирдлага хийдэг. Сарын өмнө бидний хуримтлуулсан туршлагаа хотынхоо мэдээллийн технологийн нийгэмлэгтэй хуваалцсан байгууллагын хурал өндөрлөлөө. Би вэб програмуудыг хянах талаар ярьсан. Материал нь энэ үйл явцыг эхнээс нь бүтээгээгүй бага эсвэл дунд түвшний хүмүүст зориулагдсан байв.
Аливаа хяналтын тогтолцооны үндэс нь бизнесийн асуудлыг шийдвэрлэхэд оршино. Хяналтын төлөө хяналт тавих нь хэнд ч сонирхолгүй. Бизнес юу хүсдэг вэ? Ингэснээр бүх зүйл хурдан бөгөөд алдаагүй ажиллах болно. Бизнесүүд идэвхтэй байхыг хүсдэг бөгөөд ингэснээр бид өөрсдөө үйлчилгээнд тулгарч буй асуудлуудыг тодорхойлж, аль болох хурдан засах болно. Үнэн хэрэгтээ эдгээр нь өнгөрсөн жил миний үйлчлүүлэгчдийн нэг төсөл дээр шийдсэн асуудлууд юм.
Төслийн тухай
Энэхүү төсөл нь тус улсын хамгийн том үнэнч хөтөлбөрүүдийн нэг юм. Бид урамшууллын карт гэх мэт янз бүрийн маркетингийн хэрэгслээр дамжуулан жижиглэн худалдааны сүлжээнүүдэд борлуулалтын давтамжийг нэмэгдүүлэхэд тусалдаг. Төсөлд нийтдээ арван сервер дээр ажилладаг 14 программ багтсан байна.
Ярилцлагын явцад админууд вэб програмуудыг хянахад үргэлж зөв ханддаггүйг би олон удаа анзаарсан: ихэнх нь үйлдлийн системийн хэмжигдэхүүнд анхаарлаа хандуулж, хааяа үйлчилгээнүүдийг хянадаг.
Миний хувьд хэрэглэгчийн хяналтын систем өмнө нь Icinga дээр суурилсан байсан. Дээрх асуудлуудыг ямар ч байдлаар шийдэж чадаагүй. Ихэнхдээ үйлчлүүлэгч өөрөө бидэнд асуудлын талаар мэдээлдэг байсан бөгөөд ихэнхдээ бид шалтгааныг ойлгоход хангалттай мэдээлэлгүй байсан.
Нэмж дурдахад түүний цаашдын хөгжил нь дэмий хоосон гэдгийг тодорхой ойлгосон. Icinga-г мэддэг хүмүүс намайг ойлгох байх гэж бодож байна. Тиймээс бид төслийн вэб програмын хяналтын системийг бүрэн шинэчлэн боловсруулахаар шийдсэн.
Prometheus
Бид Прометейг гурван үндсэн үзүүлэлтээр сонгосон.
- Маш олон тооны боломжтой хэмжүүрүүд. Манайд 60 мянга байгаа. Мэдээжийн хэрэг, бид тэдгээрийн дийлэнх хэсгийг (95% орчим) ашигладаггүй гэдгийг тэмдэглэх нь зүйтэй. Нөгөөтэйгүүр, тэд бүгд харьцангуй хямд байдаг. Бидний хувьд энэ нь өмнө нь хэрэглэж байсан Icinga-тай харьцуулахад нөгөө туйл юм. Үүнд хэмжүүр нэмэх нь маш их зовлон байсан: одоо байгаа нь үнэтэй байсан (ямар ч залгаасын эх кодыг хараарай). Аливаа залгаас нь Bash эсвэл Python хэл дээрх скрипт байсан бөгөөд үүнийг эхлүүлэх нь зарцуулсан нөөцийн хувьд үнэтэй байдаг.
- Энэ систем нь харьцангуй бага хэмжээний нөөц зарцуулдаг. 600 MB RAM, нэг цөмийн 15%, хэдэн арван IOPS нь бидний бүх үзүүлэлтэд хангалттай. Мэдээжийн хэрэг, та хэмжүүр экспортлогчдыг ажиллуулах хэрэгтэй, гэхдээ тэдгээр нь бүгд Go-д бичигдсэн байдаг бөгөөд бас эрчим хүчний өлсгөлөн биш юм. Орчин үеийн бодит байдалд энэ нь асуудал биш гэж би бодохгүй байна.
- Kubernetes руу шилжих боломжийг олгодог. Үйлчлүүлэгчийн төлөвлөгөөг авч үзвэл сонголт нь ойлгомжтой.
ELK
Өмнө нь бид лог цуглуулдаггүй, боловсруулдаггүй байсан. Алдаа дутагдал нь бүгдэд ойлгомжтой. Бид энэ системийг ашиглаж байсан туршлагатай учраас ELK-ийг сонгосон. Бид тэнд зөвхөн програмын бүртгэлийг хадгалдаг. Сонгон шалгаруулалтын гол шалгуур нь бүрэн текст хайлт, түүний хурд байв.
Сlickhouse
Эхэндээ сонголт нь InfluxDB дээр унасан. Бид Nginx бүртгэл, pg_stat_statements-аас статистик мэдээлэл цуглуулж, Prometheus-ийн түүхэн өгөгдлийг хадгалах хэрэгтэйг ойлгосон. Бид Influx-д дургүй байсан, учир нь энэ нь үе үе их хэмжээний санах ойг хэрэглэж, гацаж эхэлдэг. Нэмж дурдахад, би асуулгыг remote_addr-аар бүлэглэхийг хүссэн боловч энэ DBMS-д зөвхөн шошгуудаар бүлэглэх боломжтой. Шошго нь үнэтэй (санах ой), тэдгээрийн тоо нь нөхцөлт хязгаарлагдмал байдаг.
Бид дахин хайлтаа эхлүүлсэн. Хамгийн бага нөөц зарцуулалттай аналитик мэдээллийн сан шаардлагатай байсан бөгөөд дискэн дээрх өгөгдлийг шахах нь дээр.
Clickhouse нь эдгээр бүх шалгуурыг хангасан бөгөөд бид сонголтондоо хэзээ ч харамсдаггүй. Бид үүнд ер бусын хэмжээний өгөгдөл бичдэггүй (оруулах тоо минутанд ердөө таван мянга орчим байдаг).
NewRelic
NewRelic нь үйлчлүүлэгчийн сонголт байсан учраас бидэнтэй хамт байсан түүхтэй. Бид үүнийг APM болгон ашигладаг.
Заббик
Бид Zabbix-ийг зөвхөн төрөл бүрийн API-ийн хар хайрцгийг хянах зорилгоор ашигладаг.
Хяналтын арга барилыг тодорхойлох
Бид даалгаврыг задалж, улмаар мониторинг хийх арга барилыг системчлэхийг хүссэн.
Үүнийг хийхийн тулд би системээ дараах түвшинд хуваасан.
- техник хангамж ба VMS;
- үйлдлийн систем;
- системийн үйлчилгээ, програм хангамжийн стек;
- өргөдөл;
- бизнесийн логик.
Энэ арга яагаад тохиромжтой вэ:
- түвшин бүрийн ажлыг хэн хариуцаж байгааг бид мэддэг бөгөөд үүний үндсэн дээр бид анхааруулга илгээх боломжтой;
- Бид дохиог дарахдаа уг бүтцийг ашиглаж болно - виртуал машин бүхэлдээ боломжгүй үед мэдээллийн сан байхгүй байгаа тухай анхааруулга илгээх нь хачирхалтай байх болно.
Бидний даалгавар бол системийн үйл ажиллагааны зөрчлийг тодорхойлох явдал тул бид дохиоллын дүрмийг бичихдээ анхаарах ёстой тодорхой хэмжүүрүүдийг түвшин бүрт онцлон тэмдэглэх ёстой. Дараа нь "VMS", "Үйлдлийн систем" болон "Системийн үйлчилгээ, програм хангамжийн стек" гэсэн түвшингүүдийг авч үзье.
Виртуал машинууд
Хостинг бидэнд процессор, диск, санах ой, сүлжээг хуваарилдаг. Тэгээд бид эхний хоёрт асуудалтай байсан. Тиймээс, хэмжүүрүүд:
CPU хулгайлагдсан цаг - та Amazon дээр виртуал машин худалдаж авахдаа (жишээлбэл, t2.micro) танд процессорын цөмийг бүхэлд нь хуваарилдаггүй, харин зөвхөн тухайн үеийн квотыг хуваарилдаг гэдгийг ойлгох хэрэгтэй. Мөн та үүнийг шавхах үед процессорыг танаас салгах болно.
Энэхүү хэмжүүр нь ийм мөчүүдийг хянаж, шийдвэр гаргах боломжийг олгодог. Жишээлбэл, илүү тарган тариф авах эсвэл суурь даалгавар болон API хүсэлтийн боловсруулалтыг өөр өөр серверүүдэд түгээх шаардлагатай юу?
IOPS + CPU iowait цаг - ямар нэг шалтгааны улмаас олон клоуд хостинг хангалттай IOPS хангаагүйгээс нүгэл үйлддэг. Түүнээс гадна IOPS багатай хуваарь нь тэдний хувьд маргаан биш юм. Тиймээс CPU iowait цуглуулах нь зүйтэй юм. Энэ хос графикаар - бага IOPS, өндөр I/O хүлээлттэй - та аль хэдийн хостингтой ярилцаж, асуудлыг шийдэж чадна.
үйлдлийн систем
Үйлдлийн системийн үзүүлэлтүүд:
- боломжтой санах ойн хэмжээ %;
- swap ашиглалтын үйл ажиллагаа: vmstat swapin, swapout;
- боломжтой инодын тоо болон файлын систем дээрх сул зай%
- дундаж ачаалал;
- tw төлөв дэх холболтын тоо;
- хүснэгтийн бүрэн байдлыг хянах;
- Сүлжээний чанарыг ss хэрэгсэл, iproute2 багц ашиглан хянах боломжтой - түүний гаралтаас RTT холболтын үзүүлэлтийг авч, dest портоор нь бүлэглээрэй.
Мөн үйлдлийн системийн түвшинд бид процесс гэх мэт байгууллагатай байдаг. Системд түүний үйл ажиллагаанд чухал үүрэг гүйцэтгэдэг процессуудын багцыг тодорхойлох нь чухал юм. Жишээлбэл, танд хэд хэдэн pgpool байгаа бол та тэдгээрийн талаар мэдээлэл цуглуулах хэрэгтэй.
Хэмжилтийн багц нь дараах байдалтай байна.
- CPU-ууд;
- санах ой нь үндсэндээ оршин суудаг;
- IO - IOPS-д илүү тохиромжтой;
- FileFd - нээх ба хязгаарлах;
- хуудасны чухал алдаа - ингэснээр та ямар процесс солигдож байгааг ойлгох боломжтой.
Бид Docker дээр бүх хяналтыг байрлуулж, хэмжүүрийн өгөгдлийг цуглуулахын тулд зөвлөхийг ашигладаг. Бусад машинууд дээр бид процесс-экспортлогчийг ашигладаг.
Системийн үйлчилгээ, програм хангамжийн стек
Аппликейшн бүр өөрийн гэсэн онцлогтой бөгөөд тодорхой хэмжүүрийг ялгахад хэцүү байдаг.
Бүх нийтийн багц нь:
- хүсэлтийн хувь хэмжээ;
- алдааны тоо;
- саатал;
- ханасан байдал.
Энэ түвшний мониторингийн хамгийн тод жишээ бол Nginx болон PostgreSQL юм.
Манай системд хамгийн их ачаалалтай үйлчилгээ бол мэдээллийн сан юм. Өмнө нь бид мэдээллийн сан юу хийж байгааг олж мэдэхэд бэрхшээлтэй тулгардаг байсан.
Бид дискний ачаалал их байгааг харсан боловч удаан бүртгэлүүд нь үнэндээ юу ч харуулаагүй. Бид асуулгын статистикийг цуглуулдаг pg_stat_statements-ийг ашиглан энэ асуудлыг шийдсэн.
Энэ бол админд хэрэгтэй зүйл юм.
Бид унших, бичих хүсэлтийн үйл ажиллагааны графикийг бүтээдэг.
Бүх зүйл энгийн бөгөөд ойлгомжтой, хүсэлт бүр өөрийн гэсэн өнгөтэй байдаг.
Үүний нэгэн адил гайхалтай жишээ бол Nginx бүртгэл юм. Цөөхөн хүн тэдгээрийг задлан шинжилж, заавал байх ёстой зүйлсийн жагсаалтад дурддаг нь гайхах зүйл биш юм. Стандарт формат нь мэдээлэл сайтай биш бөгөөд үүнийг өргөжүүлэх шаардлагатай.
Би хувьдаа хүсэлтийн_цаг, урсгалын_хариултын_цаг, илгээсэн_байтын_байт, хүсэлтийн_урт, хүсэлтийн_id-г нэмсэн. Бид хариу өгөх хугацаа болон алдааны тоог зурсан:
Бид хариу өгөх хугацаа, алдааны тоог графикаар бүтээдэг. Санаж байна уу? Би бизнесийн зорилгын талаар ярьсан уу? Хурдан бөгөөд алдаагүй байх уу? Эдгээр асуудлуудыг бид хоёр графикаар аль хэдийн тусгасан. Мөн та тэдгээрийг ашиглан жижүүрийн администраторуудыг аль хэдийн дуудаж болно.
Гэхдээ өөр нэг асуудал хэвээр байна - ослын шалтгааныг хурдан арилгах.
Ослын шийдэл
Асуудлыг тодорхойлохоос эхлээд шийдвэрлэх хүртэлх бүх үйл явцыг хэд хэдэн үе шатанд хувааж болно.
- асуудлыг тодорхойлох;
- жижүүрийн администраторт мэдэгдэл;
- үйл явдалд хариу үйлдэл үзүүлэх;
- шалтгааныг арилгах.
Бид үүнийг аль болох хурдан хийх нь чухал юм. Асуудлыг тодорхойлох, мэдэгдэл илгээх үе шатанд бид их цаг хугацаа хожих боломжгүй - ямар ч тохиолдолд тэдэнд хоёр минут зарцуулагдах болно, дараа нь сайжруулахад зориулж зүгээр л хагалсан талбайнууд болно.
Жижүүрийн утас дуугарлаа гэж бодъё. Тэр юу хийх вэ? Асуултуудын хариултыг хайж олоорой - юу эвдэрсэн, хаана эвдэрсэн, хэрхэн хариу үйлдэл үзүүлэх вэ? Бид эдгээр асуултад хэрхэн хариулахыг эндээс үзнэ үү.
Бид энэ бүх мэдээллийг мэдэгдлийн текстэнд оруулаад, энэ асуудлыг хэрхэн шийдвэрлэх, хэрхэн шийдвэрлэх, өргөжүүлэх талаар тайлбарласан вики хуудасны холбоосыг өгнө.
Би хэрэглээний давхарга болон бизнесийн логикийн талаар юу ч хэлээгүй байна. Харамсалтай нь манай програмууд хэмжүүр цуглуулах хараахан хэрэгжүүлээгүй байна. Эдгээр түвшний аливаа мэдээллийн цорын ганц эх сурвалж нь бүртгэл юм.
Хэдэн оноо.
Нэгдүгээрт, бүтэцлэгдсэн бүртгэлийг бич. Мессежийн текстэнд контекст оруулах шаардлагагүй. Энэ нь тэднийг бүлэглэх, дүн шинжилгээ хийхэд хэцүү болгодог. Logstash энэ бүхнийг хэвийн болгоход удаан хугацаа зарцуулдаг.
Хоёрдугаарт, хүндийн түвшинг зөв ашиглах. Хэл бүр өөрийн гэсэн стандарттай. Би хувьдаа дөрвөн түвшинг ялгадаг.
- алдаа байхгүй;
- үйлчлүүлэгчийн алдаа;
- алдаа бидний талд байна, бид мөнгө алдахгүй, эрсдэл хүлээхгүй;
- Алдаа нь бидний талд, бид мөнгө алддаг.
Ингээд товчлон хэлье. Бизнесийн логик дээр тулгуурлан хяналт тавихыг хичээх хэрэгтэй. Аппликешныг өөрөө хянаж, борлуулалтын тоо, шинэ хэрэглэгчийн бүртгэлийн тоо, одоогийн идэвхтэй хэрэглэгчдийн тоо гэх мэт хэмжүүрээр ажиллахыг хичээгээрэй.
Хэрэв таны бизнес бүхэлдээ хөтчийн нэг товчлуур байвал энэ нь дарж, зөв ажиллаж байгаа эсэхийг хянах хэрэгтэй. Үлдсэн нь хамаагүй.
Хэрэв танд ийм зүйл байхгүй бол та бидний хийсэн шиг програмын бүртгэл, Nginx бүртгэл гэх мэтээр үүнийг гүйцээхийг оролдож болно. Та програмтай аль болох ойр байх ёстой.
Үйлдлийн системийн хэмжүүрүүд нь мэдээжийн хэрэг чухал, гэхдээ бизнес үүнийг сонирхдоггүй, бид үүнийг төлдөггүй.
Эх сурвалж: www.habr.com