Мониторинг Basis Dynamix с помощью Proto Observability Platform

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

• Сбор метрик Basis Dynamix Enterprise
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Переменные окружения
  • Параметры конфигурации
  • Как происходит сбор метрик
  • Теги, добавляемые автоматически
  • Проверка
  • Сервисные проверки
  • Список метрик
    • Метрики аккаунтов
    • Метрики ресурсных групп
    • Метрики виртуальных машин
    • Метрики вычислительных узлов (гипервизоры)
    • Метрики Prometheus для ВМ

Сбор метрик Basis Dynamix Enterprise

Интеграция basis_dynamix собирает метрики из платформы виртуализации Basis Dynamix Enterprise через её REST API. Источники данных:

• учетные записи (consumption / reserved / limits),
• ресурсные группы (consumption / reserved / limits),
• виртуальные машины: аллокация (vCPU, RAM, диски, статус) из cloudapi/compute/list, живая утилизация (vCPU / RAM / диск) из cloudbroker/resmon/getByComputes, рантайм диск/сеть I/O из cloudapi/prometheus/computes,
• вычислительные узлы / гипервизоры: ёмкость (CPU, RAM, NUMA, overcommit, статус) из cloudbroker/node/list и живая утилизация (CPU% / RAM% по узлу) из cloudbroker/resmon/get_by_nodes.

В системе доступен сбор метрик аккаунтов, ресурсных групп, виртуальных машин и гипервизоров; поставляются встроенные дашборды для визуализации иерархии сущностей и их метрик:

Метрики нормализуются: имена и ключи приводятся к нижнему регистру, пробелы и дефисы заменяются на _. В protoobp имена метрик не содержат точек — точки заменяются на _: агент эмитит basis_dynamix.<...>, в хранилище и запросах это basis_dynamix_<...>. Все имена метрик в этом документе приведены в итоговом виде (с _). Для метрик Prometheus дополнительно удаляется префикс compute из имени метрики.

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. Положите файл проверки basis_dynamix.py в /etc/protoobp-agent/checks.d/.

2. Создайте файл /etc/protoobp-agent/conf.d/basis_dynamix.d/conf.yaml:

   init_config:
   
   instances:
     - client_id: "<BASIS_CLIENT_ID>"
       client_secret: "<BASIS_CLIENT_SECRET>"
       base_url: "https://dynamix.example.ru"
       sso_url: "https://sso-dynamix.example.ru/v1/oauth/access_token"
   
       timeout: 10
       ssl_verify: false
       min_collection_interval: 20
   
       tags:
         - platform:basis_dynamix
   
       # Опционально: размер страницы cloudapi/compute/list (для парков 1000+ ВМ)
       #compute_page_size: 1000
   
       # Опционально: окно живой утилизации resmon (get_by_nodes / getByComputes),
       # секунды. Эндпоинты агрегируют по часу — значения < 3600 возвращают пустой
       # ответ. По умолчанию и минимум 3600; меньшие значения поднимаются до 3600.
       #resmon_window_seconds: 3600
   
       # Опционально: Prometheus compute метрики (рантайм ВМ).
       # Имена нормализуются в basis_dynamix_compute_* без префикса "compute".
       # Пример: computeReadBytes -> basis_dynamix_compute_readbytes.
       # Если не задано — используется встроенный набор по умолчанию
       # (CPU, память, диск/сеть I/O).
       #prometheus_metric_ids:
       #  - computeCPUload
       #  - computeMemoryUsage
       #  - computeMemoryUsed
       #  - computeMemoryAvailable
       #  - computeReadBytes
       #  - computeReadRequests
       #  - computeWriteBytes
       #  - computeWriteRequests
       #  - computeReceiveBytes
       #  - computeTransmitBytes
       #  - computeReceivePackets
       #  - computeTransmitPackets
       prometheus_for_last: 300       # окно агрегации Prometheus, секунды
       prometheus_step: 15            # шаг; сервер требует for_last >= 2*step
       #prometheus_decimal_places: 0
   

3. Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

В этом сценарии файл проверки и конфигурация монтируются с хоста внутрь контейнера агента, а параметры подключения к Basis Dynamix передаются через переменные окружения. Так не нужно хранить секреты в YAML и пересобирать образ при ротации кредов.

1. Подготовьте каталог рядом с docker-compose.yml:

.
├── docker-compose.yml
├── .env
├── checks.d/
│   └── basis_dynamix.py
└── conf.d/
    └── basis_dynamix.d/
        └── conf.yaml

2. Файл conf.d/basis_dynamix.d/conf.yaml — без секретов; всё, что нужно для подключения, придёт из переменных окружения:

init_config:

instances:
  - # client_id / client_secret / base_url / sso_url придут из
    # BASIS_CLIENT_ID / BASIS_CLIENT_SECRET / BASIS_BASE_URL / BASIS_SSO_URL —
    # в YAML их можно не указывать.

    lookback_seconds: 300
    #resmon_window_seconds: 3600   # окно живой утилизации resmon; минимум 3600 (агрегация по часу)
    timeout: 10
    ssl_verify: false
    min_collection_interval: 20

    tags:
      - platform:basis_dynamix

    # Опционально: Prometheus compute метрики
    #prometheus_metric_ids:
    #  - computeReadBytes
    #  - computeWriteBytes
    #  - computeReceiveBytes
    #  - computeTransmitBytes
    #prometheus_for_last: 0
    #prometheus_step: 20
    #prometheus_decimal_places: 0

3. Файл .env рядом с docker-compose.yml (добавьте его в .gitignore):

# ProtoOBP backend
POBP_API_KEY=<your_protoobp_api_key>
POBP_BACKEND_URL=<your_protoobp_backend_url>

# Basis Dynamix Enterprise
BASIS_BASE_URL=https://dynamix.example.ru
BASIS_SSO_URL=https://sso-dynamix.example.ru/v1/oauth/access_token
BASIS_CLIENT_ID=<your_basis_client_id>
BASIS_CLIENT_SECRET=<your_basis_client_secret>

4. Файл docker-compose.yml:

services:
  protoobp-agent:
    container_name: protoobp-agent
    image: registry.git.proto.group/protoobp/protoobp-artifacts/protoobp-agent:7.40.3
    pid: host
    ports:
      - "8126:8126"        # APM trace intake
      - "8125:8125/udp"    # DogStatsD
    volumes:
      # Хост-метрики и автоматическое обнаружение контейнеров:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
      - /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
      - /etc/os-release:/host/etc/os-release:ro
      # Файлы интеграции:
      - ./checks.d:/etc/protoobp-agent/checks.d:ro
      - ./conf.d/basis_dynamix.d:/etc/protoobp-agent/conf.d/basis_dynamix.d:ro
    environment:
      # Подключение к ProtoOBP backend
      POBP_API_KEY: ${POBP_API_KEY}
      POBP_POBP_URL: ${POBP_BACKEND_URL}
      # Подключение к Basis Dynamix Enterprise
      BASIS_BASE_URL: ${BASIS_BASE_URL}
      BASIS_SSO_URL: ${BASIS_SSO_URL}
      BASIS_CLIENT_ID: ${BASIS_CLIENT_ID}
      BASIS_CLIENT_SECRET: ${BASIS_CLIENT_SECRET}
    healthcheck:
      test: ["CMD", "agent", "health"]
      interval: 30s
      timeout: 10s
      retries: 3

5. Запустите агента:

docker compose up -d

Если файл проверки или конфигурацию пришлось обновить уже после старта — перечитайте конфигурацию без перезапуска контейнера:

docker compose exec protoobp-agent agent reload

6. Проверьте, что проверка поднялась (см. Проверка ниже):

docker compose exec protoobp-agent agent status | grep -A 10 "basis_dynamix"

При смене кредов отредактируйте .env и выполните docker compose up -d — контейнер перезапустится с новыми переменными окружения, файл conf.yaml менять не нужно.

Переменные окружения

Если значение указано и в YAML, и в переменной окружения, приоритет — у YAML.

Параметры конфигурации

Префикс метрик basis_dynamix_ не настраивается.

Как происходит сбор метрик

1. Получение SSO-токена через sso_url (grant_type=client_credentials).
2. Список аккаунтов: cloudapi/account/list (берутся только со статусом CONFIRMED). Для каждого аккаунта — cloudapi/account/getResourceConsumption (из Consumed / Reserved / resourceLimits формируются account_*).
3. Список ресурсных групп: cloudapi/rg/list. Для каждой РГ — cloudapi/rg/getResourceConsumption (rgId / gid — альтернативные идентификаторы при HTTP 400/404).
4. Вычислительные узлы (гипервизоры): cloudbroker/node/list (требует admin-токен). Из cpuInfo, memory, numaTopology, *_allocation_ratio и status формируются метрики node_* — это ёмкость, не утилизация.
5. Живая утилизация узлов: cloudbroker/resmon/get_by_nodes с окном {starttime, endtime} (= resmon_window_seconds). Из usage формируются node_usage_* (CPU% / RAM / vCPU по узлу), из cpuInfo — node_usage_cpu_info_* — отдельное от ёмкости пространство имён, источники не пересекаются.
6. Список ВМ: cloudapi/compute/list с пагинацией (page / size). Из полей ответа формируются метрики аллокации compute_cpus / compute_ram / compute_total_disks_size / compute_disk_count / compute_vins_connected / compute_up, а id каждой ВМ собирается в список для запроса Prometheus.
7. Живая утилизация ВМ: cloudbroker/resmon/getByComputes с тем же окном. Из usage формируются compute_usage_* (vCPU / RAM / CPU-время / storage), из disks — агрегаты compute_disk_size_max / compute_disk_size_used. Утилизация привязывается к уже собранным тегам ВМ по computeId.
8. Prometheus по ВМ (рантайм диск/сеть I/O): cloudapi/prometheus/computes с параметрами computeIds, metricIds, forLast, step, decimalPlaces. Ответ имеет вид {"<id>": {"<metricId>": [{"timestamp", "value"}, …]}}; из каждой серии берётся последняя точка.

Стадии выполняются с общим дедлайном (≈ 0.9 × min_collection_interval): если бюджет времени исчерпан, медленные стадии пропускаются, а уже собранные метрики публикуются. Во всех блоках публикуются только числовые значения (булевы и нечисловые поля игнорируются). HTTP-уровень построен на requests (RequestsWrapper агента): пул соединений, ретраи на 429/5xx/таймаут/connection-error и потоковое ограничение размера ответа.

Теги, добавляемые автоматически

В зависимости от типа метрики и данных API добавляются теги:

• account_id, account_name
• rg_id, rg_name, rg_gid, rg_guid
• compute_id, compute_name (метрики ВМ)
• node_id, node_name (метрики гипервизоров)

К каждой точке также добавляются статические теги из параметра tags.

Высококардинальные поля (IP / MAC сетевых интерфейсов, идентификаторы дисков) в теги не выносятся.

Проверка

Убедитесь, что проверка запустилась и собирает метрики:

docker exec protoobp-agent agent status | grep -A 10 "basis_dynamix"

Ожидаемый вывод — Instance ID: ... [OK] и ненулевое Metric Samples:

    basis_dynamix (0.1.0)
    ---------------------
      Instance ID: basis_dynamix:6f0a4c12d3a7b8e9 [OK]
      Configuration Source: file:/etc/protoobp-agent/conf.d/basis_dynamix.d/conf.yaml
      Total Runs: 120
      Metric Samples: Last Run: 842, Total: 101,040
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 120
      Average Execution Time : 2.815s
      Last Execution Date : 2026-05-13 13:47:16 UTC
      Last Successful Execution Date : 2026-05-13 13:47:16 UTC

Запустить проверку вручную:

docker exec protoobp-agent agent check basis_dynamix

Сервисные проверки

• basis_dynamix_api — статус сбора метрик за итерацию (OK / CRITICAL).

Список метрик

Метрики аккаунтов

Типичные значения <resource>: cpu, ram, disksize, disksizemax, extips, gpu, gpu_units, cu_c, cu_d, cu_dm, cu_i, cu_m.

Метрики ресурсных групп

Набор <resource> — тот же, что и для аккаунтов.

Метрики виртуальных машин

Метки: account_id, account_name, rg_id, rg_name, compute_id, compute_name.

Аллокация / инвентарь (из cloudapi/compute/list):

Живая утилизация (из cloudbroker/resmon/getByComputes, раздел usage):

Агрегаты по дискам (из resmon/getByComputes, раздел disks):

Рантайм диск/сеть I/O ВМ поступает из Prometheus — см. Метрики Prometheus для ВМ.

Метрики вычислительных узлов (гипервизоры)

Метки: node_id, node_name. Источников два: cloudbroker/node/list даёт ёмкость / конфигурацию узла, а cloudbroker/resmon/get_by_nodes — живую утилизацию (CPU% / RAM% по узлу). Оба контура требуют admin-токен.

Ёмкость / конфигурация (из cloudbroker/node/list):

Живая утилизация (из cloudbroker/resmon/get_by_nodes, раздел usage):

Из раздела cpuInfo того же ответа (живые числовые поля): basis_dynamix_node_usage_cpu_info_clockspeed, …_corecount, …_physcount, …_threadcount. Нечисловые поля (model_name, flags) не публикуются.

Метрики Prometheus для ВМ

Источник — cloudapi/prometheus/computes; это рантайм-метрики ВМ. Префикс — basis_dynamix_compute_ (без повторения слова compute в имени метрики). Метки совпадают с метками ВМ (compute_id, compute_name, account_id, account_name, rg_id, rg_name). Данные поступают только для запущенных ВМ — у остановленных ряды пустые.

Полный список допустимых metricIds: computeCPUload, computeMemoryUsage, computeMemoryUsable, computeMemoryUnused, computeMemoryUsed, computeMemoryAvailable, computeReadBytes, computeReadRequests, computeReceiveBytes, computeReceivePackets, computeTransmitBytes, computeTransmitPackets, computeWriteBytes, computeWriteRequests.

Значения берутся из последней точки ряда за период prometheus_for_last.