Обмислете концепцията за наблюдение на Kubernetes, запознайте се с инструмента Prometheus и говорете за предупреждение.
Темата за мониторинга е обемна, не може да се разглоби в една статия. Целта на този текст е да предостави преглед на инструментите, концепциите и подходите.
Материалът на статията е изстискан от . Ако искате да вземете пълен курс - запишете се за курс по .
Какво се наблюдава в клъстер на Kubernetes
физически сървъри. Ако клъстерът Kubernetes е разположен на неговите сървъри, трябва да наблюдавате тяхното здраве. Zabbix се справя с тази задача; ако работите с него, тогава не е нужно да отказвате, няма да има конфликти. Zabbix е този, който следи състоянието на нашите сървъри.
Да преминем към мониторинг на ниво клъстер.
Компоненти на контролната равнина: API, Scheduler и др. Като минимум трябва да се уверите, че API на сървъри или etcd е по-голям от 0. Etcd може да върне много показатели: от дисковете, на които се върти, от здравето на своя etcd клъстер и други.
докер се появи отдавна и всички са добре запознати с проблемите му: много контейнери генерират замръзване и други проблеми. Следователно самият Docker, като система, също трябва да бъде контролиран, поне за наличност.
dns. Ако DNS отпадне в клъстера, тогава цялата услуга Discovery ще отпадне след него, обажданията от pods до pods ще спрат да работят. В моята практика нямаше такива проблеми, но това не означава, че състоянието на DNS не трябва да се следи. Забавянето на заявката и някои други показатели могат да бъдат проследени в CoreDNS.
Ingress. Необходимо е да се контролира наличието на входове (включително Ingress Controller) като входни точки към проекта.
Основните компоненти на клъстера са демонтирани - сега да слезем на нивото на абстракциите.
Изглежда, че приложенията работят в контейнери, което означава, че трябва да бъдат контролирани, но в действителност не е така. Подовете са ефимерни: днес работят на един сървър, утре на друг; днес са 10, утре 2. Следователно никой не следи подс. В рамките на архитектурата на микроуслугата е по-важно да се контролира наличността на приложението като цяло. По-специално проверете наличността на крайните точки на услугата: работи ли нещо? Ако приложението е налично, тогава какво се случва зад него, колко реплики има сега - това са въпроси от втори ред. Няма нужда да наблюдавате отделни случаи.
На последното ниво трябва да контролирате работата на самото приложение, да вземете бизнес показатели: брой поръчки, поведение на потребителите и т.н.
Прометей
Най-добрата система за наблюдение на клъстер е . Не знам за инструмент, който може да се мери с Prometheus по отношение на качество и лекота на използване. Той е чудесен за гъвкава инфраструктура, така че когато казват „наблюдение на Kubernetes“, те обикновено имат предвид Prometheus.
Има няколко опции за започване на работа с Prometheus: като използвате Helm, можете да инсталирате обикновен Prometheus или Prometheus Operator.
- Редовен Прометей. Всичко е наред с него, но трябва да конфигурирате ConfigMap - всъщност да напишете текстови конфигурационни файлове, както правехме преди, преди архитектурата на микросервизите.
- Prometheus Operator е малко по-разпространен, малко по-сложен по отношение на вътрешната логика, но е по-лесно да се работи с него: има отделни обекти, абстракциите се добавят към клъстера, така че те са много по-удобни за управление и конфигуриране.
За да разберете продукта, препоръчвам първо да инсталирате обикновения Prometheus. Ще трябва да конфигурирате всичко чрез конфигурацията, но това ще бъде от полза: ще разберете кое към какво принадлежи и как е конфигурирано. В Prometheus Operator незабавно се издигате до абстракция по-високо, въпреки че можете също да се ровите в дълбините, ако желаете.
Prometheus е добре интегриран с Kubernetes: той има достъп и взаимодейства с API сървъра.
Prometheus е популярен, поради което голям брой приложения и езици за програмиране го поддържат. Необходима е поддръжка, тъй като Prometheus има собствен формат на метрики и за да го прехвърлите, ви трябва или библиотека в приложението, или готов експортер. А такива износители има доста. Например, има PostgreSQL Exporter: той взема данни от PostgreSQL и ги преобразува във формат Prometheus, така че Prometheus да може да работи с него.
Архитектура на Прометей
Prometheus сървър е задната част, мозъкът на Прометей. Метриките се съхраняват и обработват тук.
Метриките се съхраняват в базата данни за времеви редове (TSDB). TSDB не е отделна база данни, а пакет на езика Go, който е вграден в Prometheus. Грубо казано, всичко е в един двоичен файл.
Не съхранявайте данни в TSDB за дълго време
Инфраструктурата на Prometheus не е подходяща за дългосрочно съхранение на показатели. Периодът на задържане по подразбиране е 15 дни. Можете да надвишите това ограничение, но имайте предвид: колкото повече данни съхранявате в TSDB и колкото по-дълго го правите, толкова повече ресурси ще консумира. Съхраняването на исторически данни в Prometheus се счита за лоша практика.
Ако имате огромен трафик, броят на показателите е стотици хиляди в секунда, тогава е по-добре да ограничите съхранението им по дисково пространство или по период. Обикновено „горещите данни“ се съхраняват в TSDB, показатели само за няколко часа. За по-дълго съхранение се използва външно хранилище в тези бази данни, които наистина са подходящи за това, например InfluxDB, ClickHouse и т.н. Видях още добри отзиви за ClickHouse.
Prometheus Server работи по модела издърпайте: той отива за показатели до онези крайни точки, които сме му дали. Те казаха: „отидете на API сървъра“ и той отива там на всеки n-ти брой секунди и взема показателите.
За обекти с кратък живот (задача или cron задача), които могат да се появят между периодите на изтриване, има компонент Pushgateway. Метриките от краткосрочни обекти се вкарват в него: заданието е издигнато, извършено е действие, изпратени са показатели към Pushgateway и е завършено. След известно време Prometheus ще слезе със собственото си темпо и ще вземе тези показатели от Pushgateway.
За да конфигурирате известията в Prometheus има отделен компонент - Alertmanager. И правилата за предупреждение. Например, трябва да създадете предупреждение, ако API на сървъра е 0. Когато събитието се задейства, предупреждението се предава на мениджъра на предупреждения за по-нататъшно изпращане. Мениджърът на предупреждения има доста гъвкави настройки за маршрутизиране: една група предупреждения може да бъде изпратена до телеграм чата на администраторите, друга до чата на разработчиците и трета до чата на инфраструктурните работници. Известията могат да се изпращат до Slack, Telegram, имейл и други канали.
И накрая, ще ви разкажа за функцията убиец на Prometheus - Откриването. Когато работите с Prometheus, не е необходимо да посочвате конкретни адреси на обекти за наблюдение, достатъчно е да зададете техния тип. Тоест, не е нужно да пишете „ето IP адреса, тук е портът - монитор“, вместо това трябва да определите по какви принципи да намерите тези обекти (цели - цели). Самият Prometheus, в зависимост от това кои обекти са активни в момента, изтегля необходимите и ги добавя към мониторинга.
Този подход се вписва добре в структурата на 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
В уеб интерфейса на Prometheus няма да намерите красиви и разбираеми графики, от които можете да направите заключение за състоянието на клъстера. За да ги изгради, Prometheus е интегриран с Grafana. Получаваме такива табла.
Настройването на интеграцията на Prometheus и Grafana не е никак трудно, можете да намерите инструкции в документацията: Е, ще завърша с това.
В следващите статии ще продължим темата за мониторинга: ще говорим за събиране и анализиране на регистрационни файлове с помощта на Grafana Loki и алтернативни инструменти.
Автор: Марсел Ибраев, сертифициран Kubernetes администратор, практикуващ инженер в компанията , лектор и разработчик на курсове Slurm.
Източник: www.habr.com