# Почему важно мониторить поисковую систему: Manticore → Prometheus → Grafana

Запустите полный стек мониторинга для Manticore Search одной Docker-командой и получите готовый для продакшена дашборд Grafana с 21 алертом из коробки.

Один из наших пользователей недавно обратился к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не сломалось.

Сервис работал, ошибок в логах не было, загрузка CPU выглядела нормально, но пользователи уже жаловались, что поиск тормозит.

Так обычно и проявляются проблемы с поиском в продакшене. Не как драматичный сбой, а как медленное, постепенное ухудшение. Чуть больше трафика здесь, чуть больше индексации там, и прежде чем вы это заметите, производительность уже просела.

К тому моменту, когда пользователи это замечают, настоящая проблема нередко назревает уже несколько часов. Без ясной картины происходящего остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или что-то идёт не так, но это пока не видно?

Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.

## Представляем дашборд Manticore для Grafana

Именно для этого мы и сделали новый дашборд Manticore для Grafana.

Вместо россыпи сырых метрик он даёт чистую, практичную картину того, что действительно важно в работе поиска в продакшене. С первого взгляда можно увидеть:

- Нода в порядке?
- Насколько высока текущая нагрузка?
- Замедляются ли запросы?
- Какие таблицы используют больше всего ресурсов?

Дашборд помогает быстро перейти от жалобы пользователя к реальной первопричине.

## Как работает стек

Настройка проста: **Manticore → Prometheus → Grafana**.

Manticore экспортирует богатый набор внутренних метрик, Prometheus собирает и хранит их как тайм-серии, а Grafana визуализирует всё это в нашем готовом дашборде, включая **21 готовый алерт для продакшена**.

Вы можете запустить весь стек одной командой Docker:

```bash
docker run -e MANTICORE_TARGETS=localhost:9308 -p 3000:3000 manticoresearch/dashboard
```

(Измените переменную окружения `MANTICORE_TARGETS`, если ваш сервер Manticore слушает на другом адресе.)

Если предпочитаете настроить всё вручную, используйте эти файлы:
- [JSON дашборда](https://raw.githubusercontent.com/manticoresoftware/grafana-dashboard/main/grafana/dashboards/manticore-dashboard.json)
- [Правила алертов](https://raw.githubusercontent.com/manticoresoftware/grafana-dashboard/main/prometheus/rules/manticore-alerts.yml)
- Пример [конфигурации Prometheus](https://raw.githubusercontent.com/manticoresoftware/grafana-dashboard/main/prometheus/prometheus.yml)

Минимальная конфигурация Prometheus для сбора метрик:

```yaml
scrape_configs:
  - job_name: "manticore"
    static_configs:
      - targets: ["localhost:9308"]
```

## Изучаем дашборд

Дашборд устроен так, чтобы искать проблему можно было последовательно, без лишних переключений.

### 1. Сводка по состоянию (начните с этого)

![Сводка состояния](./grafana-dashboard-full/preview-general.png)

Откройте дашборд и сначала посмотрите на верхнюю строку панелей. Она сразу даёт ясную картину общего состояния ноды.

Ключевые панели, на которые стоит смотреть:
- **Health / Up** — может ли Prometheus вообще собирать метрики?
- **Health / Crash indicator** — были ли падения недавно?
- **Workers Utilization %** + **Load / Queue pressure** — высокая загрузка плюс растущая очередь запросов — один из самых явных ранних признаков того, что нода подходит к пределу.

Панель **System Score** тоже даёт быструю общую оценку состояния с первого взгляда.

### 2. Нагрузка от запросов и время ответа

![Раздел нагрузки 1](./grafana-dashboard-full/load_1.png)
![Раздел нагрузки 2](./grafana-dashboard-full/load_2.png)

Дальше проверьте, с какой нагрузкой сейчас работает система.

- **QPS Total** показывает общий уровень трафика.
- **Search Latency (p95/p99)** — одна из самых важных панелей: средние значения могут скрывать проблемы, а перцентили показывают, какое время ответа пользователи видят в худшем случае.
- **Slowest Thread** помогает находить тяжёлые или зависшие запросы.
- **Work Queue Length** и **Worker Saturation** вместе показывают, справляется ли нода или воркеры уже на пределе.

### 3. Память и ресурсы

![Раздел памяти](./grafana-dashboard-full/memory.png)

Этот раздел особенно полезен, потому что нагрузка на память — очень частая и часто скрытая причина замедлений в поисковых системах. Вместо одного расплывчатого числа дашборд разбивает всё так, что вы сразу видите, где именно растёт потребление.

- **Searchd RSS** и **Buddy RSS** показывают *общий объём резидентной памяти* — сколько физической RAM основной поисковый демон `searchd` и вспомогательный процесс Buddy реально используют прямо сейчас.
- Панели **Anon RSS** идут на уровень глубже. «Анонимная» память — это приватная, динамическая RAM, которую выделяет сам Manticore (куча, кеши запросов, загруженные структуры данных, временные буферы — всё, что не опирается на файл на диске). В отличие от памяти, отображённой из файлов, которую ОС может выгрузить или вернуть, именно анонимная память обычно сильнее всего нагружает систему.

Зачем показывать и RSS, и Anon RSS? Общий RSS даёт общую картину, а Anon RSS объясняет, что за ней стоит. Если общий RSS растёт, но Anon RSS стабилен, рост может быть безобидным, например из‑за большего числа закешированных файлов. Если быстро растёт и Anon RSS, это обычно признак того, что структуры данных Manticore или активность запросов съедают всё больше памяти, а именно это и ведёт к более медленным запросам или даже к свопингу.

Внизу вы также увидите несколько полезных индикаторов:
- **Resources / FDs (searchd)** — текущее количество открытых файловых дескрипторов, которые использует поисковый демон. Manticore держит открытыми много файлов индексов, особенно у больших real-time таблиц с множеством дисковых чанков. Если число станет слишком большим, можно упереться в лимит ОС и начать получать ошибки «Too many open files». Поднять софт лимит можно настройкой `max_open_files` (см. [документацию Manticore по настройкам сервера](https://manual.manticoresearch.com/Server_settings/Searchd#max_open_files)).
- Активные воркеры, число таблиц и необслуживаемые таблицы — всё это помогает быстро заметить, что требует внимания.

### 4. Инсайты по таблицам

![Раздел таблиц](./grafana-dashboard-full/tables.png)

Теперь посмотрите на сами данные.

- Число документов по таблицам
- Топ-10 таблиц по использованию RAM и диска
- Панель **Tables / Health** — она объединяет число документов, RAM, диск и флаги состояния (locked/optimizing) в одном виде.

### 5. Состояние кластера и история изменений

![Раздел кластера](./grafana-dashboard-full/cluster.png)
![Раздел истории](./grafana-dashboard-full/history.png)

Для сетапов с репликацией здесь видны состояние нод и статус синхронизации. Раздел истории отлично отвечает на самый важный вопрос во время любого инцидента: *что изменилось прямо перед тем, как всё замедлилось?*

## Заключение

Вспомним исходную ситуацию: поиск внезапно стал заметно медленнее.

Достаточно было открыть этот дашборд, чтобы проблема почти сразу стала очевидной: воркеры нагружались всё сильнее, очереди росли, а потребление памяти продолжало расти — и всё это ещё до появления явных ошибок или падений. Получив чёткую картину того, что реально происходит внутри движка, удалось быстро найти первопричину, внести нужные изменения и вернуть поиску скорость и стабильность, которых ожидали пользователи.

Настоящая ценность мониторинга не только в красивых графиках. Это способ заранее замечать назревающие проблемы, пока они не начали стоить вам денег или клиентов.

Этот дашборд убирает слепую зону. Он даёт нужную ясность, чтобы поиск оставался быстрым и надёжным.