Для чего нам нужен EC2 service discovery? В первую очередь – что бы избежать необходимости открывать порт на Application Load Balancer и гонять трафик “через мир”.
Т.е. вместо того, что бы в конфиге Prometheus указывать статичный URL и URI, типа mainhost.domain.tld/metrics, который был бы направлен на AWS ALB, у которого было бы правило форвардить URI /metrics в AWS Target Group, у которой был бы таргет на порт 9253 (екскпортер, который собирает метрики с PHP-FPM, см. Prometheus: мониторинг PHP-FPM + Ansible роль) – мы просто указываем Prometheus выполнить поиск инстансов с определёнными тегами в AWS аккаунте, после чего он их резолвит по локальным IP.
Так мы экономим и трафик, который не будет передаваться через Load Balancer, обойдёмся без торчащих наружу портов для мониторинга, и упростим поиск и добавление новых ЕС2 в мониторинг, не говоря уже об упрощении схемы вообще (см. абзац выше).
Основное ограничение тут: EC2 должен быть либо в той же VPC, где запущен Prometheus, либо между VPC должен быть поднят .
Ниже – пример использования Prometheus ec2_sd_configs на примере ЕС2 с .
Подготовка
Запускаем ЕС2, на котором будем тестить, открываем доступ к нему из Security Group хоста мониторинга на порт 9100:
IAM
Что бы Prometheus мог получить доступ к инстансам – добавляем IAM пользователя с Programmatic access и добавляем ему полиси EC2 ReadOnly:
Используя Access и Secret ключи этого пользователя – будем настраивать сам Prometheus.
Настройка EC2
Подключаемся на инстанс:
Устанавливаем Docker:
Запускаем node_exporter:
Проверяем:
Настройка Prometehus
Теперь можно добавить хост в Prometheus.
Редактируем его конфиг, в данном случае это /opt/prometheus/prometheus-server-conf.yml, добавляем:
global:
scrape_interval: 15s
external_labels:
monitor: 'btrm-monitor'
scrape_configs:
- job_name: 'prometheus'
metrics_path: "/prometheus/metrics"
static_configs:
- targets: ['localhost:9090']
- job_name: 'ec2'
ec2_sd_configs:
- region: us-east-2
access_key: AKI***CUA
secret_key: 0oP***ggW
port: 9100
Перезапускаем:
Проверяем таргеты:
Тут http://10.0.1.175:9100/metrics – это сам ЕС2 с Prometheus, а котором не запущен node_exporter, http://10.0.3.108:9100/metrics – “левый” хост в другой VPC, а http://10.0.1.192:9100/metrics – запущенный ранее ЕС2, который и будем мониторить.
Relabelling
Вернёмся к конфигу Prometheus, оставим сборк метрик только с хоста с тегом Name=prom-ec-sd:
...
relabel_configs:
- source_labels: [__meta_ec2_tag_Name]
regex: prom-*
action: keep
...
И переименуем его, что бы в метке instance вместо приватного IP выводился InstanceID, используя мета-лейбл __meta_ec2_instance_id:
...
- source_labels: [__meta_ec2_instance_id]
target_label: instance
Теперь полностью он выглядит так:
global:
scrape_interval: 15s
external_labels:
monitor: 'btrm-monitor'
scrape_configs:
- job_name: 'prometheus'
metrics_path: "/prometheus/metrics"
static_configs:
- targets: ['localhost:9090']
- job_name: 'ec2'
ec2_sd_configs:
- region: "us-east-2"
access_key: "AKI***CUA"
secret_key: "0oP***ggW"
port: 9100
relabel_configs:
- source_labels: [__meta_ec2_tag_Name]
regex: prom-.*
action: keep
- source_labels: [__meta_ec2_instance_id]
target_label: instance
Перезапускаем Prometheus, проверяем:
И в графиках:
Готово.
