- PVSM.RU - https://www.pvsm.ru -
В основу этой статьи легла наша внутренняя документация для DevOps-инженеров, объясняющая, как работает Prometheus под управлением Prometheus Operator в разворачиваемых и обслуживаемых кластерах Kubernetes.
С первого взгляда Prometheus [1] может показаться достаточно сложным продуктом, но, как и любая хорошо спроектированная система, она состоит из явно выраженных функциональных компонентов и по сути делает всего три вещи: а) собирает метрики, б) выполняет правила, в) сохраняет результат в базу данных временных рядов (time series). Статья посвящена не столько самому Prometheus, сколько интеграции этой системы с Kubernetes, для чего мы активно используем вспомогательный инструмент под названием Prometheus Operator [2]. Но начать всё же необходимо с самого Prometheus…
Итак, если подробнее остановиться на двух первых функциях Prometheus, то они работают следующим образом:
scrape_interval
, выполняется HTTP-запрос к этой цели. В ответ получаются метрики в своём формате [3], которые сохраняются в базу.evaluation_interval
обрабатываются правила (rules), на основании которых:
У сервера Prometheus есть config и rule files (файлы с правилами).
В config имеются следующие секции:
scrape_configs
— настройки поиска целей для мониторинга (подробнее см. в следующем разделе);rule_files
— список директорий, где лежат правила, которые необходимо загружать:
rule_files:
- /etc/prometheus/rules/rules-0/*
- /etc/prometheus/rules/rules-1/*
alerting
— настройки поиска Alertmanager'ов, в которые отправляются алерты. Секция очень похожа на scrape_configs
с тем отличием, что результатом её работы является список endpoints, в которые Prometheus будет отправлять алерты.Общий алгоритм работы Prometheus выглядит следующим образом:
scrape_configs
, согласно которой настраивает свой внутренний механизм обнаружения сервисов (Service Discovery).
В scrape_configs
указан список scrape job'ов (это внутреннее понятие Prometheus), каждый из которых определяется следующим образом:
scrape_configs:
# Общие настройки
- job_name: kube-prometheus/custom/0 # просто название scrape job'а
# показывается в разделе Service Discovery
scrape_interval: 30s # как часто собирать данные
scrape_timeout: 10s # таймаут на запрос
metrics_path: /metrics # path, который запрашивать
scheme: http # http или https
# Настройки Service Discovery
kubernetes_sd_configs: # означает, что targets мы получаем из Kubernetes
- api_server: null # использовать адрес API-сервера из переменных
# окружения (которые есть в каждом поде)
role: endpoints # targets брать из endpoints
namespaces:
names: # искать endpoints только в этих namespaces
- foo
- baz
# Настройки "фильтрации" (какие enpoints брать, какие — нет) и "релейблинга"
# (какие лейблы добавить или удалить — для всех получаемых метрик)
relabel_configs:
# Фильтр по значению лейбла prometheus_custom_target,
# полученного из service, связанного с endpoint
- source_labels: [__meta_kubernetes_service_label_prometheus_custom_target]
regex: .+ # подходит любой НЕ пустой лейбл
action: keep
# Фильтр по имени порта
- source_labels: [__meta_kubernetes_endpoint_port_name]
regex: http-metrics # подходит, если порт называется http-metrics
action: keep
# Добавляем лейбл job, используем значение лейбла prometheus_custom_target
# у service, к которому добавляем префикс "custom-"
#
# Лейбл job — служебный в Prometheus. Он определяет название группы,
# в которой будет показываться target на странице targets, а также он будет
# у каждой метрики, полученной у этих targets (чтобы можно было удобно
# фильтровать в rules и dashboards)
- source_labels: [__meta_kubernetes_service_label_prometheus_custom_target]
regex: (.*)
target_label: job
replacement: custom-$1
action: replace
# Добавляем лейбл namespace
- source_labels: [__meta_kubernetes_namespace]
regex: (.*)
target_label: namespace
replacement: $1
action: replace
# Добавляем лейбл service
- source_labels: [__meta_kubernetes_service_name]
regex: (.*)
target_label: service
replacement: $1
action: replace
# Добавляем лейбл instance (в нём будет имя пода)
- source_labels: [__meta_kubernetes_pod_name]
regex: (.*)
target_label: instance
replacement: $1
action: replace
Таким образом, Prometheus сам отслеживает:
Изменение конфига требуется в следующих случаях:
Разобравшись с основами Prometheus, перейдём к его «оператору» — специальному вспомогательному компоненту для Kubernetes, упрощающему развёртывание и эксплуатацию Prometheus в реалиях кластера.
Для пресловутого «упрощения», во-первых, в Prometheus Operator с помощью механизма CRD (Custom Resource Definitions [4]) заданы три ресурса:
prometheus
[5] — определяет инсталляцию (кластер) Prometheus;servicemonitor
[6] — определяет, как мониторить набор сервисов (т.е. собирать их метрики);alertmanager
[7] — определяет кластер Alertmanager'ов (мы ими не пользуемся, поскольку отправляем метрики напрямую в свою систему уведомлений, которая принимает, агрегирует и ранжирует данные из множества источников — в том числе, интегрируется со Slack и Telegram).
Во-вторых, оператор следит за ресурсами prometheus
и генерирует для каждого из них:
prometheus.yaml
(конфиг Prometheus) и configmaps.json
(конфиг для prometheus-config-reloader
).
Наконец, оператор также следит за ресурсами servicemonitor
и за ConfigMaps с правилами, и на их основании обновляет конфиги prometheus.yaml
и configmaps.json
(они хранятся в секрете).
Под состоит из двух контейнеров:
prometheus
— сам Prometheus;prometheus-config-reloader
— обвязка [8], которая следит за изменениями prometheus.yaml
и при необходимости вызывает reload конфигурации Prometheus (специальным HTTP-запросом — см. подробнее ниже), а также следит за ConfigMaps с правилами (они указаны в configmaps.json
— см. подробнее ниже) и по необходимости скачивает их и перезапускает Prometheus.
Под использует три тома (volumes):
config
— примонтированный секрет (два файла: prometheus.yaml
и configmaps.json
). Подключён в оба контейнера;rules
— emptyDir
, который наполняет prometheus-config-reloader
, а читает prometheus
. Подключён в оба контейнера, но в prometheus
— в режиме только для чтения;data
— данные Prometheus. Подмонтирован только в prometheus
.
prometheus
(подробнее см. в документации [9]).any: true
), Prometheus Operator вычисляет (обращаясь к Kubernetes API) список пространств имён, в которых есть Services, подходящие под лейблы, указанные в Service Monitor.servicemonitor
(см. документацию [10]) и на основании вычисленных пространств имён, Prometheus Operator генерирует часть конфига (секцию scrape_configs
) и сохраняет конфиг в соответствующий секрет.prometheus.yaml
обновляется).prometheus-config-reloader
, который по HTTP отправляет запрос в Prometheus на перезагрузку.scrape_configs
, которые обрабатывает уже согласно своей логике работы (см. подробнее выше).
ruleSelector
, указанный в ресурсе prometheus
.prometheus.yaml
, после чего срабатывает логика, в точности соответствующая обработке Service Monitors (см. выше).configmaps.json
(в нём указан список ConfigMaps и их контрольные суммы).configmaps.json
обновляется).prometheus-config-reloader
, который скачивает изменившиеся ConfigMaps в директорию rules
(это emptyDir
).prometheus-config-reloader
отправляет по HTTP запрос в Prometheus на перезагрузку.Подробнее о том, как мы используем Prometheus (и не только) для мониторинга в Kubernetes, я планирую рассказать [11] на конференции RootConf 2018 [12], что будет проходить 28 и 29 мая в Москве, — приходите послушать и пообщаться.
Читайте также в нашем блоге:
Автор: distol
Источник [19]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/278669
Ссылки в тексте:
[1] Prometheus: https://prometheus.io/
[2] Prometheus Operator: https://github.com/coreos/prometheus-operator
[3] своём формате: https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-format-details
[4] Custom Resource Definitions: https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions
[5] prometheus
: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheus
[6] servicemonitor
: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#servicemonitor
[7] alertmanager
: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#alertmanager
[8] обвязка: https://github.com/coreos/prometheus-operator/tree/master/contrib/prometheus-config-reloader
[9] документации: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec
[10] документацию: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#servicemonitorspec
[11] планирую рассказать: http://rootconf.ru/moscow-rit/2018/abstracts/3507
[12] RootConf 2018: http://rootconf.ru/moscow-rit/2018
[13] Операторы для Kubernetes: как запускать stateful-приложения: https://habrahabr.ru/company/flant/blog/326414/
[14] Мониторинг с Prometheus в Kubernetes за 15 минут: https://habrahabr.ru/company/flant/blog/340728/
[15] Истории успеха Kubernetes в production. Часть 4: SoundCloud (авторы Prometheus): https://habrahabr.ru/company/flant/blog/339724/
[16] Представляем loghouse — Open Source-систему для работы с логами в Kubernetes: https://habrahabr.ru/company/flant/blog/341386/
[17] Наш опыт с Kubernetes в небольших проектах: https://habrahabr.ru/company/flant/blog/331188/
[18] Инфраструктура с Kubernetes как доступная услуга: https://habrahabr.ru/company/flant/blog/341760/
[19] Источник: https://habrahabr.ru/post/353410/?utm_campaign=353410
Нажмите здесь для печати.