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

分布式监控概述

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

分布式监控应用场景

如果你所处的项目，是单机的部署的应用，或者节点数不超过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接收到一个写请求时，它计算出写之后系统的状态，把它变成一个事务。

1. 下篇文章给大家讲解的是分布式系统开发实战： 分布式监控，实战：基于ZooKeeper的服务注册和发现；
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持!