Мониторинг MongoDB с помощью Proto Observability

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

• Сбор метрик MongoDB
  • Конфигурация MongoDB
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка
  • Собираемые метрики
    • Лейблы
    • Операции (opcounters)
    • Соединения
    • Документы и операции (metrics.document / metrics.operation)
    • Латентность операций (oplatencies)
    • Память (mem / extra_info / tcmalloc)
    • Сеть
    • Ассерты
    • WiredTiger
    • Курсоры
    • Команды (metrics.commands)
    • Локи и глобальный лок (locks / globallock)
    • Журналирование (dur)
    • Уровень базы данных (dbStats)
    • Уровень коллекции (collStats / top)
    • Репликация (replset / opcountersrepl / oplog)
    • Прочее
  • Ключевые метрики для дашбордов и алертов
• Сбор логов MongoDB
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор метрик MongoDB

Интеграция mongo подключается к mongod (или mongos) клиентом MongoDB и собирает метрики из serverStatus, dbStats, collStats, replSetGetStatus, top и metrics.commands. Поддерживаются standalone, replica set и sharded cluster — для каждого узла mongod и для каждого mongos заводится отдельный instance проверки (см. ниже).

Это обычная Python-проверка, не JMX, поэтому суффикс -jmx в образе агента не нужен — подойдёт обычный protoobp-agent:7.40.3.

Конфигурация MongoDB

Создайте read-only пользователя для агента ProtoOBP в базе admin. Нужны три роли:

• read@admin — чтение serverStatus / dbStats / collStats;
• clusterMonitor@admin — replSetGetStatus, top, getCmdLineOpts, serverStatus целиком;
• read@local — метрики oplog (mongodb_oplog_timediff, mongodb_oplog_usedsizemb и т.п.).

// подключитесь к mongod как администратор
use admin
db.auth("admin", "<YOUR_PASSWORD>")

// MongoDB 3.x и новее
db.createUser({
  user: "protoobp",
  pwd:  "protoobp",
  roles: [
    { role: "read",           db: "admin" },
    { role: "clusterMonitor", db: "admin" },
    { role: "read",           db: "local" }
  ]
})

// Для очень старых версий (MongoDB 2.x)
db.addUser("protoobp", "protoobp", true)

В Docker этот скрипт удобно положить в docker-entrypoint-initdb.d — официальный образ mongo выполняет каждый *.js / *.sh из этого каталога один раз при первой инициализации тома данных, уже после создания root-пользователя из MONGO_INITDB_ROOT_USERNAME / MONGO_INITDB_ROOT_PASSWORD:

// docker-entrypoint-initdb.d/01-protoobp-user.js
db.getSiblingDB('admin').createUser({
  user: 'protoobp',
  pwd:  'protoobp',
  roles: [
    { role: 'read',           db: 'admin' },
    { role: 'clusterMonitor', db: 'admin' },
    { role: 'read',           db: 'local' }
  ]
});

services:
  mongodb:
    image: mongo:7
    environment:
      MONGO_INITDB_ROOT_USERNAME: admin
      MONGO_INITDB_ROOT_PASSWORD: <YOUR_PASSWORD>
    volumes:
      - ./docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d:ro
    ports:
      - "27017:27017"

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

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

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

   init_config:
   
   instances:
     - hosts:
         - mongodb:27017          # хост[:порт] узла mongod (по умолчанию 27017)
       username: protoobp
       password: protoobp
       database: admin            # база, из которой читать dbStats
       options:
         authSource: admin        # пользователь protoobp создан в admin
   
       ## Доп. наборы метрик (по умолчанию собирается базовый сэмпл):
       ##   metrics.commands — статистика по командам БД
       ##   top              — статистика использования по коллекциям
       ##   collection       — метрики коллекций из списка `collections`
       ##   tcmalloc         — аллокатор памяти TCMalloc
       ##   jumbo_chunks     — jumbo-чанки (только на mongos)
       # additional_metrics:
       #   - metrics.commands
       #   - top
       #   - collection
   
       ## Список баз для сбора метрик (по умолчанию — все базы):
       # dbnames:
       #   - mydb
   
       ## Конкретные коллекции для per-collection метрик (нужен
       ## `additional_metrics: [collection]`):
       # collections:
       #   - events
   
       ## Метрики доступа по индексам для коллекций из `collections` (MongoDB 3.2+):
       # collections_indexes_stats: false
   
       ## Читать ли с доступных реплик (отключите, если реплики недостижимы):
       # replica_check: true
   
       ## Доп. теги на все метрики и сервис-проверки этого instance:
       # tags:
       #   - mongo_role:standalone
   

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

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

Добавьте autodiscovery-лейблы к контейнеру MongoDB. В docker-compose.yaml:

labels:
  com.protoobp.ad.check_names: '["mongo"]'
  com.protoobp.ad.init_configs: "[{}]"
  com.protoobp.ad.instances: '[{"hosts": ["%%host%%:%%port%%"], "username": "protoobp", "password": "protoobp", "database": "admin", "options": {"authSource": "admin"}}]'

С дополнительными наборами метрик и per-collection / per-db метриками (%%host%% / %%port%% подставляются агентом из инспекта контейнера):

labels:
  com.protoobp.ad.check_names: '["mongo"]'
  com.protoobp.ad.init_configs: "[{}]"
  com.protoobp.ad.instances: >-
    [{"hosts": ["%%host%%:%%port%%"], "username": "protoobp", "password": "protoobp",
      "database": "admin", "options": {"authSource": "admin"},
      "additional_metrics": ["metrics.commands", "top", "collection"],
      "dbnames": ["demo", "admin", "local"],
      "collections": ["events"], "collections_indexes_stats": true,
      "tags": ["mongo_role:standalone"]}]    

Или в Dockerfile:

LABEL "com.protoobp.ad.check_names"='["mongo"]'
LABEL "com.protoobp.ad.init_configs"='[{}]'
LABEL "com.protoobp.ad.instances"='[{"hosts": ["%%host%%:%%port%%"], "username":"protoobp", "password":"protoobp", "database":"admin", "options":{"authSource":"admin"}}]'

Проверка

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

docker exec protoobp-agent agent status | grep -A 12 "^    mongo$"

Ожидаемый вывод — [OK] для instance и ненулевое число Metric Samples (версия проверки и числа варьируются; на MongoDB 7 с включёнными metrics.commands / top / collection — порядка 375 сэмплов за запуск):

mongo (4.0.2)
-------------
  Instance ID: mongo:58f178627f486c86 [OK]
  Configuration Source: container:docker://0ee90e8358f1...
  Total Runs: 36
  Metric Samples: Last Run: 375, Total: 13,432
  Events: Last Run: 0, Total: 0
  Service Checks: Last Run: 1, Total: 36
  Average Execution Time : 33ms
  metadata:
    version.raw: 7.0.32
    version.scheme: semver

Если instance в состоянии [ERROR] — частые причины: неверный authSource (Authentication failed), у пользователя нет роли clusterMonitor, агент не в той docker network, что MongoDB.

Собираемые метрики

Почти все метрики имеют тип gauge. Имена, заканчивающиеся на ps (...insertps, ...bytesinps и т.п.), — это rate в секунду: интеграция сама считает производную кумулятивного счётчика на стороне агента, в бэкенд уходит уже скорость. Часть метрик собирается только при включённых additional_metrics или только в определённых топологиях — это отмечено.

Лейблы

Плюс любые теги из tags: в конфиге instance (например, mongo_role:standalone).

Операции (opcounters)

Скорость операций, которые получил этот узел напрямую от клиентов.

Соединения

Документы и операции (metrics.document / metrics.operation)

Латентность операций (oplatencies)

Из serverStatus().opLatencies — суммарная и средняя латентность по типам операций.

Память (mem / extra_info / tcmalloc)

Сеть

Ассерты

WiredTiger

Метрики storage engine WiredTiger — кэш и concurrency tickets.

Курсоры

Команды (metrics.commands)

Собираются при additional_metrics: [metrics.commands]. Для каждой команды — сколько раз выполнена (total) и сколько раз упала в секунду (failedps): count, insert, update, delete, findandmodify, createindexes, eval.

Локи и глобальный лок (locks / globallock)

mongodb_globallock_* — состояние очереди и активных клиентов на чтение/запись:

mongodb_locks_<scope>_acquirecount_<mode>ps / acquirewaitcount.<mode>ps / timeacquiringmicros.<mode>ps — счётчики захватов лока в секунду, ожиданий и времени ожидания, по областям (scope: global, database, collection, metadata, oplog, mmapv1journal) и режимам (mode: shared, exclusive, intent_shared, intent_exclusive). Пример: mongodb_locks_database_acquirecount_intent_exclusiveps.

Журналирование (dur)

Метрики durability/journal (serverStatus().dur; на storage engine со mmap):

Уровень базы данных (dbStats)

Несут лейбл db:<имя_базы>. Базы выбираются параметром dbnames: (по умолчанию — все).

Уровень коллекции (collStats / top)

Собираются при additional_metrics: [collection] для коллекций из списка collections:. Несут лейблы db:<база> и collection:<имя>. Каждая коллекция добавляет ~8 + (число индексов) серий.

mongodb_usage_<op>_count / .countps / .time (<op>: total, queries, getmore, insert, update, remove, commands, readlock, writelock) — из top, при additional_metrics: [top], по коллекциям (collection:<имя>): число операций с момента старта, в секунду и суммарное время в микросекундах. Например, mongodb_usage_queries_countps.

Репликация (replset / opcountersrepl / oplog)

Эти метрики появляются только на узлах replica set / sharded cluster.

Прочее

Ключевые метрики для дашбордов и алертов

Доступность

• Отсутствие свежих серий по server / hosts — алерт: узел MongoDB недоступен или агент не может подключиться (проверьте authSource, роли пользователя, сеть).
• mongodb_uptime резко сбросился в маленькое значение — mongod перезапускался.

Нагрузка и пропускная способность

• mongodb_opcounters_insertps / .queryps / .updateps / .deleteps / .commandps — базовый профиль нагрузки. Резкий рост commandps или падение всех до нуля — повод посмотреть.
• mongodb_metrics_document_returnedps против mongodb_metrics_queryexecutor_scannedps — если просматривается на порядки больше, чем возвращается, не хватает индексов.
• mongodb_metrics_operation_scanandorderps > 0 стабильно — сортировки без индекса.

Латентность

• mongodb_oplatencies_reads_latency_avg / .writes.latency.avg / .commands.latency.avg — алерт по росту относительно базовой линии.
• mongodb_collection_reads_latency_avg / .writes.latency.avg per collection — какая коллекция тормозит.

Соединения

• mongodb_connections_current приближается к current + available (потолок) — скоро connection refused у клиентов.
• Резкий рост mongodb_connections_totalcreated (rate) — connection storm, пул на стороне приложения не работает.

Память и кэш

• mongodb_wiredtiger_cache_bytes_currently_in_cache против mongodb_wiredtiger_cache_maximum_bytes_configured — приближение к 95 % и рост mongodb_wiredtiger_cache_tracked_dirty_bytes_in_cache выше ~20 % → агрессивное вытеснение, деградация.
• mongodb_wiredtiger_cache_pages_evicted_by_application_threadsps > 0 — прикладные потоки вынуждены сами вытеснять страницы (кэш под давлением).
• mongodb_wiredtiger_concurrenttransactions_read_available / .write.available → 0 — тикеты кончились, операции встают в очередь.
• mongodb_mem_resident против лимита контейнера (mongodb_system_mem_limit) — близко к лимиту → риск OOM-kill.
• mongodb_extra_info_page_faultsps высокий — рабочий набор не помещается в RAM.

Локи / конфликты

• mongodb_globallock_currentqueue_readers / .writers > 0 стабильно — операции ждут лока.
• mongodb_metrics_operation_writeconflictsps высокий — частые конфликты записи (горячие документы).
• mongodb_asserts_userps всплеск — много ошибок клиентских операций.

Репликация (replica set)

• mongodb_replset_health == 0 для члена набора — узел down → алерт.
• mongodb_replset_optime_lag (на primary) или mongodb_replset_replicationlag растёт — secondary отстаёт.
• mongodb_replset_state сменился на не-primary/secondary (recovering, rollback, …) — нештатное состояние члена набора.
• mongodb_oplog_timediff (окно oplog) сокращается — secondary рискует «выпасть» из репликации, нужен resync.

Хранилище

• mongodb_stats_fsusedsize / mongodb_stats_fstotalsize per db — заполнение диска.
• mongodb_stats_datasize / mongodb_stats_indexsize per db — рост данных и индексов; индексы крупнее данных = переиндексировано.
• mongodb_collection_collectionscans_totalps > 0 стабильно для горячей коллекции — запросы без индекса.

Сбор логов MongoDB

Логи mongod / mongos собираются ProtoOBP агентом и отправляются в бэкенд ProtoOBP. Здесь — только специфичные для MongoDB настройки. Включение логов на стороне агента (logs_enabled, logs_pobp_url) описано в Получение данных логов.

{"t":{"$date":"2026-05-12T10:00:00.123+00:00"},"s":"I","c":"NETWORK","id":22943,"ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.18.0.4:42130","connectionId":12,"connectionCount":3}}

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

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

Дополните уже существующий /etc/protoobp-agent/conf.d/mongo.d/conf.yaml (тот же файл, в котором лежит instances: для метрик) блоком logs:.

logs:
  - type: file
    path: /var/log/mongodb/mongod.log
    source: mongo
    service: mongodb

/var/log/mongodb/mongod.log — стандартный путь при установке из пакета (параметр systemLog.path в /etc/mongod.conf). У агента должны быть права на чтение этого файла (пользователь pobp-agent — добавьте его в группу, которой принадлежит файл лога, обычно mongodb).

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

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

Шаг 1 — включите сбор логов в самом агенте через переменные окружения и смонтируйте директорию JSON-логов docker-демона:

services:
  protoobp-agent:
    environment:
      POBP_LOGS_ENABLED: "true"
      POBP_LOGS_CONFIG_USE_HTTP: "true"
      POBP_LOGS_CONFIG_LOGS_POBP_URL: <protoobp-backend>:<port>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # Прямое чтение JSON-лог файлов docker-демона быстрее,
      # чем тянуть их через Docker socket API.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Шаг 2 — добавьте лейбл com.protoobp.ad.logs к контейнеру MongoDB. Образ mongo по умолчанию пишет лог в stdout, агент его подхватит и пометит записи указанными source и service:

services:
  mongodb:
    labels:
      com.protoobp.ad.logs: '[{"source": "mongo", "service": "mongodb"}]'

Проверка

В выводе agent status должен быть раздел Logs Agent со статусом running и источник mongo с ненулевым BytesRead:

docker exec protoobp-agent agent status \
  | sed -n '/^==== Logs Agent ====/,/^====/p'

Пример:

==========
Logs Agent
==========
    Reliable: Sending compressed logs in HTTPS to ... on port 443
    LogsProcessed: 13423
    LogsSent: 13401

  docker
  ------
    - Type: file
      Identifier: <container_id>
      Path: /var/lib/docker/containers/<container_id>/<container_id>-json.log
      Service: mongodb
      Source: mongo
      Status: OK
      BytesRead: 6.74e+06