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

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

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

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

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

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

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

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

• 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 растёт.
• Вы видите, что одна нода перезапустилась.
• Вы видите, что один запрос, вероятно, создаёт основную проблему.

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

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

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