Kubernetes мониторингийн тухай ойлголтыг авч үзье, Prometheus хэрэгсэлтэй танилцаж, сэрэмжлүүлэх талаар ярилцъя.
Хяналтын сэдэв нь асар том бөгөөд үүнийг нэг нийтлэлд багтаах боломжгүй. Энэхүү текстийн зорилго нь арга хэрэгсэл, үзэл баримтлал, арга барилын тоймыг өгөх явдал юм.
Өгүүллийн материал --аас авсан . Хэрэв та бүрэн сургалтанд хамрагдахыг хүсвэл курст бүртгүүлээрэй .
Kubernetes кластерт юу хянагддаг
Физик серверүүд. Хэрэв Kubernetes кластерыг өөрийн сервер дээр байрлуулсан бол та тэдний эрүүл мэндийг хянах хэрэгтэй. Заббикс энэ ажлыг гүйцэтгэдэг; Хэрэв та түүнтэй ажиллах юм бол татгалзах шаардлагагүй, зөрчилдөөн гарахгүй. Энэ бол манай серверүүдийн төлөв байдлыг хянадаг Zabbix юм.
Кластерийн түвшний хяналт руу шилжье.
Хяналтын онгоцны бүрэлдэхүүн хэсгүүд: API, Scheduler болон бусад. Хамгийн багаар бодоход та серверийн API эсвэл etcd нь 0-ээс их байгаа эсэхийг хянах хэрэгтэй. Etcd нь эргэлдэж буй дискнүүд, etcd кластерын эрүүл мэнд гэх мэт олон хэмжигдэхүүнийг өгч чадна.
Docker эрт дээр үеэс гарч ирсэн бөгөөд хүн бүр түүний асуудлуудыг сайн мэддэг: олон савнууд хөлдөлт болон бусад асуудлуудыг үүсгэдэг. Тиймээс Docker өөрөө системийн хувьд ядаж бэлэн байгаа эсэхийг хянах ёстой.
dns. Хэрэв кластерт DNS бүтэлгүйтвэл Discovery үйлчилгээ бүхэлдээ бүтэлгүйтэх ба pods-аас pods руу залгах ажиллагаа зогсох болно. Миний практикт ийм асуудал гараагүй боловч энэ нь DNS статусыг хянах шаардлагагүй гэсэн үг биш юм. Хүсэлтийн хоцролт болон бусад зарим хэмжигдэхүүнийг CoreDNS дээр хянах боломжтой.
Нэвтрэх. Төсөлд нэвтрэх цэгүүд болох оролт (оролтын хянагч орно) байгаа эсэхийг хянах шаардлагатай.
Кластерын үндсэн бүрэлдэхүүн хэсгүүдийг задалсан - одоо хийсвэрлэлийн түвшинд хүрцгээе.
Аппликейшн нь pods-д ажилладаг юм шиг санагдаж байгаа бөгөөд энэ нь тэдгээрийг хянах шаардлагатай гэсэн үг боловч бодит байдал дээр тийм биш юм. Pod нь түр зуурынх: өнөөдөр тэд нэг сервер дээр, маргааш нөгөө сервер дээр ажилладаг; Өнөөдөр 10, маргааш 2. Тийм учраас хэн ч хонхорхойг хянадаггүй. Микро үйлчилгээний архитектурт програмын хүртээмжийг бүхэлд нь хянах нь илүү чухал юм. Ялангуяа үйлчилгээний төгсгөлийн цэгүүд байгаа эсэхийг шалгана уу: ямар нэг зүйл ажиллаж байна уу? Хэрэв програм байгаа бол түүний ард юу болж байна, одоо хичнээн хуулбар байгаа бол эдгээр нь хоёр дахь зэрэглэлийн асуултууд юм. Бие даасан тохиолдлуудад хяналт тавих шаардлагагүй.
Сүүлчийн түвшинд та програмын үйл ажиллагааг хянах, бизнесийн хэмжүүрүүдийг авах хэрэгтэй: захиалгын тоо, хэрэглэгчийн зан байдал гэх мэт.
Prometheus
Кластерийг хянах хамгийн сайн систем . Чанар, хэрэглэхэд хялбар байдлын хувьд Prometheus-тай харьцуулах ямар ч хэрэгслийг би мэдэхгүй. Энэ нь уян хатан дэд бүтцийн хувьд маш сайн тул хүмүүс "Кубернетес мониторинг" гэж хэлэхэд ихэвчлэн Прометейг хэлдэг.
Prometheus-ийг эхлүүлэх хэд хэдэн сонголт байдаг: Helm ашиглан та ердийн Prometheus эсвэл Prometheus Operator суулгаж болно.
- Ердийн Прометей. Бүх зүйл зүгээр, гэхдээ та ConfigMap-ийг тохируулах хэрэгтэй - үндсэндээ бичил үйлчилгээний архитектураас өмнө бидний өмнө нь бичсэн шиг текстийн тохиргооны файлуудыг бичих хэрэгтэй.
- Prometheus Operator нь дотоод логикийн хувьд арай илүү өргөн цар хүрээтэй, арай илүү төвөгтэй боловч ажиллахад хялбар байдаг: тусдаа объектууд байдаг, хийсвэрлэлүүд кластерт нэмэгдсэн тул тэдгээрийг хянах, тохируулахад илүү тохиромжтой.
Бүтээгдэхүүнийг ойлгохын тулд эхлээд ердийн Prometheus суулгахыг зөвлөж байна. Та тохиргоогоор дамжуулан бүх зүйлийг тохируулах хэрэгтэй болно, гэхдээ энэ нь ашигтай байх болно: та юунд хамаарах, хэрхэн тохируулагдсаныг ойлгох болно. Prometheus Operator дээр та нэн даруй илүү өндөр хийсвэрлэлд автдаг, гэхдээ хэрэв хүсвэл та гүн рүү нэвтэрч болно.
Prometheus нь Kubernetes-тэй сайн нэгдсэн: API серверт хандаж, түүнтэй харилцах боломжтой.
Prometheus нь алдартай бөгөөд олон тооны програм, програмчлалын хэлээр дэмжигддэг. Prometheus нь өөрийн хэмжүүрийн форматтай тул дэмжлэг шаардлагатай бөгөөд үүнийг шилжүүлэхийн тулд танд програм доторх номын сан эсвэл бэлэн экспортлогч хэрэгтэй. Мөн ийм экспортлогч нэлээд олон байдаг. Жишээлбэл, PostgreSQL Экспортлогч байдаг: энэ нь PostgreSQL-ээс өгөгдлийг авч Prometheus формат руу хөрвүүлдэг бөгөөд ингэснээр Prometheus түүнтэй ажиллах боломжтой.
Прометей архитектур
Прометей сервер - энэ бол серверийн хэсэг, Прометейгийн тархи юм. Энд хэмжүүрүүдийг хадгалж, боловсруулдаг.
Хэмжих үзүүлэлтүүд нь хугацааны цуврал мэдээллийн санд (TSDB) хадгалагддаг. TSDB нь тусдаа мэдээллийн сан биш, харин Prometheus-д суулгасан Go багц юм. Товчоор хэлбэл, бүх зүйл нэг хоёртын системд байдаг.
TSDB-д өгөгдлийг удаан хадгалж болохгүй
Prometheus-ийн дэд бүтэц нь хэмжигдэхүүнийг удаан хугацаанд хадгалахад тохиромжгүй. Анхдагч хадгалах хугацаа нь 15 хоног байна. Та энэ хязгаарыг давж болно, гэхдээ та TSDB-д хэдий чинээ их мэдээлэл хадгалж, удаан хийх тусам илүү их нөөц зарцуулна гэдгийг санаарай. Прометейд түүхийн мэдээллийг хадгалах нь муу үйлдэл гэж тооцогддог.
Хэрэв танд маш их ачаалал байгаа бол хэмжигдэхүүнүүдийн тоо секундэд хэдэн зуун мянгаар хэмжигддэг бол тэдгээрийн хадгалалтыг дискний зай эсвэл хугацаагаар хязгаарлах нь дээр. Ихэвчлэн TSDB нь "халуун өгөгдөл" хэмжигдэхүүнийг хэдхэн цагийн турш хадгалдаг. Урт хугацааны хадгалалтын хувьд гадаад санах ойг үүнд үнэхээр тохиромжтой мэдээллийн санд ашигладаг, жишээлбэл InfluxDB, ClickHouse гэх мэт. Би ClickHouse-ийн талаар илүү сайн сэтгэгдлийг харсан.
Prometheus Server нь загварын дагуу ажилладаг Татах: тэр өөрөө бидний өгсөн төгсгөлийн цэгүүд рүү хэмжигдэхүүн рүү явдаг. Тэд "API сервер рүү оч" гэж хэлсэн бөгөөд энэ нь n дэх секунд тутамд тэнд очиж, хэмжүүрүүдийг авдаг.
Богино хугацаатай объектуудын хувьд (ажил эсвэл крон ажил) хусах үеүүдийн хооронд гарч ирэх боломжтой бол Pushgateway бүрэлдэхүүн хэсэг байдаг. Богино хугацааны объектуудын хэмжигдэхүүнийг түүн рүү оруулдаг: ажил өсч, үйлдлийг хийж, хэмжигдэхүүнийг Pushgateway руу илгээж, дуусгасан. Хэсэг хугацааны дараа Прометей өөрийн хурдаар явж, Pushgateway-ээс эдгээр хэмжигдэхүүнийг авах болно.
Prometheus дахь мэдэгдлийг тохируулахын тулд тусдаа бүрэлдэхүүн хэсэг байдаг - Сэрэмжлэгч. Мөн анхааруулах дүрэм. Жишээлбэл, хэрэв серверийн API 0 бол сэрэмжлүүлэг үүсгэх хэрэгтэй. Үйл явдал эхлэхэд сэрэмжлүүлэгийг цаашид илгээхийн тулд дохионы менежерт дамжуулдаг. Анхааруулга менежер нь чиглүүлэлтийн уян хатан тохиргоотой: нэг бүлгийг админуудын телеграм чат руу, нөгөөг нь хөгжүүлэгчдийн чат руу, гурав дахь хэсгийг дэд бүтцийн ажилчдын чат руу илгээж болно. Мэдэгдлийг Slack, Telegram, имэйл болон бусад суваг руу илгээх боломжтой.
Эцэст нь би Прометейгийн алуурчин шинж чанарыг танд хэлье. Олж мэдсэн. Prometheus-тэй ажиллахдаа хяналт тавих объектын тодорхой хаягийг зааж өгөх шаардлагагүй бөгөөд тэдгээрийн төрлийг зааж өгөхөд хангалттай. Өөрөөр хэлбэл, "энд IP хаяг, энд порт - монитор" гэж бичих шаардлагагүй, харин эдгээр объектуудыг ямар зарчмаар олохоо тодорхойлох хэрэгтэй (зорилтууд - зорилго). Прометей өөрөө аль объектууд идэвхтэй байгаагаас хамааран шаардлагатай зүйлсийг татаж аваад хяналтанд нэмдэг.
Энэ арга нь Kubernetes-ийн бүтцэд маш сайн нийцдэг бөгөөд энд бүх зүйл хөвдөг: өнөөдөр 10 сервер байна, маргааш 3. Серверийн IP хаягийг байнга зааж өгөхгүйн тулд бид үүнийг хэрхэн олох талаар бичсэн байсан - Discovering үүнийг хийх болно.
Прометей хэл гэж нэрлэдэг PromQL. Энэ хэлийг ашигласнаар та тодорхой хэмжүүрүүдийн утгыг авч, дараа нь тэдгээрийг хувиргаж, тэдгээрт үндэслэн аналитик тооцоолол хийх боломжтой.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Prometheus вэб интерфэйс
Prometheus нь өөрийн гэсэн, нэлээд минималист вэб интерфэйстэй. Зөвхөн дибаг хийх эсвэл үзүүлэхэд тохиромжтой.
Та Expression мөрөнд PromQL дээр асуулга бичиж болно.
"Сэрэмжлүүлэг" таб нь анхааруулах дүрмийг агуулдаг бөгөөд тэдгээр нь гурван статустай:
- идэвхгүй - хэрэв сэрэмжлүүлэг одоогоор идэвхгүй бол, өөрөөр хэлбэл бүх зүйл хэвийн байгаа бөгөөд энэ нь ажиллахгүй байна;
- хүлээгдэж байна - энэ нь сэрэмжлүүлэг асаалттай байсан ч илгээлт хараахан болоогүй байгаа бол. Сүлжээний анивчихыг нөхөхийн тулд саатлыг тохируулсан: хэрэв заасан үйлчилгээ нэг минутын дотор нэмэгдсэн бол дохиолол дуугарах шаардлагагүй болно;
- Гал асаах нь дохио асч, мессеж илгээх гурав дахь төлөв юм.
Статус цэснээс та Прометей гэж юу болох талаар мэдээлэл авах боломжтой. Дээр дурдсан зорилтууд руу шилжих шилжилт бас бий.
Prometheus интерфейсийн талаар илүү дэлгэрэнгүй тоймыг үзнэ үү .
Графанатай нэгтгэх
Prometheus вэб интерфэйсээс та кластерын төлөв байдлын талаар дүгнэлт хийх боломжтой үзэсгэлэнтэй, ойлгомжтой графикуудыг олохгүй. Тэдгээрийг бүтээхийн тулд Прометей Графанатай нэгтгэдэг. Эдгээр нь бидний авдаг хяналтын самбарууд юм.
Прометей ба Графана хоёрыг нэгтгэх нь тийм ч хэцүү биш бөгөөд зааварчилгааг баримтаас олж болно. , за, би үүгээр дуусгая.
Дараах нийтлэлүүдэд бид мониторингийн сэдвийг үргэлжлүүлэх болно: бид Grafana Loki болон өөр хэрэгслийг ашиглан лог цуглуулах, дүн шинжилгээ хийх талаар ярих болно.
Зохиогч: Марсель Ибраев, Kubernetes-ийн итгэмжлэгдсэн администратор, тус компанийн дадлагажигч инженер , илтгэгч болон Slurm курс хөгжүүлэгч.
Эх сурвалж: www.habr.com