В продолжение поста Kubernetes: мониторинг с Prometheus, в котором мы настроили мониторинг вручную, и более-менее разобрались с тем, как оно всё внутри работает – теперь попробуем прикрутить Prometheus Operator из Helm-репозитория.

Напомню, задача – поднять Prometheus и все необходимые експортёры в AWS Elastic Kubernetes Cluster, и с него через /federation передавать метрики на наш “центровой” Prometheus, где уже есть Alertmanager и Grafana.

Смутил целый набор чартов – есть просто Prometheus, есть kube-prometheus, есть prometheus-operator, причём от разных разработчиков:

• Bitnami Prometheus Operator – https://github.com/bitnami/charts/tree/master/bitnami/prometheus-operator/
• CoreOS Prometheus Operator – https://github.com/coreos/prometheus-operator
• Helm Community Prometheus Operator – https://github.com/prometheus-community/helm-charts
• CoreOS kube-prometheus – https://github.com/coreos/kube-prometheus
• И “просто Prometheus” – https://github.com/helm/charts/tree/master/stable/prometheus

Хотя в репозитории находится только один prometheus-operator:

Разница между stable/prometheus и stable/prometheus-operator в том, что в Operator включена Grafana с набором готовых дашборд и набор ServiceMonitors для сбора метрик с сервисов кластера, таких как CoreDNS, API Server, Scheduler, etc.

Собственно – используем stable/prometheus-operator.

Prometheus Operator deployment

Деплоим:

Проверяем поды:

Note: alias kk="kubectl" >> ~/.bashrc

Итак, Prometheus Operator деплоит нам целый набор сервисов – и сам Prometheus, и Alertmanager, и Grafana, плюс набор ServiceMonitors:

Роль ServiceMonitors рассмотрим ниже, когда будем добавлять свой ServiceMonitor в Добавление сервиса в мониторинг.

Grafana access

Пока всё это тестируем – пробросим порт на Grafana, что бы посмотреть какие дашборды там есть.

Находим под с Grafana:

И вызываем port-forward:

Открываем в браузере localhost:3000, логинимся с admin и паролем prom-operator, и получаем целый набор готовых графиков, например:

На момент написания – Prometheus Operator запускал Grafana 7.0.3 (на нашем “центровом” сервере мониторинга всё ещё 6.5).

Собственно, из всего этого в будущем просто можно будет надёргать примеров всяких запросов.

На сейчас нам тут не нужны ни сама Grafana, ни Alertmanager, так что попозже мы их выпилим.

Prometheus Operator configuration

Prometheus Operator использует Custom Resource Definitions, которые описывают ресурсы:

Например, в prometheuses.monitoring.coreos.com описывается Custom Resource с именем Prometheus:

И далее к нему можно обращаться, как к обычному ресурсу Kubernetes, используя имя из names:

Нам тут интересно значение serviceMonitorSelector:

...
serviceMonitorSelector: 
  matchLabels:
    release: prometheus

Которое определяет какие ServiceMonitors будут включены под “наблюдение” Prometheus.

Добавление сервиса в мониторинг

Теперь попробуем добавить новый сервис в наш мониторинг:

1. запустим Redis server
2. запустип redis_exporter
3. добавим ServiceMonitor
4. настроим Prometheus Operator использование этого ServiceMonitor для сбора метрик с експортёра

Запуск Redis server

Создаём неймспейс, что бы максимально приблизить условия к “боевым”, когда мониторинг и приложения работают не в одном default namespace, а в разных:

Запускаем Redis:

Создаём для него сервис:

Проверяем:

Окей – сам Redis работает, добавляем его експортер.

Запуск redis_exporter

Запускаем из Helm:

Проверяем его сервис:

Его ендпоинт:

Поверим доступ к метрикам – запустим дебаг-под с Debian, устанавливаем в нём curl:

И обращаемся к ендпоинту сервиса redis_exporter:

Либо без дополнительного пода – делаем port-forward на redis-svc:

И проверяем с локальной машины:

Хорошо – у нас есть приложение – Редис, есть его експортёр, который отдаёт нам метрики на порту 9121 по URI /metrics – теперь надо настроить Prometheus Operator на сбор метрик с него.

Создание Kubernetes ServiceMonitor

Проверим лейблы нашего redis_exporter:

И ещё раз глянем селектор serviceMonitorSelector ресурса prometheus:

В конце манифеста находим:

...
serviceMonitorSelector: 
  matchLabels:
    release: prometheus

Т.е. Prometheus ищет ServiceMonitor-ы с тегом release, у которых значение prometheus.

Далее – создаём ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    serviceapp: redis-servicemonitor
    release: prometheus
  name: redis-servicemonitor
  namespace: monitoring
spec:
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 15s
    port: redis-exporter
  namespaceSelector:
    matchNames:
    - monitoring
  selector:
    matchLabels:
      release: redis-exporter

В его labels задаём release: prometheus, что бы Prometheus его обнаружил, а в selector.matchLabels – указываем поиск сервисов с тегом release: redis-exporter.

Применяем:

И проверяем таргеты Prometheus:

Метрики Редиса:

Что надо дальше?

А дальше надо выпилить из Operator запуск Alertmanager и Grafana.

Prometheus Operator Helm deployment и конфигурация сервисов

Хотя – а зачем выпиливать Графану? Там уже есть пачка готовых дашборд – пусть остаётся.

Давайте сделаем иначе:

• на каждый EKS кластер выкатываем Operator с Grafana, но без Alertmanager
• на локальных кластеру Prometheus retention period для хранения метрик используем дефолтный – 2 недели, и локальные Grafana будут выводить графики за две недели
• Alertmanager выпиливаем – будем использовать его с центрального сервера мониторинга – там уже настроены роуты, каналы, и прочее – надо будет только добавить алерты
• центральный сервер мониторинга хранит метрики год, и там нарисуем свою дашборду(ы) Grafana

Значит надо будет создать два LoadBalancer – один с типом internet-facing для Grafana, и один для Prometheus – internal, т.к. к Prometheus в кластере будет ходить “центральный” Prometheus через AWS VPC Peering, и с /federation забирать у него метрики.

И всё это надо заинтегрировать с нашей автоматизацией – Ansible, см. AWS Elastic Kubernetes Service: — автоматизация создания кластера, часть 2 — Ansible, eksctl.

Но сначала сделаем вручную, конечно.

Итак, что нам надо изменить в дефолтном деплое Prometheus Operator?

• убрать деплой Alertmanager
• добавить настройки для:
  • Prometheus и Grafana – должны деплоится за LoadBalancer
  • логин-пароль для Grafana

Дальше смотрим доступные параметры в документации – https://github.com/helm/charts/tree/master/stable/prometheus-operator.

Пока начнём с того, что передеплоим стек без Алертменеджера, для этого надо передать alertmanager.enabled.

Проверяем под сейчас:

Редеплоим, через --set задаём alertmanager.enabled=false:

Проверяем поды ещё раз – Алертменеджера нет, отлично.

Настройка LoadBalancer

Итак, мы хотим открыть доступ из мира к Grafana – значит нужен будет ресурс Ingress для неё, и отдельный Ingress для Prometheus.

Что есть в доке:

Добавляем Ingress для Графаны:

Эм…

Думаете – в документации указано как его настроить? Счас…

Пригорает от такой “документации” иногда.

Какую-то подсказку удалось нагуглить тут: https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/advanced.html#ingress

Пробуем – теперь уже через values.yaml, что бы не городить кучу --set, добавляем hosts:

grafana:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"
      alb.ingress.kubernetes.io/scheme: "internet-facing"
    hosts:
      - "dev-0.eks.monitor.example.com"

Деплоим:

И смотрим логи ALB Controller:

I0617 11:37:48.272749       1 tags.go:43] monitoring/prometheus-grafana: modifying tags {  ingress.k8s.aws/cluster: “bttrm-eks-dev-0”,  ingress.k8s.aws/stack: “monitoring/prometheus-grafana”,  kubernetes.io/service-name: “prometheus-grafa
na”,  kubernetes.io/service-port: “80”,  ingress.k8s.aws/resource: “monitoring/prometheus-grafana-prometheus-grafana:80”,  kubernetes.io/cluster/bttrm-eks-dev-0: “owned”,  kubernetes.io/namespace: “monitoring”,  kubernetes.io/ingress-name
: “prometheus-grafana”} on arn:aws:elasticloadbalancing:us-east-2:534***385:targetgroup/96759da8-e0b8253ac04c7ceacd7/35de144cca011059
E0617 11:37:48.310083       1 controller.go:217] kubebuilder/controller “msg”=”Reconciler error” “error”=”failed to reconcile targetGroups due to failed to reconcile targetGroup targets due to prometheus-grafana service is not of type NodePort or LoadBalancer and target-type is instance”  “controller”=”alb-ingress-controller” “request”={“Namespace”:”monitoring”,”Name”:”prometheus-grafana”}

Хорошо – давайте добавим /target-type: "ip", что бы AWS ALB слал трафик прямо на под с Grafana, а не на WorkerNodes, заодно добавим валидные коды ответов:

grafana:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"  
      alb.ingress.kubernetes.io/scheme: "internet-facing"
      alb.ingress.kubernetes.io/target-type: "ip"
      alb.ingress.kubernetes.io/success-codes: 200,302
    hosts:
      - "dev-0.eks.monitor.example.com"

Либо, что бы использовать Instance type – можно переопределить тип Service для Grafana, и задать его в NodePort:

grafana:
  service:
    type: NodePort
    port: 80
    annotations: {}
    labels: {}  
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"
      alb.ingress.kubernetes.io/scheme: "internet-facing"
      alb.ingress.kubernetes.io/success-codes: 200,302
    hosts:
      - "dev-0.eks.monitor.example.com"

Передеплоиваем:

Через минуту поднялся ALB:

Но теперь при открытии страницы dev-0.eks.monitor.example.com – ALB отдаёт 404:

Что тут происходит?

1. ALB принимает запрос к dev-0.eks.monitor.example.com, отправляет его на TargetGroup с Grafana
2. Grafana возвращает 302 /login
3. мы возвращаемся к ALB, но теперь в URI передаём /login

Проверяем правила Listener:

Ну, да – а в правилах балансера на все запросы кроме / мы возвращаем 404. Соответсвенно, и на /login тоже возвращается 404.

Очень хотелось бы увидеть комментарии разработчика, который дефолтным рулом path задал именно такое.

Возвращаемся к нашему values.yaml, добавляем path равным /*.

А hosts, что бы избежать ошибки “Invalid value: []networking.IngressRule(nil): either `backend` or `rules` must be specified” и не привязываться к конкретному домену можно задать просто в виде "":

grafana:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: "alb"
      alb.ingress.kubernetes.io/target-type: "ip"
      alb.ingress.kubernetes.io/scheme: "internet-facing"
      alb.ingress.kubernetes.io/success-codes: 200,302
    hosts:
      - ""
    path: /*

Редеплоим, проверяем:

И открываем в браузере:

Prometheus и Lens

И даже в Lens появились все графики вместо ошибок “Metrics are not available due to missing or invalid Prometheus configuration” и “Metrics not available at the moment“:

В целом – на этом, думаю, всё основное рассмотрели.

Можно прикручивать автоматизацию, и выкатывать в тестирование.

Ссылки по теме

• Kubernetes monitoring with Prometheus – Prometheus operator tutorial
• Prometheus Operator – Installing Prometheus Monitoring Within The Kubernetes Environment
• Quick Start with Prometheus Monitoring
• Prometheus Operator — How to monitor an external service
• How to Set Up DigitalOcean Kubernetes Cluster Monitoring with Helm and Prometheus Operator
• Configuring prometheus-operator helm chart with AWS EKS
• Zero to JupyterHub with Kubernetes
• Howto expose prometheus, grafana and alertmanager with nginx ingress
• Howto expose prometheus, grafana and alertmanager with nginx ingressEKS: failed to reconcile targetGroups due to failed to load serviceAnnotation due to no object matching key