作业帮基础观测能力之一监控体系实践

正文

请到「今天看啥」查看全文

Prometheus 只支持单机部署，无法集群化, 在大数据量的场景下无法作为监控数据的存储中心，因此我们选择了 VictoriaMetrics 来存储监控数据。

在实际使用中，VictoaMetrics 在性能表现上十分优秀，单核可以支持 5W/S 的指标写入，查询的平均耗时在 50ms 左右，P99 在 2s 以内。

监控访问

我们的监控数据会在以下 3 个场景提供访问：

• 监控大盘：我们选择 grafana 作为监控数据的展示面，收敛所有的可视化需求。

• 指标告警：告警上我们复用了 grafana 的告警能力，从而在告警时做到与可视化界面的联动。

• 服务巡检：我们提供了巡检系统定期扫描服务的健康度，通过可信任的 API 来访问监控数据， 从而提前发现提前治理。

• 根因分析：当线上服务遇到问题时，我们提供了根因分析服务来快速分析定位问题。根因分析系统会通过可信任的 API 获取日志、监控、追踪和事件等数据，按策略进行分析定位。

多维度的监控指标采集是怎么建设的

我们将监控层级从下到上分为 4 层, 并按所属层次划分管理对应的采集任务，每一层的指标会由对应的 prometheus 实例来负责采集。

系统指标建设

系统指标里主要包括 K8S 集群，网络，基础组件，Pod，Node 的各种指标。

通过这一层的指标我们了解系统的运行状态，通过监控数据知晓系统中的各种问题。

存储指标建设

存储是整个系统中极为重要的一部分，我们会为每类存储建立它们的指标数据。

存储指标里主要包括了 Mysql，Redis，ES，MQ 等各种存储的指标，以感知它们的运行情况。

另外我们会读取服务与存储的请求关系，为每个存储绑定服务依赖关系，从而完成存储与服务监控指标数据的联动。

服务指标建设

服务是整个系统的核心部分，我们会围绕着服务建立各类监控指标，自动完成指标的采集和汇聚，从而向用户提供全面的服务监控指标。

当前主要包含以下几类数据：

服务入流量指标

• 服务出流量指标

• 存储（mysql、redis、es 等）访问指标

• MQ 生产 / 消费指标

• 服务运行时指标（Runtime）

服务指标建设致力于提供覆盖服务的通用指标数据，上线的服务无需额外配置就可以看到自己的大盘数据。

业务指标建设

服务运行时有很多业务指标需要观测，这些指标我们无法直接观测到，需要服务主动暴露出来。这种监控需求之前一般是通过服务增加打点日志然后进行统计分析完成的。这种实践方式会有几个问题在：

• 依赖日志链路：可用性和准确性强依赖日志链路，而日志的可用性保证一般会低于服务的可用性保证。

• 依赖分析服务：对分析统计的服务强依赖，并且这个依赖会带来额外的资源开销。

• 使用门槛高：需要额外配置日志解析和数据统计的规则，有一定的使用门槛。

在业务指标的实践上，我们建议服务通过 prometheus sdk 来统计关心的业务指标数据，并通过 metrics 接口暴露出来最后交由 proemtheus 自动完成采集。这种方式有几个优点：

请到「今天看啥」查看全文