Настройка мониторинга 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?

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 включает 10 коллекторов против 3 у dcu/mongodb_exporter, что в 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 дня. Стоимость рассчитывается индивидуально и зависит от сложности архитектуры.

Свяжитесь с нами для настройки мониторинга вашего кластера. Получите консультацию по вашему проекту уже сегодня. Закажите аудит текущего мониторинга — мы найдем узкие места и предложим решения.