我们先来了解什么是监控、监控的重要性以及监控的目标，当然每个人所在的行业不同、公司不同、业务不同、岗位不同，对监控的理解也不同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。
对系统不间断实时监控：实际上是对系统不间断的实时监控(这就是监控)；
实时反馈系统当前状态：我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障；
保证服务可靠性安全性：我们监控的目的就是要保证系统、服务、业务正常运行；
保证业务持续稳定运行：如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行；
既然我们了解到了监控的重要性、以及监控的目的，那么下面我们需要了解下监控有哪些方法。
了解监控对象：我们要监控的对象你是否了解呢？比如 CPU 到底是如何工作的？
性能基准指标：我们要监控这个东西的什么属性？比如 CPU 的使用率、负载、用户态、内核态、上下文切换。
报警阈值定义：怎么样才算是故障，要报警呢？比如 CPU 的负载到底多少算高，用户态、内核态分别跑多少算高？
故障处理流程：收到了故障报警，我们怎么处理呢？有什么更高效的处理流程吗？
我们了解了监控的方法、监控对象、性能指标、报警阈值定义、以及故障处理流程几步骤，当然我们更需要知道监控的核心是什么？
发现问题：当系统发生故障报警，我们会收到故障报警的信息 ；
定位问题：故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析，比如一台服务器连不上：我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等等，我们就需要去分析故障具体原因；
解决问题：当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障；
总结问题：当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现；
下面我们需要选择一款合适公司业务的监控工具进行监控,这里我对监控工具进行了简单的分类
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化、图形化等。
Zabbix 是一个分布式监控系统，支持多种采集方式和采集客户端，有专用的 Agent 代理，也支持 SNMP、IPMI、JMX、Telnet、SSH 等多种协议，它将采集到的数据存放到数据库，然后对其进行分析整理，达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说，它的总体功能做的非常优秀。从以上各种监控系统的对比来看，Zabbix 都是具有优势的，其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点，读者只要稍加学习，即可构建自己的监控系统。
小米的监控系统：open-falcon。open-falcon 的目标是做最开放、最好用的互联网企业级监控产品。
现在市场上有很多不错的第三方监控，比如：监控宝、监控易、听云、还有很多云厂商自带监控，但是在这里我们不打算着重介绍，如果想了解三方监控可自行上官网咨询。（避免说广告植入）
上面介绍了这么多，那么到底选择什么监控工具最合适呢，我这里推荐几款开源监控工具：Zabbix、Open-Falcon、LEPUS 天兔(专用于监控数据库)。
但是本文还是基于 Zabbix 来构建整个监控体系生态圈。
那么下面我们就来聊聊，Zabbix 的整个流程：
数据采集：Zabbix 通过 SNMP、Agent、ICMP、SSH、IPMI 等对系统进行数据采集；
数据存储：Zabbix 存储在 MySQL 上，也可以存储在其他数据库服务；
数据分析：当我们事后需要复盘分析故障时，Zabbix 能给我们提供图形以及时间等相关信息，方面我们确定故障所在；
数据展示：web 界面展示、(移动 APP、java_php 开发一个 web 界面也可以) ；
监控报警：电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）；
报警处理：当接收到报警，我们需要根据故障的级别进行处理，比如:重要紧急、重要不紧急等。根据故障的级别，配合相关的人员进行快速处理；
我们上面了解了监控方法、目标、流程、也了解了监控有哪些工具，可能有人会疑惑，我们具体要监控些什么东西？那么我在这里进行了分类整理:
早期我们通过机房巡检的方式，查看硬件设备灯光闪烁情况判断是否故障，这样非常浪费人力，并且是重复性无技术含量的工作，大家懂得。
当然我们现在可以通过IPMI对硬件详细情况进行监控，并对 CPU、内存、磁盘、温度、风扇、电压等设置报警阈值(自行对监控报警内容编写合理的报警范围)
IPMI监控硬件服务参考资料
中小型企业基本全是 Linux 服务器，那么我们肯定要监控系统资源的使用情况，系统监控是监控体系的基础。
监控主要对象:
CPU 有几个重要的概念：上下文切换、运行队列和使用率。
这也是我们 CPU 监控的几个重点指标。
通常情况，每个处理器的运行队列不要高于3，CPU 利用率中“用户态/内核态”比例维持在70/30，空闲状态维持在50%，上下文切换要根据系统繁忙程度来综合考量。
针对 CPU 常用的工具有：htop、top、vmstat、mpstat、dstat、glances
Zabbix 提供系统监控模板：Zabbix Agent Interface
内存：通常我们需要监控内存的使用率、SWAP 使用率、同时可以通过 zabbix 描绘内存使用率的曲线图形发现某服务内存溢出等。
针对内存常用的工具有: free、top、vmstat、glances
内存使用率：IO 分为磁盘 IO 和网络 IO。除了在做性能调优我们要监控更详细的数据外，那么日常监控，只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度，网络也是监控网卡流量即可。
常用工具有：iostat、iotop、df、iftop、sar、glances
其它的系统监控还有运行的进程端口、进程数、登陆用户、Open File 等（详细查看 zabbix 自带 OS Linux 模板）
把硬件监控和系统监控研究明白后，我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务，都需要监控起来。
应用服务监控也是监控体系中比较重要的内容，例如：LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq 等等，相关的服务都需要使用zabbix监控起来
笔者之前写过服务监控详细的操作过程，这里就不一一展示了。
Zabbix 提供应用服务监控：Zabbix Agent UserParameter
Zabbix 提供的Java监控：Zabbix JMX Interface
percona 提供 MySQL 数据库监控：percona-monitoring-plulgins
作为一个针对全国用户的电商网站，时刻掌握各地到机房的网络状态也是必须的。
网络监控是我们构建监控平台时必须要考虑的，尤其是针对有多个机房的场景，各个机房之间的网络状态，机房和全国各地的网络状态都是我们需要重点关注的对象，那么如何掌握这些状态信息呢？我们需要借助于网络监控工具 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 上看到。
当然也可以通过Zabbix过滤错误日志来进行告警。
虽然Linux开源的安全产品不少，比如四层 iptables，七层WEB防护 Nginx+lua 实现 WAF，最后将相关的日志都收至 ELK Stack，通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间的事情，并且个人认为效果并不是很好。这个时候我们可以选择接入第三方服务厂商。
三方厂商提供全面的漏洞库，涵盖服务、后门、数据库、配置检测、CGI、SMTP 等多种类型
全面检测主机、Web 应用漏洞自主挖掘和行业共享相结合第一时间更新 0day 漏洞，杜绝最新安全隐患
由于 API 变得越来越重要，很显然我们也需要这样的数据来分辨我们提供的 API 是否能够正常运作。
监控 API 接口 GET、POST、PUT、DELETE、HEAD、OPTIONS 的请求， 可用性、正确性、响应时间为三大重性能指标
全面监控网页性能，DNS 响应时间、HTTP 建立连接时间、页面性能指数、响应时间、可用率、元素大小等
Zabbix 提供 URL监控：Zabbix Web 监控
没有业务指标监控的监控平台，不是一个完善的监控平台，通常在我们的监控系统中，必须将我们重要的业务指标进行监控，并设置阈值进行告警通知。
例如电商行业：
每分钟产生多少订单；
每分钟注册多少用户；
每天有多少活跃用户；
每天有多少推广活动；
推广活动引入多少用户；
推广活动引入多少流量；
推广活动引入多少利润；
等等 重要指标都可以加到 Zabbix 上，然后通过 screen 展示。
故障报警通知的方式有很多种，当然我们最常用的还是短信，邮件，短信报警
一般报警后我们故障如何处理，首先，我们可以通过告警升级机制先自动处理，比如Nginx服务down了，可以设置告警升级自动启动Nginx。 但是如果一般业务出现了严重故障，我们通常根据故障的级别，故障的业务，来指派不同的运维人员进行处理。 当然不同业务形态、不同架构、不同服务可能采用的方式都不同，这个没有一个固定的模式套用。
在运维面试中，常常会被问到监控相关的问题，那么这个问题到底该如何来回答，我针对本文给大家提供了一个简单的回答思路。
硬件监控。 通过 SNMP 来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他，可以通过IPMI来实现。当然如果没有硬件全都是云，直接跳过这一步骤。
系统监控。 如 CPU 的负载，上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘 inode 使用率。当然这些都是需要配置触发器，因为默认太低会频繁报警。
服务监控。 比如公司用的 LAMP 架构，nginx 自带 Status 模块、PHP也有相关的 Status、MySQL 可以通过 percona 官方工具来进行监控、Redis 这些通过自身的 info 获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容，以及报警和图形功能。
网络监控。 如果是云主机又不是跨机房，那么可以选择不监控网络。当然你说我们是跨机房以及如何如何。推荐使用smokeping来做网络相关的监控。或者直接交给你们的网络工程师来做，因为术业有专攻。
安全监控。 如果是云主机可以考虑使用自带的安全防护。当然也可以使用 iptables。如果是硬件，那么推荐使用硬件防火墙。使用云可以购买防 DDoS，避免出现故障导致 down 机一天。如果是系统，那么权限、密码、备份、恢复等基础方案要做好。web 同时也可以使用 Nginx+Lua 来实现一个web层面的防火墙。当然也可以使用集成好的Openresty。
Web监控。 web 监控的话题其实还是很多。比如可以使用自带的 web 监控来监控页面相关的延迟、js响应时间、下载时间等等。这里我推荐使用专业的商业软件,监控宝或听云来实现。毕竟人家全国各地都有机房。（如果本身是多机房那就另说了）
日志监控。 如果是 web 的话可以使用监控 Nginx 的50x、40x的错误日志，PHP 的 ERROR 日志。其实这些需求无非是，收集、存储、查询、展示，我们其实可以使用开源的 ELKstack 来实现。Logstash（收集）、elasticsearch（存储+搜索）、kibana（展示）
业务监控。 我们上面做了那么多，其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论，监控比较重要的业务指标，（需要开会确认）然后通过简单的脚本就可以实现，最后设置触发器即可 。
流量分析。 平时我们分析日志都是拿 awk sed xxx 一堆工具来实现。这样对我们统计ip、pv、uv不是很方便。那么可以使用百度统计、 google 统计、商业，让开发嵌入代码即可。为了避免隐私也可以使用 piwik 来做相关的流量分析。
可视化。 通过 screen 以及引入一些第三方的库来美化界面，同时我们也需要知道，订单量突然增加、突然减少。或者说突然来了一大波流量，这流量从哪儿来，是不是推广了，还是被攻击了。可以结合监控平台来梳理各个系统之间的业务关系。
自动化监控。 如上我们做了那么多的工作，当然不能是一台一台的来加 key 实现。可以通过 Zabbix 的主动模式以及被动模式来实现。当然最好还是通过 API 来实现。
总结
真正想做到更完整的监控体系，目前的开源软件，确实无法很好的满足，有条件的公司都开始自己开发自己的监控系统，比如小米开源的Open-Falcon。也有比较好的开源的监控框架如Sensu等，再加上influxdb、grafana可以用来定制符合自己企业的监控平台。
当然我说的还是很简单，经验有限、思路也仅能提供这么多。 以上就是我分享对监控的一些方法和心得。（老鸟勿喷）
评论