运维必知必会的监控知识体系全梳理

共计 7736 个字符，预计需要花费 20 分钟才能阅读完成。

监控是整个运维乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供详实的数据用于追查定位问题。

目前业界有很多不错的开源产品可供选择。选择一款开源的监控系统，是一个省时省力、效率最高的方案。当然，对监控不是很明白的朋友们，看了以下文章可能会对监控整个体系有比较深刻的认识。

一、监控目标

每个人由于所在的行业、公司、业务、岗位不同，对监控的理解也不尽相同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

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

二、监控方法

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

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

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

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

三、监控核心

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

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

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

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

四、监控工具

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

1、老牌监控

MRTG（Multi Route Trffic Grapher） 是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的 Tobias Oetiker 与 Dave Rand 所开发，以 GPL 授权。

MRTG 最好的版本是 1995 年推出的，用 Perl 语言写成，可跨平台使用，数据采集用 SNMP 协议，MRTG 将手机到的数据通过 Web 页面以 GIF 或者 PNG 格式绘制出图像。

Ganglia 是一个跨平台的、可扩展的、高性能的分布式监控系统，如集群和网格。它基于分层设计，使用广泛的技术，用 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 化、图形化等。

2、王牌监控

Zabbix 是一个分布式监控系统，支持多种采集方式和采集客户端，有专用的 Agent 代理，也支持 SNMP、IPMI、JMX、Telnet、SSH 等多种协议，它将采集到的数据存放到数据库，然后对其进行分析整理，达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说，它的总体功能做得非常优秀。

从以上各种监控系统的对比来看，Zabbix 都是具有优势的，其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点，读者只要稍加学习，即可构建自己的监控系统。

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

3、三方监控

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

五、监控流程

上面介绍了这么多，到底选择什么监控工具最合适呢？我这里推荐几款开源监控工具：Zabbix、Open-Falcon、LEPUS 天兔 (专用于监控数据库)。

但本文还是基于 Zabbix 来构建整个监控体系生态圈。下面我们就来聊聊 Zabbix 的整个流程：

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

六、监控指标

上面了解了监控方法、目标、流程、也了解了监控有哪些工具，可能有人会疑惑，我们具体要监控些什么东西，在这里我进行了分类整理，包含硬件监控、系统监控、应用监控、网络监控、流量分析、日志监控、安全监控、API 监控、性能监控、业务监控。

1、硬件监控

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

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

IPMI 监控硬件服务参考资料：Zabbix IPMI Interface

2、系统监控

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

监控主要对象：

CPU 有几个重要的概念：上下文切换、运行队列和使用率。这也是我们 CPU 监控的几个重点指标。

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

针对 CPU 常用的工具有：htop、top、vmstat、mpstat、dstat、glances。Zabbix 提供系统监控模板：Zabbix Agent Interface。

CPU 整体状态

上下文切换

负载状态

内存：通常我们需要监控内存的使用率、SWAP 使用率、同时可以通过 Zabbix 描绘内存使用率的曲线图形发现某服务内存溢出等。

针对内存常用的工具有：free、top、vmstat、glances。

内存使用率

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

磁盘使用率

磁盘读 / 写吞吐

网卡进出口流量

TCP11 种状态信息

其它系统监控还有运行的进程端口、进程数、登陆用户、Open File 等（详细查看 Zabbix 自带 OS Linux 模板）。

其它相关监控

3、应用监控

把硬件监控和系统监控研究明白后，我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务，都需要监控起来。

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

nginx_status

PHP-FPM_status

Redis_status

JVM 监控

笔者之前写过服务监控详细的操作过程，这里就不一一展示，详情访问：Zabbix 监控各种应用服务。

Zabbix 提供应用服务监控：Zabbix Agent UserParameter
Zabbix 提供的 Java 监控：Zabbix JMX Interface
Percona 提供 MySQL 数据库监控：percona-monitoring-plulgins

4、网络监控

作为一个针对全国用户的电商网站，时刻掌握各地到机房的网络状态也是必须的。

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

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

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

smokeping

监控宝

5、流量分析

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

但是，数据始终是在对方手中，个性化定制不方便，于是 Google 出一个叫 Piwik 的开源分析工具。

piwik

百度统计

6、日志监控

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

对于日志监控来说，最见的需求就是收集、存储、查询、展示，开源社区正好有相对应的开源项目：Logstash（收集）+ElasticSearch（存储 + 搜索）+Kibana（展示）。

我们将这三个组合起来的技术称之为 ELK Stack，所以说 ELK Stack 指的是 Elasticsearch、Logstash、Kibana 技术栈的结合。

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

ELK 日志展示

当然也可以通过 Zabbix 过滤错误日志来进行告警。

Zabbix 日志展示

7、安全监控

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

某某三方安全

三方厂商提供全面的漏洞库，涵盖服务、后门、数据库、配置检测、CGI、SMTP 等多种类型。

全面检测主机、Web 应用漏洞自主挖掘和行业共享相结合第一时间更新 0 -day 漏洞，杜绝最新安全隐患。

8、API 监控

由于 API 变得越来越重要，很显然我们也需要这样的数据来分辨我们提供的 API 是否能够正常运作。

监控 API 接口 GET、POST、PUT、DELETE、HEAD、OPTIONS 的请求。可用性、正确性、响应时间为三大重性能指标。

API 监控

三方 API 监控

响应时间

9、性能监控

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

Zabbix 站点监控

终端响应时间

第三方监控监控大盘。各类图表一目了然，全面体现网页性能健康状况。

10、业务监控

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

每分钟产生多少订单、每分钟注册多少用户、每天有多少活跃用户、每天有多少推广活动、推广活动引入多少用户、推广活动引入多少流量、推广活动引入多少利润等，重要指标都可以加入 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。