大数据下的精准实时监控系统 | Promethus or Zabbix?

我们先来了解什么是监控，监控的重要性以及监控的目标，当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

• 对系统不间断实时监控:实际上是对系统不间断的实时监控(这就是监控)

• 实时反馈系统当前状态:我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障

• 保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行

• 保证业务持续稳定运行:如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

监控方法

既然我们了解到了监控的重要性、以及监控的目的，那么下面我们需要了解下监控有哪些方法。

• 了解监控对象:我们要监控的对象你是否了解呢？比如CPU到底是如何工作的？

• 性能基准指标:我们要监控这个东西的什么属性？比如CPU的使用率、负载、用户态、内核态、上下文切换。

• 报警阈值定义:怎么样才算是故障，要报警呢？比如CPU的负载到底多少算高，用户态、内核态分别跑多少算高？

• 故障处理流程:收到了故障报警，那么我们怎么处理呢？有什么更高效的处理流程吗？

监控核心

我们了解了监控的方法、监控对象、性能指标、报警阈值定义、以及故障处理流程几步骤，当然我们更需要知道监控的核心是什么？

• 发现问题:当系统发生故障报警，我们会收到故障报警的信息

• 定位问题:故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析，比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等等，我们就需要去分析故障具体原因。

• 解决问题:当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。

• 总结问题:当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。

监控工具

下面我们需要选择一款合适公司业务的监控工具进行监控,这里我对监控工具进行了简单的分类。

老牌监控

MRTG（Multi Route Trffic Grapher）是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的Tobias Oetiker与Dave Rand所开发，以GPL授权。MRTG最好的版本是1995年推出的，用perl语言写成，可跨平台使用，数据采集用SNMP协议，MRTG将手机到的数据通过Web页面以GIF或者PNG格式绘制出图像。

Grnglia是一个跨平台的、可扩展的、高性能的分布式监控系统，如集群和网格。它基于分层设计，使用广泛的技术，用RRDtool存储数据。具有可视化界面，适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统，可以轻松的处理2000个节点的集群环境。

Cacti（英文含义为仙人掌）是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具，它通过snmpget来获取数据使用RRDtool绘图，但使用者无须了解RRDtool复杂的参数。提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板。在历史数据展示监控方面，其功能相当不错。Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能）

Nagios是一个企业级监控系统，可监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机状态以及服务，同时提供异常告警通知功能等。Nagios可运行在Linux和UNIX平台上。同时提供Web界面，以方便系统管理人员查看网络状态、各种系统问题、以及系统相关日志等 Nagios的功能侧重于监控服务的可用性，能根据监控指标状态触发告警。目前Nagios也占领了一定的市场份额，不过Nagios并没有与时俱进，已经不能满足于多变的监控需求，架构的扩展性和使用的便捷性有待增强，其高级功能集成在商业版Nagios XI中。

Smokeping主要用于监视网络性能，包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持，特点是绘制图非常漂亮，网络丢包和延迟用颜色和阴影来标示，支持将多张图叠放在一起，其作者还开发了MRTG和RRDtll等工具。Smokeping的站点为：http://tobi.oetiker.cn/hp

开源监控系统OpenTSDB用Hbase存储所有时序（无须采样）的数据，来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集，支持永久存储，可以做容量规划，并很容易地接入到现有的告警系统里。OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的采集指标，并进行存储、索引和服务，从而使这些数据更容易让人理解，如Web化、图形化等。

王牌监控

Zabbix是一个分布式监控系统，支持多种采集方式和采集客户端，有专用的Agent代理，也支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库，然后对其进行分析整理，达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说，它的总体功能做的非常优秀。从以上各种监控系统的对比来看，Zabbix都是具有优势的，其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点，读者只要稍加学习，即可构建自己的监控系统。

Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。Prometheus是最近几年开始流行的一个新兴监控告警工具，特别是kubernetes的流行带动了prometheus的应用。

小米的监控系统：open-falcon。open-falcon的目标是做最开放、最好用的互联网企业级监控产品。

三方监控

现在市场上有很多不错的第三方监控，比如：监控宝、监控易、还有很多云厂商自带监控，但是在这里我们不打算着重介绍，如果想了解三方监控可自行上官网咨询。

监控指标

我们上面了解了监控方法、目标、流程、也了解了监控有哪些工具，可能有人会疑惑，我们具体要监控写什么东西，那么我在这里进行了分类整理:

硬件监控

早期我们通过机房巡检的方式，查看硬件设备灯光闪烁情况判断是否故障，这样非常浪费人力，并且是重复性无技术含量的工作，大家懂得。

当然我们现在可以通过IPMI对硬件详细情况进行监控，并对CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围)

系统监控

中小型企业基本全是Linux服务器，那么我们肯定是要监控起系统资源的使用情况，系统监控是监控体系的基础。

CPU CPU有几个重要的概念:上下文切换、运行队列和使用率。

这也是我们CPU监控的几个重点指标。通常情况，每个处理器的运行队列不要高于3，CPU 利用率中用“户态/内核态”比例维持在70/30，空闲状态维持在50%，上下文切换要根据系统繁忙程度来综合考量。

针对CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances

内存 通常我们需要监控内存的使用率、SWAP使用率、同时可以通过zabbix描绘内存使用率的曲线图形发现某服务内存溢出等。针对内存常用的工具有: free、top、vmstat、glances

IO IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外，那么日常监控，只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度，网络也是监控网卡流量即可。

常用工具有：iostat、iotop、df、iftop、sar、glances

应用监控

把硬件监控和系统监控研究明白后，我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务，都需要监控起来。应用服务监控也是监控体系中比较重要的内容，例如：LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等，相关的服务都需要使用zabbix监控起来。

网络监控

网络监控是我们构建监控平台是必须要考虑的，尤其是针对有多个机房的场景，各个机房之间的网络状态，机房和全国各地的网络状态都是我们需要重点关注的对象，那么如何掌握这些状态信息呢？我们需要借助于网络监控工具Smokeping。

Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl写的，主要是监视网络性能，www 服务器性能，dns查询性能等，使用rrdtool绘图，而且支持分布式，直接从多个agent进行数据的汇总。

同时，由于自己监控点比较少，还可以借助很多商业的监控工具，比如监控宝、听云、基调、博瑞等。同时这些服务提供商还可以帮助你监控CDN的状态。

流量分析

网站流量分析对于运维人员来说，更是一门必须掌握的知识了。比如对于一家电商公司来说：通过对订单来源的统计和分析，可以了解我们在某个网站上的广告投入有没有收到预期的效果。可以区分不同地区的访问人数、甚至商品交易额等。

百度统计、google分析、站长工具等等，只需要在页面嵌入一个js即可。但是，数据始终是在对方手中，个性化定制不方便，于是google出一个叫piwik的开源分析工具。

日志监控

通常情况下，随着系统的运行，操作系统会产生系统日志，应用程序会产生应用程序的访问日志、错误日志，运行日志，网络日志，我们可以使用ELK来进行日志监控。

对于日志监控来说，最见的需求就是收集、存储、查询、展示，开源社区正好有相对应的开源项目：logstash（收集） + elasticsearch（存储+搜索） + kibana（展示） 我们将这三个组合起来的技术称之为ELK Stack，所以说ELK Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。

如果收集了日志信息，那么如果部署更新有异常出现，可以立即在kibana上看到。

安全监控

虽然Linux开源的安全产品不少，比如四层iptables，七层WEB防护nginx+lua实现WAF，最后将相关的日志都收至Elkstack，通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间，并且个人效果并不是很好。这个时候我们可以选择接入第三方服务厂商。

三方厂商提供全面的漏洞库，涵盖服务、后门、数据库、配置检测、CGI、SMTP等多种类型全面检测主机、Web应用漏洞自主挖掘和行业共享相结合第一时间更新0day漏洞，杜绝最新安全隐患。

API监控

由于API变得越来越重要，很显然我们也需要这样的数据来分辨我们提供的 API是否能够正常运作。监控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的请求 可用性、正确性、响应时间为三大重性能指标

性能监控

全面监控网页性能，DNS响应时间、HTTP建立连接时间、页面性能指数、响应时间、可用率、元素大小等

业务监控

没有业务指标监控的监控平台，不是一个完善的监控平台，通常在我们的监控系统中，必须将我们重要的业务指标进行监控，并设置阈值进行告警通知。比如电商行业：

每分钟产生多少订单， 每分钟注册多少用户， 每天有多少活跃用户， 每天有多少推广活动， 推广活动引入多少用户， 推广活动引入多少流量， 推广活动引入多少利润， 等等 重要指标都可以加入zabbix上，然后通过screen展示。

监控报警

故障报警通知的方式有很多种，当然我们最常用的还是短信，邮件

报警处理

一般报警后我们故障如何处理，首先，我们可以通过告警升级机制先自动处理，比如nginx服务down了，可以设置告警升级自动启动nginx。但是如果一般业务出现了严重故障，我们通常根据故障的级别，故障的业务，来指派不同的运维人员进行处理。当然不同业务形态、不同架构、不同服务可能采用的方式都不同，这个没有一个固定的模式套用。

面试监控

在运维面试中，常常会被问题监控相关的问题，那么这个问题到底该如何来回答，我针对本文给大家提供了一个简单的回答思路。

1. 硬件监控。通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他，可以通过IPMI来实现。当然如果没有硬件全都是云，直接跳过这一步骤。

2. 系统监控。如CPU的负载，上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode使用率。当然这些都是需要配置触发器，因为默认太低会频繁报警。

3.服务监控。比如公司用的LNMP架构，nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过percona官方工具来进行监控。Redis这些通过自身的info获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容，以及报警和图形功能。

4.网络监控。如果是云主机又不是跨机房，那么可以选择不监控网络。当然你说我们是跨机房以及如何如何。推荐使用smokeping来做网络相关的监控。或者直接交给你们的网络工程师来做，因为术业有专攻。

5.安全监控。如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件，那么推荐使用硬件防火墙。使用云可以购买防DDOS，避免出现故障导致down机一天。如果是系统，那么权限、密码、备份、恢复等基础方案要做好。web同时也可以使用Nginx+Lua来实现一个web层面的防火墙。当然也可以使用集成好的openresty。

6.Web监控。web监控的话题其实还是很多。比如可以使用自带的web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件,监控宝或听云来实现。毕竟人家全国各地都有机房。（如果本身是多机房那就另说了）

如果是web的话可以使用监控Nginx的50x、40x的错误日志，PHP的ERROR日志。其实这些需求无非是，收集、存储、查询、展示，我们其实可以使用开源的ELKstack来实现。Logstash（收集）、elasticsearch（存储+搜索）、kibana（展示）

8.业务监控。我们上面做了那么多，其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论，监控比较重要的业务指标，（需要开会确认）然后通过简单的脚本就可以实现，最后设置触发器即可

9.流量分析。平时我们分析日志都是拿awk sed xxx一堆工具来实现。这样对我们统计ip、pv、uv不是很方便。那么可以使用百度统计、google统计、商业，让开发嵌入代码即可。为了避免隐私也可以使用piwik来做相关的流量分析。

10.可视化。通过screen以及引入一些第三方的库来美化界面，同时我们也需要知道，订单量突然增加、突然减少。或者说突然来了一大波流量，这流量从哪儿来，是不是推广了，还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。

11.自动化监控。如上我们做了那么多的工作，当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。

监控如何精准实时的覆盖

监控建设需要解决的两个核心问题就是：优先用户发现问题和快速定位解决问题。

如何优先用户发现问题：需要具备监控的眼睛足够多，针对运维对象从物理设备、系统组件以及应用层对象能够全面覆盖，以及针对不断增长的运维对象能够持续扩展。

如何快速定位解决问题：不仅需要针对告警信息的多维关联分析，同时还需具备针对告警事件的闭环处理以及故障自愈管理，支撑运维人员快速解决故障。

平台化监控设计

基于传统建设监控系统的方式，你会发现如果想要覆盖全面的运维对象，所需建设各种场景监控系统就会越来越多，海量无效的告警事件接踵而来，同时围绕同一故障的告警信息都分布在各个监控系统中，这么一来就很难实现快速的告警定位分析。

为了满足不断变化的监控需求，我们得换一种建设思路，通过平台+场景的建设思路，不仅能够满足监控覆盖全面性的要求，还能够持续扩展监控场景以满足变化的需求。

监控平台

聚焦监控数据链路能力，从数据采集 → 数据存储 → 数据加工 → 数据监测 → 告警管理 → 故障闭环 → 监控可视化能力。

数据采集：监控数据采集类型包括指标（Metrics）、日志（Logs）、跟踪（Trace），针对不同的数据采用的数据采集方式也不同，如：Agent代理采集、脚本插件采集、日志采集、协议采集、进程采集、Web拨测、APM探针以及API接口等。

因此在考虑监控平台采集能力设计的时候，需要具备灵活扩展的采集器扩展能力，能够支持适配当下主流监控系统的不同采集器的方法。

数据存储：

数据分析：针对监控数据分析能力，包括数据清洗、数据丰富、数据计算以及数据检测能力，如数据丰富过程中的CMDB字段丰富，数据计算支持各种运算规则（AVG\SUM\MAX\MIN\COUNT），数据检测支持静态阈值、同比、环比以及机器学习扩展。

告警管理：

提供告警事件的统一管理，包括告警收敛、告警聚合、告警屏蔽以及告警通知等功能：告警聚合：支持按对象进行聚合、按应用进行聚合、按时间进行聚合、基于CMDB拓扑关系进行聚合、以及按负责人进行聚合。告警屏蔽：支持变更维护期内告警屏蔽，屏蔽维度支持时间、对象、策略等。告警通知：支持微信、短信、语言、邮件告警通知，以及API或自定义渠道通知。

故障闭环：实现告警事件的快速跟进和闭环管理，如对接工单系统自动生成事件工单，对接自动化系统实现故障自愈。

监控可视化：基于监控视图的可视化展示，实时展现监控对象的状态信息以及告警事件的信息。

监控场景

基于监控指标数据采集能力，以及监控后台的数据存储和监测分析能力，构建各种运维对象的监控场景，如硬件监控、云监控、系统监控、组件监控、日志监控，以及应用服务和性能监控等。

硬件设备监控：监控对象：网络设备、存储设备、物理机；采集方式：基于通用协议采集SNMP、IPMI。

云监控：监控对象：虚拟化、私有云公有云平台健康性，以云产品的容量、性能监控；采集方式：基于云平台API采集插件。

系统组件监控：采集方式：基于Agent、脚本、插件采集，支持持续扩展。监控对象：应用网站服务、应用协议服务以及C\S应用可用性；采集方式：基于Selenium、RPA技术，持续扩展脚本、协议以及模拟采集。

日志监控：监控对象：文本日志、系统日志，关键字的监控；采集方式：基于系统层日志采集。

应用性能监控：监控对象：应用性能、调用链分析、接口调用分析等；采集方式：APM探针或应用SDK。

智能监控有效延展

运维监控的建设，从系统化 → 平台化 → 智能化的演进过程， 基于平台化的集中监控数据管理，赋予运维大数据平台的数据分析、数据开发、数据建模的能力，实现体系化智能监控场景，如动态阈值、异常检测、根因定位以及容量预测等。

企业统一监控建设阶段

第一阶段：统一告警事件管理

基于企业现有运维体系的建设现状，多多少少都已经有了各种监控工具系统的建设，有些是采用传统商用监控系统，如IBM_Tivovi、HP_OVO、SCOM、SolarWinds、听云、Dynatrace等，也有些是采用开源监控系统，如Zabbix、Prometheus、Pinpoint等。

基于已建设监控系统现状，监控系统覆盖已经达到一定程度，但运维人员面临的痛点问题更多是海量告警、无效告警等，因此可以优先考虑告警事件的统一管理，实现告警事件的闭环管理。

告警源接入，支持各种常用监控系统集成，以及标准告警事件API接口：

告警事件，集成企业ITSM系统，自动创建事件工单：

实现整体告警事件的端到端闭环管理：

第二阶段：集中监控数据处理

基于企业级监控平台的设计，通过可扩展的统一监控采集插件能力，持续建设监控覆盖面，同时基于平台层的数据链路服务能力，建设集中多维度数据分析服务以及监控数据仓库，从而支撑企业上层运维端、用户端的个性化监控场景。

自有监控平台化数据链路能力：

监控系统数据集成，构建集中数据仓库，实现数据智能分析和建模能力赋能：

基于后台监控数据服务能力，构架个性化场景监控工具系统：

第三阶段：一体化运维监控平台

基于企业ITOM运维管理一体化建设中，监控平台与周边运维系统，如配置管理、云资源管理、运维流程管理以及自动化管理，彼此相互依赖及融合。

Zabbix与Prometheus对比

这部分来自 dbaplus 社群特别邀请到美图SRE负责人-石鹏(东方德胜) 作为主持人、 招商银行技术经理-蔡翔华 作为 Zabbix 使用方、 甜橙金融基础技术架构师-刘宇 作为 Prometheus 使用方，针对 Zabbix 和 Prometheus 展开实用选型探讨。

Q1：Zabbix和Prometheus分别适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？

蔡翔华：我们和Zabbix官方其实有沟通过，业内他们有一些监控到了40万以上的节点数，当然这个节点数也要根据你每个节点上监控多少东西。Zabbix其实有一个指标叫做NVPS（New Value Per Second），也就是每秒新增的值的指标，来判断你的监控规模是不是合适的。

那么对于5000个节点以上的场景来说，其实Zabbix还是OK的，你可以通过多布署一些Proxy，去对后台数据库做一些性能调优等等，以这些方式去提高整个监控平台的可承受、负载的性能。

另外关于高可用，我们的数据库端是会有Mycat或者HAProxy高可用，但服务器端本身它其实没有高可用，那么我们可以依赖于虚拟化平台，或者是比如像我们有Vmotion等热迁移这些技术。另外，在未来的5.x版本或者6版本以上的话，官方已经将原生的高可用纳入到Zabbix的Roadmap里面了，大家可以期待一下。

石鹏：好的，蔡老师的核心观点其实就是我们需要关注核心的指标，也就是NVPS，这个值是比较关键的。然后蔡老师之前您在实际的应用中，见过这个系统的峰值可以达到多少吗？是否可以给大家做个参考？

蔡翔华：在我们自己的环境里面，NVPS峰值达到过6000以上，但我们后面其实也做了一些优化，把它调整到3000左右。主要目的是，因为一开始我们做的时候是希望做到大而全，什么都监控，但最后发现其实大而全不一定有用，因为很多监控即使它是问题，你也不会care它。

刘宇：是的，蔡老师已经讲得比较详细了，其实以多大的规模是取决于你的监控目标，还有就是采集的间隔，比如说5秒采集一次和1分钟采集一次，这个规模都是支持着不一样的目标，所以还是要根据你的需求。

一般来说，我们会配置成30秒或者是一分钟；如果是对于高频的，会15秒。因为单个Prometheus性能已经比较强了，一般来说，它每秒百万个指标都是没什么问题的。Prometheus会根据你的指标来计算，就是看你一个监控点上有多少个指标，这样来换算。

如果你单个Prometheus的性能达不到它的要求时，也可以去做一些拆分，比如说我们把Prometheus根据它的功能来做区分，这个去监控node exporter，那个去监控Redis，这样来做区分。

当然，如果你单个的性能还是不够的话，可以用分区，即用hash mod去多分几个Prometheus来做监控。

然后关于高可用这块，其实社区Prometheus这部分做得也不是特别好，会用两个Prometheus来同时监控同样的一个目标，这样来做到一个高可用。当然，在容器环境，你也可以去通过K8S的deployment这种方式，来把高可用维护起来。

Q2：Zabbix和Prometheus怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？

蔡翔华：的确，存储这个问题因为监控写的东西最多就是写到存储里面去，Zabbix以前被吐槽最多的就是它不支持时序数据库TSDB。其实在4.2以后，它就已经开始支持TSDB了，当然可能还没有Prometheus那么成熟，它主要的数据库还是MySQL为主。

如果就存储问题的话，一方面你可以去尝试TSDB的这种方式；另外一方面的话，你可以去通过增加SSD，或者说数据库层面的一些性能提升，去解决它的问题。包括数据库本身可以去分库分表，去拆分一下，然后对历史数据做一个归档……就是通过数据库层面的优化，来解决这个问题。

那么对于历史存储和分析这些信息，Zabbix提供了两个维度，一个叫history，一个叫trend，也就是一个历史数据和趋势数据。它具体数值是可以自己设定的，它的逻辑是说，如果超过history的保留期限，比如说30天，它自动会把数据归档成trend的数据，trend的数据就会只会保留最大值、最小值和平均值这三个指标，而并不能像history数据可以看到每一秒钟，甚至说每一个轮巡周期的指标。

我们实际场景应用的话，主要是用于我们的性能分析，因为我们有很多互联网应用，会看一下这个业务增长对我平台的要求，会不会CPU比较紧张、内存比较紧张等等。另外，我们会根据这些数据做一个分析，为我们后期的扩容、决策提供一些参考性的依据。比方说我现在看到今年整体的使用率在多少，我们每年的增长量是在20%还是30%，这样我们后续做一些决策的时候，是需要多少的资源、多少的预算，就比较能有参考价值。

刘宇：Prometheus本身存储如果存在本地的话，大概只能存15天，最多你也只能放到30天这样子。官方其实也不建议你把所有的监控数据都存在Prometheus的一个本地的数据库里。

我们是存在InfluxDB的，也有一些是可以存在比如说ES，通过remote_write的功能去存到ES或者是其它时序数据库中，或者是比如说HBase这种大数据的也可以存。

石鹏：好的了解，其实关于存储这个问题，我们还是更多应该从需求出发。整体来看有一些比较通用的思路，最典型的就是这两种：

第一种是数据的转储。比如像Prometheus，我们在本地只存2周或者4周的数据，然后更多的话，就把它写到远端。

第二种思路是做数据采样。其实在很多监控系统里面，是一个比较常规的思路，就像在Zabbix里的history、trend，开始可能是每30秒一个点，然后数据采样之后，可能是每5分钟一个点。就用这样的方式，把这个数据量级减小，然后以此来做存储问题的优化。

Q3：Zabbix和Prometheus怎么应对告警风暴和误报？

蔡翔华：首先误报这个事情，其实在我理解里是不存在的。也就是说，之所以我们会觉得很多有误报的东西存在，是因为我们对于规则，比方说我监控东西或者是我配置触发器，本身是有问题的。

我碰到很多人说，打算监控它的CPU使用率，很多人会直接记录usage，它的使用率，也有很多人会监控它的free的这个space。但有时候会由于配置错误，导致原本监控cpu usage的使用了cpu free的指标。所以说，其实很多时候报警之所以会产生误报，是因为配置本身不是很正确。

Zabbix的工作机制很简单：我去收集数据，去根据这个处罚规则去做比较，然后去发报警。当中所有的逻辑其实本身是不会出任何问题，除非说收集数据配错了、触发规则配错了、报警机制配错了……这些其实更多是人为的因素在里面。

所以说，更多的是要通过这种检查来判断一下你是否有配错。

另外一个减少误报的方式是通过模板化。因为我们只要配置一次模板，那我把所有的Linux机型的监控模板都统一起来，对于所有监控Linux都套用同一个模板，那么就可以在一定程度上降低误报。关键还是在于人的问题。

关于告警风暴，其实Zabbix里有一个特性叫做依赖项目。就比方说我现在有一台机器宕机，那么它可能里面的端口都会不通，然后ping也ping不通，CPU可能也拿不到，可能会有一堆的报警。那么我们可以把所有的这种依赖项关联到ping上，一旦ping的机器都死了，上面肯定东西都是宕掉了，这样子的话，它只会报ping的这一个问题，而不会把这堆机器上所有的东西都给报出来。就好比一个人如果死了，你跟他说这里有问题那里有问题，其实没有任何意义。它就只会把你最终的Root Cause（根因）给报出来，去防范这种告警风暴。

刘宇：是的，误报我其实跟蔡老师的观点是很像的，就是告警中其实是存在一个误报率的，如果你的误报率很高的话，运维人员就很疲劳了，可能大家都会觉得狼来了，没有办法信任你的那种告警，反而你真正发生故障的告警就会被忽略掉。所以制定告警的规则就非常重要，需要想办法把误报率给它降低。

那这种规则的制定其实就比较不是那么具体，会比较抽象，可能比如说把必须要人工介入处理的这种，才把它定为告警；然后如果系统可以自己处理掉，就不要把它告出来，或者只是在后面做一个每天发一次的报告也就行了。这是我对误报的一个看法。

关于告警风暴，在Prometheus中，对告警风暴的处理方式是这样：可以通过静默告警解决，或者是可以加入维护组，或者是也可以做一个聚合，也就是把告警给聚集，然后同类的告警合并，这样来减少告警的条数，主要是这样来做的。

当然如果你有些机器需要维护，它也是可以支持的，就是可以把一些告警直接静默掉。当然还有就是测试环境，比如说这种告警，你就可以完全忽略掉，我觉得可以这样来解决。

石鹏：好的，我总结一下，关于误报这个问题，两位老师的意见是比较一致的，我也是比较赞同的。误报其实最根本的原因就是可能你的使用不合理，不管是你的配置还是说你的各种姿势可能不合理，才会导致误报。

然后针对告警风暴，其实Zabbix和Prometheus也就是alert manager，它们都有提供一些相应的功能、特性。在Zabbix这边的话，可以像蔡老师说的用依赖项，然后也是可以加维护，也可以规避一些告警；然后Prometheus这边是alert manager它里面有silent这个静默规则，也是可以去做一些规避告警这种东西。

可能在很多公司，他们除了监控平台本身去做告警风暴的抑制，还会有另外一层。比如说我们公司这边是这样：

我们有一个告警平台，所有的告警都会汇集到这个告警平台里，然后这个告警平台会去做一层合并、收敛和抑制。这样的话，就可以不用特别依赖监控平台本身来提供这些特性，而是由一个统一的平台，在做最后发送动作的时候，再来做一层cover。可能在量级大的场景下，这种是比较推荐的一种思路。

蔡翔华：是的，因为真正的监控当中，其实还会纳入很多比方说ES等其它监控平台，甚至是一些业务告警。当平台很多的时候，其实你需要有一层聚合的方式，去把告警做一个聚合收敛，然后通过在聚合平台里配置一定规则之后，再去做后续的一些报警。

石鹏：没错，并且你有这个平台之后，就可以把一些告警的规则和策略做得更统一，这样的话，给用户的界面和体验也会更好。

蔡翔华：对，所以说其实看公司规模，因为这一块会涉及到一些二次开发，如果公司没有这个能力，那就可以把Zabbix全套或Prometheus全套都用上；如果后续有能力去做这种聚合的话，其实Zabbix也好，Prometheus也好，更多的角色定位会变成一个收集器的角色。然后后面的逻辑其实都交给事件管理平台或聚合平台去做。

刘宇：没错，这里Zabbix其实也可以把它的报警发送到alert manager里，也可以做一些静默处理，因为Zabbix本身它的静默功能确实不是特别多，还是alert manager会做的更好一点。所以两个工具其实可以结合起来使用。

Q4：在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？

蔡翔华：首先我们是有尝试过智能监控，但是包括我看到的很多书籍里面，包括Prometheus的一些书籍里面，也说设这种固定的预知是一个很蠢的方法。

根据我这边实际的应用，其实你要做到智能监控，肯定要有一些大数据的东西，比方说我有这种规律：

例如，按照我们的实际操作里有很多互联网的应用，有些东西它就是会有高并发高抢购，可能每个月固定的时候，比如每个月10号放一个活动，活动时它的量是平时的10倍甚至100倍；但也可能有时候，业务会不停地在不同的时间放，你很难去判断这个点到底是不是一个故障点。

也就是说，你用户数从10变成了1万，这1万到底是因为故障了，还是说是因为业务的一些逻辑导致的，很难判断。所以目前来说，我们尝试以后，还是用了一些比较固定的报警预知去做。

那么回到这个话题，Zabbix本身它提供了一些预测的功能，它会预测现在我的磁盘消耗大约什么时候会消耗到20%以下，或某个阈值以下，它本身是提供了这个功能的。还有一些内置函数可以去做这个计算。但是目前来说，我个人还是建议使用一个比较固定的阈值，可以方便我们有一个明确判断，否则你早期会有很多的误报，甚至可能你都会觉得这东西很正常。

预测的数据也是基于现状的，如果可以对预测数据进行判断报警，理论上，也可以针对现有的数据进行判断报警。

刘宇：这块我们实践的案例倒不是特别多，我主要还是对数据库的监控比较熟，所以就说一下我们在数据库的自动治愈上是怎么实现的吧。

比如说告警，它发送出来的同时，也会发送给数据库的一个自动化平台，这个平台会有一个程序根据告警内容来调一些自动治愈的程序来处理这种简单的故障。但这个其实做的也比较有限，就是说我的这种能够自愈的程序，都是根据具体场景的，并不是所有的东西都可以做。比如说清理日志、杀读库大查询，以及需要加一些表空间这些场景，类似这种比较固定的会采用自愈来做，其他的尝试倒不是太多。

石鹏：嗯嗯，这个问题其实比较前沿，并且涉猎的范围是比较广的。像自动治愈，其实Zabbix也有一些相关的功能，它可以去配置action，当发现告警，有问题，我就可以绑定脚本去做一下处理。

但这个东西要做到什么程度，或者说要用什么技术来打造这个底座，可能都会有些差别。

蔡翔华：是的，因为我觉得Prometheus和Zabbix或者说其他平台，都支持调action、调脚本去做一些重启，但是我觉得关键问题的点是在于你敢不敢做这个事情。

因为我们知道我们的环境其实是很复杂的。比方说，我发觉数据库宕了，服务停了，我敢不敢通过这个服务自己切过去。因为很多时候并不是数据库本身的问题，是网络的问题，网络抖动了，监控数据拿不到了。这个是非常依赖于整个整体环境的，你可能要想到方方面面，这个规则会非常复杂。你可能在做服务自愈的时候，还要去对其他的东西做一个完全的检查，确保其他东西是没有问题的。

所以不说服务自愈，哪怕在我们日常的故障处理当中，也很依赖于经验。就是说这个东西是能做的，但是我们不太敢，因为要考虑的要素很多，就不太敢去直接做自愈这一块。

石鹏：没错，本身其实它是一个体系化的工程，不仅仅是跟监控相关。我这边的一个想法是这样，关于自动治愈这块，我们可能还是要更多去依靠业务侧的能力。就是说，业务侧要具备一些这种架构设计上的考量，比如说架构的柔性，可以自己去做限流、降级、做熔断，这要求业务侧有这样的能力才可以，而不是说仅仅依靠监控系统去做某些动作触发。

至于说一些算法和策略的话，之前美图这边也是有过一些简单的尝试，应用不算非常广泛。但业界的话，DataOps、AIOps的概念也是比较火热，这些东西在像BAT这些公司其实也有一些实际的应用已经在落地了。

之前我们做的话，有做这么几个小东西，关于故障预测是有这么几个算法：有同期的数据比较、同期的振幅比较、有一个移动平均算法、然后再有一个变点监测。然后这几个的话，可以简单说一下思路，其实也比较好理解。

同期数据，是我按照周期，比如说今天某个时间点这个数据，我去比较昨天这个点是什么样子的，去比较数据；

振幅，其实它就相对更柔性一点，里面会给你加上一个权重，加上一个比例，比如正态分布里边的3-sigma，作为振幅系数去比较同期的数据，看在算上振幅之后，你是不是已经超出了，去做一个预测；

变点监测，就是说我整体的数据曲线是什么样子的，突然出现了一个离我正常预测曲线偏离非常远的一个点，这种的话会有一个这样的算法来做这个事情。

然后这块相对比较成熟的工具的话，像腾讯之前有开源的运维学件METIS，它里面集成了非常多的算法模型，这个有兴趣的同学可以去做一些了解。

Q5：监控大屏是怎么设计的？

蔡翔华：首先从技术本身来说，5.0版本可以看到Zabbix的UI都很不错，可以很多的组、主机都往大屏里面去拖。大屏的话，我们大概会分几块：

第一块是整个系统运行状态。我可能整个系统有从用户登录到用户支付，包括到购物车等等，有一个链路。我对于每个链路其实都会有一个监控，它每一个S组 Service的组，那么Service的组里面包括它的应用、数据库缓存、应用系统甚至硬件服务器，一旦这里有任何东西出问题之后，直接会在大屏上显示一个警告，那么我就会知道现在整个生产环节哪个系统是有问题的。

那么另外就是一个summary，一个overview的全局的导览，因为一旦我知道这个有问题，我就希望更加细化知道这个东西哪里有问题。那么在下面就会有一个trigger list的问题列表，就是说有哪些触发器被触发了，我会看到比方说，数据库端口不通了，还是说磁盘空间已经满了。下面会有trigger list，然后这个trigger list会按照故障等级是disaster还是warning，同时对应的管理员或者运维人员也会收到这个短信，就知道要立即去处理了。

所以我们尽可能就在大屏里从两方面来把控，一方面从大的来讲，有一个over view看到全局，从小的来讲，我要知道我的故障发生在哪里。基本上保证这两个要素在大屏里面就OK了。

刘宇：我们这边大屏其实主要还是应用的维度以及网络流量的维度为主。比如说从公网的一个出口和入口的流量来看会不会有大面积的一个问题。如果发现已经达到外面防火墙或者它流量的一个阈值了，就可以迅速定位问题。

如果是细节的话，我们会在大型活动前夕，梳理活动链路上的所有应用，根据应用的维度来设计这样一个大屏。大屏可以看到链路上所有应用、数据库或者是中间件的情况，一旦哪个应用的QPS高了，或者是其他压力的情况，就可以第一时间定位到问题出现在哪里，是这样一个思路来做。

石鹏：监控大屏做得好，确实可以辅助我们技术同学去更快地定位和排查问题，还有一个比较重要的点，我是这么想的，就是老板会关注。有些公司会把大屏设计得非常有科技感，让老板看的话，可能老板也觉得我的技术团队还挺牛的。当然这是一个题外话。

前面蔡老师和刘老师都给了一些建设上的思路，就是你应该去包含哪些数据，应该怎么去做。这方面的话，我的一个思考是你可能要去做服务的梳理，然后可以以分块、分业务或者说按照分层的方式来做。

分块的话，就是你按照业务线来分。你公司可能有很多块业务，然后按照不同的业务去提供一个视角。在每个业务里，你可以去做分层，分层的意思就是说可以把整个链路，从客户端一直到CDN、 DNS链路，然后到LB入口层，以及应用这一层是什么样的，再关联到后面的一些后端资源，像数据库、缓存这些东西，还有一些其他的周边依赖，按照这样分层的方式来做。

关于技术实现方面，我简单赘述两句。我们公司的监控大屏是用了Grafana来做的，Grafana可能已经成为了事实上的监控UI、数据可视化的标准了，它可以后面去接各种各样的数据源，然后你各个监控系统、各种数据原理的数据可以统一来展示。

这里需要感谢一个社区的插件，叫Flow Charting，这个插件可以非常好地去做监控链路的事情，就是你可以用这个插件去把整个链路关键环节，以这种图的方式绘制出来，然后给每一个点、每一条线绑定上监控数据，最后生成的图就动起来了，就可以看到一个全局性的链路状态：从入口一直到后端资源，包括各种依赖，当前它的状态是什么样子的。

当然这个前提是，你整个链路的监控数据是要完备的，然后你才可以借助这个插件去把它呈现出来，大概是这个样子的，在这个图上就一目了然了。

Q6：自动化运维管理是Zabbix和Prometheus同时使用还是二选一更合适？

蔡翔华：如果是个纯容器化的，就说你环境里面全是Docker，那么说实话我也不推荐你去使用Zabbix。

因为Zabbix对容器的监控，虽然官方已经开始重视了，甚至说现在也支持了Prometheus的很多metrics和exporter这种方式去做监控，就是它也可以原生的去支持Prometheus这些东西，但相对来说，Prometheus在容器化监控这边还是会更好一些。

如果你的监控需求是又要监控硬件服务器，又要监控中间件，又要监控业务指标，那么我推荐使用Zabbix，因为Zabbix覆盖的面会更广一些。

的确我觉得任何需求Zabbix和Prometheus都可以去做，但是从实现成本来说，相对于Prometheus，你的服务环境越复杂，Zabbix可能就越适合这种比较复杂的异构的环境。

刘宇：我们目前公司情况是两个都在用，的确是偏容器的会往Prometheus优先考虑，如果是旧的，比如说是有偏服务化的这种监控，也会慢慢地往Prometheus做一些迁移。

如果你的环境是一种就可以满足的话，建议还是一种，因为毕竟只需要维护一种技术栈就可以了。或者是你可以做一些偏重，比如说把一些不变的放在一种上面，经常会变的放在另外一种上面。尽量去减少你维护的技术栈。如果你的环境比较简单的话，只用一种，当然是最好了。

石鹏：其实还是看场景，美图跟刘老师这边比较类似，我们也是多种监控工具在用，不过我们现在没有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，还有很多基于大数据的一些流式处理的组件，我们都是混合在用。

主要还是看你具体的需求和场景，没有银弹，没有说一个工具可以非常合适去搞定所有事情。当然它有可能有能力，但是它并不一定特别合适。至于具体的选择上，还是要看具体场景。比较明确的一个思路可能就是要看你的监控对象到底是容器还是非容器，它是这种易变的还是比较稳定态的。这两个思路的话，也是跟蔡老师和刘老师比较一致的。

Q7：分布式链路的可观测性和端到端诊断怎么做？

蔡翔华：分布式链路其实我们没有用Zabbix，因为分布式链路要考虑上下游的关系，所以我们会基于APM去做。现在像业内比较流行的CAT，可以参考这些去做。

端到端的侦测的话，其实Zabbix也支持，它支持两种方式：

一个是它可以在本地跑一些脚本去做，就是说我这个检测是从Zabbix某个Agen端出发，到另外一台目标机器，而不是通过Zabbix server去做检测。所以说这是Zabbix 提供的另外一种方式，Zabbix active的一种方式，它可以去实现这种端到端的侦测。Zabbix active的监控方式也是比较好的一种方式，可以减轻Zabbix server端的压力，或proxy端的压力，能提供更丰富的一些监控。

刘宇：这块因为Prometheus是一个基于数值的监控，对于这种全链路的话，一般不太会用Prometheus来做，基本上会用APM的一些分布式链路追踪的工具，比如skywalking等来做。

还会通过一些日志系统来做分布式的监控，在链路上，提前写入一些标签，这样从始至终都可以拿到整个链路上的一个关系，就可以做一些分布式链路上的监控的东西。

石鹏：是的，这也就回到我们前面讨论的，没有银弹，没有一种技术栈可以解决所有需求的。包括Zabbix和Prometheus，其实更关注的还是在偏服务端，如果是应用端的话，其实还是要依赖一些APM的工具。就像刘老师说的Apache的skywalking，还有像鹰眼、基于open tracing的其他工具。这些东西其实都是一种思路。

还有一些有技术能力的公司，会选择自研一些APM工具，需要自己去开发各种SDK，然后需要迁到客户端，去上报数据，是这个样子的。

其实端到端整体的建设思路应该是分段的，客户端的是一段，中间链路是一段，服务端又是另外一侧。所以想做端到端，很难说用一个工具就可以完全覆盖起来。

现在基于云原生、微服务这些发展的比较火热，可能会有一些各个服务之间调用链路的服务治理相关的监控需求，可能也不是说通过Prometheus或Zabbix就可以很好地去完成。还是要看需求场景，选择更合适的工具，并且组合起来使用。

Q8：大规模场景下，Prometheus和Zabbix的性能和成本哪个比较低？

蔡翔华：首先我觉得还是看应用场景，因为大规模场景下，要看这个场景是容器多还是非容器环境多，这是一个主要依据。

Zabbix性能的话，其实瓶颈主要是在数据库，只要把数据库的优化做得足够好，其实开头也说了，业内也有做到40万NVPS的这种案例，已经是比较变态了。那无非就是说，去做数据库分区分库拆表、加SSD存储，通过这种方式。

成本的话，我个人觉得在底层资源满足的前提下，成本应该都OK。因为Prometheus是基于exporter，Zabbix是基于Agent，通过Zabbix agent，配合自动发现和低级别发现的这种方式去实现自动化。

配置成本可能Zabbix会低很多，因为都是基于UI去做，而Prometheus是基于配置文件去做，这个可能Zabbix会更好些。所以我综合成本，觉得Zabbix稍微会好一些，但还是取决于你的场景里有多少虚拟化。

刘宇：我觉得如果是性能的话，通过一些分区的手段都能解决。但如果是非常大的规模，通过Zabbix，其实它的数据库瓶颈还是比较严重的，这块还是需要一些比较好优化手段才能解决。

监控采集的agent的方式而言，我觉得Prometheus的exporter做得非常全面，像我们以前用Zabbix，基本上有很多东西监控都是自己去开发的；而现在用Prometheus，基本上对于这种采集器的开发都没有了，用社区的就可以全部解决了。所以在采集的层面上，去实现它最底层和服务的一个数据采集，我感觉Prometheus的成本会更低一点。

当然因为Prometheus相对来说还是一个微服务的架构，它的所有组件都是分开的，在搭建成本、学习成本会稍微高一点。

石鹏：其实还是要针对个性化的场景去做一些选择。成本的话，如果说你的环境是一个比较纯粹的，要么是全容器，要么是虚拟化或者物理环境，你就选一种就好了。如果说你是异构的话，可能就不可避免的要选两种同时维护。这两种里如果有所侧重的话，成本其实就会有所侧重，所以还是看你的具体需求。