运维监控答疑解惑：谈谈运维监控那些事儿
运维监控答疑解惑：谈谈运维监控那些事儿当然我们现在可以通过 IPMI 对硬件的详细情况进行监控，并对 CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围)早期我们通过机房巡检的方式，查看硬件设备灯光闪烁情况判断是否故障，这样非常浪费人力，并且是重复性无技术含量的工作，大家懂得。下面我们需要选择一款合适公司业务的监控工具进行监控 这里我对监控工具进行了简单的分类。我们上面了解了监控方法、目标、流程、也了解了监控有哪些工具，可能有人会疑惑，我们具体要监控些什么东西，那么我在这里进行了分类整理。硬件监控系统监控应用监控网络监控流量分析日志监控安全监控API监控性能监控业务监控
谈谈运维监控那些事儿
我们先来了解什么是监控，监控的重要性以及监控的目标，当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。
- 对系统不间断的实时监控：实际上是对系统不间断的实时监控(这就是监控)。
- 实时反馈系统当前状态：我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障。
- 保证服务可靠性安全性：我们监控的目的就是要保证系统、服务、业务正常运行。
- 保证业务持续稳定运行:如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。
监控方法
既然我们了解到了监控的重要性、以及监控的目的，那么下面我们需要了解下监控有哪些方法。
- 了解监控对象：我们要监控的对象你是否了解呢？比如 CPU 到底是如何工作的？
- 性能基准指标：我们要监控这个东西的什么属性？比如 CPU 的使用率、负载、用户态、内核态、上下文切换。
- 报警阈值定义：怎么样才算是故障，要报警呢？比如 CPU 的负载到底多少算高，用户态、内核态分别跑多少算高？
- 故障处理流程：收到了故障报警，那么我们怎么处理呢？有什么更高效的处理流程吗？
监控核心
我们了解了监控的方法、监控对象、性能指标、报警阈值定义、以及故障处理流程几个步骤，当然我们更需要知道监控的核心是什么？
- 发现问题：当系统发生故障报警，我们会收到故障报警的信息。
- 定位问题：故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析，比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等等，我们就需要去分析故障具体原因。
- 解决问题：当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。
- 总结问题：当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。
监控工具
下面我们需要选择一款合适公司业务的监控工具进行监控 这里我对监控工具进行了简单的分类。
监控流程
- 数据采集：Zabbix 通过 SNMP、Agent、ICMP、SSH、IPMI 等对系统进行数据采集。
- 数据存储： Zabbix存储在MySQL上，也可以存储在其他数据库服务。
- 数据分析：当我们事后需要复盘分析故障时，zabbix能给我们提供图形以及时间等相关信息，方便我们确定故障所在。
- 数据展示：web界面展示、(移动APP、java_php开发一个web界面也可以)。
- 监控报警：电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）。
- 报警处理：当接收到报警，我们需要根据故障的级别进行处理，比如:重要紧急、重要不紧急，等。根据故障的级别，配合相关的人员进行快速处理。
监控指标
我们上面了解了监控方法、目标、流程、也了解了监控有哪些工具，可能有人会疑惑，我们具体要监控些什么东西，那么我在这里进行了分类整理。
硬件监控
系统监控
应用监控
网络监控
流量分析
日志监控
安全监控
API监控
性能监控
业务监控
硬件监控
早期我们通过机房巡检的方式，查看硬件设备灯光闪烁情况判断是否故障，这样非常浪费人力，并且是重复性无技术含量的工作，大家懂得。
当然我们现在可以通过 IPMI 对硬件的详细情况进行监控，并对 CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围)
系统监控
中小型企业基本全是 Linux 服务器，那么我们肯定是要监控起系统资源的使用情况，系统监控是监控体系的基础。
应用监控
把硬件监控和系统监控研究明白后，我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务，都需要监控起来。
应用服务监控也是监控体系中比较重要的内容，例如：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，最后将相关的日志都收至 ELK Stack，通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间，并且个人效果并不是很好。这个时候我们可以选择接入第三方服务厂商。
三方厂商提供全面的漏洞库，涵盖服务、后门、数据库、配置检测、CGI、SMTP 等多种类型全面检测主机、Web 应用漏洞自主挖掘和行业共享相结合第一时间更新 0day 漏洞，杜绝最新安全隐患。
API 监控由于 API 变得越来越重要，很显然我们也需要这样的数据来分辨我们提供的 API 是否能够正常运作。监控API接口 GET、POST、PUT、DELETE、HEAD、OPTIONS 的请求可用性、正确性、响应时间为三大重性能指标。
性能监控全面监控网页性能，DNS 响应时间、HTTP 建立连接时间、页面性能指数、响应时间、可用率、元素大小等。
业务监控没有业务指标监控的监控平台，不是一个完善的监控平台，通常在我们的监控系统中，必须将我们重要的业务指标进行监控，并设置阈值进行告警通知。比如电商行业：每分钟产生多少订单，每分钟注册多少用户，每天有多少活跃用户，每天有多少推广活动，推广活动引入多少用户，推广活动引入多少流量，推广活动引入多少利润等等重要指标都可以加入 Zabbix 上，然后通过 Screen展示。
监控报警故障报警通知的方式有很多种，当然我们最常用的还是短信，邮件。
一般报警后我们故障如何处理呢？首先，我们可以通过告警升级机制自动处理，比如 Nginx 服务 Down ，可以设置告警升级自动启动 Nginx。
但是如果一般业务出现了严重故障，我们通常根据故障的级别，故障的业务，来指派不同的运维人员进行处理。
当然不同业务形态、不同架构、不同服务可能采用的方式都不同，这个没有一个固定的模式套用。
在运维面试中，常常会被问题监控相关的问题，那么这个问题到底该如何来回答，我针对本文给大家提供了一个简单的回答思路。
硬件监控通过 SNMP 来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他，可以通过 IPMI 来实现。当然如果没有硬件全都是云，直接跳过这一步骤。
监系统监控如 CPU 的负载、上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode 使用率。当然这些都是需要配置触发器，因为默认太低会频繁报警。
监服务监控比如公司用的 LNMP 架构，Nginx 自带 Status 模块、PHP 也有相关的Status、MySQL 的话可以通过 Percona 官方工具来进行监控。Redis 这些通过自身的 Info 获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容，以及报警和图形功能。
网络监控如果是云主机又不是跨机房，那么可以选择不监控网络。当然你说我们是跨机房以及如何如何。推荐使用 Smokeping 来做网络相关的监控。或者直接交给你们的网络工程师来做，因为术业有专攻。
监安全监控如果是云主机可以考虑使用自带的安全防护。当然也可以使用 Iptables。如果是硬件，那么推荐使用硬件防火墙。使用云可以购买防 DDOS，避免出现故障导致 Down 机一天。如果是系统，那么权限、密码、备份、恢复等基础方案要做好。Web 同时也可以使用 Nginx Lua来实现一个 Web 层面的防火墙。当然也可以使用集成好的 Openresty。
Web 监控的话题其实还是很多。比如可以使用自带的 Web 监控来监控页面相关的延迟、js响应时间、下载时间等等。这里我推荐使用专业的商业软件 监控宝或听云来实现。毕竟人家全国各地都有机房。（如果本身是多机房那就另说了）日志监控如果是 Web 的话可以使用监控 Nginx 的 50x、40x 的错误日志，PHP的ERROR 日志。其实这些需求无非是收集、存储、查询、展示，我们其实可以使用开源的 ELK Stack 来实现。
业务监控我们上面做了那么多，其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论，监控是比较重要的业务指标，然后通过简单的脚本就可以实现，最后设置触发器即可。
监流量分析平时我们分析日志都是拿 Awk Sed 等一堆工具来实现。这样对我们统计 IP、PV、UV不是很方便。那么可以使用百度统计、Google统计，让开发嵌入代码即可。为了避免隐私也可以使用 Piwik来做相关的流量分析。
可视化通过 Screen 以及引入一些第三方的库来美化界面，同时我们也需要知道，订单量突然增加、突然减少。或者说突然来了一大波流量，这流量从哪儿来，是不是推广了，还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。
自动化监控如上我们做了那么多的工作，当然不能是一台一台的来加 Key 实现。可以通过Zabbix 的主动模式以及被动模式来实现。当然最好还是通过 API 来实现。
监控总结真正想做到更完整的监控体系，目前的开源软件，确实无法很好地满足，有条件的公司都开始自己开发自己的监控系统，比如小米开源的 Open-Falcon。也有比较好的开源的监控框架如 Sensu 等，再加上 Influxdb、Grafana可以用来定制符合自己企业的监控平台。
聊了这么多监控运维的事情，接着分享一些关于监控运维的常用软件吧
Zabbix 作为企业级的网络监控工具，通过从服务器，虚拟机和网络设备收集的数据提供实时监控，自动发现，映射和可扩展等功能。
Zabbix的企业级监控软件为用户提供内置的Java应用服务器监控，硬件监控，VMware监控和CPU，内存，网络，磁盘空间性能监控。
企业级网络监控工具能够每分钟进行 3 000 000 次检查，具有更高的安全性和数据中心监控功能。
Nagios 是一款用于监控IT基础架构和查看当前状态、历史日志和基本报告的开源软件工具。 Nagios 用户可以监控系统指标，网络协议，应用程序，服务器，网络基础架构和接收故障警报。
Nagios提供三种类型的网络管理工具，Nagios XL，Nagios日志服务器和Nagios网络分析器。其中 Nagios XL 最适合网络监控（尽管其他两种也提供网络监控服务）。
Nagios XL提供企业级网络监控，为用户提供带宽报告，网络心跳监控，自定义URL，电子邮件报告和远程机器监控。 升级的企业版提供基于Web的服务器控制台访问，业务流程监控，记录审核和自动化删除功能。
最初发布于2001年， Cacti 是一款开源的基于Web的网络监控和专为数据记录而设计的图形化工具。它可以用于实时显示网络数据，如CPU负载或带宽利用率。
Cacti是RRDtool的前端应用程序，RRDtool是一种用于存储实时变化数据的开源数据库工具，其使用SNMP作为其默认收集算法，但如果你喜欢本地Perl的PHP脚本，那么你也可以使用它们。
其最新版本0.8.8h于2016年5月发布，主要功能包括无限图形项目、图形自动填充支持、图形数据处理、自定义数据采集脚本、内置SNMP支持、图形模板、数据源模板、主机模板和基于用户的管理
GroundWork Monitor Core 是监控网络、应用和云计算使用情况的平台。开源版本包含最多可监控50个设备和基于社区的支持的许可证，该软件还有其对应的商业版本。
在其网络管理功能方面，GroundWork提供网络和设备的自发现和维护、拓扑、报警控制、通过API/SNMP/IPMI的数据收集和对OpenDaylight SDN的支持等功能。
GroundWork还提供了存储管理，支持大规模的企业级供应商，如NetApp和EMC，以及从磁盘、块或对象存储的数据收集和存储缓冲以及中断可视化。
由于GroundWork的一站式网络管理方法，这种套件可能更适合那些寻找成熟品牌的大型商业和企业，而不是以开发人员为重点的工具，如Big Brother或Big Sister。
VMware的Hyperic工具用于在物理、虚拟或云环境下监控Web应用程序及其性能。 它适用于应用程序服务器，web服务器，数据库，操作系统，虚拟机管理程序，消息传递服务和目录服务器。
Hyperic提供基础架构和操作系统监控，详细的报告，应用程序和中间件监控，警报和修复工作流程以及通用可扩展的API。
该网络监控工具提供了企业版本，可以提高网络警报功能，并且能更好地创建基准。
基于Linux的Observium是一个自动监测的网络监控工具。 据该网站介绍，“该工具是由一批经验丰富的专业网络工程师和系统管理员开发和维护的，Observium是一个由用户自己设计和构建的平台。”
Observium提供社区版本和专业版，使用RRDTool进行缓冲存储和图形化功能，并具有易于使用的用户界面和报告功能。 但是，它没有报告导出功能，这可能对商务应用来讲会是一个问题。
社区版本将为用户提供对所有支持设备或指标的完整自动监测功能，通过自动发现协议进行网络映射，自动识别数百种设备，并且每六个月发布一个新版本。
而专业版用户将获得所有社区版本的功能并且还将获得实时软件更新和修复功能，基于规则的自动分组功能，网络阈值和状态警报系统以及流量统计系统。
NetXMS 提供了企业级开源网络管理和监控程序，它在Windows和Linux上有一个简单的用户界面。
NetXMS通过相对简单的安装过程为IT基础架构的所有层提供了分布式网络监控、自动化网络发现和详细报告。
此外，服务器设备和代理对于这样一个全面的产品来说是相当轻量级的。
定位于企业级， Pandora FMS 提供了一个时尚且整洁的用户体验，提供了易于阅读的快速洞察工具以及重要的网络统计信息，例如网络状态、已上报的告警、已部署的代理数量和其他最近执行任务的列表。
Pandora FMS可以在无需外部访问的情况下执行网络诊断，这意味着用户可以更快地响应任何网络问题。事实上，FMS声称，在代理模式下的器监控系统响应速度约为10秒。
NetDisco专为类 Unix 操作系统而设计，通过NSMP提供基于网络的自动发现网络设备的功能，从而生成网络拓扑图。它是专为中型到大型网络而设计的。
该网络管理工具可用于定位设备，创建设备目录并报告IP地址和交换机端口使用情况。
NetDisco用户可以通过MAC或IP在网络上定位机器，关闭交换机端口，或更改端口的VLAN或PoE状态，按照型号，供应商，软件和操作系统对网络硬件进行清点，并给你的网络创建一个详细的拓扑图。
OpenNMS是在1999年发布的，旨在为大型企业级用户提供事件管理，服务监控和性能测量。
使企业用户受益的主要特点包括外部脚本、向通话系统工程师发送警报、扩展Java本机通知策略API、请求跟踪（RT）集成、高级警报、IPv4和IPv6网络可达性超过ICMP、测试状态和节点库存信息。
企业服务或是“风格”网络提供预置事件，通知，数据收集，工作流和附加报告等功能。
RANCID 听起来像一个消极的名字，除非你学会Really Awesome New Cisco的配置。这一点意味着它能监视路由器或其他设备的配置，并维护任何更改过的历史记录。RANCID 支持很多供应商的设备，包括 Juniper路由，HP交换机，Redback的NAS 和 很多对Observium有扩展设备的支持。
RANCID支持许多供应商的设备，包括Juniper路由器，HP交换机，Redback NAS和许多其他设备，以及对Observium的扩展支持。
RANCID提供多种网络管理功能，包括登录到路由器表（router.db）中的每个设备，运行各种命令以获取将被保存的信息，将之前收集的信息中的任何变化发送到邮件列表，并提交这些更改到版本控制系统。
另一个需要提及的网络监控工具是Xymon（以前称为Hobbit）。 Xymon监控服务器，应用程序和网络，通过网页提供有关所有这些网络组件运行状况的信息。
其网站上表示Xymon的开发受到Big Brother的启发，同Big Sister一样，它试图解决Big Brother BTF的缺点，如性能方面。 同时，Xymon更容易部署并且是免费的。
Big Brother创建于20世纪90年代中期，用于监控网络系统，后来被Quest Software收购，而其又被戴尔在2012年收购。
许多其他网络监控工具都是模仿Big Brother的，所以它有一个大型的、详细的论坛和有帮助的开发人员社区，是初学者的好选择。
除了可用于学生和非商业用途的开源版本之外，其还提供了名为Big Brother Professional Edition的商业版本。
Big Sister创始人托马斯·艾比（Thomas Aeby）表示，他对Big Brother的网络监控印象深刻，但希望提高其性能，减少坏事件发生时的警报数量，并进行其他改进。
Big Sister提供网络监控，节点管理，doxygen过滤器和Web应用程序框架，作为Unix衍生产品和Microsoft Windows操作系统的一部分。
Big Sister对监控网络系统的IT管理员有所帮助。当系统故障时，它会通知管理员，生成状态变化历史记录日志并显示各种系统性能数据。
Open Falcon 是由小米开源的运维监控系统。小米从互联网公司的一些需求出发，从各位SRE、SA、DEVS的使用经验和反馈出发，结合业界的一些大的互联网公司做监控，用监控的一些思考出发，设计开发了小米的监控系统：open-falcon。open-falcon的目标是做最开放、最好用的互联网企业级监控产品。
其特点是：
- 强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
- 水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
- 高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
- 人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
- 高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
- 高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
- dashboard：多维度的数据展示，用户自定义Screen
- 高可用：整个系统无核心单点，易运维，易部署，可水平扩展
- 开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。
Icinga 起初是 Nagios 的一个分支。Icinga 2 则是做减法得来的，它还能提供分布式监控和多线程框架，这是 Nagios 或 Icinga 1 所不具备的。你可以从 Nagios 迁移到 Icinga 1，然后再迁移到 Icinga 2。
与 Nagios 一样，Icinga 几乎也能通吃所有设备，搭配 SNMP、定制插件和扩展使用效果更佳。
Icinga 提供全局监控和警告框架，只是在 Web UI 上与 Nagios 有所不同。
Icinga 有多款 Web UI，它与 Nagios 的不同主要是配置，用户通过 Web UI 就能搞定，省去了麻烦的配置文档。对于那些在命令行之外管理配置的人来说，这是个重大利好。
Icinga 融入了多款绘图和监控套件（如 PNP4Nagios、inGraph 和 Graphite），可视化性能绝对可靠。此外，Icinga 还拥有扩展报告功能。
Ntop 计划，也就是传说中的计划 Ntopng，已经陆陆续续开发了十年。它是一款顶尖的网络流量监控工具，Web 图形用户界面简洁且顺滑。它使用 C 语言编写且完全独立，你只需要运行配置，就能监控某个特定网络接口的单一进程，就这么简单。
Ntop 提供了简单易懂的图形和表格来显示当前和过去的网络流量，包括协议、源、目的地以及特定交易的历史，甚至两端的主机。此外，你还会发现广泛的网络利用率图表、实时地图和趋势，以及针对各种附加件（例如NetFlow和sFlow）的插件框架。这里甚至还有专门嵌入到 Ntop 的硬件监控器 Nbox。
Ntop 甚至用上了轻量级 Lua API 框架，通过脚本语言就能支持扩展。Ntop 还可以将主机数据存储在 RRD 文件中，以支持持久的数据采集。
Ntop 最便捷的用途就是现场流量检查。当你发现自己的某个 Cacti PHP Weathermap 突然显示红色的网络链接集时，就意味着这些链接的利用率超过了 85%，但原因却不得而知。只要切换到 Ntopng 程序来监控该网络段，就可以查看最高流量消耗者每分钟的报表，并立即获知到底哪个主机在占用流量。
这种可视性算得上是无价之宝了，而且唾手可得。从本质上来讲，你可以在被配置成交换机级别的任何端口运行 Ntopng，以便监控任何端口或者 VLAN。
