编者按：InfoQ 开设新栏目“品味书香”，精选技术书籍的精彩章节，以及分享看完书留下的思考和收获，欢迎大家关注。本文节选自林帆著《CoreOS 实践之路》中的章节“CoreOS 综合案例”，介绍了CoreOS 在分布式系统监控中的应用。
6.1.1 案例说明
6.1.1.1 案例背景
在一个运行着数十上百种应用服务的集群的运维和应用设计中常常会遇到这样的需求：服务状态的收集，如何在集群的任意节点上快速地获取到整个集群中任意一个服务的状态呢？
这是典型的大型分布式服务监控任务。传统的解决方案一般都需要引入一个额外的监控系统，例如 Nagios。这些监控工具通常会使用一个集中的数据收集和存储节点，然后利用在每个节点上的客户端收集定制数据，并发送回收集节点进行统一处理和展示，其余节点如果需要集群状态，就要到这个收集节点上获取。此外，对于容器化应用，还需要在制作容器时就将收集服务数据的客户端打包到容器里面，从而对容器内容造成侵入性。另一些解决方案是让监控的客户端安装在每个主机节点上，通过 Docker 服务获取容器的运行状态。这种方法比较适合采集基本的容器数据信息，例如 CPU、内存、磁盘访问等，而不便于对具体的服务进行定制信息收集。
在这个案例中，需要考虑如下几个分布式服务监控的具体特性。
- 硬件故障的可能性，监控服务的系统不应该存在单点依赖的情况。
- 被监控服务运行的节点、数量均不确定，因此设计的系统应该具备足够的灵活性。
- 当被监控服务由于故障而转移到新的节点上运行时，监控应该能够继续正常进行。
6.1.1.2 方案分析
在 CoreOS 系统中，数据存储和分发的任务已经有 Etcd 能够解决，而定时采集监控的工具可以用 Fleet 配置一个服务脚本来完成，因此，用户只需要设计好监控数据的收集方法就足够了。
此外，在 CoreOS 系统中，被监控的分布式服务程序本身可以通过 Fleet 来管理。为了避免集中收集数据引入单点故障问题，数据的收集也应该采用分布式的方式，在被监控服务所在的节点上就近采集，然后直接保存到 Etcd 中。为此，可以通过 Fleet 中的服务依赖管理功能，为每个被监控的服务配备一个额外的“秘书服务”，这个服务就跟随着被监控的应用服务在节点间同时启动，同时迁移，同时记录下被监控服务的实时状态。这样便省去了传统的集中收集数据时判断哪个节点当前运行哪些服务的麻烦。
收集数据的定制会包含很多针对具体业务场景相关的细节，不具有普遍共性。为了不偏颇特别的应用场景，在这个例子中，采用一个最简单的服务作为监控的目标：一个 Apache HTTP 服务器的默认页面地单纯地检查 HTTP 服务是否可用。监控这个简单的服务，除了收集数据的方法以外，与监控一个复杂的服务并没有任何差别。通过这个例子，我们将体会到 Etcd 与 Fleet 搭配的轻量级服务组合能够为集群管理带来的便利性。
6.1.2 方案实施
6.1.2.1 容器化被监控的服务
由于 Docker 和 Rkt 等容器具备了集群镜像分发的特性，将服务容器化能够使得普通的服务通过 Fleet 的协助获得更好的跨节点调度能力。
特别是对于运行在 CoreOS 系统上的服务，由于系统的只读分区不可修改，加上系统本身十分精简，许多不常用的依赖库或软件都无法找到。若不通过容器运行，许多服务都难以运行起来。作为模拟被监控服务的目的，我们直接使用 Docker 官方仓库里的 Apache 镜像，并编写相应的服务 Unit 模板文件来运行服务的实例。
将以下文件保存为 apache@.service，放到 /etc/systemd/system/ 目录中。
[Unit] Description= 运行在 %i 端口上的 Apache HTTP Web 服务 # 需要依赖的服务 Requires=etcd.service Requires=docker.service # 依赖的启动顺序 After=etcd.service After=docker.service [Service] # 第一次运行下载镜像较耗时，为了防止误判，关闭启动的超时判定 TimeoutStartSec=0 # 关闭 Systemd 在结束服务时杀死同 CGroup 进程的操作 # 这个操作对 Docker 托管的服务不适用，会误杀 Docker 后台守护进程 KillMode=none # 读取 CoreOS 的公共环境变量文件 EnvironmentFile=/etc/environment # 启动的命令，使用 -= 符号表示忽略 docker kill 和 docker rm 运行时的错误 ExecStartPre=-/usr/bin/docker kill apache.%i ExecStartPre=-/usr/bin/docker rm apache.%i ExecStartPre=/usr/bin/docker pull httpd ExecStart=/usr/bin/docker run --name apache.%i -p ${COREOS_PUBLIC_IPV4}:%i:80 httpd # 结束的命令 ExecStop=/usr/bin/docker stop apache.%i [X-Fleet] # 不要在同一个服务器节点上运行多个 Apache 服务 Conflicts=apache@*.service
在第 3 章中我们已经介绍了 Unit 模板文件，在上面这个模板文件中，使用 @后面的参数作为运行时监听的端口号。在实际的应用中这是一种推荐的做法，因为它能够使得管理服务时可以很方便地通过服务名称找到服务监听的端口号。
上面模板文件中的注释已经比较详细了。这个模板文件可以适用于大多数通过 Docker 托管的服务。下面再简单介绍一下这个模板中的几个部分，以便用户修改这个模板以适应具体业务场景的需求。
首先，在 Unit 段中，Requires 列出了这个服务需要依赖的其他用户或系统服务的名字，然后用 After 和 Before（这里没有）等关键字指明这些服务的启动顺序。CoreOS 会等待所有写在 After 区域的服务启动完成后再运行当前服务，同时在当前服务启动完成后，唤起所有写在 Before 区域的其他服务。
然后，在 Service 段中，设置了两个特别的参数“TimeoutStartSec=0”和“KillMode=none”。前一个配置之前提到过，主要是防止 Docker 在第一次启动时由于下载镜像时间较长，被 Systemd 认为失去响应而误杀；后一个配置是因为 Docker 的每个容器都托管于同一个守护进程下面，默认在服务停止后 Systemd 会尝试杀死所有属于同一 CGroup 下的进程，此时它会尝试去清理 Docker 的后台进程，结果是要么 Docker 的守护进程意外结束，要么 Systemd 始终依然认为进程没有清理干净，导致下一次启动同名的容器时出现莫名的问题。
配置“EnvironmentFile=/etc/environment”是属于 CoreOS 特有的用法，在 CoreOS 系统中，/etc/environment 文件默认包含了服务器节点的公网 IP 地址和内网 IP 地址，这个文件中的变量是在每次系统启动时写入的。
$ cat /etc/environment COREOS_PRIVATE_IPV4=172.31.14.97 COREOS_PUBLIC_IPV4=##.##.##.## <- 演示目的，隐藏实际地址
CoreOS 下的许多服务都会使用这个配置文件，这个模板后面用到的变量 COREOS_ PUBLIC_IPV4 就来自于这个文件。
最后，在 X-Fleet 段中，可以看到这里配置的“Conflicts=apache@*.service”让与当前服务相同的服务进程不要调度到当前这个节点上。这样做是为了实现服务的高可用性，在出现单节点故障的时候，确保其他相同的服务是运行在集群中不同的节点上的，整个集群仍然能够继续对外提供服务。在实际应用时，还需要加上反向代理作为负载均衡节点，从而屏蔽后端服务调度对用户访问造成的影响。
对于一般的应用服务而言，这个模板的配置基本是通用的。
6.1.2.2 使用 Fleet 和 Etcd 监控服务状态
这次内容的主角，秘书服务（暂且想象她是一位貌美如花的女子）出场了。我们来一睹它的芳容。
[Unit] Description= 监控运行在 %i 端口上的 Apache 服务运行状态 # 需要依赖的服务 Requires=etcd.service Requires=apache@%i.service # 依赖的启动顺序 After=etcd.service After=apache@%i.service BindsTo=apache@%i.service [Service] # 读取 CoreOS 的公共环境变量文件 EnvironmentFile=/etc/environment # 服务意外终止时自动重启 Restart=on-failure RestartSec=0 # 启动的命令 # 检测被监控的服务是否运行正常，并将检测的结果用 etcdctl 写入 Etcd 记录中 ExecStart=/bin/bash -c '\ while true; do \ curl -f ${COREOS_PUBLIC_IPV4}:%i; \ if [ $? -eq 0 ]; then \ etcdctl set /services/apache/${COREOS_PUBLIC_IPV4} \'{"host": "%H", "ipv4_addr": ${COREOS_PUBLIC_IPV4}, "port": %i}\' --ttl 30; \ else \ etcdctl rm /services/apache/${COREOS_PUBLIC_IPV4}; \ fi; \ sleep 20; \ done' # 结束的命令 ExecStop=/usr/bin/etcdctl rm /services/apache/${COREOS_PUBLIC_IPV4} [X-Fleet] # 服务运行在与它所监控的 Apache 服务相同的主机上 ConditionMachineOf=apache@%i.service
这个文件应该被命名为 apache-secretary@%i.service 并存放到 /etc/systemd/system/ 目录中。如果读完这个文件依然觉得这个秘书长得有点抽象，下面就具体分析一下这个 Unit 文件内容。
首先，不难看出，它也是一个 Unit 模板（使用了 %i 占位符）。
然后，它的 Unit 段使用了一个特别的限定：BindsTo=apache@%i.service。这个关键字表明，这个秘书服务需要随着它监控的 Apache 应用服务一起被停止和重启。这一点很必要，否则这个秘书就无法正确地汇报所监控的服务状态了。
接下来，Service 段中的 ExecStart 和 ExecStop 的内容是需要重点说明的地方，待稍后慢慢道来。
最后，X-Fleet 段指明这个服务要与对应的服务始终保持在同一个主机节点上，这使得秘书服务能够直接就近获得服务状态，而不用去查找当前被监控服务运行的节点。
这样看来，最麻烦的地方无非就是上面这段乱糟糟的 ExecStart 命令了。先大略地打量一下，这个地方和 ExecStop 里面都使用了 etcdctl，它们应该是比较关键的内容，先提出来看看。
在 ExecStart 中的这个命令，是往 Etcd 数据服务的 /services/apache/ 目录下写入了一个以当前 Apache 服务所在 IP 地址命名的键，而键的内容就是秘书所记录的服务信息，包括服务所在的主机名、公网 IP 地址和监听的公网网卡端口号。最后的 TTL 设置是其中的精彩之处，它确保了当整个服务失效或被迁移到其他节点上时，这条记录会在 30 秒内被清除。
etcdctl set /services/apache/${COREOS_PUBLIC_IPV4} \'{"host": "%H", "ipv4_addr": ${COREOS_PUBLIC_IPV4}, "port": %i}\' --ttl 30;下面这个命令在 ExecStart 和 ExecStop 中各出现了一次，它的参数比较清晰，就是移除 /services/apache/ 下面刚才写入的那个键。
etcdctl rm /services/apache/${COREOS_PUBLIC_IPV4};在 ExecStart 命令的最外层，使用一个“while true”循环将整个执行的命令包裹起来，因此除非外部因素结束这个秘书服务，否则监控的任务就不会停止。在服务本身出现故障失联时，它将会跟随着被监控服务一起停止、一起被迁移，然后又一起在新节点上继续提供服务。
再往下看，有一个“sleep 20”的行，也就是说，在被监控服务运行正常的情况下，每隔 20 秒秘书就会刷新一次服务状态信息（虽然在这个例子里只有 IP 地址、端口这些比较固定的信息，但在实际情况中所监控的信息可能不止这些）。这也使得在正常情况下，Etcd 中的数据永远不会由于 TTL 的超时而被清除。
至此，这个 ExecStart 的意思也就大致清晰了。其中还没有被提到的那行 curl 命令，以及“etcdctl set”中需要记录的内容就是实际监控服务需要定制的部分。这个例子里的 Apache 其实是监控的最简单情况。
简单归简单，但稍加思考就不难发现一个问题，要求用户自己管理启动两个有依赖顺序的服务？显然这里有些不合理的地方。
6.1.2.3 关联秘书服务
刚刚在写 Apache 应用服务时，由于还没有秘书的存在，我们只考虑了应用服务自己的启动依赖。然而，一个合理的需求是，当应用服务启动时，相应的秘书服务也应该自动启动。还记得上面 apache-secretary@%i.service 文件中的 BindsTo 那行吗？事实上，单有这个配置只能够实现这个服务随着相应的 Apache 服务停止和重启，当 Apache 启动时，由于秘书服务的进程还不存在，这里的 BindsTo 是不会生效的。因此，还需要向 Apache 服务中加上秘书服务的依赖，以及指定启动顺序。
# Requirements Requires=etcd.service Requires=docker.service Requires=apache-secretary@%i.service # 增加这行，指明依赖服务名称 # Dependency ordering After=etcd.service After=docker.service Before=apache-secretary@%i.service # 增加这行，指定依赖启动顺序
现在只要服务自身启动了，Fleet 就会在同一个节点上为它分配一个独立的秘书服务。
6.1.2.4 启动服务
在第 4 章中，已经介绍过在 Fleet 中启动 Unit 模板的方法，只需要在 Fleet 命令中的模板名参数的 @符号后面加上相应的标识字符串就可以运行服务的实例了。由于我们在模板中使用了这个标识字符串作为服务在容器外暴露的端口号（这是一种很常用的技巧），因此这个字符串应该使用一个小于 65525 的数字表示。例如：
$ fleetctl submit apache@.service apache-secretary@.service $ fleetctl load apache@8080.service apache-secretary@8080.service $ fleetctl start apache@8080.service
最后一步执行“fleetctl start”的时候只需要指定一个 Apache 服务就足够了，它的监控秘书服务会在 Apache 服务之后自动被 Fleet 触发。
6.1.2.5 服务状态
启动完成以后，可以用 fleetctl 检查一下集群中运行的所有服务。
$ fleetctl list-units | grep apache UNIT MACHINE ACTIVE SUB apache-secretary@8080.service 14ffe4c3… /172.31.14.97 active running apache@8080.service 14ffe4c3… /172.31.14.97 active running
还可以再注册一个 Apache 服务到集群中，它会自动运行到不同的节点上（由于 apache@.service 文件中的 Conflicts 配置）。
$ fleetctl load apache@8081.service apache-secretary@8081.service $ fleetctl start apache@8081.service $ fleetctl list-units | grep apache UNIT MACHINE ACTIVE SUB apache-secretary@8081.service 1af37f7c... /172.31.14.95 active running apache-secretary@8080.service 14ffe4c3... /172.31.14.97 active running apache@8081.service 1af37f7c... /172.31.14.95 active running apache@8080.service 14ffe4c3... /172.31.14.97 active running
现在，在集群中的任意一个节点上，通过 Etcd 都可以轻松地获得集群中每一个 Apache 服务的信息。
$ etcdctl ls /services/apache/ /services/apache/172.31.14.97 /services/apache/172.31.14.95 $ etcdctl get /services/apache/172.31.14.95 { "host": "core01", "ipv4_addr": "172.31.14.95", "port": "8081" }
6.1.2.6 模拟故障情景
最后我们快速地模拟一下这种情况，即有一部分应用服务挂了。
将一个服务停止（或者直接杀死，不过那样它会到别的节点上自动重启，可能观察不到效果），按照上面的设计，记录在 Etcd 中的信息应该在 30 秒后由于 TTL 超时而被删除。
$ fleetctl stop apache@8080.service $ fleetctl list-units UNIT MACHINE ACTIVE SUB apache-secretary@8080.service 14ffe4c3... /172.31.14.97 inactive dead apache-secretary@8081.service 1af37f7c... /172.31.14.95 active running apache@8080.service 14ffe4c3... /172.31.14.97 inactive dead apache@8081.service 1af37f7c... /172.31.14.95 active running
现在，再来查询一次服务状态，可以看到记录的 Apache 服务只剩下 172.31.14.95 节点的 8081 端口的那个了。
$ etcdctl ls /services/apache/ /services/apache/172.31.14.95 $ etcdctl get /services/apache/172.31.14.97 Error: 100: Key not found (/services/apache/172.31.14.97)
6.1.3 案例延伸
6.1.3.1 为模板实例建立链接
在做这个案例的测试时，如果手工启动每个服务和相应的秘书服务还是相对比较麻烦的。由于 Fleet 启动使用了模板服务必须明确地指定标识字符串，因此总是需要在启动命令参数里面明确地写出每个服务的名称和标识，并且管理起来并不十分方便。
相比之下，由于非模板的 Unit 文件每个都是独立的实体，可以使用通配符（*）来一次启动在同一个目录下的多个 Unit 服务。因为每个服务对应了磁盘上一个真实的 Unit 文件，那么可不可以使用链接文件来给同一个模板创建多个带标识字符串的别名来代替呢？
下面我们来做个测试，为每个服务模板创建三个以带标识字符串的完整服务实例名称命名的链接文件。
$ ln -s templates/apache@.service instances/apache@8082.service $ ln -s templates/apache@.service instances/apache@8083.service $ ln -s templates/apache@.service instances/apache@8084.service $ ln -s templates/apache-secretary@.service instances/apache-secretary@8082.service $ ln -s templates/apache-secretary@.service instances/apache-secretary@8083.service $ ln -s templates/apache-secretary@.service instances/apache-secretary@8084.service
然后用通配符启动这个目录下的所有链接文件。
$ fleetctl start instances/* Unit apache@8082.service launched on 14ffe4c3... /172.31.14.97 Unit apache@8083.service launched on 1af37f7c... /172.31.14.95 Unit apache@8084.service launched on 9e389e93... /172.31.14.93 Unit apache-secretary@8082.service launched on 14ffe4c3... /172.31.14.97 Unit apache-secretary@8083.service launched on 1af37f7c... /172.31.14.95 Unit apache-secretary@8084.service launched on 9e389e93... /172.31.14.93
可以看到，Fleet 欣然接受了这些通过链接创建的替身文件，并正确地将链接文件的标识字符串用于配置相应的应用服务启动。实际上，这种给每个要启动的具体应用实例创建一个链接到真实模板的方式恰恰是 CoreOS 官方推荐的使用模板方式，它将原本仅仅体现在启动参数里面的服务标识固化为一个个随时可见、可管理的链接，为管理服务提供了很大的便利。
6.1.3.2 数据的处理与展示
在这个案例的最后，所有的监控数据都还是以键值对的形式保持在 Etcd 的配置存储空间中的。这样的数据虽然得以持久和方便地查询，但却显得既不直观也不友好。
在实际的应用中，一般会对这类有意义的数据进行进一步的处理和展示。例如计算实时的集群服务健康状况，在特定条件下触发报警，或者将数据以图标的形式更清晰地提供给使用者。这些工作虽然没有在这个案例中进行详细讨论，但却是评判一套数据监控方案实用性的重要方面。CoreOS 对数据的处理与展示并没有提供什么特别的工具，所有的工作都需要由用户通过 Etcd API 额外编码实现。
我们在第 5 章中已经介绍了 Etcd API 的使用，基于这些 RESTful 的接口实现用户自己的 Web 页面的监控工具并不是什么难事，由于具体界面设计与实际应用的业务场景十分相关，通用性不高，这里不做详述。
6.1.4 案例总结
在这个案例中，虽然我们仅仅设计了一个单纯的 HTTP 服务的监控，然而随着需要监控的服务数量的增加和集群中服务的流动（节点间迁移）增多，案例中监控策略的复杂度并不会显著地增加，算得上是因为简单所以可靠。分布在各个节点上的秘书服务能够很好地适应被监控服务的动态变化，并且对被监控服务具有很低的入侵性（不会限制服务运行在哪里），因此当应用场景变得复杂化、分布化时，其优势会比传统的集中式管理策略体现得更加明显。从本质上说，这是在用分布式的思想来解决分布式的问题，因此显得得心应手，驾轻就熟。
书籍介绍
本书是一本介绍 CoreOS 操作系统使用和周边技术的入门实践类书籍。本书内容分为三个主要部分。第一部分 （第 1 章）主要介绍 CoreOS 的基本概念和系统的安装，为后续各个组件的使用做好铺垫工作；第二部分（第 2~6 章）主要介绍 CoreOS 中 * 核心的内置 组件，通过这些组件，使用者能够完成大部分 CoreOS 的日常操作和开发任务；第三部分（第 7~9 章）主要针对 CoreOS 中一些比较进阶的话题以及组件 进行更具体的讲解，并介绍一些 CoreOS 使用技巧。
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论