## 监控的必要性
> 在一个IT环境中会存在各种各样的设备，比如：硬件设备，软件设备，系统环境，运行服务。那么在这么复杂的环境下，尤其是大公司里成千上万的服务器我们如何去管理和维护呢？如何能保证公司资源的正常运转？我们通过什么手段去及时掌握基础环境和业务应用的可用性？如何获取到各组件的运行状态（如：CPU使用率，内存的使用率，硬盘的使用率，服务是否运行正常，端口是否存在，带宽流量以及网站访问的状态码），公司业务扩展需要增加服务器又该如何操作呢？等等这些问题都需要有一个系统的工具来帮助我们实现--这就是监控系统。
## 监控体系的实现
> 一个监控系统的组成大体可以分为两部分:数据采集（客户端Agent）和数据存储分析告警展示（服务端Server）
> 数据采集又分为主动模式（客户端主动上报数据到服务器）和被动模式（服务器到客户端去采集数据）
> 通常情况下，大多数监控系统都支持这两种模式。被动模式对服务器的开销大，只适合中小企业的监控环境；而主动模式对服务器的开销小，更适合企业的大规模的监控环境。
> 采集数据的协议有两种：专用的客户端采集和共用的协议采集（SNMP、SSH、Telnet等）
> 对采集到的监控数据，可以将其存储到数据库或者文本或者其他方式，根据企业的需求来决定。
## 开源的监控软件介绍
- MRTG
>> MRTG（Multi Route Trffic Grapher）是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的Tobias Oetilker与Dave Rand所开发，以GPL授权。MRTG最好的版本是1995年推出的，用perl语言写成，可跨平台使用，数据财局用SNMP协议，MRTG将收集到的数据通过Web页面以PNG格式绘制出图像。
- Cacti
>> （英文含义仙人掌）是一套基于PHP、MySQL和RRDtool开发的网络流量检测图形分析工具，它通过snmpget来获取数据使用RRDtool绘图，但使用者无须了解RRDtool复杂的参数；它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与ADAP结合进行用户认证，同时也能自定义模板。在历史数据展示监控方面，起功能相当不错。
>> Cacti通过添加模板，是不同设备的监控添加具有可复用性，并且具备可自定义绘图功能，具有强大的运算能力（数据的叠加功能）。
>> Cacti的官方网站：http://www.cacti.net/
- Smokeping
>> Smokeping主要的功能是用于监控网络性能，包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是RRDtool做的支持，特点是绘制展示图特别漂亮，玩过丢包和延迟用颜色和阴影来标识，支持将多张图叠加放在一起，起作者还开发了MRTG和RRDtll等工具
>> Smokeping的官方网站：http://tobi.oetiker.cn
- Graphite
>> Craphite是一个用于采集网站实时信息并惊醒统计的开源的项目。Graphite服务支持平均每分钟4800次更新操作，采用简单文本协议，具有绘图你能，其即插即用的功能方便地用于任何需要监控的系统上。
>> 和其他监控工具不同的而是，Graphite本身并不收集具体的数据，这些数据收集的工作通常由第三方工具或插件完成，可以说，Graphite是一个绘图工具。
>> Graphite的安装网址：http://graphite.wikidot.com/
- Nagios
>> Nagios（Nagios Ain’t Goona Insist on Saintood）是一个企业级别的、免费的、开源IT基础设施监控系统，可监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机参数以及服务，同时提供异常告警通知功能等。
>> Nagios可运行在Linux和UNIX平台上。能有效监控Windows、Linux、UNIX、VMware的主机状态，交换机、路由器等网络设备，同时提供一个可选的基于浏览器的web界面以方便系统管理人员查看系统的运行状态、网络状态、服务状态、日志信息以及其他异常现象等。
>> Nagios的功能侧重于监控服务的可用性，能及时根据触发条件告警。
>> 目前Nagios也占领了一定的市场份额，不过Nagios并没有与时俱进，已经不能厚满足于多变的监控市场需求，架构的扩展性和使用的便捷性有待增强，其告警功能集成在商业版Nagios XI中。
>> Nagios能实现的功能特性：
1. 监控网络服务（SMTP、POP3、HTTP、FTP、PING等）
2. 监控本级以及远程主机资源（CPU负载、磁盘利用率、进程等）；
3. 允许用户编写主机的插件来监控特定的服务，方便地扩展主机的服务的检测方法，支持多种开发语言（Shell、Perl、Python、PHP等）
4. 具备定义网络分层结构的能力，用“parent”主机定义来表达网络主机间的关系，这种关系可被用来发现和明晰主机宕机或不可达状态
5. 当服务或主机问题产生于解决时将告警发送给联系人（通过EMail、短信、用户定义方式）
6. 可以支持并实现对主机的冗余监控
7. 可用Web界面查看当前的网络状态、通知和故障历史、日志文件等
>> Nagios的官网地址：http://www.nagios.org/
安装步骤可参考：http://os.51cto.com/art/201403/433062.htm
- Zenoss
>> Zenoss（Zenoss Core）是开源企业级IT管理软件，它允许IT管理员依靠单一的Web控制台来监控网络架构的状态和健康度。
>> Zenoss Core的强大功能来自深入的列表与配置管理数据库，用于发现和管理公司IT环境的各类资产（包括服务器、网络和其他结构设备）。Zenoss可以创建资产清单和对应的组件级别（接口、服务、进程、已安装的软件等）建立好模型后，Zenoss就可以监控和报告IT架构中各种资源都饿 状态和性能状况了。同时还提供与CMDB关联的时间和错误管理系统，以协助提高各类事件和提醒的管理效率，以此提高IT管理人员的效率。
>> 使用代理收集和基于标准的管理协议：
WMI、PerfMon、SNMP、JMX、HTTP、Telnet、SSH、Syslog、CIMP、FTP、SMTP等
>> Zenoss的官方地址：http://www.zenoss.org/
- Ganglia
>> Ganglia是一个跨平台的、可扩展的。高性能的分布式监控系统，如集群和网络。它基于分层设计，使用广泛的技术，用RRDtool存储数据。具有可视化界面，适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统，可以轻松的管理2000个节点的集群环境。
>> Ganglia是UC Berkeley发起的一个开源集群监视项目，核心包含gmond、gmetad以及一个web前端，主要用于监控系统性能，如：cpu、mem、硬盘利用率、I/O负载、网络流量情况等，通过曲线很容易见到每个节点的工作状态。
>> Ganglia的工作原理是，每台服务器上运行一个收集和发送度量数据的名为gmond的守护进程；gmetad可以部署在集群内任一台节点上或者通过网络连接到集群的独立柱基，它通过单播路由的方式与gmond通信，收集区域内节点的状态信息，并以XML数据的形式保存在数据库中；有RRDtool工具处理数据，并生成相应的图形显示，以Web方式直观的提供给客户端。
>> Ganglia官方地址：http://ganglia.info/
- OpenTSDB
>> OpenTSDB是一款开源的监控系统，用Hbase存储所有哦时序（无序采样）的数据，来构建一个分布式、可伸缩的时间序列数据库。它支持妙计数据采集，支持永久存储，可以做容量规划，并很容易地接入到现有的告警系统里。
>> OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的而采集指标，并进行存储、索引和服务，从而使这些数据更容易让人理解，如Web花、图形化等
>> OpenTSDB的官放网址：http://opentsdb.net/
- Zabbix
>> Zabbix是一个基于Web界面的提供分布式系统监控以及网络监控功能的而企业级的开源解决方案。
>> Zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解除存在的各种问题。
>> Zabbix由两部分组成：zabbix server和可选组件zabbix agent
>> Zabbix server可以通过SNMP、zabbix agent、ping、端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OSX等平台上，将收集到的数据进行分析整理，达到条件触发告警。
>> 从以上各种监控系统的对比来看，Zabbix都是具有优势的，其丰富的功能、可扩展的能力、二次开发的能力和简单易用，只要使用者稍加学习即可上手使用。
>> Zabbix的官方网站：http://www.zabbix.com/
## Zabbix简介
1. Zabbix简介
>> 随着云计算、虚拟化的大规模应用，以及未来移动互联网、物联网等的兴起，Zabbix的使用将越来越广泛，应用场合也越来越多。目前，不少互联网公司、云计算公司、需要继承软件公司、外包服务公司等，都有对Zabbix进行二次开发和大规模的使用。所以，可以断言，Zabbix在未来将会引领监控软件的浪潮，这也是为什么要学习Zabbix的原因之一。
>> Zabbix适合大中型，中小型企业，单个Server节点可以支持上万台设备，每秒可以处理1.5万此请求，理论上可以支持5万台设备。Zabbix自身的定位是中小型企业和大型企业，如果在特大型环境中使用，需要解决大并发、大压力的问题，这对使用者提出了更高的要求。Zabbi是真正的源代码开源产品，用户可以自由下载并使用。
2.Zabbix的功能特性
- 数据收集：可用、性能检测；支持Agent、SNMP、IPMI、JMX、SSH、Telnet等；自定义的检测；自定义收集数据的频率；服务端/代理端和客户端模式
- 灵活的触发器：可以自定义非常灵活的阀值和多种相关联的条件
- 高度可定制的告警：发送通知，可以定制包括告警级别、动作升级、收件人和媒体类型
- 实时的绘图功能：监控项将数据实时绘制在图形上
- Web监控能力：Zabbix可以monitor浏览器请求一个网站，并检测返回值和响应时间
- 多种可视化的展示：可以自定义监控的展示图。将多种监控数据集中展示到以张图上；网络拓扑图；自定义Screens和Slide shows可以将多种图形集中展示；报表功能；资源使用情况的监控展示
- 历史数据的存储：数据存储在数据库中；历史数据的存放周期可配置；定期删除国企的历史数据
- 配置简单易上手：配置比较简单，只需要一下两步即可-->添加设备和应用模板即可完成监控
- 使用模板：模板可以分组；模板具有可继承性
- 网络发现：支持自动发现网络设备和服务器（可以通过自动发现服务规则实现）；Agent自动发现；支持自动发现实现动态监控的而批量监控（支持自定义）内置的自动发现包括文件系统、网络接口、SNMP OLD，可定制自动发现。
- 快速的访问接口：Web页面基于PHP；远程访问；日志审计
- API功能：应用API功能可以方便地和其他系统结合，包括手机客户端的使用
- 系统权限：不同的用户展示监控的资源不同
- 程序特性：用C语言编写，其性能和内存开销非常小
- 大型环境的支持：利用Zabbix-Proxy方式即可轻松构建远程监控
3.选择Zabbix七大理由
- Zabbix是一个自由开发源代码的产品，用户可以对源代码进行任意修改和二次开发。Zabbix采用GNU General Public License (GPL) Version2开源协议
- 安装和配置简单，用户仅仅需要一些简单的学习，即可完成监控的搭建工作
- 搭建环境简单，基于开源软件构建平台，仅需要Linux、Apache/Nginx、MySQL/PostgreSQL/Oracle、PHP即可，无须专用操作系统支持，也无须专用硬件
- Zabbix-Agent完全支持Linux、UNIX、Windows、AIX、BSD和Solaris的监控，Server和Agent都采用C语言编码，对系统的资源占用非常小，数据采集的性能和速度非常快
- 将数据采集持久存储到数据库，便于对监控数据的二次分析
- 非常丰富的扩展能力，很轻松地自定义监控项和实现数据采集，几乎能监控所有的数据。例如：可以监控网站的访问次数，监控UPS和天气温度等。毫不夸张地说，在Zabbix的世界里，往往有想不到的事情，没有办不到的事情。
- 开源社区的运作模式，有各种论坛、邮件列表、IM及时沟通等。
## 进入正题，对监控的理解
1.确定目标、统一思想
- 我们直接跳过什么是监控和监控的重要性等大段描述，先仔细的想一想，监控的目标是什么？每个人的答案都不同，我的回答是：终极目标就是为了保证业务的持续和稳定运行。如此偏激的回答就是让读者从现在开始要站在业务的角度的开始规划监控体系，而不是某个技术范畴。
- 在开始之前，我们还是先统一下认识：要监控一个对象，需要掌握哪些东西呢？
- 监控对象的理解：要监控的对象你是否了解呢？比如CPU到底是如何工作的？
- 监控对象的指标：我们要监控这个东西的什么属性？比如CPU的CPU使用率、负载、上下文切换。
- 确定报警基准线：怎么样才算是故障，要报警呢？比如CPU的负载到底多少算高？
2.如果你不知道从和入手，那么 我们就慢慢一步一步来，最后做个总结
- 硬件监控
> 硬件设备监控是最基础的监控手段，比如定期的的机房巡检。
>> 通常我们的服务器上都会有远程控制卡，如Dell的iDRAC,HP的ILO和IBM的IMM等，可以通过Web界面来进行硬件的监控和管理工作，如果购买企业级的授权，还可以使用控制台进行管理。在Linux下，通常我们使用IPMI来完成物理设备的监控工作。通常必须要监控的就是温度、硬盘故障等。
- 系统监控
> 首先考虑的就是服务器的系统资源的使用情况，这是监控体系的基础，监控的多项包括:
>> CPU
>>> 关于CPU，有3个重要的概念：上下文切换（context switchs），运行队列（Run queue）和使用率（utilization）。
>>> 这也是我们CPU监控的三个重点。通常情况下，每个处理器的运行队列要小于等于3，CPU 利用率中user/system比例维持在70/30，上下文切换要根据系统繁忙程度来综合考量。
>>> 常用的监控工具有：top vmstat mpstat
>> Memory
>>> Linux虚拟内存是一个庞大的东东，通常我们需要监控内存的使用率、SWAP使用率、同时可以通过内存的使用率曲线来发现某些服务的内存溢出等。
>>> 监控工具有：free vmstat
>> IO
>>> IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外，那么日常监控，只关注磁盘使用率、io wait即可，网络也是监控网卡流量即可。
>
>>>> 工具有iostat iotop iftop。
>>> TCP监控：在很多情况下有必要监控TCP的状态，可以使用netstat或者ss来获取所有的TCP连接，来展现11种不同的TCP连接状态的数量，可以在大并发中及时发现TCP的相关故障
>> 其它的系统监控还有运行的进程数、登陆用户、Open File等
- 应用服务监控
>> Apache：Apache提供了mod_status和mod_info模块用来输出Apache的状态，各种grep和awk搞定。
>> Nginx：同样有状态模块，编译的时候加上—with-http_stub_status_module，然后就可以使用stub_status on来开启了
>> Memcached：使用nc给memcached发送了一个stats命令就获取到了所有想要的信息
>> Redis：小王还是使用nc给redis发送了一个info命令就获取到了redis的相关状态。
>> JVM：使用jmconsole，或者jmx就可以进行远程监控
>> 还需要将所有的API接口状态进行监控，比如通过curl检查返回的HTTP状态码。有条件的用户，可以做一个URL监控平台，专门用来做这个事情,这样就会显的一目了然.
3.那么问题来了,最开始这些活用脚本都能实现,但是慢慢的发现,随着公司的发展和业务的扩大,脚本越来越多,每天邮箱里的邮件也越来越多,每天上班光邮件就得看好长时间,那么就需要使用一个软件类来实现这些功能了,于是乎,很热门,很流行的监控软件zabbix就登场了
>> 硬件监控：Zabbix IPMI Interface
>> 系统监控：Zabbix Agent Interface
>> Java监控：Zabbix JMX Interface
>> 网络设备监控：Zabbix SNMP Interface
>> 应用服务监控：Zabbix Agent UserParameter
>> MySQL数据库监控：percona-monitoring-plulgins
>> URL监控：Zabbix Web 监控
> 这样一来，之前的脚本只需要简单修改下就都可以使用，同时也可以灵活的设置报警阈值、告警方式、告警升级、告警去重、告警依赖等等，同时还使用Zabbix的自动发现功能实现上线一台服务器后，自动添加监控。
> 当你服务器数量翻倍增加，机房也增加的时候，zabbix还提供了Zabbix Proxy代理来实现跨机房的分布式监控
> 对于告警通知：邮件、微信、短信、钉钉等，都可以与Zabbix快速的集成，网上有很多此类文档。
> 针对某些可以进行直接处理的报警，Zabbix可以触发Action来轻松帮你实现，故障的自动处理。
- 流量分析
>> 网上很多，比如google分析、百度统计、站长工具等等一堆统计的东西，只需要在页面嵌入一个js即可，但是这些工具的数据都不在本地，于是一个叫做piwik的开源项目帮我们解决了这个问题。参考：https://www.oschina.net/question/17_1525
- 网络监控
>> 网络监控是我们构建监控平台是必须要考虑的，尤其是针对有多个机房的场景，各个机房之间的网络状态，机房和全国各地的网络状态都是我们需要重点关注的对象，那么如何掌握这些状态信息呢？我们需要借助于网络监控工具Smokeping。
>> Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl写的，主要是监视网络性能，www 服务器性能，dns查询性能等，使用rrdtool绘图，而且支持分布式，直接从多个agent进行数据的汇总。
>> 同时，由于自己监控点比较少，还可以借助很多商业的监控工具，比如监控宝、基调、博瑞等。同时这些服务提供商还可以帮助你监控CDN的状态。参考：***linux/shiyongsmokepingjiankongidcjifangwangluozhiliangqingkuang_556136_1375949500.html
- 安全监控
>> 虽然iptables完成了四层的安全防护，但是针对七层的Web层面怎么办呢？可以使用Nginx + Lua编写了一个WAF，然后把相关的日志记录到了Elasticsearch中，通过kibana可以图形化的展示不同的攻击类型的统计。参考：https://github.com/loveshell/ngx_lua_waf
- 业务监控
>> 没有业务指标监控的监控平台是一个不完善的监控平台，通常在我们做监控系统中，必须将我们重要的业务指标进行监控，并设置阈值进行告警通知。
>> 比如每分钟的订单、每分钟注册、日活用户、短信使用量等重要的业务指标都可以加入到Zabbix上。
- 日志监控
> 通常情况下，系统会产生系统日志、应用程序会有应用的访问日志、错误日志，服务有运行日志等，可以使用ELK来进行日志监控。
> 对于日志来说，最常见的需求就是收集、存储、查询、展示，开源社区正好有相对应的开源项目：
>> logstash（收集）
>> elasticsearch（存储+搜索）
>> kibana（展示）
> 我们将这三个组合起来的技术称之为ELK Stack，所以说ELK Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。
> 如果收集了错误日志，那么如果部署更新有异常出现，可以立即在kibana上看到。当然也可以使用Zabbix来进行错误日志的过滤来进行告警。
- 自动化
> 在大规模的环境中，如果无法做到自动化监控，那么手动添加监控不仅仅是一个恐怖的工作，而且也无法保证完整性
>> 主动模式 比如使用Zabbix的自动发现，主动的对全网进行扫描，然后自动添加相关的监控服务器和引用监控模板
>> 被动模式 也可以使用Zabbix API进行被动的监控的添加。比如以CMDB为核心，如果检测到某服务器增加了Nginx服务，那么自动调用Zabbix API添加上Nginx的监控模板
> 真正想做到更完整的监控体系，目前的开源软件，确实无法很好的满足，有条件的公司都开始自己开发自己的监控系统，比如小米开源的Open-Falcon。也有比较好的开源的监控框架如Sensu等，再加上influxdb grafana可以用来定制符合自己企业的监控平台。
- 可视化
> 运维的重要目标之一就是数据的可视化，一个监控平台不能很好的反映出来业务的波动，就是耍流氓。之前的一切努力在业务部门的领导中变得一文不值。
>> 面向传统运维：
>>> 尽可能的完善业务监控，如果有专门的业务分析系统，要想办法和运维的监控平台进行结合
>>> 梳理清楚各个子系统之间和业务的关系，比如如果突然间流量增加了50M，能够快速的知道这50M流量到了那个业务系统上，访问的哪些URL，以及这个业务系统的相关状态
>> 面向DevOps：
>>> 将所有的监控项和业务之间建立关系树，比如业务、网络、系统、数据库、流量、推广活动（流量分析）之间可以形成一个庞大的关系链。这是一个比较庞大的工程，业务是多变的，如何让监控平台能尽可能的适应多变的业务是一个艰巨的任务。参考：http://echarts.baidu.com/index.html
4.还有和运维相关的页面性能监控（页面资源数量、DNS解析时间、首屏时间、加载最慢的资源、产生阻塞的JS等）、代码监控、与运维无关的舆论监控等.
本文出自 “yunwei” 博客，请务必保留此出处http://tiantianlele.blog.51cto.com/10811177/1861488
原文地址：http://tiantianlele.blog.51cto.com/10811177/1861488
