分布式系统开发实战：分布式监控，分布式监控常用技术

分布式监控概述

运维离不开监控就像鱼离不开水，一款功能强大的监控系统可以有力地保证业务的性能和稳定性。特别是在分布式系统架构下，节点数量众多，手工维护这些节点的状态已经不可能了。因此，分布式系统往往会配套搭建监控系统，以保障分布式系统的持续可用。

分布式监控应用场景

如果你所处的项目，是单机的部署的应用，或者节点数不超过3个，那么即便不使用专业的监控产品，也能满足你平常的运维需要。你可以手工操作登录到部署应用的主机上，通过执行命令行来观察主机资源占用的情况，比如CPU、硬盘、内存等；也可以通过观察应用的日志文件，来排查应用运行过程中的问题。

但是，当部署的节点数达到一定量，比如10个甚至更多，通过手工操作来监测主机便变成了一个不可能完成的任务。一方面，手工操作费时费力，重复性操作令人乏味；另一方面，也是最为重要的一点，手工操作加大出错的可能性。所以，把重复性的工作交给计算机来做是明智之举。采用成熟的分布式监控产品帮助你减少不必要的劳动，省心省力。你要做的只是设置必要的执行脚本或者报警阈值，分布式监控产品会自动帮你运维。当运维过程中监测到异常时，你会收到来自监控系统的告警通知。这样，让人主动去轮询排查运维问题，转变成了被动接收告警通知，从而大大解放了人力。

分布式监控常用技术

目前，市面上开源的监控产品比较多，功能也很丰富。比如，Nagios、Zabbix便是两款老牌的工业级的监控产品，可以胜任大部分的场景，包括硬件资源以及软件资源的监控。Consul和ZooKeeper则更加专注于服务的管理，比如服务的注册与发现、维护服务的高可用等。接下来将会对这些技术做详细的介绍。

Nagios

Nagios是一款开源的免费网络监视工具，致力于打造符合行业标准的IT基础架构的监控系统。Nagios提供了服务器、网络和应用的完整的IT监控和报警，可以有效监控Windows、Linux和UNIX的主机状态，以及交换机、路由器、打印机等网络设备。在系统或服务状态异常时可以发出邮件或短信报警，第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信进行通知。

Nagios的产品系列如下。

·Nagios XI：提供最强大的IT基础设施的监控和IT监控软件报警，适用于苛刻的组织级要求。

·Nagios Log Server：强大的企业级日志监控、管理和分析应用程序，允许企业快速、轻松地从所有的机器生成的日志数据里进行浏览、查询和分析。

·Nagios Network Analyzer：为商业级网络流量和带宽信息提供数据分析解决方案。Nagios Network Analyzer可以积极主动地解决故障、检测异常行为，并能在它们影响关键业务流程之前揭露其安全威胁。

·Nagios Fusion：整个基础设施监控的集中可视化工具。

·Nagios Core：IT监控软件的行业标准。Nagios Core引擎已经在网络基础设施监控领域成为行业标准长达十多年，提供强大的性能和灵活性。Nagios XI使用Nagios Core作为其基础核心组件。

在上述产品中，除了Nagios Core是开源、免费的产品，其他的都是商业软件。学习或者开发Nagios，了解Nagios Core是必不可少的，本节内容也主要围绕Nagios Core来展开。为了避免概念上的混淆，下文中所指的Nagios特指Nagios Core产品。

Nagios Core主要提供以下功能特性。

·监控网络服务（SMTP、POP3、HTTP、NNTP、PING等）。

·监控主机资源（处理器负荷、磁盘利用率等）。

·简单的插件设计使得用户可以方便地扩展自己服务的检测方法。

·并行服务检测机制。

·具备定义网络分层结构的能力，用“parent”主机定义来表达网络主机间的关系，这种关系可被用来发现和明晰主机宕机或不可达状态。

·当服务或主机产生问题以及问题解决时将告警通知发送给联系人（通过E-mail、短信或者用户定义方式）。

·具备定义事件句柄功能，它可以在主机或服务的事件发生时获取更多问题定位。

·自动的日志文件回滚。

·可以支持并实现对主机的数据冗余监控。

·可选的Web界面用于查看当前的网络状态、通知和故障历史、日志文件等。

Nagios Core的开源协议是GNU General Public License Version 2。

Zabbix

Zabbix是一个基于Web界面的提供分布式系统监控和网络监控功能的企业级开源解决方案。Zabbix能监视各种网络参数，保证服务器系统的安全运行，并提供

灵活的通知机制，让系统管理员可以快速定位以及解决存在的各种问题。

1.Zabbix简介

Alexei Vladishev创建了Zabbix项目，当前处于活跃开发状态，Zabbix SIA对其提供支持。

Zabbix是一个企业级的、开源的、分布式的监控套件。Zabbix可以监控服务器、虚拟机和网络设备的运行状况。Zabbix利用灵活的告警机制，允许用户对事件发送基于E-mail的告警通知，这样可以保证用户快速地对问题做出响应。

Zabbix提供了数据采集强大的性能和可扩展性；提供了Zabbix代理，让分布式监控得以实现；Zabbix带有一个基于Web的界面、安全的用户认证和灵活的用户权限架构；支持polling和trapping模式，与本地高性能代理协作，几乎可以收集来自流行的操作系统的所有数据；同时，也提供了无代理的监控方法。

Zabbix可以自动发现网络服务器和设备。

Zabbix是近乎零成本的，因为Zabbix的编写和发布基于GPL GeneralPublic License version 2协议，意味着源代码是免费发布的。当然，Zabbix公司也提供商业化的技术支持。

Zabbix是一个高度集成的网络监控套件，通过一个软件包即可提供以下特性。

·数据收集。

·可用性及性能检测。

·支持SNMP（trapping及polling）、IPMI、JMX、VMware等的监控。·自定义检测。

·自定义间隔来收集收据。

·通过server/proxy和agent来执行。

·灵活的阈值定义。

·允许灵活地自定义阈值，在Zabbix中称为触发器（Trigger），其存储在后端数据库中。

·高级告警配置

·可以发送自定义的升级计划、接收者及媒体类型的通知。

·通知信息可以配置并允许使用宏（Macro）变量。

·通过远程命令等实行自动化动作。

·Web监控功能。

·Zabbix可以按照在网站上模拟鼠标点击的路径来检查功能和响应时间。

·实时绘图。

·通过内置的绘图方法实现监控数据实时绘图。

·扩展的图形化显示。

·允许自定义创建多监控项的视图。

·网络拓扑（Network Maps）。

·自定义的面板和界面，并允许在控制面板页面显示。

·报告。

·高等级（商业）监控资源。·历史数据存储。

·数据存储在数据库中。

·历史数据可配置。

·内置数据清理机制。

·配置简单。

·通过添加监控设备方式来添加主机。

·只需在数据库中配置一次，就能长期监控。

·监控设备允许使用模板。

·模板使用。

·模板中可以添加组监控。

·模板允许继承。

·网络自动发现。

·自动发现网络设备。

·agent自动注册。

·自动发现文件系统、网卡设备、SNMP OID等。

·快速的Web界面。

·Web前端采用PHP编写。

·访问无障碍。

·你想怎么做就能怎么做。

·审计日志。

·Zabbix API。

·Zabbix API提供程序级别的访问接口，第三方程序可以很快接入。

·权限系统。·★ 安全的权限认证。

·★ 用户可以限制允许维护的列表。

·全特性、agent易扩展。

·★ 在被监控目标上进行部署。

·★ 支持Linux及Windows。

·二进制守护进程。

·★ C语言开发，高性能，低内存消耗。

·★ 易移植。

·具备应对复杂环境情况的能力。

·★ 通过Zabbix proxy可以非常容易地创建远程监控。

2.Zabbix对于容器的支持

随着容器技术越来越流行，用容器来安装应用已经越来越普遍。目前，以Docker镜像形式的容器来安装Zabbix已被支持。

下面是以Docker来安装、使用Zabbix的常见示例。

本示例演示如何运行MySQL版本的Zabbix server，其Zabbix Web界面基于NGINX Web服务器和Zabbix Java gateway。

（1）开启一个空的MySQL server实例如下。

# docker run --name mysql-server -t \
-e MYSQL_DATABASE="zabbix" \
-e MYSQL_USER="zabbix" \
-e MYSQL_PASSWORD="zabbix_pwd" \
-e MYSQL_ROOT_PASSWORD="root_pwd" \
-d mysql:5.7

（2）开启一个Zabbix Java gateway实例如下。

# docker run --name zabbix-java-gateway -t \
-d zabbix/zabbix-java-gateway:latest

（3）开启Zabbix server实例，并链接到创建的MySQL server实例如下。

# docker run --name zabbix-server-mysql -t \
-e DB_SERVER_HOST="mysql-server" \
-e MYSQL_DATABASE="zabbix" \
-e MYSQL_USER="zabbix" \
-e MYSQL_PASSWORD="zabbix_pwd" \
-e MYSQL_ROOT_PASSWORD="root_pwd" \
-e ZBX_JAVAGATEWAY="zabbix-java-gateway" \
--link mysql-server:mysql \
--link zabbix-java-gateway:zabbix-java-gateway \
-p 10051:10051 \
-d zabbix/zabbix-server-mysql:latest

（4）开启Zabbix Web实例，并链接到创建的MySQL server和Zabbix server实例。

# docker run --name zabbix-web-nginx-mysql -t \
-e DB_SERVER_HOST="mysql-server" \
-e MYSQL_DATABASE="zabbix" \
-e MYSQL_USER="zabbix" \
-e MYSQL_PASSWORD="zabbix_pwd" \
-e MYSQL_ROOT_PASSWORD="root_pwd" \
--link mysql-server:mysql \
--link zabbix-server-mysql:zabbix-server \
-p 80:80 \
-d zabbix/zabbix-web-nginx-mysql:latest

Consul

Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现、监控与配置。与其他分布式服务注册与发现的方案相比，Consul的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检测、Key-Value存储、多数据中心方案等，而且不再需要依赖其他工具（比如ZooKeeper等），使用起来也较为简单。Consul是用Go开发的，因此具有天然可移植性（支持Linux、Mac OS X、FreeBSD、Solaris和Windows）；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合。

1.Consul简介

Consul可以为基础设施提供服务发现和配置。其核心的功能如下。

·服务发现（Service Discovery）：Consul客户端提供了能被其他客户端诸如API或MySQL等发现的服务。使用DNS或HTTP，应用程序可以很容易地找到它们所依赖的服务。

·健康检测（Health Checking）：Consul客户端可以提供任何数量的健康检测，可以是给定服务，或是本地节点。此功能可以用来监控集群的通信情况。

·Key-Value存储：应用程序可以利用Key-Value存储，实现包括动态配置、功能降级、协调、领导人选举（Leader Election）等。简单的HTTP API使得它更易于使用。

·多数据中心（Multi Datacenter）：Consul支持开箱即用的多数据中心。

Consul的设计对DevOps社区和应用开发者来说非常友好，使得它非常适合现代的、弹性的基础设施。与其他同类型的产品相比，Consul具有以下优势。

·使用Raft算法来保证一致性，比复杂的Paxos算法更直接。相比较而言，ZooKeeper采用的是Paxos，而etcd使用的则是Raft。

·支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟、分片等情况。ZooKeeper和etcd均不提供对多数据中心功能的支持。

·支持健康检测，etcd不提供此功能。

·支持HTTP和DNS协议接口。ZooKeeper的集成较为复杂，etcd只支持HTTP。

·官方提供Web管理界面，etcd无此功能。

简单来说，相比ZooKeeper，Consul更轻量，依赖轻（Go与Java的对比），Raft算法要比Paxos算法简单得多，而且效率高。相比etcd，Consul提供了更多的功能，比如DNS server、多数据中心同步、Web界面等。

2.Consul架构

Consul是一个复杂的系统，该系统由许多不同的部件组成。图15-1所示是来自官方文档的Consul架构。

图15-1 Consul架构

首先，Consul支持多数据中心（Datacenter），从这个架构图中可以看到有两个数据中心，分别标记为“DATACENTER1”和“DATACENTER 2”。每个数据中心都是由server和client组成的。基于故障处理和性能平衡的考虑，建议有3~5个server。随着机器的增多，则consensus会越来越慢。对client没有限制，可以很容易地扩展到成千上万。同一个数据中心的所有节点都要加入Gossip协议，这意味着Gossippool包含给定数据中心的所有节点，原因如下。

·没有必要为client配置server、地址参数，发现是自动完成的。

·节点故障检测的工作不是放置在server上，而是分布式系统完成的。这使故障检测比心跳机制更具可扩展性。

·当重要的事件发生时，如leader election，可用来作为消息层的通知。

每个数据中心的server都属于一个Raft对等端。这意味着它们一起工作，在它们的中间选出一个leader。leader是有额外职责的，需要负责处理所有的查询和事务。事务也必须通过consensus协议复制到所有的伙伴中。由于这一要求，当非leader server接收到一个RPC请求时，会转发到集群的leader中。

server节点也作为WAN gossip pool的一部分。这个pool与LAN pool是不同的，它为具有更高延迟的网络响应做了优化，并且可能包含其他Consul集群的server节点。设计WAN gossip pool的目的是让数据中心能够以low-touch（低接触）的方式发现彼此。将一个新的数据中心加入现有的WAN Gossip中是很容易的。因为pool中的所有server都是可控制的，所以能够满足跨数据中心的要求。当一个server接收到不同的数据中心的要求时，它把这个请求转发给相应数据中心的任一server。然后，接收到请求的server可能会转发给本地leader。

多个数据中心之间是低耦合的，但由于需要满足故障检测、连接缓存和多路复用等需求，跨数据中心被设计为能够快速和可靠地响应请求。

ZooKeeper

ZooKeeper分布式服务框架是Apache Hadoop的一个子项目，主要用来解决分布式应用中经常遇到的一些数据管理问题，如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

1.ZooKeeper简介

正如ZooKeeper（动物园管理员）名称的含义，整个协调分布式系统（Coordinating Distributed Systems）就是一个动物园（Zoo），系统里面的各种组件被定义为各种动物（比如，Hadoop就是大象，Whirr就是飞鸟，Hive是蜜蜂，Pig是肥猪），而ZooKeeper在里面起协调管理作用。

ZooKeeper是分布式应用的高性能协调服务。它暴露了常见的服务——例如命名、配置管理、同步和组服务——在一个简单的界面，让你不必从头开始编写它们。它被设计为易于编程，使用与文件系统目录树结构类似的数据模型。ZooKeeper使用Java编写。

协调服务（Coordination Services）的开发是非常困难的。它们特别容易出错，比如会出现竞态条件和死锁。ZooKeeper的出现，正好缓解了分布式应用程序从头开始实施协调服务所产生的问题。

2.设计目标

ZooKeeper的设计目标。

·操作简单：ZooKeeper主要用来协调处理分布式任务（通过一个叫多层次的命名空间，这种命名空间类似于文件系统）。一个命名空间就是一个数据寄存器，称为znode，按照ZooKeeper的说法，多层次的命名空间就是文件与目录的关系。但ZooKeeper的数据保存在内存中，可以实现高吞吐量和低延迟。

·自我复制：像图15-2所示的这个分布式系统，ZooKeeper主要是在各个server间复制数据，ZooKeeper服务必须彼此知道对方的存在。它们维持一个内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数的ZooKeeper机器可以运行，ZooKeeper就可以提供正常的服务。

当一个Client需要的服务可通过TCP连接到一个server时，如果这个server挂掉了，它就会自动连接另一个server。

·有序：ZooKeeper通过更新一个计数器来反映ZooKeeper的事务顺序，子操作可以通过这个计数器来实现更高层次的抽象，例如原语同步。

·快速：ZooKeeper尤其在读取时表现的性能更为强悍，因为ZooKeeper service可以同时由很多机器提供，而且读的速度是写的速度的10倍。

图15-2 ZooKeeper系统示意

3.数据模型和多层次命名空间

ZooKeeper的多层次命名空间就像常见的文件系统，每个节点的路径是唯一的，如图15-3所示。

图15-3 ZooKeeper多层次命名空间

4.ZooKeeper节点和临时节点

ZooKeeper的节点是通过像树一样的结构来进行维护的，并且每一个节点通过路径来标示和访问。除此之外，每一个节点还拥有自身的一些信息，包括数据、数据长度、创建时间、修改时间，等等。从这样一类既含有数据，又作为路径标示的节点的特点中可以看出，ZooKeeper的节点既可以被看作一个文件，又可以被看作一个目录，它同时具有二者的特点。为了便于表达，一般使用znode来表示所讨论的ZooKeeper节点。具体地说，znode通过管理包含数据、访问控制列表（AccessControl List，ACL）、时间戳的版本号数据结构，来实现缓存生效以及协调更新。每当znode中的数据更新后，它所维护的版本号将增加，这非常类似于数据库中计数器时间戳的操作方式。

另外，znode还具有原子性操作的特点：命名空间中，每一个znode的数据将被原子地读写。读操作将读取与znode相关的所有数据，写操作将替换掉所有的数据。除此之外，每一个节点都有一个访问控制列表，这个访问控制列表规定了用户操作的权限。

ZooKeeper中同样存在临时节点。这些节点与session同时存在，当session生命周期结束，这些临时节点也将被删除。临时节点在某些场合也发挥着非常重要的作用。

5.有条件的update和watch

ZooKeeper支持watch的概念。client可以在znode上设置watch。当znode变更时，watch将被触发并移除。当watch被触发后，client就会收到一个数据包，说明znode已经改变了。如果在client和ZooKeeper server之间的连接被断开，则client将接收到本地通知。

6.保证

ZooKeeper的速度非常快，非常简单。为了支撑其更复杂的服务，提供了以下保证。

·顺序一致性（Sequential Consistency）：client更新后将在它们应用时按照顺序进行发送。

·原子性（Atomicity）：更新非成功即失败。

·单一系统映像（Single System Image）：一个client将看到相同的服务视图，而不管它连接到哪个服务器。

·可靠性（Reliability）：一旦更新已被应用，它会从那个时候开始一直持续，直到client再次更新为止。

·时效性（Timeliness）：该系统的client视图保证在一定时间内是最新的。

7.简单API

ZooKeeper提供了非常简单的编程接口，它仅支持以下操作。

·create：在树中的位置创建一个节点。·delete：删除一个节点。

·exists：测试一个节点是否出现在某个位置。

·get data：从一个节点读取数据。

·set data：写入数据到节点。

·get children：检索节点的子节点的列表。

·sync：等待数据被传播。

8.实现

图15-4展示了ZooKeeper服务的高层组件。除了请求处理器（Request Processor），构成ZooKeeper服务的每个服务器都有一个备份。

复制的数据库（Replicated Database）是一个内存数据库，包含整个数据树。为了可恢复，更新日志会被记录到磁盘，并且在更新这个内存数据库之前，先序列化到磁盘。

每个ZooKeeper server都为client提供服务。client只连接到一个server，并提交请求。读请求直接由本地的副本数据库提供数据。对服务状态进行修改的请求、写请求通过一个约定的协议进行通信。

作为这个协议的一部分，所有的写请求都被传送到一个叫“leader”的server，而其他的server叫作“follower”。follower从leader接收信息修改的提议，并决定是否同意进行修改。当leader发生故障时，协议的信息层（Messaging Layer）关注leader的替换，并同步到所有的follower。

图15-4 ZooKeeper服务的高层组件

ZooKeeper采用一个自定义的信息层原子操作协议，由于信息层的操作是原子性的，ZooKeeper能保证本地的副本数据库不会产生不一致。当leader接收到一个写请求时，它计算出写之后系统的状态，把它变成一个事务。