Yuxu Ge
文章 · 2019-10-24

内容检索平台的 Solr 监控实践与可观测性优化

在内容搜索系统中，Solr 的性能和稳定性直接影响用户体验。当平台的搜索响应时间在高峰期出现下降时，我们开始构建系统化的监控方案，从三个维度出发：Solr 应用层指标、JVM 内部状态、主机资源占用。本文介绍我们监控的核心指标、自动化分析的方法，以及摸索过程中踩过的坑。

值得监控的指标

Solr（尤其是 SolrCloud 模式）的指标预置了 collection、shard、replica 等标签，便于按维度区分。我们将指标分为三类，每一类对应具体的业务和技术后果：

查询性能： 请求返回有多快，系统是否能承受当前流量？

索引健康： 索引数据是否按预期增长，资源消耗是否在控制范围？

运行时健康： JVM 是否稳定，系统资源是否趋近饱和？

这三个维度覆盖了大多数问题的诊断：延迟上升但 QPS 和错误率正常，查看 GC 和内存；QPS 骤降，检查错误率和集群副本状态；索引大小异常增长，排查索引流程。

平均值与高分位的陷阱

最常见的监控失误是只看平均延迟。假如 95% 的查询在 100 ms 内返回，但 5% 花 500 ms，平均值会掩盖问题——直到用户投诉才发现。

Solr 的指标包括 solr_metrics_core_time_seconds_total（查询处理总耗时）和 solr_metrics_core_requests_total（查询总数）。利用这两个计数器，我们计算时间窗口内的平均延迟：

increase(solr_metrics_core_time_seconds_total[5m])
/ increase(solr_metrics_core_requests_total[5m])

这样得到 5 分钟内的平均值，但却隐藏了尾部。若要获取 P95，需要直方图数据。若 Solr 的 Prometheus 导出器配置了分布桶，使用：

histogram_quantile(0.95, sum(rate(search_latency_bucket[5m])) by (le))

这样计算出过去 5 分钟的 95 分位延迟。若导出器未提供直方图，应调整配置开启它，或直接调用 Solr Metrics API 获取分位值。现实情况往往是：平均延迟 100 ms，但 P95 延迟 500 ms。只监控平均值的告警会完全失效。

集群状态与副本健康

SolrCloud 中，只要某个 shard 的至少一个副本活跃，查询就能成功。这意味着基础指标（QPS、延迟）看起来正常，但集群已在悄悄降级。

我们用 solr_collections_shard_state 和 solr_collections_replica_state 直接监控每个副本的状态。若某副本超过几分钟未处于 ACTIVE 状态，立即告警。单个副本下线是警告，同一 shard 的两个副本同时出问题才是真正的 P1 事件。

自动化观察

除了看图表，脚本能帮助我们发现趋势和验证假设。我们用 Python 直接调用 Solr Metrics API 和 Prometheus。

健康检查脚本

Solr 的 /admin/ping 接口返回 core 的健康状态。一个简单的脚本每隔几分钟运行一次，能捕捉到 Prometheus 标准抓取间隔可能错过的瞬时故障：

import requests

solr_url = "http://<Solr主机>:8983/solr/<collection>/admin/ping?wt=json"
try:
    response = requests.get(solr_url, timeout=5)
    data = response.json()
    if response.status_code == 200 and data.get("status") == "OK":
        print("Solr 核心正常：PING 状态 OK")
    else:
        print("Solr 核心健康检查失败！返回:", data)
except requests.RequestException as e:
    print("Solr 健康检查出现异常：", e)

这是对被动 Prometheus 抓取的补充。Solr 短暂无响应时，这个脚本往往能比下一次指标拉取提早若干秒发现，缩短了检测延迟。

趋势分析

为了规划增长或调查渐进式性能衰退，我们通过 Prometheus 的 query_range 接口提取时间序列数据。例如追踪索引大小增长：

import requests
import datetime

# Prometheus HTTP API 接口和查询参数
prom_url = "http://<Prometheus服务器>/api/v1/query_range"
metric = "index_size{collection=\"main_content\"}"  # 假设主要内容索引的集合名为 main_content
end = int(datetime.datetime.now().timestamp())
start = end - 7*24*3600  # 一周前
step = 24*3600  # 间隔1天

params = {
    "query": metric,
    "start": start,
    "end": end,
    "step": step
}
response = requests.get(prom_url, params=params)
data = response.json()

if data.get("status") == "success":
    results = data["data"]["result"]
    if results:
        values = results[0]["values"]  # 时间序列数据点 [timestamp, value]
        initial = float(values[0][1])
        latest = float(values[-1][1])
        diff = latest - initial
        growth_pct = (diff / initial * 100) if initial > 0 else float('inf')
        print(f"一周前索引大小: {initial:.2f}, 现在索引大小: {latest:.2f}")
        print(f"一周内索引增长了 {diff:.2f} 字节, 增幅 {growth_pct:.1f}%")
    else:
        print("查询结果为空，可能指标不存在")
else:
    print("Prometheus 查询失败：", data.get("error", "未知错误"))

这会取过去一周每天一个数据点，并计算绝对增长和百分比增长：

一周前索引大小: 1.50e+10, 现在索引大小: 1.80e+10  
一周内索引增长了 3.00e+09 字节, 增幅 20.0%

周增长率达 20% 就提示应该开始规划存储。我们对查询速率（发现季节性）、GC 耗时（发现性能债）、错误率（发现可靠性趋势）做类似分析。Prometheus 的 HTTP API 返回 JSON，用 Python 解析和分析比盯着仪表板图表灵活得多。

Grafana 仪表板

精心设计的仪表板不是装饰品，它是值班人员诊断事故的操作界面。我们通过实践学到几点重要教训。

用模板变量驾驭多集群

不要为每个 collection 或节点硬编码单独的图表。使用 Grafana 的模板变量：

一个仪表板就能覆盖所有集群、collection、副本。运维人员通过下拉菜单切换视角，而不用跳转不同仪表板。选择 "All" 时还能聚合或对比多个 collection——对有文章、评论、文档等多个索引的平台至关重要。

PromQL 查询的计算权重

避免在 Grafana 中计算。用 PromQL 让 Prometheus 完成繁重工作。例如 QPS：

rate(solr_metrics_core_requests_total{handler="/select"}[1m])

直接得到每秒请求数，无需后处理。延迟也类似：

increase(solr_metrics_core_time_seconds_total[5m])
/ increase(solr_metrics_core_requests_total[5m])

两种写法都没问题，关键原则是：让 Prometheus 做聚合和计算，Grafana 只负责渲染。

布局与标签清晰度

相关面板并排放置。QPS 尖峰常常先于延迟上升出现；两图相邻能节省调查时间。Y 轴必须标注单位。"0.1" 不加单位无法理解——是 0.1 秒还是 0.1 毫秒？Grafana 的单位选择器可以防止误读。

用图例模板区分叠加的线条。监控多个节点时，{{base_url}}/{{collection}}_{{shard}}_{{replica}} 这样的图例一目了然。

层次化钻取

顶层仪表板显示所有 collection 的聚合健康度。接收到告警时（比如某 collection 延迟高），通过变量筛选到该 collection；必要时再深入到特定 shard 或副本。Grafana 支持仪表板间跳转，可配置跳转时携带变量。一条通用告警就变成了 30 秒内定位到相关数据的路径。

控制查询开销

监控许多 shard 和副本时，PromQL 会变得昂贵。避免宽泛的正则或大范围的 by() 分组。必要时用 Prometheus Recording Rule 预聚合——比如将所有 /select 和 /query 处理器合并成 search_requests_total，然后只查询这个指标。刷新间隔应在 10–30 秒；过于频繁反而增加后端压力，收益微乎其微。

我们踩过的坑

坑一：平均值隐藏长尾

我们曾监控平均查询延迟数个月，自认为系统健康。当少数查询开始超过 1 秒时没有察觉，因为平均值依然很低。用户抱怨后才发现问题。解决办法：同时告警 P95 和 P99，而不仅是平均值。设置 "P95 延迟 > 200 ms 持续 5 分钟" 这样的规则，让长尾指引告警。

坑二：错误无声地发生

性能指标看起来不错，系统却在无声地失败。若 Solr 查询报错，用户无结果——比缓慢更糟。检查各处理器的错误数或错误率。我们曾碰到大量查询因连接超时失败，而 QPS 和延迟指标仍然可以接受，因为失败的请求返回速度快或根本没返回。立即把错误率纳入告警。

坑三：JVM 状态被忽视

我们关注面向用户的指标（QPS、延迟），却忽视了 JVM 行为。某实例开始频繁发生持续 20+ 秒的 Full GC，冻结所有查询处理。因为暂停期间没有请求被计数，平均延迟不受影响。告警未曾触发，用户却经历了完全不可用。

直接监控 GC 耗时、GC 频次和堆占用。若 Full GC 时长或频次激增，立即告警。类似地，监控线程池队列深度和打开的文件句柄——触及系统限制会导致隐蔽的失败模式，仅从 QPS 图表看不出来。

坑四：集群降级检测滞后

SolrCloud 中，某副本失败而其他副本存活时，查询仍能成功。基础指标（QPS、延迟）照常。若第二个副本也在同一 shard 上失败，该 shard 变得不可用，系统级联失败。我们学会了监控副本的显式状态。副本超过几分钟非 ACTIVE 状态，那就是需要立即响应的事件，免得下一个失败到来时系统已经衰退。

坑五：告警阈值调优不当

CPU >90% 就告警，会在日常索引导入时误触发。设到 >99% 又会漏掉真正的问题。我们的做法：从历史数据开始。若 CPU 在正常负载下通常 30–60%，突增到 85% 就值得关注，哪怕规则说的是 90%。给阈值加上持续时间条款：" CPU > 85% 持续 5 分钟" 能捕捉持续过载，但忽略短暂尖峰。结合多个指标：凌晨 3 点 QPS 低且错误率为零属正常，中午同样数据就成了问题。

每月根据实际事件和误报回顾和调整告警规则。最好的阈值源自数据，不是猜测。

现在我们的做法

多维度全面覆盖。 不仅监控用户看到的（QPS、延迟），也监控使之成为可能的（缓存命中率、索引增长、GC 暂停、副本状态）。关联这些视角快速定位根因。

高分位优先于平均值。 P95 和 P99 延迟、错误率和副本状态是主要告警触发器。平均 QPS 和延迟作为背景参考，尤其是在负载尖峰时平均值小幅上升往往属正常。

告警关联到运维手册。 告警通知里包含预先填好变量的 Grafana URL，直接显示相关仪表板。这将从告警到诊断的时间缩短一半。

持续调优。 每次事故过后，我们问：哪些指标本可以提前预警？哪些阈值配置有误？我们为曾经的监控盲点补上覆盖，根据实际发生的情况调整规则。从不改变的监控系统是一个脆弱的系统。

我们把 Solr 看作一个透明的系统，而不是黑盒——每一层都可观测。这种透明度让我们能够敏捷行动，在用户感知问题之前就做出响应。

© 2026 Yuxu Ge ·