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

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

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

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

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

• итоги по кластеру целиком — потребление и резерв ЦП, памяти, хранилища и внешних IP-адресов,
• учетные записи — потребление, резерв и квоты,
• ресурсные группы — потребление, резерв и квоты,
• виртуальные машины — выделенные ресурсы и инвентарь, живая утилизация (vCPU, память, диски) и рантайм-показатели диска и сети,
• гипервизоры — ёмкость (ЦП, память, NUMA, переподписка, статус) и живая утилизация,
• управляющие узлы платформы — ёмкость и статус,
• системы хранения — ёмкость и заполнение по хранилищу и по каждому пулу.

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

Метрики нормализуются: имена и ключи приводятся к нижнему регистру, пробелы и дефисы заменяются на _. В 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
   
       # Опционально: размер страницы при чтении списка ВМ (для парков 1000+ машин)
       #compute_page_size: 1000
   
       # Опционально: окно живой утилизации ВМ и гипервизоров, секунды.
       # Платформа отдаёт эти показатели готовыми часовыми интервалами,
       # поэтому значения меньше 7200 поднимаются до 7200. По умолчанию 7200.
       #resmon_window_seconds: 7200
   
       # Опционально: какая роль узла считается гипервизором.
       # По умолчанию "cpunode" — хосты, которые несут ВМ. Менять не нужно.
       #node_role: cpunode
   
       # Опционально: какая роль узла считается управляющим узлом
       # (basis_dynamix_ctrl_node_*). По умолчанию "physical".
       # "" — не собирать управляющие узлы вовсе.
       #control_node_role: physical
   
       # Опционально: 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: 7200   # окно живой утилизации ВМ и гипервизоров; минимум 7200
    #node_role: cpunode            # роль узла, считающаяся гипервизором
    #control_node_role: physical   # роль узла, считающаяся управляющим узлом
    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.80.2
    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_ не настраивается.

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

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

• grid_id (метрики грида)
• account_id, account_name
• rg_id, rg_name, rg_gid, rg_guid
• compute_id, compute_name (метрики ВМ)
• node_id, node_name — метрики гипервизоров, а также метрики ВМ: гипервизор, на котором размещена машина
• sep_id, sep_name, sep_type, pool_name — метрики хранилищ и разбивка потребления по СХД
• policy_id — разбивка потребления по политикам хранения

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

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

Проверка

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

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

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

    basis_dynamix (0.4.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: 1,582, Total: 189,840
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 120
      Average Execution Time : 17.412s
      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 при успехе, WARNING, если часть метрик собрать не удалось, CRITICAL при полном отказе сбора (например, если не удалось получить токен доступа).

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

Метрики грида (кластер целиком)

Итоги по всему кластеру — те же числа, что Basis Dynamix показывает на верхней панели своего дашборда: «ЦП», «ОЗУ», «Хранилище и Политики», «Общедоступные IP-адреса». Это данные самой платформы, а не сумма по аккаунтам, поэтому они не зависят от того, все ли аккаунты подтверждены.

Типичные значения <resource>: cpu (шт), ram (МБ), disksize, disksizemax (ГБ), extips, gpu. Дополнительно — разбивка по СХД и политикам хранения, см. ниже.

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

Метрики собираются только по подтверждённым учётным записям — аккаунт в другом статусе в метриках не появится.

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

Дополнительно публикуется разбивка account_consumed_seps_* / account_consumed_policies_* (и те же ряды для reserved) — см. Разбивка потребления по СХД и политикам хранения.

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

Набор <resource> — тот же, что и для аккаунтов. Дополнительно публикуется разбивка rg_consumed_seps_* / rg_consumed_policies_* (и те же ряды для reserved) — см. следующий раздел.

Разбивка потребления по СХД и политикам хранения

Каждый блок потребления и резерва — грида, аккаунта и ресурсной группы — содержит два вложенных разреза тех же гигабайтов: по системам хранения (СХД и их пулам) и по политикам хранения. Они публикуются отдельными рядами с дополнительными метками.

где <область> — grid, account или rg. К перечисленным меткам добавляются обычные метки области (grid_id, либо account_id + account_name, либо rg_id + rg_name …).

Комбинированный разрез «политика хранения × система хранения × пул» не публикуется — доступны только два разреза по отдельности.

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

Метки: account_id, account_name, rg_id, rg_name, compute_id, compute_name, а также node_id / node_name — гипервизор, на котором размещена машина (у машины, не размещённой в данный момент ни на одном узле, этой метки нет).

Выделенные ресурсы и инвентарь:

Живая утилизация:

Суммарно по дискам машины:

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

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

Метки: node_id, node_name. Здесь только гипервизоры — хосты, которые несут виртуальные машины. Управляющие серверы платформы вынесены в отдельное семейство метрик, см. Метрики управляющих узлов.

Ёмкость и конфигурация узла:

Живая утилизация узла:

Дополнительно публикуются характеристики процессора узла: basis_dynamix_node_usage_cpu_info_clockspeed, …_corecount, …_physcount, …_threadcount.

Метрики управляющих узлов (control plane)

Метки: node_id, node_name. Это физические серверы управляющего контура платформы — они не несут виртуальных машин.

Набор полей тот же, что у гипервизоров, отличается только префикс:

Метрики хранилищ (SEP)

SEP (storage endpoint provider) — система хранения, подключённая к платформе.

Метки: sep_id, sep_name, sep_type (LOCAL / SHARED), для пулов дополнительно pool_name. Идентификаторы отдельных дисков в метки не выносятся.

По системе хранения целиком:

По каждому пулу — те же поля с префиксом basis_dynamix_sep_pool_: usage, usage_limit, disk_count, disk_usage, snapshot_count, snapshot_usage. Полной ёмкости на уровне пула платформа не отдаёт, поэтому заполнение пула считайте как sep_pool_usage / sep_pool_usage_limit.

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

Это рантайм-метрики виртуальных машин. Префикс — 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.