Хабрахабр

[Перевод] Мониторинг кластера Kubernetes при помощи Prometheus

Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

Не забудьте пожалуйста поучаствовать в опросе.
Мониторинг кластера Kubernetes – очень важное дело. Полагаем, что следующая остановка на этом пути — книга о Prometheus, поэтому сегодня предлагаем вашему вниманию перевод небольшой статьи Бьёрна Венцеля о тесном взаимодействии Prometheus и Kubernetes. Какой контейнер сколько ресурсов расходует? В кластере содержится масса информации, позволяющей ответить на вопросы из разряда: сколько сейчас в наличии памяти, дискового пространства, как активно используется cpu? Также сюда относятся вопросы о состоянии приложений, работающих в кластере.

Его поддерживает фонд Cloud Native Computing Foundation, исходно Prometheus разрабатывался в компании SoundCloud. Один из состоявшихся инструментов для такой работы называется Prometheus. Концептуально Prometheus очень прост:

Архитектура

Сервер Prometheus может работать, например, в кластере Kubernetes и получать конфигурацию через специальный файл. Такая конфигурация, в частности, содержит информацию о том, где находится терминал, с которого нужно собрать данные по истечении указанного интервала. Затем сервер Prometheus запрашивает с этих терминалов метрики в специальном формате (обычно они доступны по адресу /metrics) и сохраняет их в базе данных временных рядов. Ниже приведен краткий пример: небольшой конфигурационный файл, запрашивающий метрики у модуля node_exporter, развертываемого в качестве агента на каждом узле:

scrape_configs: - job_name: "node_exporter" scrape_interval: "15s" target_groups: - targets: ['<ip>:9100']

Сначала определяем имя задания job_name, позже по этому имени можно запрашивать метрики в Prometheus, затем интервал снятия данных scrape_interval и группу серверов, на которых работает node_exporter. Теперь Prometheus будет каждые 15 секунд запрашивать у сервера путь path /metrics к актуальным метрикам. Выглядит примерно так:

# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds 1.4852e-05
go_gc_duration_seconds{quantile="0.25"} 2.0702e-05
go_gc_duration_seconds{quantile="0.5"} 2.2059e-05
...

Сначала дается название метрики, затем подписи (информация в фигурных скобках) и, наконец, значение метрики. Самое интересное — функция поиска по этим метрикам. Для этой цели в Prometheus есть очень мощный язык запросов.

Если Prometheus не может снять метрики сам, то существует и другая функциональность под названием pushgateway. Основная идея Prometheus, уже описанная выше, такова: Prometheus с заданным интервалом опрашивает порт по поводу метрик и сохраняет их в базе данных временных рядов. Шлюз pushgateway принимает метрики, присланные внешними заданиями, а Prometheus с заданным интервалом собирает информацию с этого шлюза.

Компонент alertmanager позволяет задавать пределы, и в случае их превышения посылать уведомления по электронной почте, slack или opsgenie. Еще один опциональный компонент архитектуры Prometheus – это alertmanager.

Также в нем есть множество экспортеров, например, вышеупомянутый node_exporter. Кроме того, сервер Prometheus содержит множество интегрированных возможностей, например, может запрашивать на Amazon API инстансы ec2 или запрашивать у Kubernetes поды, узлы и сервисы. Такие экспортеры могут работать, к примеру, на узле, где установлено приложение вроде MySQL и с заданным интервалом опрашивать приложение по поводу метрик и предоставлять их на терминале /metrics, а сервер Prometheus может собирать оттуда эти метрики.

Есть, к примеру, такая библиотека, разработанная Prometheus для экспорта таких метрик. Кроме того, не составляет труда написать собственный экспортер – например, для приложения, предоставляющего такие метрики, как информация jvm. Вот пример со страницы client_java: Эта библиотека может использоваться в сочетании со Spring, а также позволяет вам определять собственные метрики.

@Controller
public class MyController { @RequestMapping("/") @PrometheusTimeMethod(name = "my_controller_path_duration_seconds", help = "Some helpful info here") public Object handleMain() { // Делаем что-либо }
}

Это метрика, описывающая длительность метода, а другие метрики теперь можно предоставлять через терминал или проталкивать через pushgateway.

Использование в кластере Kubernetes

Как я уже упоминал, для использования Prometheus в кластере Kubernetes есть интегрированные возможности для снятия информации с пода, узла и сервиса. Самое интересное, что Kubernetes специально спроектирован для работы с Prometheus. Например, kubelet и kube-apiserver предоставляют метрики, доступные для чтения в Prometheus, поэтому организовать мониторинг очень просто.

В этом примере для начала я использую официальный helm-чарт.

Во-первых, мне нужно было активировать rbac в установке Prometheus, в противном случае Prometheus был не в состоянии собирать информацию с kube-apiserver. Для себя я немного изменил конфигурацию helm-чарта, устанавливаемого по умолчанию. Поэтому я написал собственный файл values.yaml, в котором описано, как должен отображаться helm-чарт.

Я внес самые простые изменения:

  1. alertmanager.enabled: false, то есть отменил развертывание alertmanager в кластере (я не собирался использовать alertmanager, думаю, предупреждения проще сконфигурировать при помощи Grafana)
  2. kubeStateMetrics.enabled: false думаю, эти метрики возвращают лишь некоторую информацию о предельном количестве подов. При первом запуске системы эта информация мне не важна
  3. server.persistentVolume.enabled: false пока у меня по умолчанию не сконфигурирован персистентный том
  4. Я изменил в Prometheus конфигурацию сбора информации, как это сделано в pull-реквесте на github. Дело в том, что в Kubernetes v1.7 метрики cAdvisor работают на другом порте.

После этого можно запустить Prometheus при помощи helm:

helm install stable/prometheus --name prometheus-monitoring -f prometheus-values.yaml

Теперь можно перейти в графический веб-интерфейс Prometheus и посмотреть некоторую информацию: Так мы установим сервер Prometheus, и на каждом узле – установим под node_exporter.

kubectl port-forward <prometheus-server-pod> 9090

На следующем скриншоте показано, с каких целей Prometheus собирает информацию (Status/targets), и когда в последние несколько раз снималась информация:

Можно посмотреть метрики подробно, перейдя в Graph и написав запрос для просмотра интересующей нас информации: Здесь видно, как Prometheus запрашивает метрики у apiserver, узлов, cadvisor, работающего на узлах и у конечных точек сервисов kubernetes.

В нижней части схемы заметны подписи, добавляемые Prometheus или уже доступные у node_exporter. Здесь, например, мы видим свободное хранилище в точке монтирования “/”. Мы используем эти подписи, чтобы запрашивать только точку монтирования “/”.

Настраиваемые метрики с аннотациями

Как уже было показано на первом скриншоте, где выведены цели, с которых Prometheus запрашивает метрики, также существует метрика для пода, работающего в кластере. Одна из приятных фич Prometheus – это возможность снимать информацию с целых подов. Если контейнер в поде предоставляет метрики Prometheus, то мы можем собирать эти метрики при помощи Prometheus автоматически. Единственное, о чем еще нам нужно позаботиться – снабдить установку двумя аннотациями; в моем случае nginx-ingress-controller делает это «из коробки»:

apiVersion: extensions/v1beta1
kind: Deployment
metadata: name: nginx-ingress-controller namespace: ingress-nginx
spec: replicas: 1 selector: matchLabels: app: ingress-nginx template: metadata: labels: app: ingress-nginx annotations: prometheus.io/port: '10254' prometheus.io/scrape: 'true'
...

Здесь мы видим, что шаблон развертывания снабжается двумя аннотациями Prometheus. Первая описывает порт, через который Prometheus должен запрашивать метрики, а вторая активирует функционал сбора данных. Теперь Prometheus запрашивает у Kubernetes Api-Server поды, аннотированные для сбора информации, и пытается собрать информацию с терминала /metrics.

Работа в федеративном режиме

У нас есть проект, в котором Prometheus используется в федеративном режиме. Идея такова: мы собираем лишь ту информацию, что доступна только изнутри кластера (или эту информацию проще собрать именно изнутри кластера), включаем федеративный режим и получаем эту информацию при помощи второго Prometheus, установленного вне кластера. Таким образом удается собирать информацию сразу с нескольких кластеров Kubernetes, также захватывая и другие компоненты, не доступные изнутри данного кластера или не касающиеся этого кластера. Вдобавок, затем не приходится долговременно хранить в кластере собранные данные и, если с кластером что-то пойдет не так, мы сможем собрать некоторую информацию, например, node_exporter, и извне кластера.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть