Instrumentation: Общие параметры интеграций

Mon, 01 Jan 0001 00:00:00 +0000

На этой странице:

Где задаются параметры
min_collection_interval — интервал сбора
tags — теги метрик интеграции
service — сервис
empty_default_hostname — метрики без имени хоста
Проверка

Каждая интеграция настраивается своим файлом conf.d/<интеграция>.d/conf.yaml (или шаблоном автообнаружения в контейнерной среде) и имеет собственные параметры — они описаны на странице интеграции. Параметры на этой странице общие: агент обрабатывает их одинаково для любой интеграции.

Где задаются параметры

Параметры указываются в каждом элементе списка instances. Каждый элемент — отдельный экземпляр проверки со своими параметрами:

# conf.d/postgres.d/conf.yaml
init_config:

instances:
 - host: db-prod-01
 port: 5432
 username: protoobp
 password: ENC[postgres_password]
 min_collection_interval: 30
 service: billing-db
 tags:
 - team:billing
 - env:prod

 - host: db-test-01
 port: 5432
 username: protoobp
 password: ENC[postgres_password_test]
 tags:
 - env:test

Параметр service можно также указать в init_config — тогда он действует на все экземпляры, у которых service не задан.

min_collection_interval — интервал сбора

Как часто агент запускает проверку, в секундах. По умолчанию — 15.

instances:
 - host: db-prod-01
 min_collection_interval: 60

Увеличьте интервал для тяжёлых проверок: запросов к крупным базам данных, обращений к API систем виртуализации и СХД, опроса большого числа сетевых устройств. Это снижает нагрузку и на агента, и на наблюдаемую систему.
Уменьшать интервал ниже 15 секунд не рекомендуется: метрики отправляются на бэкенд пакетами раз в 15 секунд, и более частые запуски не дают дополнительной детализации на графиках.
Интервал — минимальный промежуток между запусками. Если проверка выполняется дольше интервала, следующий запуск откладывается до завершения текущего.
Метрики-скорости (*_per_s, rate) вычисляются по разнице двух соседних запусков, поэтому при большом интервале они сглаживаются.

Учитывайте интервал в правилах алертинга: окно правила должно покрывать несколько запусков проверки, иначе пропуск одного запуска приведёт к ложному срабатыванию правила на отсутствие данных.

tags — теги метрик интеграции

Список тегов ключ:значение, которые агент добавляет ко всем метрикам и событиям проверки этого экземпляра. В хранилище метрик тег становится меткой: team:billing → team="billing".

instances:
 - host: db-prod-01
 tags:
 - team:billing
 - env:prod

Теги экземпляра применяются сразу, без дополнительных параметров — в отличие от тегов хоста. Они удобны, когда на одном хосте работают проверки разных команд или окружений.

Рекомендации:

используйте ключи из строчных латинских букв, цифр и _;
используйте теги с небольшим числом значений; уникальные значения многократно увеличивают число временных рядов;
изменение или удаление тега начинает новый временной ряд для каждой метрики проверки.

service — сервис

Добавляет к метрикам и событиям проверки тег service:<значение>:

init_config:
 service: billing-db  # для всех экземпляров

instances:
 - host: db-prod-01
 - host: db-prod-02
 service: billing-db-replica  # переопределяет значение из init_config

Используйте одно и то же имя сервиса в интеграции и в трейсере приложения, если хотите видеть метрики инфраструктурного компонента рядом с данными сервиса.

empty_default_hostname — метрики без имени хоста

По умолчанию агент добавляет к метрикам проверки метку host со своим именем хоста. Параметр empty_default_hostname: true отключает это для метрик, у которых проверка не указала хост явно:

instances:
 - url: https://portal.corp.local/health
 empty_default_hostname: true

Включайте параметр только для метрик, которые не относятся к хосту агента: доступность внешнего адреса, состояние удалённого сервиса, метрики уровня кластера. Метрики без host не отображаются на страницах хостов в разделе Инфраструктура.

Проверка

protoobp-agent configcheck <интеграция> показывает, какие параметры агент прочитал для каждого экземпляра.
protoobp-agent check <интеграция> выполняет проверку один раз и выводит метрики с тегами — по нему видно, что tags и service применились.
В выводе protoobp-agent status (раздел Collector) для каждого экземпляра видны число запусков, среднее время выполнения и время последнего успешного запуска.

Команды для разных платформ — на странице Команды и проверка работы.