企业级监控平台，监控系统选型

相关内容链接：

• 监控系统选型，这篇不可不读！

一、监控基础知识

监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

1.1 监控系统的7大作用

正所谓「无监控，不运维」，监控系统的地位不言而喻。

不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么？它能发挥什么作用？

• 实时采集监控数据：包括 硬件、操作系统、中间件、应用程序等各个维度的数据。
• 实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。
• 预知故障和告警： 能够提前预知故障风险，并及时发出告警信息。
• 辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位。
• 辅助性能调优：为性能调优提供数据支持，比如慢SQL，接口响应时间等。
• 辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑。
• 辅助自动化运维：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。

1.2 使用监控系统的正确姿势

出任何线上事故，先不说其他地方有问题，监控部分一定是有问题的。

听着很甩锅的一句话，仔细思考好像有一定道理。我们在事故复盘时，通常会思考这3个和监控有关的问题：有没有做监控？监控是否及时？监控信息是否有助于快速定位问题？

可见光有一套好的监控系统还不够，还必须知道 「如何用好它」。一个成熟的研发团队通常会定一个监控规范，用来统一监控系统的使用方法。

• 了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
• 确定监控对象的指标 ：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。
• 定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。
• 建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

1.3 监控的对象和指标都有哪些？

监控已然成为了整个产品生命周期非常重要的一环，运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。 可见，监控的对象已经越来越立体化。

这里，我对常用的监控对象以及监控指标做了分类整理，供大家参考。

3.1 硬件监控

包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态

3.2 服务器基础监控

• CPU：单个CPU以及整体的使用情况
• 内存：已用内存、可用内存
• 磁盘：磁盘使用率、磁盘读写的吞吐量
• 网络：出口流量、入口流量、TCP连接状态

3.3 数据库监控

包括：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询

3.4 中间件监控

• Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
• Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
• 缓存 ：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
• 消息队列：连接数、队列数、生产速率、消费速率、消息堆积量

3.5 应用监控

• HTTP接口：URL存活、请求量、耗时、异常量
• RPC接口：请求量、耗时、超时量、拒绝量
• JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
• 线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
• 连接池：总连接数、活跃连接数
• 日志监控：访问日志、错误日志
• 业务指标：视业务来定，比如PV、订单量等

1.4 监控系统的基本流程

无论是开源的监控系统还是自研的监控系统，监控的整个流程大同小异，一般都包括以下模块：

• 数据采集：采集的方式有很多种，包括 日志埋点进行采集（通过Logstash、Filebeat等进行上报和解析）， JMX标准接口输出监控指标，被监控对象提供REST API进行数据 采集（如Hadoop、ES），系统命令行，统一的SDK进行侵入式的埋点和上报等。
• 数据传输：将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统，有主动Push模式，也有被动Pull模式。
• 数据存储：有使用MySQL、Oracle等RDBMS存储的，也有使用时序数据库RRDTool、OpentTSDB、InfluxDB存储的，还有使用HBase存储的。
• 数据展示：数据指标的图形化展示。
• 监控告警：灵活的告警设置，以及支持邮件、短信、IM等多种通知通道。

1.5 监控目标

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

1. 对系统不间断实时监控:实际上是对系统不间断的实时监控(这就是监控)
2. 实时反馈系统当前状态:我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障
3. 保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
4. 保证业务持续稳定运行:如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

1.6 监控方法

1. 了解监控对象:我们要监控的对象你是否了解呢？比如CPU到底是如何工作的？
2. 性能基准指标:我们要监控这个东西的什么属性？比如CPU的使用率、负载、用户态、内核态、上下文切换。
3. 报警阈值定义:怎么样才算是故障，要报警呢？比如CPU的负载到底多少算高，用户态、内核态分别跑多少算高？
4. 故障处理流程:收到了故障报警，那么我们怎么处理呢？有什么更高效的处理流程吗？

1.7 监控核心

1. 发现问题:当系统发生故障报警，我们会收到故障报警的信息
2. 定位问题:故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析，比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等等，我们就需要去分析故障具体原因。
3. 解决问题:当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。
4. 总结问题:当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。

1.8 监控流程

1. 数据采集: Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等对系统进行数据采集
2. 数据存储: Zabbix存储在MySQL上，也可以存储在其他数据库服务
3. 数据分析: 当我们事后需要复盘分析故障时，zabbix能给我们提供图形以及时间等相关信息，方面我们确定故障所在。
4. 数据展示: web界面展示、(移动APP、java_php开发一个web界面也可以)
5. 监控报警:电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）
6. 报警处理:当接收到报警，我们需要根据故障的级别进行处理，比如:重要紧急、重要不紧急，等。根据故障的级别，配合相关的人员进行快速处理。

二、主流监控系统介绍

下面再来认识下主流的开源监控系统，由于篇幅有限，我挑选了3款使用最广泛的监控系统：Zabbix、Open-Falcon、Prometheus，会对它们的架构进行介绍，同时总结下各自的优劣势。

老牌监控:

• 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都是具有优势的，其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点，读者只要稍加学习，即可构建自己的监控系统。

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

2.1 Zabbix（老牌监控的优秀代表）

Zabbix 1998年诞生，核心组件采用C语言开发，Web端采用PHP开发。它属于老牌监控系统中的优秀代表，监控功能很全面，使用也很广泛，差不多有70%左右的互联网公司都曾使用过 Zabbix 作为监控解决方案。

先来了解下Zabbix的架构设计：

• Zabbix Server：核心组件，C语言编写，负责接收Agent、Proxy发送的监控数据，也支持JMX、SNMP等多种协议直接采集数据。同时，它还负责数据的汇总存储以及告警触发等。
• Zabbix Proxy：可选组件，对于被监控机器较多的情况下，可使用Proxy进行分布式监控，它能代理Server收集部分监控数据，以减轻Server的压力。
• Zabbix Agentd：部署在被监控主机上，用于采集本机的数据并发送给Proxy或者Server，它的插件机制支持用户自定义数据采集脚本。Agent可在Server端手动配置，也可以通过自动发现机制被识别。数据收集方式同时支持主动Push和被动Pull 两种模式。
• Database：用于存储配置信息以及采集到的数据，支持MySQL、Oracle等关系型数据库。同时，最新版本的Zabbix已经开始支持时序数据库，不过成熟度还不高。
• Web Server：Zabbix的GUI组件，PHP编写，提供监控数据的展现和告警配置。

下面是 Zabbix 的优势：

• 产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。
• 采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式。
• 较强的扩展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本。
• 配置管理方便 ：能通过Web界面进行监控和告警配置，操作方便，上手简单。

下面是 Zabbix 的劣势：

• 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是5000台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。
• 应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），zabbix没有提供对应的sdk，通过插件式的脚本也能曲线实现此功能，个人感觉zabbix就不是做这个事的。
• 数据模型不强大：不支持tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。
• 方便二次开发难度大 ：Zabbix采用的是C语言，二次开发往往需要熟悉它的数据表结构，基于它提供的API更多只能做展示层的定制。

2.2 Open-Falcon（小米出品，国内流行）

Open-falcon 是小米2015年开源的企业级监控工具，采用Go和Python语言开发，这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过200家公司在使用它。

小米初期也使用的Zabbix进行监控，但是机器量和业务量上来后，Zabbix就有些力不从心了。因此，后来自主研发了Open-Falcon，在架构设计上吸取了Zabbix的经验，同时很好地解决了Zabbix的诸多痛点。

先来了解下Open-Falcon的架构设计：

• Falcon-agent：数据采集器和收集器，Go开发，部署在被监控的机器上，支持3种数据采集方式。首先它能自动采集单机200多个基础监控指标，无需做任何配置；同时支持用户自定义的plugin获取监控数据；此外，用户可通过http接口，自主push数据到本机的proxy-gateway，由gateway转发到server.
• Transfer：数据分发组件，接收客户端发送的数据，分别发送给数据存储组件Graph和告警判定组件Judge，Graph和Judge均采用一致性hash做数据分片，以提高横向扩展能力。同时Transfer还支持将数据分发到OpenTSDB，用于历史归档。
• Graph：数据存储组件，底层使用RRDTool（时序数据库）做单个指标的存储，并通过缓存、分批写入磁盘等方式进行了优化。据说一个graph实例能够处理8W+每秒的写入速率。
• Judge和Alarm：告警组件，Judge对Transfer组件上报的数据进行实时计算，判断是否要产生告警事件，Alarm组件对告警事件进行收敛处理后，将告警消息推送给各个消息通道。
• API：面向终端用户，收到查询请求后会去Graph中查询指标数据，汇总结果后统一返回给用户，屏蔽了存储集群的分片细节。

下面是Open-Falcon的优势：

• 自动采集能力：**Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等），无需在server上做任何配置，这一点可以秒杀Zabbix.
• 强大的存储能力 ：底层采用RRDTool，并且通过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。
• 灵活的数据模型：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。
• 插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本。
• 个性化监控支持：基于Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。

下面是Open-Falcon的劣势：

• **整体发展一般**：**社区活跃度不算高，同时版本更新慢，有些大厂是基于它的稳定版本直接做二次开发的，关于以后的前景其实有点担忧。
• UI不够友好 ：对于业务线的研发来说，可能只想便捷地完成告警配置和业务监控，但是它把机器分组、策略模板、模板继承等概念全部暴露在UI上，感觉在围绕这几个概念设计UI，理解有点费劲。
• **安装比较复杂：**个人的亲身感受，由于它是从小米内部衍生出来的，虽然去掉了对小米内部系统的依赖，但是组件还是比较多，如果对整个架构不熟悉，安装很难一蹴而就。

2.3 Prometheus（号称下一代监控系统）

Prometheus（普罗米修斯）是由前google员工2015年正式发布的开源监控系统，采用Go语言开发。它不仅有一个很酷的名字，同时它有Google与k8s的强力支持，开源社区异常火爆。

Prometheus 2016年加入云原生基金会，是继k8s后托管的第二个项目，未来前景被相当看好。它和Open-Falcon最大不同在于：数据采集是基于Pull模式的，而不是Push模式，并且架构非常简单。

先来了解下Prometheus的架构设计：

• Prometheus Server：核心组件，用于收集、存储监控数据。它同时支持静态配置和通过Service Discovery动态发现来管理监控目标，并从监控目标中获取数据。此外，Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的 PromQL 语言实现对数据的查询和分析。
• Exporter：用来采集数据，作用类似于agent，区别在于Prometheus是基于Pull方式拉取采集数据的，因此，Exporter通过HTTP服务的形式将监控数据按照标准格式暴露给Prometheus Server，社区中已经有大量现成的Exporter可以直接使用，用户也可以使用各种语言的client library自定义实现。
• Push gateway：主要用于瞬时任务的场景，防止Prometheus Server来pull数据之前此类Short-lived jobs就已经执行完毕了，因此job可以采用push的方式将监控数据主动汇报给Push gateway缓存起来进行中转。
• Alert Manager：当告警产生时，Prometheus Server将告警信息推送给Alert Manager，由它发送告警信息给接收方。
• Web UI：Prometheus内置了一个简单的web控制台，可以查询配置信息和指标等，而实际应用中我们通常会将Prometheus作为Grafana的数据源，创建仪表盘以及查看指标。

下面是Prometheus的优势：

• 轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的Server，便于迁移和维护。
• 较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库中，单个实例可以处理数百万的metrics。
• 灵活的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更方便。
• 强大的查询语句：PromQL允许在同一个查询语句中，对多个metrics进行加法、连接和取分位值等操作。
• 很好地支持云环境：能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。

下面是Prometheus的劣势：

• 功能不够完善：Prometheus从一开始的架构设计就是要做到简单，不提供集群化方案，长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要做到这些只能在Prometheus之上进行扩展。
• 网络规划变复杂：由于Prometheus采用的是Pull模型拉取数据，意味着所有被监控的endpoint必须是可达的，需要合理规划网络的安全配置。

三、监控指标

3.1 硬件监控

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

IPMI工具无法获取到硬件的状态，可以借助MegaCli工具探测Raid磁盘队列状态
zabbix提供IPMI监控模板：Zabbix IPMI Interface
系统自带的IPMI模板只能监控，风扇，电源，和部分温度

3.2 系统监控

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

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

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

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

3.3 应用监控

应用服务监控也是监控体系中比较重要的内容，例如：
LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等，相关的服务都需要使用zabbix监控起来。

3.4 网络监控

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

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

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

3.5 流量分析

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

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

3.6 日志监控

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

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

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

3.7 安全监控

虽然Linux开源的安全产品不少，比如四层iptables，七层WEB防护nginx+lua实现WAF，最后将相关的日志都收至Elkstack，通过图形化进行不同的攻击类型展示。

3.8 API监控

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

3.9 性能监控

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

3.10 业务监控

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

每分钟产生多少订单，
每分钟注册多少用户，
每天有多少活跃用户，
每天有多少推广活动，
推广活动引入多少用户，
推广活动引入多少流量，
推广活动引入多少利润，
今天商品打包出库多少，
今天退货商品有多少，

四、监控报警

1. 电话
2. 短信
3. 微信
4. 邮件
5. 钉钉
6. 其他方式

五、报警处理

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

报警后的处理方式：

1. 故障自愈
2. 故障级别
3. 业务划分
4. 人员划分

六、监控系统的选型建议

通过上面的介绍，大家对主流的监控系统应该有了一定的认识。面对选型问题，我的建议是：

1、先明确清楚你的监控需求：要监控的对象有哪些？机器数量和监控指标有多少？需要具备什么样的告警功能？

2、监控是一项长期建设的事情，一开始就想做一个 All In One 的监控解决方案，我觉得没有必要。从成本角度考虑，在初期直接使用开源的监控方案即可，先解决有无问题。

3、从系统成熟度上看，Zabbix属于老牌的监控系统，资料多，功能全面且稳定，如果机器数量在几百台以内，不用太担心性能问题，另外，采用数据库分区、SSD硬盘、Proxy架构、Push采集模式都可以提高监控性能。

4、Zabbix在服务器监控方面占绝对优势，可以满足90%以上的监控场景，但是应用层的监控似乎并不擅长，比如要监控线程池的状态、某个内部接口的执行时间等，这种通常都要做侵入式埋点。相反，新一代的监控系统Open-Falcon和Prometheus在这一点做得很好。

5、从整体表现上来看，新一代监控系统也有明显的优势，比如：灵活的数据模型、更成熟的时序数据库、强大的告警功能，如果之前对zabbix这种传统监控没有技术积累，建议使用Open-Falcon或者Prometheus.

6、Open-Falcon的核心优势在于数据分片功能，能支撑更多的机器和监控项；Prometheus则是容器监控方面的标配，有Google和k8s加持。

7、Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成，想要美观且强大的可视化体验，可以和Grafana进行组合。

8、用合适的监控系统解决相应的问题即可，可以多套监控同时使用，这种在企业初期很常见。

9、到中后期，随着机器数据增加和个性化需求增多（比如希望统一监控平台、打通公司的CMDB和组织架构关系），往往需要二次开发或者通过监控系统提供的API做集成，从这点来看，Open-Falcon或者Prometheus更合适。

10、如果非要自研，可以多研究下主流监控系统的架构方案，借鉴它们的优势。