最令人烦恼的事件类型是当数据库没有完全宕机，只是变慢了。
用户会立刻注意到这一点。投诉开始出现。从技术上讲，一切仍在运行，但显然有些不对劲。
而这通常是最困难的部分：不是注意到问题，而是弄清楚到底发生了什么。
当一切看起来正常，但搜索仍然缓慢
让我们来看一个相当正常的场景。
搜索开始变慢。它没有崩溃。它没有返回明显的错误。服务是正常的。从外部看，没有出现戏剧性的故障。
但用户能感觉到这一点。
于是你打开监控：
- 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运行在远程服务器上
默认情况下，仪表板期望Manticore在localhost:9308。如果你的实例运行在远程机器上，最简单的选项是使用SSH端口转发：
ssh -L 9308:localhost:9308 user@your-server
之后，本地连接到localhost:9308将被转发到远程服务器，因此仪表板无需额外更改即可连接。
一分钟之后，你就能获得系统的可用概览。
不仅仅是图表堆，而是一个帮助你快速回答实际关心问题的仪表板，当某些事情感觉不对时。
你可以在一个地方看到队列增长、工作线程饱和、延迟、进程状态和查询行为，而不是在不同工具之间切换并试图在脑海中拼凑故事。
仪表板显示的内容
这里的价值不在于有很多面板。价值在于这些面板能快速回答正确的问题。
首先查看整体系统视图：
这会立即给你基本的画面：
- 服务是否正常；
- 是否最近重启；
- 是否有队列压力；
- 工作线程是否已负载。
如果这一行看起来健康，问题可能是狭窄且局部的。如果它不健康，你立刻知道系统正承受真实压力。
然后你移动到负载和查询行为：
在这里你可以快速看到：
- 工作是否开始堆积；
- 工作线程是否饱和；
- 延迟是否变差，尤其是p95和p99；
- 是否有一个慢线程导致不成比例的麻烦。
如果你需要更多上下文，可以深入仪表板的其余部分：
集群状态：
表和数据：
到那时，你不再查看孤立的指标。你正在查看整个系统。
为什么这很重要
在以前需要花费几个小时才能理解的情况，现在你通常可以在几分钟内找到方向。
- 你可以看到队列在增长。
- 你可以看到工作线程被占用。
- 你可以看到p99在上升。
- 你可以看到一个节点重启了。
- 你可以看到一个查询可能造成了大部分问题。
这并不意味着仪表板会神奇地为你解决问题。
它所做的就是移除了整个过程中最慢的部分：弄清楚该从哪里开始查找。
而在实践中，这往往是区别于花两个小时试图理解事件和花五分钟找到真正问题之间的关键。