# 为什么监控搜索引擎很重要：Manticore → Prometheus → Grafana

通过一个 Docker 命令启动 Manticore Search 的完整监控堆栈，并立即获得包含 21 个开箱即用警报的生产就绪 Grafana 仪表板。

我们最近有一位用户联系了我们，遇到了一个熟悉的问题：搜索突然明显变慢了，尽管看起来一切正常。

服务正常运行，日志中没有错误，CPU 使用率也正常——但用户开始抱怨搜索结果感觉迟缓。

这就是搜索问题在生产环境中通常表现的方式。不是突然的故障，而是缓慢而持续的退化。这里多一点流量，那里多一些索引，不知不觉中性能就下降了。

当用户注意到时，真正的问题往往已经持续了数小时。没有良好的可见性，你只能猜测：系统是否过载？是否有一个表占用了大量资源？还是有其他问题在悄然发生？

这就是监控的重要性。它将模糊的“搜索感觉变慢”的抱怨转化为你可以实际诊断和修复的问题。

## 介绍 Manticore Grafana 仪表板

这正是我们新推出的 Manticore Grafana 仪表板所设计的用途。

它不提供原始指标，而是给你一个清晰、实用的视图，展示在生产环境中运行搜索时真正重要的内容。一目了然，你可以看到：

- 节点是否健康？
- 当前负载有多重？
- 查询是否变慢？
- 哪些表使用了最多的资源？

它旨在帮助你快速从用户症状追踪到实际的根本原因。

## 堆栈的工作原理

设置非常简单：**Manticore → Prometheus → Grafana**。

Manticore 暴露了丰富的内部指标，Prometheus 收集并存储这些指标为时间序列数据，Grafana 则使用我们预构建的仪表板进行可视化——包括 **21 个生产就绪警报**。

你可以通过一个 Docker 命令启动整个堆栈：

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

（如果你的 Manticore 实例运行在其他地方，请更改 `MANTICORE_TARGETS` 环境变量。）

如果你更喜欢手动设置，请获取这些文件：
- [仪表板 JSON](https://raw.githubusercontent.com/manticoresoftware/grafana-dashboard/main/grafana/dashboards/manticore-dashboard.json)
- [警报规则](https://raw.githubusercontent.com/manticoresoftware/grafana-dashboard/main/prometheus/rules/manticore-alerts.yml)
- 示例 [Prometheus 配置](https://raw.githubusercontent.com/manticoresoftware/grafana-dashboard/main/prometheus/prometheus.yml)

最小的 Prometheus 抓取配置：

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

## 探索仪表板

仪表板的布局设计是为了让你遵循自然的故障排除流程。

### 1. 健康摘要（从这里开始）

![健康摘要](./grafana-dashboard-full/preview-general.png)

打开仪表板，首先查看顶部行。它会立即给你一个节点整体健康的画面。

需要关注的关键面板：
- **健康 / Up** — Prometheus 是否能抓取指标？
- **健康 / 崩溃指示器** — 有最近的崩溃吗？
- **工作线程利用率 %** + **负载 / 队列压力** — 这两个面板是黄金组合。高利用率加上上升的队列压力是节点接近饱和的最明显早期迹象之一。

**系统评分** 面板也会给你一个快速的整体健康评分。

### 2. 查询负载和延迟

![负载部分 1](./grafana-dashboard-full/load_1.png)
![负载部分 2](./grafana-dashboard-full/load_2.png)

接下来，检查系统正在处理的工作负载类型。

- **QPS 总数** 显示整体流量水平。
- **搜索延迟（p95/p99）** 是最重要的面板之一——平均值可能隐藏问题，但百分位数显示了用户实际体验到的情况。
- **最慢线程** 有助于发现昂贵或卡住的查询。
- **工作队列长度** 和 **工作线程饱和度** 一起告诉你节点是否跟得上还是开始落后。

### 3. 内存和资源

![内存部分](./grafana-dashboard-full/memory.png)

这一部分非常有用，因为内存压力是搜索引擎中非常常见（且常常隐藏）的减速原因。而不是显示一个模糊的数字，仪表板将其分解，让你清楚地看到增长发生在哪里。

- **Searchd RSS** 和 **Buddy RSS** 显示 *总驻留内存* —— 主搜索守护进程（searchd）和 Buddy 辅助进程当前实际使用的物理 RAM 量。
- **Anon RSS** 面板深入一层。“匿名”内存是 Manticore 自己分配的私有、动态 RAM（想想堆、查询缓存、加载的数据结构、临时缓冲区——所有不依赖磁盘上文件的内存）。与文件映射内存（操作系统可以分页或回收）不同，匿名内存通常是给系统带来真正压力的部分。

为什么同时显示 RSS *和* Anon RSS？总 RSS 给你一个整体画面，但 Anon RSS 告诉你背后的故事。如果总 RSS 上升但 Anon RSS 稳定，增长可能是无害的（例如更多缓存文件）。如果 Anon RSS 也迅速上升，这通常意味着 Manticore 自己的数据结构或查询活动正在消耗越来越多的内存——正是导致查询变慢甚至交换的类型。

在底部你还会看到几个快速计数器：
- **资源 / FDs (searchd)** — 搜索守护进程当前使用的打开文件描述符数量。Manticore 为索引打开大量文件（尤其是大型实时表，包含许多磁盘块）。如果这个数字过高，可能会达到操作系统限制并开始看到“打开文件过多”错误。你可以通过 `max_open_files` 设置提高软限制（参见 [Manticore 服务器设置文档](https://manual.manticoresearch.com/Server_settings/Searchd#max_open_files)）。
- 活动工作线程、表数量和未服务的表——所有快速信号，表明可能需要关注。

### 4. 表级洞察

![表部分](./grafana-dashboard-full/tables.png)

现在放大到数据本身。

- 每个表的文档数量  
- 按RAM和磁盘使用量排名前10的表  
- **表 / 健康状况** 面板 — 这个面板特别有价值，因为它在一个视图中结合了文档数量、RAM、磁盘和状态标志（锁定/优化中）。  

### 5. 集群状态和历史记录  

![集群部分](./grafana-dashboard-full/cluster.png)  
![历史记录部分](./grafana-dashboard-full/history.png)  

在分布式设置中，您可以获取节点状态和同步状态。历史记录部分非常适合回答任何事件中最重要的问题：*在事情变慢之前发生了什么变化？*  

## 结论  

还记得因为搜索突然明显变慢而联系你的用户吗？  

一旦他启用了这个仪表板，问题几乎立刻变得显而易见：工作者进程变得越来越繁忙，队列在增长，内存压力在积累 —— 这一切都在任何明显错误或崩溃出现之前。通过清晰地了解引擎内部实际发生的情况，他迅速找到了根本原因，进行了正确的调整，并将性能恢复到了用户期望的快速且可靠的状态。  

监控的真正价值不仅仅是看到漂亮的图表。它是在问题造成经济损失或客户流失之前，尽早发现那些逐渐出现的问题。  

这个仪表板消除了这一盲点。它为你提供了所需的可见性，以保持搜索的快速和可靠。