基于Prometheus的基础软硬件全链路监控设计和实现

文/马永 吴跃 何李囡 程航

1 Prometheus概述

Prometheus是一套开源的系统监控报警解决框架，它源于SoundCloud公司的开源监控告警解决方案。作为新一代的云原生监控系统，拥有易管理性、高效、良好可视化等优点，旨在为集团内部提供更成熟的监控与告警服务。

国网安徽公司各信息系统自上线至今已稳定运行多年，得益于国网公司统推的I6000监控平台、性能监测等，主机、中间件、网络等方面得到了有效的监控。但随着国网安徽公司承载业务量的增加以及系统规模的扩大，对于容器层级、业务层级以及内部资源对象上的监控和问题排查变得越发复杂和困难。

针对该情况，我们结合运维场景，提出了基于Prometheus监控工具的全链路监控、告警，搭载Grafana软件统一展示的解决方案。

2 企业级系统监控面临的问题

与传统监控相比，电力企业级系统监控面临着许多难点：

（1）监控资源对象动态可变，无法进行预先配置；

（2）涉及系统多、监控范围繁杂，各类监控融合难度大；

（3）各个实例间的调用关系复杂，故障排查更困难。

在工程角度也面临着不少考验，监控系统必须要保证可靠性，同时监控数据也要保证有备份机制；监控系统必须支持快速部署及水平扩容，这既是云原生的基本要求，也符合企业系统容器化演进的实际情况。

3 企业级系统监控技术选型

监控的诸多问题让选型变得非常慎重，经过调研和部署测试，决定采用开源监控方案Prometheus。其具有以下优势：

（1）灵活的数据模型。在Prometheus里，监控数据是由值、时间戳和标签表组成的；同时Prometheus支持在监控数据采集阶段对监控数据的标签表进行修改，这使其具备强大的扩展能力。

（2）更契合的架构。采用Kubernetes作为容器编排工具，支持Prometheus无缝部署和扩展。

（3）Prometheus提供有数据查询语言PromQL。大部分情况下都可以直接通过PromQL从Prometheus里查询到需要的聚合数据，便于快速获取监控数据。

（4）丰富的组件支持。Prometheus监控主体是Prometheus Operator。除此以外，Prometheus方案加入了多种组件满足Kubernetes的监控场景，极大地丰富了Prometheus方案的功能。

（5）成熟的社区。Prometheus拥有成熟的开源社区，有丰富的参考文档，便于快速的搭建监控系统。

4 企业级系统监控目标

监控系统需要能够有效的了解其实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。通过建立完善的监控体系，从而达到以下目的：

监控数据获取：周期性的从实例中获取监控样本，并保存到基于本地磁盘实现的时间序列数据库中。

告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或提前预防问题的发生，避免出现对业务的影响。

故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控指标以及历史数据的分析，能够找到并解决根源问题。

数据可视化：通过Grafana可视化工具能够直接展示获取的系统运行状态、资源使用情况、以及服务运行状态等直观的信息。

5 Prometheus监控设计方案

国网安徽公司Prometheus监控的物理架构，具体包括数据采集模块、数据存储模块、告警上报模块、数据可视化模块四大模块。

5.1 数据采集模块

主要采用Prometheus扩展组件Nodeexporter采集底层服务器的各种运行参数，如CPU、内存使用率，主机运行时长，分区使用率，网络状态，数据IO吞吐量等信息。

5.2 数据存储模块

为数据的可视化呈现提供有效的数据支持，需要对采集到的数据进行存储，Prometheus将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。

5.3 告警上报模块

当出现异常情况时，Prometheus首先推送单条异常告警，如果异常情况大于1条，会同时触发过滤规则，此时Prometheus会将所有的告警合并成一条Json数据推送出来。根据这一特点，Prometheus可以有效减少告警数量。

5.4 数据可视化模块

采用Grafana可视化工具，提供面向集群级的数据展示服务，图标可定制化，兼容多种数据源，便于用户监控管理。

6 监控架构实际应用特点

6.1 准确性与可靠性的权衡

Prometheus作为一个基于指标的监控系统，在设计上放弃了一部分数据准确性。比如在两次采样的间隔中，内存用量有一个瞬时小尖峰，那么此时小尖峰是观察不到的。

放弃一点准确性得到的是更高的可靠性，这里的可靠性体现为架构简单、数据简单、运维简单。比如ELK或其它日志架构，日志系统想要稳定需要付出多倍的硬件成本与人力成本。

6.2 做好自身监控

Prometheus本身可以由另一个Prometheus进行监控。按照官方部署的Prometheus单实例做好自身监控。因此建议在生产环境上，要确保至少有两个独立的Prometheus实例做交叉监控。

另一个点是警报系统（Alertmanager），Prometheus可以监控到警报系统出现了问题，但是因为警报功能异常，所以警报无法正常发出。这个问题可以通过给警报系统做HA来应对。

6.3 发现维度过高的指标

Prometheus里50%以上的存储空间和80%以上的计算资源（CPU、内存）都是被两三个维度超高的指标用掉。而且这类指标由于数据量很大，时间久了就会导致Prometheus实例出问题。有效的解决办法是用警报规则找出维度过高的指标，然后在Scrape配置里Drop掉导致维度过高的label。

6.4 监控的核心目标

监控的核心目标是保障业务系统稳定。追求“监控的覆盖率”，所有系统所有层面要有指标，太多监控项让Prometheus负载加重；追求“警报的覆盖率”，事无巨细必须要有警报，最后“告警风暴”让大家都对警报产生疲劳。

监控的目标绝对不是为了达到多少个指标，多少条警报规则，不要为监控系统的功能或覆盖面负责，而要为整个系统的业务稳定性负责。

7 全链路监控展望

7.1 监控立体化

主机资源对象监控主要依赖Prometheus实现，既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。但容器监测上还有所欠缺，如需做到监控的立体化，cAdvisor是专门用来分析运行中的Docker容器的资源占用以及性能特性的工具，能够收集、聚集、处理并导出运行中容器的信息。

7.2 ELK日志分析平台搭建

Prometheus不支持日志监控及分布式追踪等功能，加入ELK实用化日志平台，进行日志监控，对服务器操作系统、数据库、中间件、应用程序等文件型日志采集和集中展示。

7.3 IPMITools管理工具应用

IPMItool是一个远程管理方案。它能够用于IPMI接口管理和配置，支持本地操作和远端操作，支持智能平台接口管理，可以独立于服务器的CPU、内存、存储、电源而工作。

IPMI是一个开放的标准、监控、记录、回收，库存和硬件实现独立于主CPU、BIOS以及操作系统的控制权。服务处理器的背后是平台管理的大脑，其主要目的是处理自主传感器监控和事件记录功能。

IPMItool提供了一个简单的命令行接口（BMC）。它具有读取传感器数据存储库（SDR）和打印传感器值，显示系统事件日志内容的功能。IPMItool工具的应用，使信息运维可以做到远程主机电源的开关、重启，服务器硬件告警的自动发送，大大节约了现场运维人力的投入。

8 结束语

安徽公司信通公司运检中心的全体开发人员，为了实现当前一个微服务的应用指标，采用了Prometheus对开源监控进行指标采集与分析，并在国网公司和网省公司各领导的正确带领下，厉兵秣马、夯实基础，为建设国际一流电网、世界一流企业，落实“一强三优”的现代化公司的企业战略努力前行。对于此项实例，可以描述微服务监控解决的主流程，能够有效地提高监控预警系统可靠性。基于Prometheus则需要使用多台服务器拉取标签，分别存储，同时根据Gossip机制去完成过滤、去噪等操作。在此过程中，由于迭代速度较快，如果需要有自动化服务发现（如Consul）配置来替代当前的手动配置。