Kubernetes. Запуск prometheus/grafana/alertmanager - запуск exporter для ingress-nginx-controller

Thank you for reading this post, don't forget to subscribe!

1.Установка prometheus
2.exporter nginx(ingress-controller)
3.exporter elasticsearch
4.exporter rabbitmq
5.exporter redis
6.настройка опо­ве­ще­ний в telegram
6.1 настрой­ка опо­ве­ще­ний в telegram в раз­лич­ные чаты(группы)
6.2. настрой­ка опо­ве­ще­ний в telegram раз­гра­ни­че­ние опо­ве­ще­ний по груп­пам (исклю­че­ния уведомлений)
7.Проблема с prometheus-kube-proxy
8.Настройка алер­та для опре­де­лён­но­го неймспейса
9.Добавление опо­ве­ще­ний и по email
10. Настрой­ка гра­фи­ков в grafana

Кача­ем репозиторий

git clone https://github.com/prometheus-community/helm-charts.git
cd helm-charts/charts/kube-prometheus-stack/
дока­чи­ва­ем чарты:
helm dep update

созда­ём namescpase в кото­ром будет всё крутиться:
kubectl create ns monitoring

теперь рас­смот­рим что пра­вим в пере­мен­ных у helm chart:

[root@prod-vsrv-kubemaster1 charts]# vim kube-prometheus-stack/values.yaml

namespaceOverride: "monitoring"

для рабо­ты telegram бота:

настра­и­ва­ем ingress у alertmanager:

настра­и­ва­ем volume для Alertmanager отме­чу что в кла­сте­ре настро­ен nfs-provisioner - nfs-storageclass

теперь настро­им grafana

тут ука­зы­ва­ем ingress а так­же добав­ля­ем хра­не­ние dashboard в nfs storage-class

теперь настра­и­ва­ем ingress для prometheus

а так же volume:

и теперь важ­ная фиш­ка, добав­ле­ние label кото­рый надо будет доба­вить на все неймспейсы:

так­же правим:

для выстав­ле­ния сро­ка хра­не­ния дан­ных можем поме­нять сле­ду­ю­щее значение:

 

запус­ка­ем теперь helm chart

[root@prod-vsrv-kubemaster1 charts]# helm upgrade --install -name prometheus kube-prometheus-stack/ -f kube-prometheus-stack/values.yaml --namespace monitoring

видим что при запус­ке доба­вил­ся label release=prometheus - проверяем:
kubectl describe pod prometheus-kube-prometheus-operator-659d5f8674-qxrf5 -n monitoring | grep -i release
release=prometheus

смот­рим label на всех неймсмейсах:
kubectl get ns --show-labels

про­ста­вим на них label release=prometheus
kubectl label namespace --all "prometheus=enabled"

про­ве­ря­ем:
kubectl get ns --show-labels

 

 

теперь настроим сбор метрик с ingress controller,

созда­ём сер­вис для ingress. Ука­зы­ва­ем namespace в кото­ром рабо­та­ет ingress, так же необ­хо­дим label app.kubernetes.io/name: ingress-nginx дан­ный лейб смот­рим так:
kubectl describe pod -n ingress-nginx ingress-nginx-controller-vqjkl | grep -A3 Labels

mkdir exporter-ingres

cat exporter-ingres/service.yaml

 

В дан­ном фай­ле так же обра­ща­ем вни­ма­ние на:
name: prometheus
на это имя будет натрав­лен port у ServiceMonitor

теперь созда­ём ServiceMonitor, он будет созда­вать в prometheus target с мет­ри­ка­ми ingress controller:

cat exporter-ingres/service-monitor.yaml

так­же правим:

 

при­ме­ня­ем:

[root@prod-vsrv-kubemaster1 charts]# kubectl apply -f exporter-ingres/service.yaml -f exporter-ingres/service-monitor.yaml

через пару мину­ток про­ве­ря­ем в prometheus

общий  вид у фай­ла values.yaml будет следующий:

cat helm-charts/charts/kube-prometheus-stack/values.yaml

 

Настроим Elasticsearch-exporter

он есть в том же репозитории:
https://github.com/prometheus-community/helm-charts.git с кото­ро­го мы запус­ка­ли сам prometheus, лежит он тут:

helm-charts/charts/prometheus-elasticsearch-exporter

!!!!!!!!!!!!сам elasticsearch уже дол­жен быть установлен.

смот­рим нуж­ные нам данные:

 

пра­вим переменные:

vim helm-charts/charts/prometheus-elasticsearch-exporter/values.yaml

ранее мы добав­ля­ли лей­бл командой:
про­ста­вим на них label release=prometheus
kubectl label namespace --all "prometheus=enabled"

про­ве­ря­ем что всё ок

теперь смот­рим на какое имя нам надо будет ссылаться:

в кон­фи­ге будем ука­зы­вать elasticsearch-master

смот­рим какие есть лейб­лы на этом сервисе:

нас инте­ре­су­ет app=elasticsearch-master

пра­вим конфиг:

vim prometheus-elasticsearch-exporter/values.yaml

в пол­ном виде кон­фиг выгля­дит так:

можем уста­нав­ли­вать:

helm install elasticsearch-exporter --values prometheus-elasticsearch-exporter/values.yaml prometheus-elasticsearch-exporter/ -n elk

через какое-то вре­мя появит­ся target

 

4.exporter rabbitmq

про­го­ня­ем label по всем namespace
kubectl label namespace --all "prometheus=enabled"

у меня уже уста­нов­лен rabbitmq в кла­сте­ре в namespace rabbitmq, про­ме­те­ус в namespace monitoring

пароль от rabbitmq у меня закрыт в секрете:

vim prometheus-rabbitmq-exporter/values.yaml

helm install rabbitmq-exporter prometheus-rabbitmq-exporter/ -n monitoring --values prometheus-rabbitmq-exporter/values.yaml

 

5. exporter redis

про­го­ня­ем label по всем namespace
kubectl label namespace --all "prometheus=enabled"

у меня уже уста­нов­лен redis в кла­сте­ре в namespace redis, про­ме­те­ус в namespace monitoring

пароль от redis у меня закрыт в секрете:

 

vim prometheus-redis-exporter/values.yaml

helm install redis-exporter prometheus-redis-exporter/ -n redis --values prometheus-redis-exporter/values.yaml

 

6. настройка оповещений в telegram

Для нача­ла созда­дим telegram bot

идём на  @BotFather

нажи­ма­ем start и полу­ча­ем спи­сок команд:

 /newbot — отправ­ля­ем ему и бот про­сит при­ду­мать имя наше­му ново­му боту. Един­ствен­ное огра­ни­че­ние на имя — оно долж­но окан­чи­вать­ся на «bot». В слу­чае успе­ха BotFather воз­вра­ща­ет токен бота и ссыл­ку для быст­ро­го добав­ле­ния бота в кон­так­ты, ина­че при­дет­ся поло­мать голо­ву над именем.

всё мы заре­га­лись, теперь этот токен мож­но исполь­зо­вать при под­клю­че­нии наше­го алерт­ме­не­дже­ра к телеграму

cat default.tmpl

cat Dockerfile

соби­ра­ем образ пушим в наш гитлаб

далее идём в теле­грамм в канал:

userinfobot
печа­та­ем старт и полу­ча­ем наш id

далее выпол­ня­ем:

echo -n "4196184" | base64
полу­ча­ем хэш
NDE5NjE4NA==

а так же полу­ча­ем хэш наше­го теле­грам токена:

echo -n "1788359733:AAFf3cK6dfEPHV5e7ePXnHP6x6GHWzEQoSw" | base64
MTc4ODM1OTczMzpBQUZmM2NLNmRmRVBIVjVlN2VQWG5IUDZ4NkdIV3pFUW9Tdw==

созда­ём deployment

cat telegrambot.yml

admin1 - тут ука­зы­ваю хэши id поль­зо­ва­те­лей кото­рые будут заходить
token - тут ука­зы­ва­ем токен наше­го теле­грам бота (хэш)
namespace - тут ука­зы­ва­ем нейм­с­пейс в кото­ром у нас запу­щен prometheus
image - тут ука­зы­ва­ем образ теле­грам­бо­та пере­со­бран­но­го и  загру­жен­но­го в наш гитлаб
- --telegram.admin - тут id поль­зо­ва­те­лей в откры­том виде

можем запус­кать:
kubectl apply -f telegrambot.yml

всё мож­но проверять:
пишем /start
и бот отвечает:

 

6.1 настройка оповещений в telegram, в различные чаты(группы)

Зада­ча - настро­ить опо­ве­ще­ния в раз­ные чаты телеграмма

за осно­ву будет взят теле­грам бот:
https://github.com/inCaller/prometheus_bot
кото­рый был зато­чен под helm chart
https://github.com/gvych/telegram-bot-helm-chart
отме­чу сра­зу что его надо допи­сы­вать в values так как с нуля он не стартует.

при­сту­пим, созда­ём в теле­грам новую группу:

добав­ля­ем наше­го бота кото­ро­го мы созда­ли в преды­ду­щем пунк­те, так как я допол­няю ста­тью поз­же, то имя бота у меня другое:

далее добав­ля­ем к груп­пе бота кото­рый поз­во­лит уви­деть chatid

вот мы полу­чи­ли chatid запом­ним его.

 

Выка­чи­ва­ем репозиторий:

git clone https://github.com/gvych/telegram-bot-helm-chart.git

cd telegram-bot-helm-chart

пра­вим вер­сию для deployment и выслав­ля­ем selector изна­чаль­но их нету в гите, общий вид будет такой:

cat telegram-bot/templates/deployment.yaml

 

так­же пра­вим кон­фиг, что­бы в уве­дом­ле­нии вид­но было alertname, description,  message - по умол­ча­нию их нету в дефолте.

telegram-bot-helm/templates/configmap.yaml

 

теперь пра­вим файл с переменными:

cat telegram-bot/values.yaml

здесь token - это токен наше­го теле­грам бота мы его полу­ча­ем при его реги­стра­ции в botfather

chat_id - это id нашей группы

url: http://alertmanager-operated:9093  это наш адрес alermanager уви­деть его мож­но сле­ду­ю­щим образом:

для каж­дой груп­пы мы будем запус­кать свой теле­грам­бот, вот второй:

cat telegram-bot/values-test.yaml

ста­вим первый:
helm upgrade --install -name telegram-bot-chat-id telegram-bot/ -f telegram-bot/values.yaml --namespace monitoring
и второй:
helm upgrade --install -name telegram-bot-test telegram-bot/ -f telegram-bot/values-test.yaml --namespace monitoring

далее созда­ём своё кастом­ное правило:

cat prometheus-alert-rule.yaml

и вто­рое:

cat prometheus-alert-rule-test.yaml

тут обра­ща­ем вни­ма­ние на раз­ное назва­ние лейблов

team: namespace-my-site

и

team: namespace-test

соглас­но дан­ным лей­б­лам алерт­ме­не­джер будет рас­ки­ды­вать в нуж­ные группы.

смот­рим что дан­ные пра­ви­ла создались:

kubectl -n monitoring get prometheusrules.monitoring.coreos.com

далее пра­вим кон­фиг алерт­ме­не­дже­ра, не забы­ва­ем что в нашем слу­чае это гит:
https://github.com/prometheus-community/helm-charts.git

пра­вим файл:
helm-charts/charts/kube-prometheus-stack/values.yaml

обра­щаю вни­ма­ние, что уста­но­вить несколь­ко типов severity мож­но в таком виде:

severity: "critical|warning"

запись вида:
continue: true
(по умол­ча­нию она false) озна­ча­ет что после пер­во­го сов­па­де­ния надо про­дол­жать роутить сообщения

всё даль­ше мож­но апдейтить:

helm upgrade --install -name prometheus kube-prometheus-stack/ -f kube-prometheus-stack/values.yaml --namespace monitoring

 

6.2. настройка оповещений в telegram разграничение оповещений по группам (исключения уведомлений)

Ввод­ная: есть админ­ский чат и есть чат раз­ра­бот­чи­ков. при настрой­ке как в пунк­те 6.1 уве­дом­ле­ния при­хо­дя­щие в чат раз­ра­бо­чи­ков дуб­ли­ру­ют­ся и в чат админов.

дан­ная ситу­а­ция про­ис­хо­дит вооб­ще пото­му, что alertmanager  со сле­ду­ю­щим конфигом:

име­ет настройку
continue: true  (по дефол­ту false)
бла­го­да­ря кото­рой уве­дом­ле­ния попав под пер­вое пра­ви­ло не пре­кра­ща­ют­ся а отправ­ля­ют­ся даль­ше по route и отправ­ля­ют­ся по дру­гим receiver (когда сов­па­да­ют по label)

ВАЖНО!!!!!!!!!!!!!!  в записи:

пра­ви­ла сов­па­де­ния рабо­та­ют не как OR а как AND (т.е. долж­ны сов­пасть ВСЕ лейблы)

Зада­ча, исклю­чить из чата адми­нов сооб­ще­ния отправ­ля­е­мые в чат раз­ра­бо­чи­ков, что­бы адми­нам при­ле­та­ли все дефолтные

Реше­ние - воз­мож­но тупень­кое но я дру­го­го не нашёл, рабо­тать будет так:

при­ле­та­ет сооб­ще­ние, с лейблами:
severity: "critical"
team: "terminal-soft"

зна­чит оно долж­но попасть толь­ко в груп­пу terminal-soft, поэто­му для receiver: "telegram-terminal-soft"   оставляем
match_re:
team: "terminal-soft"

но так как в уве­дом­ле­нии будет при­те­лать лейбл
severity: "critical"  то он будет попа­дать под сов­па­де­ние receiver: "telegram-admins" у которого
match_re:
severity: "critical|warning"

нам это­го не нуж­но поэто­му для
receiver: "telegram-terminal-soft"
ста­вим  continue: false  и тогда обра­бот­ка сле­ду­ю­щих routes не будет происходить.

вывод перед админ­ским чатом пра­ви­ло долж­но быть с условием:
continue: false
а админ­ский чат послед­ний в списке.

теперь рас­смот­рим всё это по конфигам:

пра­ви­ло по кото­ро­му будет сра­ба­ты­вать алерт:

test.rule.yml

тут обра­ща­ем вни­ма­ние на нали­чие лей­б­ла team: "terminal-soft" и отсут­ствие лей­б­ла severity: critical

 

кон­фиг алерт менеджера:

cat helm-charts/charts/kube-prometheus-stack/values.yaml

тут видим что пред­по­след­нее пра­ви­ло име­ет вид:

- receiver: "telegram-terminal-soft"
group_wait: 10s
repeat_interval: 1h
match_re:
team: "terminal-soft"
continue: false

а послед­нее пра­ви­ло для рабо­ты дефолт­ных пра­вил (кото­рые есть в prometheus  по умолчанию)

- receiver: "telegram-admins"
group_wait: 10s
repeat_interval: 1h
match_re:
severity: "critical|warning"
continue: true

7.Проблема с prometheus-kube-proxy

столк­нул­ся со сле­ду­ю­щей про­бле­мой, после запус­ка про­ме­те­уса не отоб­ра­жа­ют­ся мет­ри­ки с kube-proxy

при­кол в сле­ду­ю­щем, сам kube-proxy стар­та­нул на 127,0,0,1

а про­ме­те­ус лезет на айпиш­ник т.е. щимит­ся на ноды а там ни кто не отвечает:
[root@kub-master-1 charts]# telnet 192.168.1.205 10249
Trying 192.168.1.205…
telnet: connect to address 192.168.1.205: Connection refused

что для исправ­ле­ния дела­ем, НА ВСЕХ НОДАХ пра­вим:

[root@kub-master-1 charts]# vim /etc/kubernetes/kube-proxy-config.yaml
c
metricsBindAddress: 127.0.0.1:10249
на
metricsBindAddress: 0.0.0.0:10249

общий вид у фай­ла такой:

далее пере­за­пус­ка­ем:

[root@kub-master-1 charts]# kubectl delete pod -n kube-system kube-proxy-kub-master-1 kube-proxy-kub-master-2 kube-proxy-kub-master-3 kube-proxy-kub-worker-1 kube-proxy-kub-worker-2
pod "kube-proxy-kub-master-1" deleted
pod "kube-proxy-kub-master-2" deleted
pod "kube-proxy-kub-master-3" deleted
pod "kube-proxy-kub-worker-1" deleted
pod "kube-proxy-kub-worker-2" deleted

Про­ве­ря­ем доступность:

[root@kub-master-1 charts]# telnet 192.168.1.205 10249
Trying 192.168.1.205…
Connected to 192.168.1.205.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

и как видим мет­ри­ки теперь отображаются:

 

8.Настройка алерта для определённого namespace

У меня есть тесто­вый сервис:

cat my-site-ingress.yaml

cat my-site-service.yaml

cat my-site.yaml

при­ме­ня­ем
kubectl create ns my-site
kubectl apply -f my-site-ingress.yaml -f my-site-service.yaml -f my-site.yaml
проверяем

как видим всё ок.
теперь сде­ла­ем так что­бы сер­вис посто­ян­но падал и пере­за­пус­кал­ся, для это­го под­пра­вим в деп­лой­мен­те проверки(readinessProbe/livenessProbe) пор­та не 80 а 81:

и при­ме­ним:

kubectl apply -f my-site.yaml

как видим pod перезапускается:

но не может прой­ти проверки.

посмот­рим что в мет­ри­ках на prometheus:

при­ме­ним promql запрос:

kube_pod_container_status_ready{namespace="my-site"}[5m]

кото­рый смот­рит ста­тус кон­тей­не­ров по namespace my-site за послед­ние 5 минут.

как видим у нас 2 раз­ных име­ни контейнера:
my-deployment-apache-859486bd8c-zk99f   (кото­рый был запу­щен ранее и с ним было всё нормально)
и
my-deployment-apache-85978bf68f-mbwlm (теку­щий, кото­рый был спе­ци­аль­но сло­ман через непра­виль­ные проверки)

теперь нам надо полу­чить резуль­тат, были ли за послед­ние 5 минуть неза­пу­щен­ные кон­тей­не­ры, для это­го исполь­зу­ем сле­ду­ю­щий запрос:

sum_over_time(kube_pod_container_status_ready{namespace="my-site"}[5m]) <1

кото­рый смот­рит были ли кон­тей­не­ры со ста­ту­сом МЕНЬШЕ 1 (т.е. не запу­щен­ные) за 5 минут

для про­вер­ки можем уве­ли­чить вре­мя до 900 минут и гля­нем что он выведет:

как видим таких было 3 контейнера

воз­вра­ща­ем про­вер­ки в деп­лой­мен­те ждём 5 минут и про­ве­ря­ем статус:

как видим за 5 минут упав­ших кон­тей­не­ров не было.

теперь при­вя­жем это к alertmanager.

пра­вим име­ю­ще­е­ся пра­ви­ла прометеуса:

kubectl -n monitoring edit prometheusrules prometheus-kube-prometheus-alertmanager.rules

и в общий спи­сок где пере­чис­ля­ют­ся правила:

добав­ля­ем наше:

выхо­дим сохраняемся.

в про­ме­те­усе пере­хо­дим на вклад­ку alerts и видим наше правило:

всё теперь мож­но сно­ва ломать про­вер­ки в нашем деп­лой­мен­те и про­ве­рять поле­тел ли алерт:

как видим полетел.

про­ве­ря­ем наш теле­грам бот и видим:

в таком вот виде настра­и­ва­ет­ся алертинг.

Теперь рас­смот­рим как нам добав­лять свой алер­тинг а не пра­вить имеющийся.

смот­рим име­ю­щие правила:

добав­ля­ем наше:

cat prometheus-alert-rule.yaml

при­ме­ня­ем:
[root@kub-master-1 ~]# kubectl apply -f prometheus-alert-rule.yaml

про­ве­ря­ем:

как видим наше пра­ви­ло добавилось.

запись вида:
Namespace: {{ $labels.namespace }}
Podname: {{ $labels.pod }}

выве­дет имя нейм­с­пей­са и имя пода.

в теле­гра­ме это будет отоб­ра­жать­ся сле­ду­ю­щим образом:

9.Добавление оповещений и по email

пра­вим файл:
vim charts/kube-prometheus-stack/values.yaml

smtp_smarthost: 10.20.44.56:25  это наш smtp хост через кото­рый мы шлём почту.

receiver: 'email_unixadmins'  - на него будут идти опо­ве­ще­ния вне зави­си­мо­сти от кри­тич­но­сти алер­та, для осталь­ных мож­но выстав­лять уро­вень критичности.

и при­ме­ня­ем:

helm upgrade --install -name prometheus kube-prometheus-stack/ -f kube-prometheus-stack/values.yaml --namespace monitoring

 

10. Настройка графиков в grafana

созда­ём новый дашборд

пере­хо­дим к созда­нию панели

она будет отоб­ра­жать толь­ко наш нейм­с­пейс terminal-soft
созда­дим панель кото­рая будет отоб­ра­жать сколь­ко про­цес­сор­но­го вре­ме­ни исполь­зу­ет namespace
запрос выгля­дит сле­ду­ю­щим образом:

sum(rate(container_cpu_usage_seconds_total{namespace="terminal-soft"}[5m]))

настра­и­ва­ем отображение:

сохра­ня­ем:

 

 

теперь доба­вим panel по исполь­зо­ва­нию опе­ра­тив­ной памя­ти в namespace terminal-soft

так­же созда­ём новую панель, и исполь­зу­ем запрос:

sum(rate(container_memory_usage_bytes{namespace="terminal-soft"}[5m]))

в левой колон­ке ста­вим пара­метр, в чём изме­ря­ем (в нашем слу­чае в байтах)

и настра­и­ва­ем отоб­ра­жа­е­му леген­ду а имен­но мини­маль­ные мак­си­маль­ные зна­че­ние и т.д.

всё мож­но сохраняться

как видим 2 гра­фи­ка у нас уже отоб­ра­жа­ют­ся нормально:

 

теперь отоб­ра­зим заня­тое дис­ко­вое про­стран­ство persistantvolume

созда­ём новую панель

запрос будет выгля­деть сле­ду­ю­щим образом:
(kubelet_volume_stats_capacity_bytes{persistentvolumeclaim="$volume"} - kubelet_volume_stats_available_bytes{persistentvolumeclaim="$volume"}) / kubelet_volume_stats_capacity_bytes{persistentvolumeclaim="$volume"} * 100

у нас пови­лась пере­мен­ная volume  рас­смот­рим как её создать:

пере­хо­дим в настрой­ки dasboard

доба­вим несколь­ко переменных,
пер­вая cluster  запрос:
label_values(kubelet_volume_stats_capacity_bytes, cluster)

не забы­ва­ем ста­вить Hide Variables что­бы в пане­ли он не отображался

вто­рая namespace, запрос:

label_values(kubelet_volume_stats_capacity_bytes{cluster="$cluster", job="kubelet", metrics_path="/metrics"}, namespace)

и тре­тья volume запрос:

label_values(kubelet_volume_stats_capacity_bytes{cluster="$cluster", job="kubelet", metrics_path="/metrics", namespace="$namespace"}, persistentvolumeclaim)

вот наши 3 переменные:

теперь смот­рим на нашу панель:

добав­ля­ем legend в опи­са­нии пишем {{namespace}} (чтоб отоб­ра­жал­ся наш неймспейс)

так­же видим что ввер­ху появи­лись НЕ СКРЫТЫЕ пере­мен­ные кото­рые мы можем выбирать.

 

Отоб­ра­же­ние сети (входящий/исходящий трафик)

исполь­зу­ем 2 метрики:
вхо­дя­щий тра­фик для namespace terminal soft:
sum(rate(container_network_receive_bytes_total{pod=~"deployment.+",namespace="terminal-soft"}[1m]))

исхо­дя­щий тра­фик для namespace terminal soft:
sum(rate(container_network_transmit_bytes_total{pod=~"deployment.+",namespace="terminal-soft"}[1m]))

 

 

Отоб­ра­же­ние кодов отве­та на nginx ingress controller

созда­ём ещё одну панель.

дёр­га­ем метрику:

sum(increase(nginx_ingress_controller_request_duration_seconds_count{namespace="terminal-soft"}[1m])) by (status) > 0

в каче­стве legend ставим
{{status}} code

мож­но сохранять.


ещё доба­вим несколь­ко гра­фи­ков для отоб­ра­же­ния коли­че­ства отве­тов по статусам

200(2**)
300(3**)
400(4**)
500(5**)

созда­ём панель и добав­ля­ем запрос:
sum(increase(nginx_ingress_controller_requests{namespace="terminal-soft",status=~"2.*"}[1m]))


добав­ля­ем ещё несколь­ко пане­лей запро­сы будут ана­ло­гич­ны первому:

sum(increase(nginx_ingress_controller_requests{namespace="terminal-soft",status=~"3.*"}[1m]))

sum(increase(nginx_ingress_controller_requests{namespace="terminal-soft",status=~"4.*"}[1m]))

sum(increase(nginx_ingress_controller_requests{namespace="terminal-soft",status=~"5.*"}[1m]))

по ито­гу у нас полу­чил­ся вот такой dasboard

 

 

 

рассмотрим ещё один дашборд где при выборе namespace будут отображаться Проц/оперативка/сеть  как на весь неймспейс так и на каждый под в отдельности

 

вот так оно будет выгля­деть по итогу

пере­хо­дим в настройки:

далее созда­ём переменные:

cluster
label_values(kube_pod_info, cluster)

namespace
label_values(kube_pod_info{cluster="$cluster"}, namespace)

перей­дём к настрой­ке самих даш­бор­дов - пер­вый по перативке:

sum(rate(container_memory_usage_bytes{namespace="$namespace"}[5m]))
all MEMORY in $namespace

sum(rate(container_memory_working_set_bytes{namespace="$namespace", container!="", image!=""}[5m])) by (pod)
{{pod}}

далее проц

sum(rate(container_cpu_usage_seconds_total{namespace="$namespace"}[5m]))
all CPU in $namespace

sum(rate(container_cpu_usage_seconds_total{namespace="$namespace", container!="", image!=""}[5m])) by (pod)
{{pod}}

 

далее рас­смот­рим сеть:

sum(rate(container_network_receive_bytes_total{namespace="$namespace"}[1m]))
INPUT in ALL $namespace

sum(rate(container_network_transmit_bytes_total{namespace="$namespace"}[1m]))
OUTPUT in ALL $namespace

sum(rate(container_network_receive_bytes_total{namespace="$namespace", container!="", image!=""}[5m])) by (pod)
input in {{pod}}

sum(rate(container_network_transmit_bytes_total{namespace="$namespace", container!="", image!=""}[5m])) by (pod)
output in {{pod}}