В начале не было ничего. И создал DevOps кластер Kubernetes и сказал, что это есть хорошо. Но пришли злые программисты и начали требовать информацию о том, сколько ресурсов потребляют их контейнеры.
Привет, Хабр! Меня зовут Юра, я DevOps-инженер команды разработчиков платформы контейнеризации dBrain. В этой статье рассмотрим различия между статической и динамической конфигурацией в vmagent от Victoria Metrics (как мы собирали свой универсальный стек системы мониторинга, читайте здесь).
Если имеешь маленький кластер, то хочется схитрить и сделать его обслуживание быстрым и легким, но как говорится, всегда есть нюанс. Когда наши кластеры состояли всего из нескольких нод, конфигурация для сбора метрик была статической. Это казалось удобным и простым, но все рано или поздно приходится пересматривать.
Начнем с технической части. Стек Victoria Metrics в кластерной версии выглядит следующим образом: vmagent, vminsert, vmselect, vmstorage, vmalert, vmauth (опционально).
Конечно, найдутся те, кто спросит: “А как же vmgateway, vmrestore, vmbackup, vmmanager и прочие vm’ы”? Мы им ответим, что шекели не бесконечные и их нужно экономить.
Приступим к обзору. На мой взгляд, архитектура стека Victoria Metrics больше укладывается в современные реалии, чем стандартный Prometheus, где сбор, хранение и пересылка метрик заложены внутри самой системы мониторинга.
vmagent - сбор, релейблинг и пересылка метрик;
vminsert - прием метрик (если хотите отказоустойчивость, то репликация и запись в базу);
vmselect - чтение из базы метрик;
vmstorage - база метрик;
vmalert - алертинг и рекординг (легальный способ сделать мультиретеншен, но об этом в следующих статьях);
vmauth - auth прокси.
Этого набора компонентов достаточно для покрытия уймы требований к стеку мониторинга. Осталось только заставить их работать сообща.
Статическая или динамическая конфигурация?
Сегодня разберем vmagent. Статическая конфигурация:
- job_name: foo
static_configs:
- targets: ["x.x.x.1:8429"]Простейшая джоба для сбора метрик с vmagent с условным адресом x.x.x.1. Выглядит круто: три строки - и готово. Здесь я, конечно, согласен. А если у нас появится еще парочка vmagent’ов? Мы просто добавим их в конфигурацию. Допустим, появился vmagent-1 и vmagent-2.
- job_name: foo
static_configs:
- targets: ["x.x.x.1:8429", "x.x.x.2:8429", "x.x.x.3:8429"]Что ж, ничего сложного пока нет. Идем дальше. С тремя vmagent’ами справились, но как быть с пользовательской нагрузкой?
Добавим джобу и для пользовательской нагрузки:
- job_name: client-1
static_configs:
- targets: ["x.x.x.y:8429"]
- job_name: client-2
static_configs:
- targets: ["x.x.x.z:8429"]
- job_name: foo
static_configs:
- targets: ["x.x.x.1:8429", "x.x.x.2:8429", "x.x.x.3:8429"]Тоже кажется, что проблем нет. Подумаешь, пару секций, все же здорово, зачем нам хваленая динамическая конфигурация?
Тогда смоделируем более приближенную к реальной ситуацию. Например, нужно мониторить поды, которые при рестартах меняют свои ip, скажем, их будет 20. Что же делать в этой ситуации? Ответ один: переходить на динамическую конфигурацию - kubernetes_sd_config.
Статическая конфигурация хороша, когда целей немного и адреса не меняются. К плюсам статической конфигурации можно отнести простоту и удобство. Нужно добавить на тестовом окружении стороннюю точку сбора метрик, временный сервер для тестов, url на проверку? Добро пожаловать в статическую конфигурацию.
При настройке мониторинга внутри Kubernetes будем разбираться с динамической конфигурацией. Суть проста. Берем целевой ресурс (сервисы, поды, ноды или что-нибудь другое из доступных опций конфига) и фильтруем по заданным правилам. Выполняем несколько магических манипуляций с релейблингом, редактируем адреса - и готово: получаем только нужные нам для сбора цели.
Для разнообразия вставлю список vmagent динамических конфигураций:
azure_sd_configs is for scraping the targets registered in Azure Cloud. See these docs.
consul_sd_configs is for discovering and scraping targets registered in Consul. See these docs.
consulagent_sd_configs is for discovering and scraping targets registered in Consul Agent. See these docs.
digitalocean_sd_configs is for discovering and scraping targets registered in DigitalOcean. See these docs.
dns_sd_configs is for discovering and scraping targets from DNS records (SRV, A and AAAA). See these docs.
docker_sd_configs is for discovering and scraping Docker targets. See these docs.
dockerswarm_sd_configs is for discovering and scraping Docker Swarm targets. See these docs.
ec2_sd_configs is for discovering and scraping Amazon EC2 targets. See these docs.
eureka_sd_configs is for discovering and scraping targets registered in Netflix Eureka. See these docs.
file_sd_configs is for scraping targets defined in external files (aka file-based service discovery). See these docs.
gce_sd_configs is for discovering and scraping Google Compute Engine targets. See these docs.
http_sd_configs is for discovering and scraping targets provided by external http-based service discovery. See these docs.
kubernetes_sd_configs is for discovering and scraping Kubernetes targets. See these docs.
kuma_sd_configs is for discovering and scraping Kuma targets. See these docs.
nomad_sd_configs is for discovering and scraping targets registered in HashiCorp Nomad. See these docs.
openstack_sd_configs is for discovering and scraping OpenStack targets. See these docs.
static_configs is for scraping statically defined targets. See these docs.
yandexcloud_sd_configs is for discovering and scraping Yandex Cloud targets. See these docs.
Cntrl+C, Cntrl +V из официальной документации.
Вернемся к нашему старому примеру с vmagent, переведем статическую конфигурацию в динамическую.
Статическая конфигурация:
- job_name: foo
static_configs:
- targets: ["vmagent:8429"]Динамическая:
- job_name: monitoring
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [ __meta_kubernetes_pod_annotation_monitoring_scrape ]
action: keep
regex: "true"О чудо, проблема со скейлингом и плавающими адресами решена. Каждый под, который содержит аннотацию monitoring/scrape: true, будет помечен как цель для сбора.
Навешиваем аннотацию на все поды Victoria Metrics и радуемся жизни? Не так быстро.
Внимательные читатели уже видят проблему. Если мы пометим этой аннотацией все компоненты мониторинга, а не только vmagent, то возникнет проблема с портами и путями сбора метрик - где-то /metrics, где-то actuator/prometheus и т.д.
Давайте решать это как раз с помощью манипуляций над релейблингом. На этом стейдже мы можем не только фильтровать, но и править :) Добавим в наши аннотации два компонента - поле, содержащее порт, и путь сбора метрик.
Приведу сразу готовую конфигурацию, но отмечу, что есть много вариантов сделать такую джобу, вплоть до regex по имени сервиса из неймспейса мониторинга и сбор по endpoint’ам на порте, помеченном для мониторинга. У нас же просто конфиг для подов с аннотацией:
- job_name: monitoring
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [ __meta_kubernetes_pod_annotation_monitoring_scrape ]
action: keep
regex: "true"
- source_labels: [__address__, __meta_kubernetes_pod_annotation_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
target_label: __address__
- source_labels: [__meta_kubernetes_pod_node_name]
target_label: hostname
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: kubernetes_pod_name
- source_labels: [__meta_kubernetes_pod_annotation_metric_path]
action: replace
target_label: __metrics_path__
regex: (.+)Теперь разберем по частям что, куда и зачем.
- source_labels: [ __meta_kubernetes_pod_annotation_monitoring_scrape ]
action: keep
regex: "true"Данную часть мы уже разобрали - это фильтр. Остаются только поды с аннотацией. Но где же мы решаем проблему с портами? Тут все просто, нужно немного магии. Следите за руками, как говорится :)
- source_labels: [__address__, __meta_kubernetes_pod_annotation_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
target_label: __address__Здесь есть внутренне поле __address__, которое как раз и отвечает за адрес:порт. При помощи нехитрой регулярки (или хитрой, если не знать регулярки) мы вытаскиваем из адреса непосредственно порт и заменяем его на тот, который был в аннотации пода.
Идем дальше.
- source_labels: [__meta_kubernetes_pod_node_name]
target_label: hostname
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: kubernetes_pod_nameЗдесь из меты Kubernetes мы просто проставляем лейбл хостнейма, неймспейса и названия пода на метрику.
Потом тем же способом, что и с адресом, во внутреннюю переменную __metrics_path__ пишем то, что было в аннотации пути сбора.
- source_labels: [__meta_kubernetes_pod_annotation_metric_path]
action: replace
target_label: __metrics_path__
regex: (.+)Таким образом, с помощью одной джобы мы всегда будем собирать метрики с компонентов стека Victoria Metrics. При этом не важно поменялись ли адреса или стало больше или меньше реплик какого-нибудь сервиса. У нас всегда будет актуальная конфигурация.
Чем хороша динамическая конфигурация? Да просто это удобно, ведь сокращается количество действий для поддержания ее в актуальном состоянии и еще много прочих плюшек. А избавление от кейсов, когда разработчики что-то изменили, а тебе приходится руками менять пути, адреса, количество - всегда хорошо. Экономьте свое время и занимайтесь полезными вещами.
И небольшой бонус в конце - ссылка на сообщество Victoria Metrics. Здесь много интересного о системе мониторинга, а участники сообщества могут помочь решить вопрос по мониторингу просто так, за плюсик в карму.
