Налаштування моніторингу MongoDB через Prometheus та mongodb_exporter

Ви запускаєте db.serverStatus() і бачите сотні полів JSON. Без експортера ці дані — мертвий вантаж. Коли MongoDB падає о 3 годині ночі, а logs показують лише уривки — кожна зайва година простою коштує бізнесу сотень тисяч гривень. Саме тому моніторинг — не опція, а критичний елемент production-інфраструктури. Наша команда має понад 8 років досвіду в DevOps та більше 50 успішних проєктів з моніторингу MongoDB, від стартапів до enterprise з десятками шардів. Ми використовуємо percona/mongodb_exporter — найбільш зрілий експортер, який перетворює diagnostic data в метрики з нормальними label-ами. Без моніторингу ви ризикуєте пропустити зростання latency, раптову відмову репліки або переповнення кешу WiredTiger. Один інцидент з неправильним алертом може коштувати кількох годин downtime. У цій статті — практичний досвід, метрики, які дійсно рятують, та алерти, які ми ставимо завжди. Своєчасне виявлення проблем дозволяє суттєво скоротити витрати на простої.

Як налаштувати mongodb_exporter?

Процес налаштування включає 5 основних кроків:

1. Створіть користувача в MongoDB з мінімальними правами:

use admin
db.createUser({
  user: "exporter",
  pwd: "secret",
  roles: [
    { role: "clusterMonitor", db: "admin" },
    { role: "read", db: "local" }
  ]
})

Офіційна документація MongoDB по ролях підтверджує, що роль clusterMonitor надає read-only доступ до serverStatus та replSetGetStatus. Це мінімально необхідний набір прав.

2. Налаштуйте docker-compose.yml:

---
services:
  mongodb-exporter:
    image: percona/mongodb_exporter:0.40
    command:
      - --mongodb.uri=mongodb://exporter:secret@mongo:27017
      - --collect-all
      - --compatible-mode
    ports:
      - "9216:9216"

Флаг --compatible-mode вмикає метрики, сумісні зі старим dcu/mongodb_exporter — актуально, якщо у вас вже є дашборди. --collect-all активує всі колектори: diagnosticdata, replicaset, shards, topmetrics, indexstats, dbstats, collstats. Без цього експортер збирає лише базові метрики з'єднань та операцій.

3. Запустіть та перевірте метрики: переконайтеся, що на порту 9216 віддаються метрики у форматі Prometheus.

Чому WiredTiger cache важливий для продуктивності?

WiredTiger за замовчуванням використовує 50% RAM мінус 1 GB. Коли cache pressure високий, починається активне витіснення сторінок — mongodb_wiredtiger_cache_pages_evicted_by_application_threads_total зростає, latency запитів зростає разом з ним. На одному проєкті ми побачили, як індексний запит став виконуватися на 200 мс повільніше через cache eviction. Після збільшення кешу до 70% RAM проблема пішла. Слідкуйте за відношенням mongodb_wiredtiger_cache_bytes_currently_in_cache до max_bytes_configured — при 95% протягом 10 хвилин ставте алерт. WiredTiger cache pressure — один з перших індикаторів проблем з продуктивністю.

Які метрики критичні для replica set?

Для replica set ключових метрик три: стан членів, lag та операції. mongodb_rs_members_state показує стан: 1 (PRIMARY), 2 (SECONDARY), 6 (RECOVERING), 8 (DOWN). Будь-яке значення не 1 або 2 — це аварія. mongodb_rs_members_optime_date дозволяє обчислити replication lag: різниця між PRIMARY та SECONDARY у секундах. При перевищенні 30 секунд протягом 5 хвилин ставте алерт. mongodb_rs_members_optime_date часто ігнорують, але на великих кластерах lag може призвести до втрати даних при failover.

Критичні метрики MongoDB у production

У production ми фокусуємося на п'яти групах метрик. Ось вони у таблиці:

Replica Set стан. mongodb_rs_members_state — перший індикатор біди. Будь-яке значення окрім 1 або 2 — це надзвичайна ситуація. mongodb_rs_members_optime_date разом з різницею між PRIMARY та SECONDARY дає replication lag. На великих кластерах ми ставимо for: 5m та поріг 30 секунд, щоб уникнути хибних спрацьовувань на коротких піках навантаження.

WiredTiger cache прямо впливає на latency. Моніторинг цього показника дозволяє вчасно розширити кеш або оптимізувати запити.

Операції. mongodb_op_counters_total з типом query, insert, update, delete, command — профіль навантаження. Різка зміна співвідношення після деплою — перший сигнал, що програма використовує базу не так, як очікувалося.

З'єднання. Коли current наближається до available — база починає відмовляти. Ставте алерт при 80% заповнення.

Коли mongodb_exporter кращий за старий dcu/mongodb_exporter?

percona/mongodb_exporter перевершує dcu/mongodb_exporter у 3 рази за кількістю колекторів (10 проти 3). Це дозволяє збирати метрики колекцій, індексів та діагностичні дані — все, що потрібно для глибокого аналізу. Крім того, percona-експортер активніше розвивається та сумісний з MongoDB 7.0+. Детальніше про можливості можна дізнатися на GitHub-сторінці проєкту.

Приклад алертів для Prometheus

---
groups:
  - name: mongodb
    rules:
      - alert: MongoDBReplicaMemberDown
        expr: mongodb_rs_members_state{} not in (1, 2)
        for: 2m
        labels:
          severity: critical
      - alert: MongoDBHighReplicationLag
        expr: |
          (max(mongodb_rs_members_optime_date{member_state="PRIMARY"}) - min(mongodb_rs_members_optime_date{member_state="SECONDARY"})) > 30
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "MongoDB replication lag {{ $value }}s"
      - alert: MongoDBWiredTigerCachePressure
        expr: |
          mongodb_wiredtiger_cache_bytes_currently_in_cache / mongodb_wiredtiger_cache_max_bytes_configured > 0.95
        for: 10m
        labels:
          severity: warning

Як налаштувати моніторинг sharded кластера?

Для sharded MongoDB важливі метрики балансувальника:

• mongodb_mongos_balancer_enabled — чи ввімкнено балансувальник
• mongodb_ss_sharding_chunks_* — розподіл chunks по шардам

Якщо chunks розподілені нерівномірно — запити перевантажують один шард, інші простоюють. Експортер збирає ці дані тільки при підключенні до mongos, не до mongod напряму.

Типові помилки при налаштуванні моніторингу

Що входить у роботу?

• Аудит поточної конфігурації MongoDB та Prometheus.
• Розрахунок рекомендованих колекторів та метрик під вашу схему.
• Деплой експортера, налаштування scrape у Prometheus.
• Налаштування алертів (replica state, replication lag, cache pressure, connections).
• Створення дашборда в Grafana з key metrics.
• Документація runbook з експлуатації.

Базова налаштування (деплой, scrape, алерти на RS-стан та connections) — 4–6 годин. Повноцінний стек з collstats, indexstats, дашбордами під конкретну схему та шардуванням — 1–2 дні. Вартість базового налаштування — від 5000 грн, повного — від 15000 грн. Вартість розраховується індивідуально і залежить від складності архітектури.

Зв'яжіться з нами для налаштування моніторингу вашого кластера. Наші сертифіковані фахівці з 8-річним досвідом гарантують якісний моніторинг. Отримайте консультацію по вашому проєкту вже сьогодні. Замовте аудит поточного моніторингу — ми знайдемо вузькі місця та запропонуємо рішення.