Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.

Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.

И обычно самое сложное здесь не заметить проблему, а понять, что на самом деле происходит.

Когда всё выглядит нормально, но поиск по-прежнему медленный

Возьмём довольно обычный сценарий.

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

Но пользователи это ощущают.

Итак, вы открываете мониторинг:

• CPU выглядит нормально.

• Среднее время отклика не выглядит слишком высоким.

• Нет очевидных алертов.

На первый взгляд ничто толком не объясняет замедление.

И вы продолжаете копать...

Вы проверяете очередь. Сразу ничего не бросается в глаза.
Вы смотрите на загрузку воркеров. Они заняты, но сами по себе мало что объясняют.
Вы проверяете логи. Но там тоже ничего явного.

И спустя какое‑то время вы доходите до неприятного момента: обычные проверки уже сделаны, а где проблема, всё ещё непонятно.

Каждая метрика сама по себе выглядит более-менее нормально. Но вместе они ясно показывают, что система деградирует.

Теперь вы уже не идёте по чёткому плану расследования. Вы просто проверяете всё, что приходит в голову, и надеетесь, что закономерность проявится.

Тем временем время идёт.

Что на самом деле происходило

Через пару часов картина наконец начинает проясняться.

Оказывается:

• очередь запросов медленно росла;

• воркеры работали почти на 100 % загрузки;

• один тяжёлый запрос время от времени блокирует выполнение;

• p99 время отклика заметно хуже, чем кажется по среднему;

• и одна из нод недавно перезапустилась.

То есть все сигналы были видны с самого начала.

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

Решение: увидеть всю картину сразу

Вместо того чтобы тратить часы на ручную сборку всего этого, гораздо лучше иметь одно место, где важные сигналы уже видны.

Именно поэтому мы собрали готовый к использованию дашборд для Manticore Search, который запускается одной Docker‑командой. В него входят Grafana, Prometheus, преднастроенный источник данных и встроенные алерты.

docker run -p 3000:3000 manticoresearch/dashboard

Переменные окружения

Контейнер поддерживает две переменные окружения :

• MANTICORE_TARGETS — список инстансов Manticore Search, разделённых запятыми (по умолчанию: localhost:9308)

• GF_AUTH_ENABLED — установить true, чтобы включить вход в Grafana (по умолчанию включён анонимный доступ администратора)

Пример:

docker run -p 3000:3000 \
  -e MANTICORE_TARGETS=your-host:9308 \
  manticoresearch/dashboard

Если вы мониторите несколько нод, можете передать их списком, разделив запятыми:

docker run -p 3000:3000 \
  -e MANTICORE_TARGETS=node1:9308,node2:9308,node3:9308 \
  manticoresearch/dashboard

Если Manticore работает на удалённом сервере

По умолчанию дашборд обращается к localhost:9308. Если ваш сервер работает на удалённой машине, самый простой вариант — проброс порта через SSH:

ssh -L 9308:localhost:9308 user@your-server

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

Через минуту у вас будет ясная картина состояния системы.

Не просто куча графиков, а дашборд, который помогает быстро ответить на вопросы, действительно важные, когда что‑то идёт не так.

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

Что показывает дашборд

Ценность здесь не в том, что на дашборде много панелей. Ценность в том, что сами панели быстро отвечают на правильные вопросы.

Первое место для просмотра — общий вид системы:

Это сразу даёт вам базовую картину:

• сервис работает;

• недавно перезапускался;

• растёт ли очередь;

• воркеры уже под нагрузкой.

Если по этому блоку всё в порядке, возможно, проблема узкая и локальная. Если нет, вы сразу понимаете, что система под реальной нагрузкой.

Дальше переходите к тому, как ведут себя воркеры и запросы:

Здесь быстро видно:

• начинает ли накапливаться очередь запросов;

• упираются ли воркеры в предел;

• ухудшается ли время отклика, особенно p95 и p99;

• вызывает ли один медленный тред непропорционально большую часть проблем.

Если нужен более широкий контекст, можно углубиться в остальные разделы дашборда:

• состояние кластера:

  

• таблицы и данные:

  

На этом этапе вы больше не смотрите на разрозненные метрики. Вы смотрите на систему в целом.

Почему это важно

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

• Вы видите, что очередь растёт.

• Вы видите, что воркеры упёрлись в потолок.

• Вы видите, что p99 растёт.

• Вы видите, что одна нода перезапустилась.

• Вы видите, что один запрос, вероятно, создаёт основную проблему.

Это не значит, что дашборд волшебным образом исправит проблему за вас.

Что он действительно делает, так это убирает самую медленную часть процесса: понимание того, куда смотреть.

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