Разгледзім канцэпцыю маніторынгу Kubernetes, пазнаёмімся з інструментам Prometheus, пагаворым пра алертынг.
Тэма маніторынгу аб'ёмная, за адзін артыкул яе не разабраць. Мэта гэтага тэксту – даць агляднае ўяўленне па інструментарыі, канцэпцыях і падыходах.
Матэрыял артыкула — выцісканне з . Калі хочаце прайсці поўнае навучанне - запісвайцеся на курс па .
Што маніторыць у кластары Kubernetes
Фізічныя серверы. Калі кластар Kubernetes разгорнуты на сваіх серверах, трэба сачыць за іх здароўем. З гэтай задачай спраўляецца Zabbix; калі вы з ім працуеце, тое не трэба адмаўляцца, канфліктаў не будзе. За станам нашых сэрвераў сочыць менавіта Zabbix.
Пяройдзем да маніторынгу на ўзроўні кластара.
Control Plane кампаненты: API, Scheduler і іншыя. Як мінімум, трэба адсочваць, каб API сервераў ці etcd было больш 0. Etcd умее аддаваць шмат метрык: па дысках, на якіх ён круціцца, па здароўі свайго кластара etcd і іншыя.
Докер з'явіўся даўно і аб яго праблемах усім добра вядома: мноства кантэйнераў спараджаюць завісанні і іншыя праблемы. Таму сам Docker, як сістэму, таксама варта кантраляваць, хаця б на даступнасць.
dns. Калі ў кластары адваліцца DNS, то за ім адваліцца і ўвесь сэрвіс Discovery, перастануць працаваць звароты ад подаў да пад. У маёй практыцы падобных праблем не было, аднак гэта не значыць, што за станам DNS не трэба сачыць. Затрымкі ў запытах і некаторыя іншыя метрыкі можна адсочваць на CoreDNS.
Ingress. Трэба кантраляваць даступнасць інгрэсаў (у тым ліку Ingress Controller) як уваходных кропак у праект.
Асноўныя кампаненты кластара разабралі - зараз апусцімся ніжэй, на ўзровень абстракцый.
Здавалася б, прыкладанні запускаюцца ў падах, значыць іх трэба кантраляваць, але насамрэч няма. Поды эфемерныя: сёння працуюць на адным серверы, заўтра на іншым; сёння іх 10, заўтра 2. Таму проста поды ніхто не маніторыць. У рамках мікрасэрвіснай архітэктуры важней кантраляваць даступнасць прыкладання ў цэлым. У прыватнасці, правяраць даступнасць эндпаінтаў сэрвісу: ці працуе хоць нешта? Калі прыкладанне даступна, то што адбываецца за ім, колькі зараз рэплік - гэта пытанні другога парадку. Сачыць за асобнымі інстанс няма неабходнасці.
На апошнім узроўні трэба кантраляваць працу самога дадатку, здымаць бізнес-метрыкі: колькасць заказаў, паводзіны карыстальнікаў і іншае.
Праметэй
Лепшая сістэма для маніторынгу кластара - гэта . Я не ведаю ні аднаго інструмента, які можа параўнацца з Prometheus па якасці і зручнасці працы. Ён выдатна падыходзіць для гнуткай інфраструктуры, таму калі кажуць "маніторынг Kubernetes", звычайна маюць на ўвазе менавіта Prometheus.
Ёсць пара варыянтаў, як пачаць працаваць з Prometheus: з дапамогай Helm можна паставіць звычайны Prometheus ці Prometheus Operator.
- Звычайны Prometheus. З ім усё добра, але трэба наладжваць ConfigMap – па сутнасці, пісаць тэкставыя канфігурацыйныя файлы, як мы рабілі раней, да мікрасэрвіснай архітэктуры.
- Prometheus Operator крыху развесістей, крыху складаней па ўнутранай логіцы, але працаваць з ім прасцей: там ёсць асобныя аб'екты, абстракцыі дадаюцца ў кластар, таму іх значна зручней кантраляваць і наладжваць.
Каб разабрацца з прадуктам, я рэкамендую спачатку паставіць звычайны Prometheus. Прыйдзецца ўсё наладжваць праз канфіг, але гэта пайдзе на карысць: разбярэцеся, што да чаго ставіцца і як наладжваецца. У Prometheus Operator вы адразу паднімаецеся на абстракцыю вышэй, хоць пры жаданні пакапацца ў глыбінях таксама будзе можна.
Prometheus добра інтэграваны з Kubernetes: можа звяртацца да API Server і ўзаемадзейнічаць з ім.
Prometheus папулярны, таму яго падтрымлівае вялікую колькасць прыкладанняў і моў праграмавання. Падтрымка патрэбна, бо ў Prometheus свой фармат метрык, і для яго перадачы неабходна альбо бібліятэка ўнутры прыкладання, альбо гатовы экспарцёр. І такіх экспарцёраў дастаткова шмат. Напрыклад, ёсць PostgreSQL Exporter: ён бярэ дадзеныя з PostgreSQL і канвертуе іх у фармат Prometheus, каб Prometheus мог з імі працаваць.
Архітэктура Prometheus
Prometheus Server - Гэта серверная частка, мозг Prometheus. Тут захоўваюцца і апрацоўваюцца метрыкі.
Метрыкі захоўвае time series database (TSDB). TSDB - гэта не асобная база дадзеных, а пакет на мове Go, які ўшыты ў Prometheus. Грубіянска кажучы, усё знаходзіцца ў адным бінары.
Не захоўвайце дадзеныя ў TSDB доўга
Інфраструктура Prometheus не падыходзіць для працяглага захоўвання метрык. Па змаўчанні тэрмін захоўвання складае 15 дзён. Можна гэтае абмежаванне перавысіць, але трэба мець на ўвазе: чым больш дадзеных вы будзеце захоўваць у TSDB і чым даўжэй будзеце гэта рабіць, тым больш рэсурсаў яна будзе спажываць. Захоўваць гістарычныя дадзеныя ў Prometheus лічыцца дрэннай практыкай.
Калі ў вас вялізны трафік, колькасць метрык вылічаецца сотнямі тысяч у секунду, то лепш абмежаваць іх захоўванне па аб'ёме дыска або па тэрміне. Звычайна ў TSDB захоўваюць "гарачыя дадзеныя", метрыкі літаральна за некалькі гадзін. Для даўжэйшага захоўвання выкарыстаюць вонкавыя сховішчы ў тых базах дадзеных, якія сапраўды для гэтага падыходзяць, напрыклад InfluxDB, ClickHouse і гэтак далей. Больш за добрых водгукаў я бачыў пра ClickHouse.
Prometheus Server працуе па мадэлі цягнуць: сам ходзіць па метрыкі ў тыя эндпоінты, якія мы яму перадалі. Сказалі: "хадзі ў API Server", і ён раз у n-ую колькасць секунд туды ходзіць і забірае метрыкі.
Для аб'ектаў з кароткай працягласцю жыцця (job або cron job), якія могуць з'яўляцца паміж перыядамі скрапінгу, ёсць кампанент Pushgateway. У яго пушацца метрыкі ад кароткатэрміновых аб'ектаў: job падняўся, выканаў дзеянне, адправіў метрыкі ў Pushgateway і завяршыўся. Праз некаторы час Prometheus у сваім рытме сыходзіць і забярэ гэтыя метрыкі з Pushgateway.
Для налады апавяшчэнняў у Prometheus ёсць асобны кампанент Alertmanager. І правілы алертынгу – alerting rules. Напрыклад, трэба ствараць alert у выпадку, калі API сервераў 0. Калі падзея спрацоўвае, alert перадаецца ў alert manager для далейшай адпраўкі. У alert manager досыць гнуткія налады роўтынгу: адну групу алертаў можна адпраўляць у тэлеграм-чат адмінаў, іншую ў чат распрацоўшчыкаў, трэцюю ў чат інфраструктуршчыкаў. Абвесткі могуць прыходзіць у Slack, Telegram, на email і ў іншыя каналы.
Ну і напрыканцы раскажу пра кілер-фічу Prometheus. выяўленне. Пры працы з Prometheus не трэба ўказваць канкрэтныя адрасы аб'ектаў для маніторынгу, дастаткова задаць іх тып. Гэта значыць не трэба пісаць «вось IP-адрас, вось порт – манітор», замест гэтага трэба вызначыць, па якіх прынцыпах знаходзіць гэтыя аб'екты (мэты - Мэты). Prometheus сам, у залежнасці ад таго, якія аб'екты зараз актыўныя, падцягвае да сябе патрэбныя і дадае на маніторынг.
Такі падыход добра кладзецца на структуру Kubernetes, дзе таксама ўсё плавае: сёння 10 сервераў, заўтра 3. Каб кожны раз не ўказваць IP-адрас сервера, адзін раз напісалі, як яго знаходзіць – і Discovering будзе гэта рабіць.
Мова Prometheus называецца 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.
Ва ўкладцы Alerts змяшчаюцца правілы алертаў - alerting rules, і ў іх ёсць тры статусу:
- inactive - калі ў дадзены момант алерт не актыўны, гэта значыць па ім усё добра, і ён не спрацаваў;
- pending - гэта ў выпадку, калі алерт спрацаваў, але адпраўка яшчэ не прайшла. Затрымку ўсталёўваюць, каб кампенсаваць мігценні сеткі: калі на працягу хвіліны зададзены сэрвіс падняўся, то трывогу біць пакуль не трэба;
- firing - гэта трэці статус, калі алёрт загараецца і адпраўляе паведамленні.
У меню Status знойдзеце доступ да інфармацыі аб тым, што з сябе ўяўляе Prometheus. Там жа ёсць пераход да мэт (targets), пра якія мы казалі вышэй.
Больш падрабязны агляд інтэрфейсу Prometheus глядзіце .
Інтэграцыя з Grafana
У вэб-інтэрфейсе Prometheus вы не знойдзеце прыгожых і зразумелых графікаў, з якіх можна зрабіць выснову аб стане кластара. Каб іх будаваць, Prometheus інтэгруюць з Grafana. Атрымліваюцца вось такія дашборды.
Наладзіць інтэграцыю Prometheus і Grafana зусім нескладана, інструкцыі знойдзеце ў дакументацыі: , ну а я на гэтым скончу.
У наступных артыкулах мы працягнем тэму маніторынгу: пагаворым пра збор і аналіз логаў з дапамогай Grafana Loki і альтэрнатыўных інструментаў.
Аўтар: Марсэль Ібраеў, сертыфікаваны адміністратар Kubernetes, практыкуючы інжынер у кампаніі , спікер і распрацоўшчык курсаў Слёрм.
Крыніца: habr.com