zabbix监控-----基础（简介）

zabbix监控-----基础（简介）

1. 为什么需要监控系统

• 在互联网企业中，每个企业都会有自己的业务，需要通过底层的各种服务器或者服务器集群，比如：硬件设备、软件设备等。

• 多种应用构成复杂的IT业务系统，保证这些资源的正常运转，是一个公司IT部门的职责。而要让这些应用能够稳定地运行，则需要专业IT人员进行设计、架构、维护和调优。在这个过程中，为了及时掌控基础环境和业务应用系统的可用性，需要获取各个组件的运行状态，如CPU的利用率、系统的负载、服务的运行、端口的连通、带宽流量、网站访问状态码等信息。而这一切都离不开监控系统。

2. 监控系统的实现

• 一个监控系统的组成大致的可以分为两部分：数据采集部分（客户端）和数据存储分析告警展示部分（服务器端）

• 数据采集的工作模式可以分为被动模式（服务器端到客户端采集数据）和主动模式（客户端主动上报数据到服务器端）。通常，大多数的监控系统都能够支持这两种模式。被动模式对服务器的开销较大，比较适合小规模的监控环境；主动模式对服务器的开销较小，比较适合大规模的监控环境。
• 采集数据的协议方式可以分为两种：专用客户端采集和公用协议采集（SNMP、SSH、Telnet等）。

• 对于采集到的监控数据，可以将其存储到数据库或者文本或者其他方式，具体采用哪一种，应根据实际需求来决定。怎么规划监控系统的架构设计呢?
• 对于一般的监控环境，被监控的节点不多，产生的数据较少，采用C/S(Client/Server，客户端/服务器端)架构就足够了，下图这种架构适合于规模较小、处于同一地域的环境。

• 对于大规模的监控环境，被监控的节点多，且监控类型多，监控产生的数据和网络连接开销会非常巨大，而且由于跨地域等多种因素，需要分布式的解决方案，常见的方式为C/P/S (Client/Proxy/Server,客户端/代理端/服务器端)架构，采用中间代理将大大提高监控服务器端的处理速度，从而能支撑构建大型分布式监控的环境。

• 监控系统更重要的功能是告警和故障处理，这对及时解决问题和故障自愈非常重要。告警的时候，需要考虑到故障的有效汇报和集中汇报，防止出现“告警洪水“，即同一类告警信息重复大量地发送。

3. 常见的开源监控系统

3.1 prometheus

• Prometheus 是云原生应用程序最受认可的时间序列监控解决方案，由 CNCF 托管，使用 Go 语言开发，是 Google BorgMon 监控系统的类似实现。
• Prometheus 使用的是 Pull 模型，Prometheus Server 通过 HTTP 的 pull 方式到各个目标拉取监控数据。它使用局部配置来描述要收集的端点和收集所需的间隔。 每个端点都有一个客户端收集数据并在每次请求时更新该表示（或者客户端是配置的）。 收集此数据并将其保存在本地磁盘上的高效存储引擎中。 存储系统使用每个度量标准的仅附加文件。
• prometheus系统架构图

• Prometheus 包含一种高级表达式语言，用于选择和显示名为 PromQL 的数据。此数据可以通过 REST API 以图形或表格显示或由外部系统使用。表达式语言允许用户创建回归，分析实时数据或趋势历史数据。标签也是用于过滤和查询数据的绝佳工具。标签可以与每个度量标准名称相关联。
• Prometheus 附带 AlertManager 来处理警报。AlertManager 允许进行警报聚合以及更复杂的流量以限制发送警报的时间。假设在开关关闭的同时 10 个节点突然出问题，你可能不需要发送有关这 10 个节点的告警，因为接到报警的每个人在开关修好之前可能无法执行任何操作。使用 AlertManager，可以仅向网络团队发送有关开关告警，并在其中包含其他可能受影响系统的信息；也可以向系统团队发送电子邮件（而不是页面），以便他们知道这些节点已关闭，除非系统在开关修复后没有恢复，否则他们不需要响应。 如果发生这种情况，则 AlertManager 将重新激活那些被开关警报抑制的警报。

3.2 Graphite

• Graphite 是一款用 Python 写的开源企业级监控绘图工具，可以在廉价机硬件上运行。Graphite 可以实时收集、存储、显示时间序列类型的数据，它由三个软件组件组成：
  • carbon - 基于 Twisted 的进程，用于监听并接收数据；
  • whisper - 专门存储时序数据的小型数据库，在设计上类似于RRD；
  • graphite webapp - 基于 Django 的网页应用程序，可以从 whisper数据库获取时间序列数据并且进行展示。
• graphite架构图

• Graphite 是一个基于推送的系统，通过让应用程序推送数据到 Graphite 的 Carbon 组件中，从应用程序接收数据。 Carbon 将此数据存储在 Whisper 数据库中，Graphite Web 组件读取 Carbon 它的和数据库，允许用户在浏览器中绘制数据图或通过 API 提取数据。一个非常酷的功能是能够将这些图形导出为图像或数据文件，以便将它们轻松嵌入到其他应用程序中。
• Graphite 的另一个有趣功能是能够存储与时序指标相关的任意事件。可以在 Graphite 中添加和跟踪应用程序或基础架构部署， 这允许运维人员或开发人员对问题进行故障排除，能获得正在调查的异常行为环境中更多的背景信息。

3.3 InfluxDB

InfluxDB 是一个相对较新的时序数据库，使用 Go 语言编写，无需外部依赖，安装配置非常方便，适合构建大型分布式系统的监控系统。

其设计目标是实现分布式和水平伸缩扩展。

InfluxDB 的一些主要特征：

• 无结构 (无模式)：可以是任意数量的列
• 可以设置 metric 的保存时间
• 支持与时间有关的相关函数 (如min、max、sum、count、mean、median 等)，方便统计
• 支持存储策略: 可以用于数据的删改。(influxDB没有提供数据的删除与修改方法)
• 支持连续查询: 是数据库中自动定时启动的一组语句，和存储策略搭配可以降低 InfluxDB 的系统占用量。
• 原生的 HTTP 支持，内置 HTTP API
• 支持类似 sql 语法
• 支持设置数据在集群中的副本数
• 支持定期采样数据，写入另外的measurement，方便分粒度存储数据
• 自带 web 管理界面，方便使用 (登入方式：http://< InfluxDB-IP>:8083)

3.4 MRTG

• MRTG (Multi Router Traffic Grapher)是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的TobiasOetiker与DaveRand所开发，以GPL授权。MRTG最早的版本是在1995年春推出的，用Perl 语言写成，可跨平台使用，数据采集用SNMP协议，MRTG将收集到的数据通过Web页面以GIF或PNG格式绘制出图像，并以日、周、月为单位分别绘出，可以查询最大值和最小值。
• MRTG原本只能绘出网络设备的流量图，后来发展出了各种插件。因此，网络以外的设备也可由MRTG监控，例如，服务器的硬盘使用量、CPU的负载等。

3.5 Cacti

• Cacti (英文含义为仙人掌)是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具。它通过snmpget来获取数据，使用RRDtool绘图，但使用者无须了解RRDtool复杂的参数。它提供了非常强大.的数据和用户管理功能，可以指定每-一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。
• Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力(数据的叠加功能)。

3.6 SmokingPing

• SmokePing主要用于监视网络性能，包括常规的ping、WWW服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持，特点是绘制的图非常漂亮，网络丢包和延迟用颜色和阴影来表示，支持将多张图叠放在一-起。其作者(Tobi Oetiker)还开发了MRTG和RRDtool等工具。

3.7 Nagios

• Nagios是—个企业级的监控系统，可监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机参数以及服务，同时提供异常告警通知功能等。
• Nagios可运行在Linux和UNIX平台上，同时提供一一个可选的基于浏览器的Web界面，以方便系统管理人员查看网络状态、各种系统问题，以及日志等。
• Nagios的功能侧重于监控服务的可用性，能及时根据触发条件告警。
• 目前，Nagios 也占领了- -定的市场份额，不过从笔者的观察来看，Nagios 并没有与时俱进，已经不能满足于多变的监控需求，架构的扩展性和使用的便捷性有待增强，其高级功能集成在商业版Nagios XI中。

3.8 zenoss core

• Zenoss Core ( 简称Zenoss)是开源企业级IT管理软件，它允许IT管理员依靠单一的Web控制台来监控网络架构的状态和健康度。
• Zenoss Core的强大功能来自深入的列表与配置管理数据库，用于发现和管理公司IT环境的各类资产(包括服务器、网络和其他结构设备)。Zenoss 可以创建关键资产清单和对应的组件级别(接口、服务、进程、已安装的软件等)。建立好.模型后，Zenoss就可以监控和报告IT架构中各种资源的状态和性能状况了。同时还提供与CMDB关联的事件和错误管理系统，以协助提高各类事件和提醒的管理
  效率，以此提高IT管理人员的效率。
• Zenoss Core采用SNMP来采集数据。

3.9 Ganglia

• Ganglia是-一个跨平台的、可扩展的、高性能的分布式监控系统，如集群和网格。它基于分层设计，使用广泛的技术，用RRDtool 存储数据，具有可视化.界面，适合于对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统,可以轻松地处理2000个节点的集群环境。

3.10 opentsdb

• 开源监控系统OpenTSDB用HBase存储所有时序(无须采样)的数据，来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集，支持永久存储，可以做容量规划，并很容易地接入到现有的告警系统里。OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的采集指标，并进行存储、索引和服务，从而使这些数据更容易让人理解，如Web化、图形化等。
• 在对实时性要求比较高的场合，OpenTSDB是一个很好的选择。它支持秒级别的数据采集，这在其他监控系统中是无法想象的。因得益于其存储系统的选择,所以它支持大数据分析。因此，这个开
  源软件在未来的环境中会有更多的用户，也会获得更广泛的支持。

3.11 zabbix

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

4. 监控系统的实现

• 监控系统往往需要对物理硬件和应用软件的性能和参数进行数据汇集，实现集中管理和统一 分析。
• 在一个监控系统中，构成要素为监控服务器端程序、数据存储、被采集节点等相关模块，其告警分析和自动故障处理功能由服务器端执行。在数据采集完成之后，需要对采集到的数据进行分析和处理，判断是否有异常，是否属于告警条件。告警条件如何设置呢?通常是根据实际的经验值、业务需求来设置告警阈值。
• 达到告警条件时，则发送告警信息给管理人员，然而，对于有些故障，我们希望
  程序能自动处理，减少人工干预，让程序自动修复，只在出现严重故障、程序无
  法判断的时候，才告警通知管理人员处理。
• 一个监控系统往往需要集成资产管理,可以从逻辑上展示业务和功能的信息，通过对其进行数据分析，做到对投资与回报的一“个反馈展示，为资产的合理规划与使用提供了依据。
• 从其工作模式来看，监控系统的数据采集可以分为两种:主动监控和被动监控，一个理想的监控系统，其采集端支持的采集方式越多，其扩张能力越强大，适用的环境场合越多。
• 监控系统需要提供一一个API， 方便其他功能系统对监控数据进行操作管理，这在业务系统精密的情况下显得特别重要，通常能对外提供API功能的软件，其用户群会更广，产品会越做越好。API一般可以分为RESTful、SOAP等形式，数据类型有JSON、XML等多种。从目前的趋势来看，RESTful 已经成为绝大多数API首选的方式。
• 监控系统需要对故障数据进行分析汇总，从故障中分析出现的概率，从而可以积累经验，避免以后出现类似的问题。例如，由于机器硬件导致的故障，其概率有多大，哪些部件最容易出问题，出问题的影响概率多大，问题解决的概率有多大。从监控的数据中就可以分析并发现相关数据，在此基础上进行分析汇总，可以整理出相应的对策和相应的技术应急方案。

5. 监控系统对时间的要求

• 监控系统需要根据实际应用的需求，实时/非实时地采集和展示数据。另外，包括历史趋势数据的展示和分析，以及容量报表、可用性报告的生成。

6. 监控系统的告警需求

• 支持多种方式，如短信、邮件、IM和其他接口。具备可定制化功能，对第三方告警介质提供可编程接口。这一-点在很多场合非常重要，例如，将告警结果发送到专用的告警分析系统。
• 支持对告警内容的分析自动处理，防止误报、漏报，以及防止抖动。这一点对大多数监控系统都是一个值得挑战和研究的课题。例如，一个机房网络发生故障，按照常规告警内容，会收到无数条告警信息，内容是每个设备的故障，而对于更高级的告警信息，我们希望收到的是“某机房存在网络故障，受影响的设备的IP是X.X.X.X~ X.X.X.X， 受影响的业务是XXX."， 这样做的目的是让告警信息更智能、更有效，防止“告警炸弹”的产生。简而言之，监控数据的采集、存储、分析和故障报告是每个监控系统的基本功能，其他复杂的附加功能则是监控系统的增值业务。