Мониторинг үхсэн үү? -Хяналт урт наслаарай

2008 оноос хойш манай компани нь үндсэндээ дэд бүтцийн менежмент, вэб төслүүдэд өдөр бүр техникийн дэмжлэг үзүүлэх чиглэлээр ажилладаг: бид 400 гаруй үйлчлүүлэгчтэй бөгөөд энэ нь Оросын цахим худалдааны 15 орчим хувийг эзэлдэг. Үүний дагуу маш олон төрлийн архитектурыг дэмждэг. Хэрэв ямар нэг зүйл унавал бид 15 минутын дотор засах үүрэгтэй. Гэхдээ осол гарсан гэдгийг ойлгохын тулд та төслийг хянаж, зөрчилд хариу өгөх хэрэгтэй. Үүнийг яаж хийх вэ?

Хяналтын тогтолцоог зөв зохион байгуулахад асуудал байгаа гэж үзэж байна. Хэрэв ямар ч асуудал гараагүй байсан бол миний яриа "Prometheus + Grafana болон 1, 2, 3 залгаасуудыг суулгана уу" гэсэн нэг диссертациас бүрдэх байсан. Харамсалтай нь энэ нь цаашид ийм байдлаар ажиллахгүй байна. Хамгийн гол асуудал бол хүн бүр програм хангамжийн бүрэлдэхүүн хэсгүүдийн хувьд 2008 онд байсан зүйлд итгэдэг хэвээр байгаа явдал юм.

Хяналтын системийн зохион байгуулалтын тухайд би... чадварлаг хяналттай төсөл байхгүй гэж хэлмээр байна. Нөхцөл байдал маш муу байгаа тул хэрэв ямар нэг зүйл унавал анзаарагдахгүй байх эрсдэлтэй - эцэст нь хүн бүр "бүх зүйлийг хянаж байгаа" гэдэгт итгэлтэй байна.
Магадгүй бүх зүйлийг хянаж байгаа байх. Гэхдээ яаж?

Бид бүгдээрээ дараахтай төстэй түүхтэй тулгарсан: тодорхой devops, тодорхой админ ажиллаж байна, хөгжүүлэлтийн баг тэдэн дээр ирээд "бид суллагдсан, одоо хяналт тавина" гэж хэлдэг. Юуг хянах вэ? Хэрхэн ажилладаг?

БОЛЖ БАЙНА УУ. Бид хуучин хэв маягийг хянадаг. Энэ нь аль хэдийн өөрчлөгдөж байгаа бөгөөд та C үйлчилгээтэй харилцдаг В үйлчилгээ болсон А үйлчилгээг хянаж байсан нь тогтоогдсон. Гэхдээ хөгжүүлэлтийн баг танд: "Програм хангамжийг суулга, тэр бүгдийг хянах ёстой!"

Тэгэхээр юу өөрчлөгдсөн бэ? - Бүх зүйл өөрчлөгдсөн!

2008 он Бүх зүйл сайхан байна

Хэдэн хөгжүүлэгчид, нэг сервер, нэг мэдээллийн сангийн сервер байдаг. Бүх зүйл эндээс гардаг. Бидэнд зарим мэдээлэл байгаа, бид zabbix, Nagios, cacti суулгадаг. Дараа нь бид CPU, дискний ажиллагаа, дискний зай дээр тодорхой анхааруулга тавьдаг. Мөн бид сайтад хариу өгч, захиалга мэдээллийн санд ирж байгаа эсэхийг шалгахын тулд хэд хэдэн гарын авлагын шалгалт хийдэг. Ингээд л бид их эсвэл бага хамгаалагдсан.

Хэрэв бид тухайн үед администраторын хяналт тавихын тулд хийсэн ажлын хэмжээг харьцуулж үзвэл түүний 98% нь автомат байсан: хяналтыг хийж байгаа хүн Zabbix-ийг хэрхэн суулгах, хэрхэн тохируулах, сэрэмжлүүлгийг тохируулах талаар ойлгох ёстой. Мөн 2% - гадны шалгалтын хувьд: сайт хариу өгч, мэдээллийн санд хүсэлт гаргадаг, шинэ захиалга ирсэн.

2010 он Ачаалал нэмэгдэж байна

Бид хайлтын системийг нэмж вэбийг өргөжүүлж эхэлж байна. Бүтээгдэхүүний каталогид бүх бүтээгдэхүүнийг багтаасан эсэхийг шалгахыг хүсч байна. Мөн энэ бүтээгдэхүүний хайлт ажилладаг. Мэдээллийн сан ажиллаж байгаа, захиалга хийгдэж байгаа, сайт нь гаднаас хариу өгч, хоёр серверээс хариу өгдөг, өөр сервер рүү тэнцвэржүүлсэн үед хэрэглэгч сайтаас хөөгддөггүй гэх мэт. Илүү олон байгууллага бий.

Түүгээр ч барахгүй дэд бүтэцтэй холбоотой байгууллага нь менежерийн толгойд байгаа хамгийн том байгууллага хэвээр байна. Мониторинг хийж байгаа хүн нь zabbix суулгаад тохиргоо хийх чадвартай хүн юм байна гэсэн бодол толгойд байсаар байна.

Гэхдээ үүнтэй зэрэгцэн гадаад шалгалт хийх, хайлтын индексжүүлэгч асуулгын скриптүүдийн багц, индексжүүлэх явцад хайлт өөрчлөгдөж байгаа эсэхийг шалгах скриптүүдийн багц, бараа шилжүүлсэн эсэхийг шалгах скриптүүдийн багц зэрэг ажил гарч байна. хүргэлтийн үйлчилгээ гэх мэт. гэх мэт.

Жич: Би 3 удаа “цуврал скрипт” бичсэн. Өөрөөр хэлбэл, хяналт тавих үүрэгтэй хүн нь зүгээр л zabbix суулгадаг хүн байхаа больсон. Энэ бол код бичиж эхэлдэг хүн юм. Гэхдээ багийн оюун санаанд одоохондоо юу ч өөрчлөгдөөгүй байна.

Гэвч дэлхий өөрчлөгдөж, улам бүр төвөгтэй болж байна. Виртуалчлалын давхарга болон хэд хэдэн шинэ систем нэмэгдсэн. Тэд бие биетэйгээ харьцаж эхэлдэг. "Бичил үйлчилгээ шиг үнэртэй" гэж хэн хэлсэн бэ? Гэхдээ үйлчилгээ тус бүр нь тусдаа вэбсайт шиг харагддаг. Бид түүн рүү хандаж, шаардлагатай мэдээллээр хангаж, бие даан ажилладаг гэж ойлгож болно. Хэрэв та 5-7-10 жилийн турш хөгжиж буй төсөлд байнга оролцдог администратор бол энэ мэдлэг хуримтлагддаг: шинэ түвшин гарч ирдэг - та үүнийг ойлгосон, өөр түвшин гарч ирдэг - та үүнийг ойлгосон ...

Гэхдээ 10 жил төсөл дагалддаг хүн ховор.

Monitoringman-ийн анкет

Та 20 хөгжүүлэгчийг шууд ажилд авсан, 15 микро үйлчилгээ бичсэн шинэ стартап дээр ирсэн бөгөөд та админ: "CI/CD-г бүтээх. Гуйя." Та CI/CD-г бүтээсэн бөгөөд гэнэт та: "Бидэнд програм хэрхэн ажиллахыг ойлгохгүйгээр "шоо" дахь үйлдвэрлэлтэй ажиллахад хэцүү байна. Биднийг ижил "шоо" дотор хамгаалагдсан хязгаарлагдмал орчин болго.
Та энэ шоо дотор хамгаалагдсан хязгаарлагдмал орчин хийдэг. Тэд шууд танд: "Бид үйлдвэрлэлийн мэдээллийн сан дээр ажилладаг боловч үйлдвэрлэлийн мэдээллийн санг сүйтгэхгүй байхын тулд өдөр бүр шинэчлэгддэг тайзны мэдээллийн санг хүсч байна."

Та энэ бүхэнд амьдардаг. Гаргахад 2 долоо хоног үлдлээ, тэд танд: "Одоо энэ бүгдийг хянаж үзье ..." гэж хэлдэг. кластерийн дэд бүтцэд хяналт тавих, микро үйлчилгээний архитектурт хяналт тавих, гадны үйлчилгээтэй ажиллахад хяналт тавих...

Манай хамт олон ердийн схемийг толгойноосоо салгаад: "За, энд бүх зүйл тодорхой байна! Энэ бүхнийг хянадаг программ суулгаарай.” Тийм, тийм: Prometheus + Grafana + залгаасууд.
Тэд "Танд хоёр долоо хоног байна, бүх зүйл аюулгүй байгаа эсэхийг шалгаарай."

Бидний харж байгаа маш олон төсөл дээр нэг хүн хяналт тавихаар хуваарилдаг. Бид 2 долоо хоногийн турш мониторинг хийх хүнийг ажилд авахыг хүсч байгаа бөгөөд бид түүнд анкет бичдэг гэж төсөөлөөд үз дээ. Өнөөг хүртэл бидний хэлсэн бүх зүйлийг харгалзан үзвэл энэ хүн ямар чадвартай байх ёстой вэ?

• Тэрээр төмрийн дэд бүтцийн үйл ажиллагааны хяналт, онцлогийг ойлгох ёстой.
• Тэрээр Кубернетесийг хянах онцлогийг ойлгох ёстой (мөн хүн бүр "шоо" руу орохыг хүсдэг, учир нь та бүх зүйлээс хийсвэрлэж, нуугдаж болно, учир нь админ бусадтай нь харьцах болно) - өөрөө, түүний дэд бүтцийг, програмуудыг хэрхэн хянах талаар ойлгох ёстой. дотор.
• Тэрээр үйлчилгээнүүд хоорондоо тусгай арга замаар харилцдаг гэдгийг ойлгож, үйлчилгээнүүд хоорондоо хэрхэн харьцдаг онцлогийг мэддэг байх ёстой. Өөр арга байхгүй учраас зарим үйлчилгээ синхроноор холбогддог төслийг харах бүрэн боломжтой. Жишээлбэл, арын хэсэг нь REST-ээр, gRPC-ээр дамжуулан каталогийн үйлчилгээ рүү орж, бүтээгдэхүүний жагсаалтыг хүлээн авч, буцааж өгдөг. Та энд хүлээж чадахгүй. Мөн бусад үйлчилгээнүүдийн хувьд энэ нь асинхрон байдлаар ажилладаг. Захиалгыг хүргэх үйлчилгээ рүү шилжүүлэх, захидал илгээх гэх мэт.
  Та энэ бүхнээс аль хэдийн сэлж байсан байх? Үүнийг хянах хэрэгтэй админ нь бүр ч будилсан.
• Тэр зөв төлөвлөж, төлөвлөж чаддаг байх ёстой - ажил улам бүр нэмэгдэх тусам.
• Тиймээс тэрээр үүнийг хэрхэн тусгайлан хянах талаар ойлгохын тулд үүсгэсэн үйлчилгээнээс стратеги бий болгох ёстой. Түүнд төслийн архитектур, түүний хөгжлийн талаархи ойлголт + боловсруулахад ашигласан технологийн талаархи ойлголт хэрэгтэй.

Нэгэн хэвийн тохиолдлыг санацгаая: зарим үйлчилгээ нь PHP дээр, зарим үйлчилгээ нь Go дээр, зарим үйлчилгээ нь JS дээр байдаг. Тэд ямар нэгэн байдлаар бие биетэйгээ ажилладаг. "Бичил үйлчилгээ" гэсэн нэр томъёо эндээс гаралтай: маш олон бие даасан системүүд байдаг тул хөгжүүлэгчид төслийг бүхэлд нь ойлгох боломжгүй байдаг. Багийн нэг хэсэг нь JS дээр бие даан ажилладаг үйлчилгээг бичдэг ба бусад систем хэрхэн ажилладагийг мэдэхгүй. Нөгөө хэсэг нь үйлчилгээнүүдийг Python хэл дээр бичдэг бөгөөд бусад үйлчилгээ хэрхэн ажиллахад саад учруулдаггүй бөгөөд тэдгээр нь өөрийн гэсэн хэсэгт тусгаарлагдсан байдаг. Гурав дахь нь PHP эсвэл өөр зүйл дээр үйлчилгээ бичих явдал юм.
Энэ 20 хүн бүгд 15 үйлчилгээнд хуваагдсан бөгөөд энэ бүгдийг ойлгох ёстой админ нь нэг л байна. Зогс! 15 хүн системийг бүхэлд нь ойлгож чадахгүй байгаа тул бид системийг 20 микро үйлчилгээнд хуваасан.

Гэхдээ ямар нэгэн байдлаар хяналт тавих хэрэгтэй ...

Үр дүн нь юу вэ? Үүний үр дүнд хөгжүүлэгчдийн бүх багийн ойлгохгүй байгаа бүх зүйлийг гаргаж ирдэг нэг хүн байдаг бөгөөд тэр бас бидний дээр дурдсан зүйлийг мэдэж, хийх чадвартай байх ёстой - техник хангамжийн дэд бүтэц, Кубернетес дэд бүтэц гэх мэт.

Би юу хэлэх вэ... Хьюстон, бидэнд асуудал байна.

Орчин үеийн програм хангамжийн төслийг хянах нь өөрөө програм хангамжийн төсөл юм

Хяналт нь программ хангамж гэсэн худал итгэл үнэмшлээс бид гайхамшгуудад итгэх итгэлийг бий болгодог. Гэвч гайхамшгууд харамсалтай нь тохиолддоггүй. Та zabbix суулгаж, бүх зүйл ажиллахыг хүлээх боломжгүй. Графана суулгаад бүх зүйл сайхан болно гэж найдах нь утгагүй юм. Ихэнх цагийг үйлчилгээний үйл ажиллагаа, тэдгээрийн харилцан үйлчлэлийг шалгах ажлыг зохион байгуулах, гадаад систем хэрхэн ажиллаж байгааг шалгахад зарцуулагдана. Үнэн хэрэгтээ цагийн 90% нь скрипт бичихэд бус, харин програм хангамж боловсруулахад зарцуулагдах болно. Мөн төслийн ажлыг ойлгодог баг үүнийг зохицуулах ёстой.
Ийм нөхцөлд нэг хүн хяналтад орвол гамшиг болно. Энэ нь хаа сайгүй тохиолддог зүйл юм.

Жишээлбэл, Кафкагаар дамжуулан өөр хоорондоо харилцдаг хэд хэдэн үйлчилгээ байдаг. Захиалга ирлээ, бид Кафка руу захиалгын тухай мессеж илгээв. Захиалгын талаарх мэдээллийг сонсож, бараа ачуулдаг үйлчилгээ байдаг. Захиалгын талаарх мэдээллийг сонсож, хэрэглэгч рүү захидал илгээдэг үйлчилгээ бий. Дараа нь хэд хэдэн үйлчилгээ гарч ирэхэд бид эргэлзэж эхэлдэг.

Хэрэв та үүнийг гаргахад багахан хугацаа үлдсэн үе шатанд админ болон хөгжүүлэгчдэд өгвөл тэр хүн энэ протоколыг бүхэлд нь ойлгох хэрэгтэй болно. Тэдгээр. Ийм хэмжээний төсөл нь ихээхэн цаг хугацаа шаарддаг бөгөөд үүнийг системийн хөгжилд тооцох ёстой.
Гэхдээ ихэнхдээ, ялангуяа стартапуудад бид хяналт тавих ажлыг хожим нь хойшлуулж байгааг хардаг. "Одоо бид үзэл баримтлалын нотолгоо хийх болно, бид түүнтэй хамт хөөргөх болно, түүнийг унагах болно - бид золиослоход бэлэн байна. Дараа нь бид бүгдэд нь хяналт тавина." Төсөл мөнгө олж эхлэхэд (эсвэл) бизнес нь илүү олон боломжуудыг нэмэхийг хүсдэг - учир нь энэ нь ажиллаж эхэлсэн тул үүнийг цаашид хөгжүүлэх шаардлагатай байна! Та эхлээд өмнөх бүх зүйлээ хянах хэрэгтэй бөгөөд энэ нь цаг хугацааны 1% биш, харин илүү ихийг шаарддаг. Дашрамд хэлэхэд, хөгжүүлэгчид хяналт тавихад шаардлагатай бөгөөд шинэ функцууд дээр ажиллахыг зөвшөөрөх нь илүү хялбар болно. Үүний үр дүнд шинэ боломжууд бичигдэж, бүх зүйл эвдэрч, та эцэс төгсгөлгүй мухардалд орно.

Тэгэхээр төслийг эхнээс нь хэрхэн хянах вэ, танд хяналт тавих шаардлагатай төсөл ирсэн ч хаанаас эхлэхээ мэдэхгүй байгаа бол яах вэ?

Эхлээд та төлөвлөх хэрэгтэй.

Уянгын хазайлт: ихэнхдээ тэд дэд бүтцийн хяналтаас эхэлдэг. Жишээлбэл, бидэнд Kubernetes байна. Prometheus-ийг Grafana-тай суулгаж, "шоо"-г хянах нэмэлт өргөтгөлүүдийг суулгаж эхэлцгээе. Зөвхөн хөгжүүлэгчид төдийгүй администраторуудад "Бид энэ залгаасыг суулгах болно, гэхдээ залгаас үүнийг хэрхэн хийхийг мэддэг байх." Хүмүүс чухал үйлдлээс илүү энгийн бөгөөд энгийн зүйлээс эхлэх дуртай. Мөн дэд бүтцийн мониторинг хийхэд хялбар байдаг.

Эхлээд юуг, хэрхэн хянахаа шийдээд дараа нь бусад хүмүүс таны өмнөөс бодож чадахгүй тул хэрэглүүрийг сонго. Тэд тэгэх ёстой юу? Бусад хүмүүс бүх нийтийн системийн талаар өөрсөддөө бодсон эсвэл энэ залгаасыг бичихдээ огт бодоогүй. Энэ залгаас нь 5 мянган хэрэглэгчтэй учраас ямар ч ашиг тустай гэсэн үг биш юм. Өмнө нь тэнд 5001 хүн байсан болохоор л та 5000 дэх хүн болох байх.

Хэрэв та дэд бүтцийг хянаж эхэлбэл таны програмын арын хэсэг хариу өгөхөө больсон бол бүх хэрэглэгчид гар утасны програмтай холбоо тасрах болно. Алдаа гарч ирнэ. Тэд чам дээр ирээд "Аппликешн ажиллахгүй байна, чи энд юу хийж байгаа юм бэ?" гэж хэлэх болно. -Бид хяналт тавьж байна. - "Хэрэв та програм ажиллахгүй байгаа бол яаж хянах вэ?!"

1. Та яг хэрэглэгчийн нэвтрэх цэгээс хяналтыг эхлүүлэх хэрэгтэй гэдэгт би итгэж байна. Хэрэв хэрэглэгч програм ажиллаж байгааг харахгүй байгаа бол энэ нь алдаа юм. Мөн хяналтын систем үүнийг эхлээд анхааруулах ёстой.
2. Тэгээд л бид дэд бүтцэд хяналт тавьж чадна. Эсвэл зэрэгцээ хий. Дэд бүтцийн хувьд илүү хялбар байдаг - энд бид эцэст нь zabbix суулгаж болно.
3. Одоо та хаана ажиллахгүй байгааг ойлгохын тулд програмын үндэс рүү очих хэрэгтэй.

Миний гол санаа бол мониторинг нь хөгжлийн явцтай зэрэгцэн явах ёстой. Хэрэв та хяналтын багийнхны анхаарлыг өөр ажилд (CI/CD үүсгэх, хамгаалагдсан хязгаарлагдмал орчинд ашиглах, дэд бүтцийн өөрчлөлт хийх) сатааруулбал мониторинг хоцрогдож эхлэх бөгөөд та хөгжлийг гүйцэхгүй байж магадгүй (эсвэл эрт орой хэзээ нэгэн цагт та үүнийг зогсоох хэрэгтэй болно).

Бүх зүйл түвшингээр

Хяналтын системийн зохион байгуулалтыг би ингэж харж байна.

1) Хэрэглээний түвшин:

• програмын бизнесийн логикийг хянах;
• үйлчилгээний эрүүл мэндийн үзүүлэлтүүдийг хянах;
• интеграцийн хяналт.

2) Дэд бүтцийн түвшин:

• найрал хөгжмийн түвшний хяналт;
• системийн програм хангамжийн хяналт;
• төмрийн түвшинг хянах.

3) Дахин хэрэглээний түвшин - гэхдээ инженерийн бүтээгдэхүүний хувьд:

• програмын бүртгэлийг цуглуулах, хянах;
• APM;
• мөрдөх.

4) Анхааруулга:

• анхааруулах системийг зохион байгуулах;
• үүргийн тогтолцооны зохион байгуулалт;
• "мэдлэгийн бааз" зохион байгуулалт, ослыг боловсруулах ажлын урсгал.

чухал: Бид сэрэмжлүүлгийг дараа нь биш, тэр даруйд нь авдаг! Хяналтыг эхлүүлж, "ямар нэгэн байдлаар дараа нь" хэн сэрэмжлүүлэг хүлээн авахыг тодорхойлох шаардлагагүй. Эцсийн эцэст, мониторингийн үүрэг юу вэ: системд ямар нэг зүйл буруу ажиллаж байгааг ойлгох, энэ талаар зөв хүмүүст мэдэгдэх. Хэрэв та үүнийг эцэс хүртэл орхих юм бол зөв хүмүүс "бидэнд юу ч ажиллахгүй байна" гэж дуудаж, ямар нэг зүйл буруу байгааг мэдэх болно.

Хэрэглээний давхарга - Бизнесийн логик хяналт

Энд бид програм нь хэрэглэгчийн хувьд ажиллаж байгаа эсэхийг шалгах тухай ярьж байна.

Энэ түвшинг хөгжлийн үе шатанд хийх ёстой. Жишээлбэл, бидэнд нөхцөлт Prometheus байна: энэ нь шалгалт хийдэг сервер рүү очиж, төгсгөлийн цэгийг татаж, төгсгөлийн цэг нь очиж API-г шалгадаг.

Сайт ажиллаж байгаа эсэхийг шалгахын тулд нүүр хуудсаа хянахыг байнга асуухад програмистууд API ажиллаж байгаа эсэхийг шалгах шаардлагатай болгонд татах боломжтой бариул өгдөг. Программистууд одоо болтол /api/test/helloworld-г авч бичсээр байна
Бүх зүйл ажиллаж байгаа эсэхийг шалгах цорын ганц арга зам уу? - Үгүй!

• Ийм шалгалтыг бий болгох нь үндсэндээ хөгжүүлэгчдийн үүрэг юм. Нэгжийн тестийг код бичдэг програмистууд бичих ёстой. Учир нь хэрэв та админ руугаа "Найз минь, энд бүх 25 функцэд зориулсан API протоколуудын жагсаалт байна, бүгдийг хянаж байгаарай!" - юу ч бүтэхгүй.
• Хэрэв та "Сайн уу ертөнц" гэж хэвлэвэл API ажиллах ёстой бөгөөд ажиллах ёстойг хэн ч мэдэхгүй. API-ийн өөрчлөлт бүр шалгалтыг өөрчлөхөд хүргэдэг.
• Хэрэв танд ийм асуудал тулгарсан бол функцуудыг зогсоож, эдгээр шалгалтыг бичих эсвэл алдагдлыг хүлээн зөвшөөрөх хөгжүүлэгчдийг хуваарилж, юу ч шалгагдаагүй бөгөөд амжилтгүй болно гэдгийг хүлээн зөвшөөр.

Техникийн зөвлөмжүүд:

• Шалгалтыг зохион байгуулахын тулд гадны серверийг зохион байгуулахаа мартуузай - таны төсөл гадаад ертөнцөд нэвтрэх боломжтой гэдэгт итгэлтэй байх ёстой.
• Зөвхөн бие даасан төгсгөлийн цэгүүдийг бус API протоколыг бүхэлд нь шалгах ажлыг зохион байгуул.
• Туршилтын үр дүнгийн хамт prometheus-төгсгөлийн цэгийг үүсгэ.

Хэрэглээний давхарга - эрүүл мэндийн хэмжүүрийн хяналт

Одоо бид үйлчилгээний гаднах эрүүл мэндийн хэмжүүрүүдийн талаар ярьж байна.

Бид гадны хяналтын системээс дууддаг гадны шалгалтыг ашиглан програмын бүх "бариулыг" хянахаар шийдсэн. Гэхдээ эдгээр нь хэрэглэгчийн "хардаг" "бариулууд" юм. Манай үйлчилгээнүүд өөрсдөө ажилладаг гэдэгт итгэлтэй баймаар байна. Энэ түүх нь илүү дээр юм: K8s эрүүл мэндийн үзлэгт хамрагдсан тул ядаж "шоо" нь үйлчилгээ ажиллаж байгаа гэдэгт итгэлтэй байх болно. Гэхдээ миний үзсэн чекүүдийн тал хувь нь "Сайн уу ертөнц" гэсэн бичигтэй. Тэдгээр. Тиймээс тэр байрлуулсны дараа нэг удаа татахад бүх зүйл сайхан байна гэж хариулав. Хэрэв үйлчилгээ нь өөрийн API-ээр хангадаг бол ижил API-д зориулсан асар олон тооны нэвтрэх цэгүүд байдаг бөгөөд үүнийг хянах шаардлагатай байдаг, учир нь бид үүнийг ажиллаж байгааг мэдэхийг хүсч байна. Тэгээд бид үүнийг дотроос нь хянаж байгаа.

Техникийн хувьд үүнийг хэрхэн зөв хэрэгжүүлэх вэ: үйлчилгээ тус бүр нь одоогийн гүйцэтгэлийнхээ эцсийн цэгийг илтгэдэг бөгөөд Графана (эсвэл бусад програм) графикаас бид бүх үйлчилгээний статусыг хардаг.

• API-ийн өөрчлөлт бүр шалгалтыг өөрчлөхөд хүргэдэг.
• Эрүүл мэндийн хэмжүүрээр даруй шинэ үйлчилгээг бий болго.
• Админ нь хөгжүүлэгчид дээр ирээд "Надад хэд хэдэн функц нэмээрэй, ингэснээр би бүх зүйлийг ойлгож, хяналтын системдээ энэ талаар мэдээлэл нэмнэ үү" гэж асууж болно. Гэхдээ хөгжүүлэгчид ихэвчлэн "Бид гарахаас хоёр долоо хоногийн өмнө юу ч нэмэхгүй" гэж хариулдаг.
  Ийм алдагдал гарна гэдгийг хөгжлийн менежерүүдэд мэдэгдээрэй, хөгжлийн менежерүүдийн удирдлага ч бас мэдэгдээрэй. Учир нь бүх зүйл унах үед хэн нэгэн залгаж, "байнга унадаг үйлчилгээг" хянахыг шаардах болно (c)
• Дашрамд хэлэхэд, Grafana-д зориулж залгаас бичихийн тулд хөгжүүлэгчдийг хуваарилах - энэ нь админуудад сайн туслах болно.

Хэрэглээний давхарга - Интеграцийн хяналт

Интеграцийн хяналт нь бизнесийн чухал системүүдийн хоорондын харилцаа холбоог хянахад чиглэдэг.

Тухайлбал, өөр хоорондоо харилцдаг 15 үйлчилгээ байдаг. Эдгээр нь тусдаа сайт байхаа больсон. Тэдгээр. Бид үйлчилгээг дангаар нь татаж чадахгүй, /helloworld-г авч, үйлчилгээ ажиллаж байгааг ойлгох болно. Учир нь захиалгын вэб үйлчилгээ нь автобус руу захиалгын талаарх мэдээллийг илгээх ёстой - автобуснаас агуулахын үйлчилгээ нь энэ мессежийг хүлээн авч, цаашид түүнтэй ажиллах ёстой. Имэйл түгээлтийн үйлчилгээ үүнийг ямар нэгэн байдлаар цаашид боловсруулах ёстой гэх мэт.

Иймээс бид тус бүрдээ үйлчилгээ тус бүрийг хараад, энэ бүхэн ажилладаг гэдгийг ойлгож чадахгүй. Учир нь бид бүх зүйл хоорондоо холбогдож, харилцан үйлчилдэг тодорхой автобустай.
Тиймээс энэ үе шат нь бусад үйлчилгээтэй харилцах үйлчилгээг турших үе шатыг тэмдэглэх ёстой. Мессежийн зуучлагчийг хянах замаар харилцааны хяналтыг зохион байгуулах боломжгүй юм. Хэрэв өгөгдөл гаргадаг үйлчилгээ болон түүнийг хүлээн авдаг үйлчилгээ байгаа бол брокерыг хянах үед бид зөвхөн хажуу тийшээ нисдэг өгөгдлийг л харах болно. Хэдийгээр бид ямар нэгэн байдлаар дотооддоо энэ өгөгдлийн харилцан үйлчлэлийг хянаж чадсан ч гэсэн - тодорхой үйлдвэрлэгч өгөгдлийг нийтэлдэг, хэн нэгэн үүнийг уншдаг, энэ урсгал Кафка руу явсаар байна - хэрэв нэг үйлчилгээ нь мессежийг нэг хувилбараар илгээсэн бол энэ нь бидэнд мэдээлэл өгөхгүй. , гэхдээ нөгөө үйлчилгээ нь энэ хувилбарыг хүлээгээгүй бөгөөд алгассан. Үйлчилгээнүүд бүх зүйл ажиллаж байгааг хэлэх тул бид энэ талаар мэдэхгүй.

Би юу хийхийг зөвлөж байна:

• Синхрон холбооны хувьд: эцсийн цэг нь холбогдох үйлчилгээнд хүсэлт гаргадаг. Тэдгээр. Бид энэ төгсгөлийн цэгийг авч, үйлчилгээний доторх скриптийг татах бөгөөд энэ нь бүх цэгүүдэд очиж, "Би тийшээ татна, тийшээ татна, би тийшээ татна ..." гэж бичдэг.
• Асинхрон холбооны хувьд: ирж буй мессежүүд - төгсгөлийн цэг нь автобусанд туршилтын мессеж байгаа эсэхийг шалгаж, боловсруулалтын статусыг харуулдаг.
• Асинхрон холбооны хувьд: гадагшаа мессежүүд - эцсийн цэг нь туршилтын мессежийг автобус руу илгээдэг.

Ердийнх шиг: бидэнд өгөгдөл автобус руу шиддэг үйлчилгээ байдаг. Бид энэ үйлчилгээнд ирж, интеграцийн эрүүл мэндийн талаар бидэнд хэлэхийг хүсч байна. Хэрэв үйлчилгээ нь хаа нэгтээ (WebApp) мессеж гаргах шаардлагатай бол энэ туршилтын мессежийг гаргах болно. Хэрэв бид OrderProcessing тал дээр үйлчилгээ ажиллуулбал эхлээд бие даан нийтэлж болох зүйлээ нийтэлж, хэрэв ямар нэгэн хамааралтай зүйл байвал автобуснаас тестийн багц мессежийг уншиж, тэдгээрийг боловсруулж, мэдээлэх боломжтой гэдгээ ойлгодог. , шаардлагатай бол тэдгээрийг цааш нь нийтэлж, энэ тухай тэр хэлэв - бүх зүйл зүгээр, би амьд байна.

"Бид үүнийг байлдааны өгөгдөл дээр хэрхэн туршиж үзэх вэ?" Гэсэн асуултыг бид ихэвчлэн сонсдог. Жишээлбэл, бид ижил захиалгын үйлчилгээний талаар ярьж байна. Захиалга нь бараагаа хассан агуулах руу мессеж илгээдэг: бид үүнийг байлдааны өгөгдөл дээр туршиж үзэх боломжгүй, учир нь "миний бараа хасагдах болно!" Шийдэл: Энэ бүх тестийг эхнээс нь төлөвлө. Танд бас элэглэл хийдэг нэгжийн тестүүд байна. Тиймээс, бизнесийн үйл ажиллагаанд хор хөнөөл учруулахгүй харилцаа холбооны сувагтай илүү гүнзгий түвшинд хий.

Дэд бүтцийн түвшин

Дэд бүтцийн хяналт гэдэг нь өөрөө хяналт гэж эртнээс үзэж ирсэн зүйл.

• Дэд бүтцийн хяналтыг тусдаа процесс болгон эхлүүлэх боломжтой бөгөөд эхлүүлэх ёстой.
• Та үнэхээр хүсч байгаа ч хэрэгжиж байгаа төслийн дэд бүтцийн хяналтаас эхлэх ёсгүй. Энэ бол бүх хүмүүсийн хувьд зовлон юм. "Эхлээд би кластерт хяналт тавих болно, би дэд бүтцэд хяналт тавих болно" - өөрөөр хэлбэл. Нэгдүгээрт, энэ нь доор юу байгааг хянах боловч програм руу орохгүй. Учир нь програм нь devops-ийн хувьд ойлгомжгүй зүйл юм. Энэ нь түүнд алдагдсан бөгөөд тэр хэрхэн ажилладагийг ойлгохгүй байна. Тэгээд тэр дэд бүтцийг ойлгож, түүнээс эхэлдэг. Гэхдээ үгүй ​​- та эхлээд програмыг хянах хэрэгтэй.
• Сэрэмжлүүлгийн тоог хэтрүүлж болохгүй. Орчин үеийн системийн нарийн төвөгтэй байдлыг харгалзан сэрэмжлүүлэг байнга нисч байдаг бөгөөд та ямар нэгэн байдлаар энэ олон сэрэмжлүүлэгтэй амьдрах хэрэгтэй. Дуудлагын дагуу ирсэн хүн дараагийн хэдэн зуун дохиог хараад "Би энэ талаар бодохыг хүсэхгүй байна" гэж шийднэ. Анхааруулга нь зөвхөн чухал зүйлийн талаар мэдэгдэх ёстой.

Бизнесийн нэгжийн хэрэглээний түвшин

Гол оноо:

• ЭЛК. Энэ бол салбарын стандарт юм. Хэрэв та ямар нэг шалтгааны улмаас бүртгэлийг нэгтгэхгүй байгаа бол нэн даруй хийж эхлээрэй.
• APM. Гадны APM нь програмын хяналтыг хурдан хаах арга юм (NewRelic, BlackFire, Datadog). Та ямар нэгэн байдлаар танд юу болж байгааг ойлгохын тулд энэ зүйлийг түр суулгаж болно.
• Мөшгих. Олон арван бичил үйлчилгээнд та бүх зүйлийг хянах хэрэгтэй, учир нь хүсэлт нь өөрөө амьдрахаа больсон. Дараа нь нэмэхэд маш хэцүү тул хөгжүүлэлтийн явцад мөрдөх ажлыг нэн даруй төлөвлөх нь дээр - энэ бол хөгжүүлэгчдийн ажил, хэрэглүүр юм. Хэрэв та хэрэгжүүлж амжаагүй бол хэрэгжүүлээрэй! Jaeger/Zipkin-г үзнэ үү

Анхааруулж байна

• Мэдэгдэлийн системийн зохион байгуулалт: олон зүйлийг хянах нөхцөлд мэдэгдэл илгээх нэгдсэн систем байх ёстой. Та Grafana-д болно. Баруунд хүн бүр PagerDuty ашигладаг. Анхааруулга нь тодорхой байх ёстой (жишээ нь хаанаас ирсэн ...). Мөн мэдэгдэл хүлээн авч байгаа эсэхийг хянахыг зөвлөж байна
• Үүргийн тогтолцооны зохион байгуулалт: сэрэмжлүүлэгийг хүн бүрт илгээж болохгүй (бүгд бөөнөөрөө хариу үйлдэл үзүүлэх эсвэл хэн ч хариу үйлдэл үзүүлэхгүй). Хөгжүүлэгчид мөн дуудлага хийх хэрэгтэй: хариуцах чиглэлээ тодорхойлж, тодорхой зааварчилгаа өгч, Даваа, Лхагва гаригт яг хэн рүү залгах, Мягмар, Баасан гарагт хэн рүү залгахаа бичээрэй (эсвэл тэд өдөр бүр хэнтэй ч залгахгүй. томоохон асуудлын үйл явдал - тэд таныг сэрээх эсвэл саад болохоос айдаг: хүмүүс ихэвчлэн бусад хүмүүсийг дуудаж, сэрээх дургүй байдаг, ялангуяа шөнийн цагаар). Мөн тусламж хүсэх нь чадваргүйн үзүүлэлт биш гэдгийг тайлбарла ("Би тусламж хүсч байна, энэ нь би муу ажилчин гэсэн үг"), тусламж хүсэхийг дэмж.
• "Мэдлэгийн бааз" зохион байгуулалт, ослыг боловсруулах ажлын явц: ноцтой осол бүрийн хувьд үхлийн дараах ажлыг төлөвлөж, түр зуурын арга хэмжээ болгон ослыг арилгах арга хэмжээг бүртгэх ёстой. Мөн дахин дахин сэрэмжлүүлэх нь нүгэл гэдгийг дадал болгох; тэдгээрийг код эсвэл дэд бүтцийн ажилд засах хэрэгтэй.

Технологийн стек

Бидний стек дараах байдалтай байна гэж төсөөлье.

• мэдээлэл цуглуулах - Prometheus + Grafana;
• бүртгэлийн дүн шинжилгээ - ELK;
• APM эсвэл Tracing-д зориулсан - Jaeger (Зипкин).

Сонголтуудыг сонгох нь чухал биш юм. Учир нь хэрэв та эхэндээ системийг хэрхэн хянахаа ойлгож, төлөвлөгөөгөө бичсэн бол өөрийн шаардлагад нийцсэн хэрэгслийг сонгож эхэлнэ. Асуулт бол та хамгийн түрүүнд юуг хянахаар сонгосон бэ. Учир нь таны сонгосон хэрэгсэл таны шаардлагад огт тохирохгүй байж магадгүй юм.

Сүүлийн үед хаа сайгүй харж байгаа техникийн хэдэн зүйл:

Прометейг Кубернетес дотор шахаж байна - үүнийг хэн гаргасан бэ?! Хэрэв таны кластер сүйрвэл та юу хийх вэ? Хэрэв та дотор нь нарийн төвөгтэй кластер байгаа бол кластер дотор ямар нэгэн хяналтын систем байх ёстой бөгөөд кластер дотроос мэдээлэл цуглуулах гадна талд нь байх ёстой.

Кластер дотор бид лог болон бусад бүх зүйлийг цуглуулдаг. Харин хяналтын систем нь гадаа байх ёстой. Ихэнхдээ Promtheus-ийг дотооддоо суулгасан кластерт сайтын үйл ажиллагааг хөндлөнгийн шалгалт хийдэг системүүд байдаг. Хэрэв таны гадаад ертөнцтэй холбоо тасарч, програм ажиллахгүй бол яах вэ? Дотор нь бүх зүйл сайхан байгаа нь харагдаж байна, гэхдээ энэ нь хэрэглэгчдийн ажлыг хөнгөвчлөхгүй.

үр дүн нь

• Хөгжлийг хянах нь хэрэгслүүдийг суурилуулах биш, харин програм хангамжийн бүтээгдэхүүн боловсруулах явдал юм. Өнөөдрийн мониторингийн 98% нь кодчилол юм. Үйлчилгээнд кодлох, гадаад шалгалтыг кодлох, гадаад үйлчилгээг шалгах гэх мэт.
• Хөгжүүлэгчдийнхээ цагийг хяналтанд бүү үрээрэй: энэ нь тэдний ажлын 30 хүртэлх хувийг авах боломжтой, гэхдээ энэ нь үнэ цэнэтэй юм.
• Девопууд аа, та ямар нэг зүйлийг хянах боломжгүй гэж бүү санаа зов, учир нь зарим зүйл бол огт өөр сэтгэлгээ юм. Та програмист биш байсан бөгөөд хяналт тавих нь тэдний ажил юм.
• Хэрэв төсөл аль хэдийн ажиллаж байгаа бөгөөд хяналтанд ороогүй бол (мөн та менежер бол) хяналт тавих нөөцийг хуваарил.
• Хэрэв бүтээгдэхүүн аль хэдийн үйлдвэрлэгдэж байгаа бөгөөд та "мониторинг хийх" гэж хэлсэн devops бол миний энэ бүх талаар бичсэн зүйлийг удирдлагадаа тайлбарлаж үзээрэй.

Энэ бол Saint Highload++ бага хурлын тайлангийн өргөтгөсөн хувилбар юм.

Хэрэв та энэ талаархи миний санаа, бодлыг болон холбогдох сэдвүүдийг сонирхож байвал эндээс боломжтой сувгийг уншина уу 🙂

Эх сурвалж: www.habr.com