Kubernetes мониторингинин концепциясын карап көрүңүз, Prometheus куралы менен таанышыңыз жана эскертүү жөнүндө сүйлөшүңүз.
Мониторинг темасы көлөмдүү, аны бир макалада чечүүгө болбойт. Бул тексттин максаты - инструменттер, түшүнүктөр жана ыкмалар жөнүндө жалпы маалымат берүү.
Макаланын материалы бир сыгылган . Эгер сиз толук курска өтүүнү кааласаңыз - боюнча курска жазылыңыз .
Kubernetes кластеринде эмне көзөмөлдөнөт
физикалык серверлер. Эгерде Kubernetes кластери анын серверлеринде жайгаштырылса, алардын ден соолугуна көз салышыңыз керек. Zabbix бул тапшырманы аткарат; эгерде сиз аны менен иштесеңиз, анда баш тартуунун кереги жок, эч кандай чыр-чатактар болбойт. Бул Zabbix биздин серверлердин абалын көзөмөлдөйт.
Кластердик деңгээлде мониторинг жүргүзүүгө өтөлү.
Башкаруучу учактын компоненттери: API, Scheduler жана башкалар. Жок дегенде, сиз серверлердин же etcd API'синин 0ден чоң экенине ынанышыңыз керек. Etcd көптөгөн метрикаларды кайтара алат: ал айланып жаткан дисктер боюнча, анын etcd кластеринин ден соолугу боюнча жана башкалар.
ютуб көп убакыт мурун пайда болгон жана анын көйгөйлөрүн баары жакшы билет: көп контейнерлер тоңуп калат жана башка көйгөйлөрдү жаратат. Ошондуктан, Докердин өзү система катары, жок эле дегенде, жеткиликтүүлүгүн көзөмөлдөө керек.
dns. Эгерде DNS кластерде иштебей калса, андан кийин Discovery кызматы толугу менен иштебей калат, поддондордон подъезддерге чалуулар иштебей калат. Менин практикамда мындай көйгөйлөр болгон эмес, бирок бул DNSтин абалын көзөмөлдөөнүн кереги жок дегенди билдирбейт. Сурамдын кечигүү убактысын жана башка кээ бир көрсөткүчтөрдү CoreDNS аркылуу байкоого болот.
Кирүү. Долбоордун кирүү чекиттери катары кириштердин (анын ичинде Ingress Controller) болушун көзөмөлдөө зарыл.
Кластердин негизги компоненттери демонтаждалган – эми абстракциялардын деңгээлине өтөбүз.
Бул тиркемелерди башкаруу керек дегенди түшүндүрөт, бирок чындыгында андай эмес. Поддор эфемердик: бүгүн алар бир серверде, эртең башка серверде иштешет; бүгүн алардын саны 10, эртең 2. Ошондуктан, төө буурчактарды эч ким көзөмөлдөбөйт. Микросервис архитектурасынын ичинде, бүтүндөй тиркеменин жеткиликтүүлүгүн көзөмөлдөө маанилүү. Атап айтканда, кызматтын акыркы чекиттеринин болушун текшериңиз: эч нерсе иштейби? Эгерде тиркеме бар болсо, анда анын артында эмне болот, азыр канча репликалар бар - бул экинчи тартиптеги суроолор. Жеке инстанцияларды көзөмөлдөөнүн кереги жок.
Акыркы деңгээлде сиз тиркеменин иштешин көзөмөлдөшүңүз керек, бизнес-метрикаларды: буйрутмалардын саны, колдонуучунун жүрүм-туруму ж.б.у.с.
Prometheus
Кластерге мониторинг жүргүзүү үчүн эң жакшы система болуп саналат . Сапаты жана колдонуунун оңойлугу боюнча Prometheus менен тең келе турган куралды билбейм. Бул ийкемдүү инфраструктура үчүн сонун, ошондуктан алар "Кубернетес мониторинги" деп айтканда, алар көбүнчө Прометейди билдирет.
Prometheus менен баштоонун бир нече варианттары бар: Helm менен сиз кадимки Prometheus же Prometheus Operator орното аласыз.
- Кадимки Прометей. Аны менен баары жакшы, бирок сиз ConfigMapты конфигурациялашыңыз керек - чындыгында, микросервис архитектурасына чейин биз мурун кылгандай, текстке негизделген конфигурация файлдарын жазыңыз.
- Prometheus Operator бир аз жайылган, ички логика жагынан бир аз татаалыраак, бирок аны менен иштөө оңой: өзүнчө объекттер бар, кластерге абстракциялар кошулат, ошондуктан аларды башкаруу жана конфигурациялоо алда канча ыңгайлуу.
Продукцияны түшүнүү үчүн мен адегенде кадимки Prometheus орнотууну сунуштайм. Баарын конфигурациялоо аркылуу конфигурациялашыңыз керек болот, бирок бул пайдалуу болот: эмнеге таандык экенин жана ал кантип конфигурацияланганын билесиз. Prometheus Operator'до сиз дароо абстракцияга көтөрүлөсүз, бирок кааласаңыз, тереңдикке кирип кете аласыз.
Prometheus Kubernetes менен жакшы интеграцияланган: ал API серверине кире жана иштеше алат.
Prometheus популярдуу, ошондуктан көптөгөн тиркемелер жана программалоо тилдери аны колдойт. Колдоо керек, анткени Prometheus өзүнүн метрика форматына ээ жана аны өткөрүп берүү үчүн сизге же колдонмонун ичиндеги китепкана же даяр экспортер керек. Ал эми мындай экспортерлор аз эмес. Мисалы, PostgreSQL Экспорттоочу бар: ал PostgreSQLден маалыматтарды алып, Prometheus аны менен иштеши үчүн аны Prometheus форматына которот.
Прометей архитектурасы
Prometheus Server арткы аягы, Прометейдин мээси. Бул жерде метрика сакталат жана иштетилет.
Көрсөткүчтөр убакыт серияларынын маалымат базасында (TSDB) сакталат. TSDB өзүнчө маалымат базасы эмес, Прометейде камтылган Go тилиндеги пакет. Болжол менен айтканда, баары бир бинардык.
Маалыматтарды TSDBде көпкө сактабаңыз
Prometheus инфраструктурасы метрикаларды узак мөөнөткө сактоо үчүн ылайыктуу эмес. Демейки сактоо мөөнөтү 15 күн. Сиз бул чектен аша аласыз, бирок эсиңизде болсун: TSDBде канчалык көп маалымат сактасаңыз жана аны канчалык узак кылсаңыз, ошончолук көп ресурстар керектелет. Прометейде тарыхый маалыматтарды сактоо жаман практика болуп эсептелет.
Эгер сизде чоң трафик болсо, метрикалардын саны секундасына жүз миңдеген болсо, анда алардын сакталышын диск мейкиндиги же мезгил боюнча чектөө жакшы. Адатта, "ысык маалыматтар" TSDBде сакталат, көрсөткүчтөр бир нече сааттын ичинде. Узак сактоо үчүн тышкы сактагыч бул үчүн чындап ылайыктуу болгон маалымат базаларында колдонулат, мисалы, InfluxDB, ClickHouse ж.б. Мен ClickHouse жөнүндө жакшы пикирлерди көрдүм.
Prometheus Server үлгү боюнча иштейт тартуу: ал биз ага берген акыркы чекиттерге метрикага барат. Алар: "API серверине барыңыз" дешти, ал ал жакка секунданын n-санына барып, метрикаларды алат.
Кыргыч мезгилдердин ортосунда пайда болушу мүмкүн болгон кыска мөөнөттүү объекттер үчүн (жумуш же cron жумушу) Pushgateway компоненти бар. Кыска мөөнөттүү объекттердин көрсөткүчтөрү ага түртүлөт: жумуш көтөрүлдү, иш-аракет аткарылды, метриканы Pushgatewayге жөнөттү жана аяктады. Бир аз убакыт өткөндөн кийин, Prometheus өз ылдамдыгы менен түшүп, бул көрсөткүчтөрдү Pushgatewayден алат.
Прометейде эскертмелерди конфигурациялоо үчүн өзүнчө компонент бар - Alertmanager. Жана эскертүү эрежелери. Мисалы, сервердин API'си 0 болсо, эскертүү түзүшүңүз керек. Окуя откондо, эскертүү андан ары жөнөтүү үчүн эскертүү менеджерине жөнөтүлөт. Эскертүү менеджеринде маршрутизациянын ийкемдүү жөндөөлөрү бар: эскертүүлөрдүн бир тобун администраторлордун телеграмма чатына, экинчисин иштеп чыгуучулардын чатына, үчүнчүсүн инфраструктура кызматкерлеринин чатына жөнөтсө болот. Эскертмелерди Slack, Telegram, электрондук почта жана башка каналдарга жөнөтсө болот.
Акыр-аягы, мен Prometheus өлтүргүч өзгөчөлүгү жөнүндө айтып берем - табылышы. 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 интерфейсинин кененирээк баяндамасын караңыз .
Grafana менен интеграция
Prometheus веб-интерфейсинде сиз кластердин абалы жөнүндө тыянак чыгара турган кооз жана түшүнүктүү графиктерди таба албайсыз. Аларды куруу үчүн Прометей Графана менен бириктирилген. Биз ушундай такталарды алабыз.
Prometheus жана Grafana интеграциясын орнотуу кыйын эмес, сиз документациядан көрсөтмөлөрдү таба аласыз: Мейли, муну менен бүтүрөм.
Кийинки макалаларда биз мониторинг темасын улантабыз: биз Grafana Loki жана альтернативдүү куралдарды колдонуу менен журналдарды чогултуу жана талдоо жөнүндө сүйлөшөбүз.
Автор: Марсель Ибраев, Кубернетестин сертификатталган администратору, компаниянын инженери , баяндамачы жана курсту иштеп чыгуучу Slurm.
Source: www.habr.com