Да го погледнеме концептот на мониторинг на Кубернет, да се запознаеме со алатката Прометеј и да разговараме за алармирање.
Темата за мониторинг е обемна, не може да се опфати во една статија. Целта на овој текст е да даде преглед на алатките, концептите и пристапите.
Материјалот на статијата е стискање од . Ако сакате да добиете целосна обука, пријавете се на курс за .
Што се следи во кластерот Кубернетес
Физички сервери. Ако кластерот Kubernetes е распореден на сопствените сервери, треба да го следите нивното здравје. Zabbix се справува со оваа задача; ако работите со него, тогаш нема потреба да одбиете, нема да има конфликти. Zabbix е тој што ја следи состојбата на нашите сервери.
Да преминеме на следење на ниво на кластер.
Компоненти на контролната рамнина: API, Распоредувач и други. Најмалку, треба да следите дали API-то на серверот или etcd е поголемо од 0. Etcd може да обезбеди многу метрики: на дисковите на кои се врти, за здравјето на неговиот кластер etcd и други.
пристанишен работник се појави многу одамна и сите се свесни за неговите проблеми: многу контејнери предизвикуваат замрзнување и други проблеми. Затоа и самиот Docker како систем треба да се следи, барем за достапноста.
ДНС. Ако DNS не успее во кластер, тогаш целата услуга Discovery исто така ќе пропадне, а повиците од pods до pods ќе престанат да работат. Во мојата пракса, немаше такви проблеми, но тоа не значи дека статусот на DNS не треба да се следи. Латентноста на барањето и некои други метрики може да се следат на CoreDNS.
Влегување. Неопходно е да се контролира достапноста на влезовите (вклучувајќи го и контролорот за влез) како влезни точки во проектот.
Главните компоненти на кластерот се расклопени - сега да одиме подолу, до нивото на апстракции.
Се чини дека апликациите работат во подлоги, што значи дека треба да се контролираат, но во реалноста не. Подовите се ефемерни: денес тие работат на еден сервер, утре на друг; Денес ги има 10, утре 2. Затоа никој не ги надгледува мешунките. Во архитектурата на микросервис, поважно е да се контролира достапноста на апликацијата како целина. Особено, проверете ја достапноста на крајните точки на услугата: дали нешто функционира? Ако апликацијата е достапна, тогаш што се случува зад неа, колку реплики има сега - ова се прашања од втор ред. Нема потреба да се следат поединечни случаи.
На последното ниво, треба да ја следите работата на самата апликација, да земете деловни метрики: бројот на нарачки, однесувањето на корисниците итн.
Прометеј
Најдобар систем за следење на кластерот е . Не знам ниту една алатка што може да се спореди со Prometheus во однос на квалитетот и леснотијата на користење. Одлично е за агилна инфраструктура, па кога луѓето велат „Kubernetes monitoring“ тие обично мислат на Прометеј.
Постојат неколку опции за започнување со Prometheus: користејќи Helm, можете да инсталирате обичен Prometheus или Prometheus Operator.
- Редовен Прометеј. Сè е во ред со него, но треба да ја конфигурирате ConfigMap - во суштина, пишувајте датотеки за конфигурација на текст, како што правевме порано, пред архитектурата на микросервис.
- Операторот Prometheus е малку поопширен, малку покомплексен во својата внатрешна логика, но полесно е да се работи со него: има посебни објекти, апстракции се додаваат во кластерот, така што тие се многу поудобни за контрола и конфигурирање.
За да го разберете производот, препорачувам прво да го инсталирате обичниот Prometheus. Ќе треба да конфигурирате сè преку конфигурацијата, но ова ќе биде корисно: ќе разберете што припаѓа на што и како е конфигурирано. Во Prometheus Operator веднаш се издигнувате на повисока апстракција, иако ако сакате, можете и да навлезете во длабочините.
Prometheus е добро интегриран со Kubernetes: може да пристапи и да комуницира со серверот API.
Prometheus е популарен и е поддржан од голем број апликации и програмски јазици. Потребна е поддршка бидејќи Prometheus има свој формат на метрика, а за да го пренесете ви треба или библиотека во апликацијата или готов извозник. А такви извозници има доста. На пример, постои PostgreSQL Exporter: зема податоци од PostgreSQL и ги претвора во формат Prometheus за да може Prometheus да работи со него.
Архитектура на Прометеј
Сервер Прометеј - ова е серверскиот дел, мозокот на Прометеј. Ова е местото каде што метриката се складира и обработува.
Метриката се чува во базата на податоци за временски серии (TSDB). TSDB не е посебна база на податоци, туку Go пакет кој е вграден во Prometheus. Грубо кажано, се е во една бинарност.
Не чувајте податоци во TSDB долго време
Инфраструктурата на Прометеј не е погодна за долгорочно складирање на метрика. Стандардниот период на складирање е 15 дена. Можете да ја надминете оваа граница, но имајте на ум: колку повеќе податоци складирате во TSDB и колку подолго го правите тоа, толку повеќе ресурси ќе троши. Чувањето историски податоци во Прометеј се смета за лоша практика.
Ако имате огромен сообраќај, бројот на метрика е во стотици илјади во секунда, тогаш подобро е да го ограничите нивното складирање по простор на дискот или период. Вообичаено, TSDB складира „жешки податоци“, метрика буквално за неколку часа. За подолгорочно складирање, надворешното складирање се користи во оние бази на податоци кои се навистина погодни за ова, на пример InfluxDB, ClickHouse итн. Видов повеќе добри критики за ClickHouse.
Серверот Prometheus работи според моделот се повлече: тој самиот оди по метрика до крајните точки што му ги дадовме. Тие рекоа: „Одете на серверот API“, и тој оди таму секој n-ти број секунди и ги зема метриките.
За предмети со краток век на траење (работа или cron job) што може да се појават помеѓу периодите на стругање, постои компонента Pushgateway. Метриката од краткорочните објекти се втурнати во неа: работата се зголеми, ја заврши акцијата, ја испрати метриката до Pushgateway и заврши. По некое време, Прометеј ќе оди со свое темпо и ќе ги преземе овие метрики од Pushgateway.
За да ги конфигурирате известувањата во Прометеј, постои посебна компонента - Менаџер за предупредување. И правилата за предупредување. На пример, треба да креирате предупредување ако API-то на серверот е 0. Кога настанот се активира, предупредувањето се пренесува до менаџерот за предупредувања за понатамошно испраќање. Менаџерот за предупредувања има прилично флексибилни поставки за рутирање: една група предупредувања може да се испрати до телеграмскиот разговор на администраторите, друга до разговорот на програмерите и трета до разговорот на работниците во инфраструктурата. Известувањата може да се испраќаат на Slack, Telegram, е-пошта и други канали.
И, конечно, ќе ви кажам за убиствената карактеристика на Прометеј - откривање. Кога работите со Прометеј, не треба да наведете специфични адреси на објекти за следење, доволно е да го наведете нивниот тип. Тоа е, нема потреба да пишувате „тука е IP адресата, тука е пристаништето - монитор“, наместо тоа треба да одредите според кои принципи да ги најдете овие објекти (цели - цели). Самиот Прометеј, во зависност од тоа кои објекти се моментално активни, ги повлекува потребните и ги додава на мониторингот.
Овој пристап добро се вклопува со структурата Кубернет, каде што сè исто така лебди: денес има 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)Веб интерфејс на Прометеј
Прометеј има свој, прилично минималистички веб-интерфејс. Погоден само за дебагирање или демонстрација.
Можете да напишете барање во PromQL во линијата Expression.
Јазичето за предупредувања содржи правила за предупредување и тие имаат три статуси:
- неактивно - ако предупредувањето не е активно во моментот, односно сè е во ред со него и не функционира;
- во очекување - ова е ако предупредувањето е активирано, но испраќањето сè уште не е извршено. Доцнењето е поставено да го компензира трепкањето на мрежата: ако наведената услуга се зголеми за една минута, тогаш сè уште нема потреба да се огласува алармот;
- пукањето е трет статус, кога се пали предупредувањето и испраќа пораки.
Во менито Статус ќе најдете пристап до информации за тоа што е Прометеј. Има и транзиција кон целите за кои зборувавме погоре.
За подетален преглед на интерфејсот Prometheus, видете .
Интеграција со Графана
Во веб-интерфејсот Prometheus нема да најдете убави и разбирливи графикони од кои можете да извлечете заклучоци за состојбата на кластерот. За да ги изгради, Прометеј се интегрира со Графана. Ова се контролните табли што ги добиваме.
Поставувањето на интеграцијата на Прометеј и Графана воопшто не е тешко; упатствата може да се најдат во документацијата: Па, ќе завршам со ова.
Во следните написи ќе ја продолжиме темата за следење: ќе зборуваме за собирање и анализа на трупци со помош на Grafana Loki и алтернативни алатки.
Автор: Марсел Ибраев, сертифициран администратор на Кубернетес, инженер-практик во компанијата , развивач на курсеви за звучници и Slurm.
Извор: www.habr.com