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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если предпочитаете настроить всё вручную, возьмите эти файлы:

• JSON дашборда
• Правила алертов
• Пример конфигурации Prometheus

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

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

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

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

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

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

Ключевые панели, на которые стоит смотреть:

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

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

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

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

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

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

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

• 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 по настройкам сервера ).
• Активные воркеры, число таблиц и не обслуживаемые таблицы — всё это быстрые сигналы того, что чему-то может потребоваться внимание.

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

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

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

5. Состояние кластера и история

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

Заключение

Помните пользователя, который пришёл, потому что поиск внезапно стал заметно медленнее?

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

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

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