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

Сервис работал, ошибок в логах не было, загрузка 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. Состояние кластера и история изменений

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

Заключение

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

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

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

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