DCOS监控模块设计

1、第 1 页 共 13 页DCOS 监控模块设计说明书初稿邹能人 第 2 页 共 13 页目目 录录DCOS监控系统.1系统架构设计说明书.1第一章第一章 现状与需求分析现状与需求分析 .51.1. 业务现状.51.1.1. 业务背景.51.1.2. 主要建设目标与任务.51.2. 需求分析.61.2.1. 监控需求.61.2.2. 需求综合分析.8第二章第二章 总体设计总体设计.92.1. 技术选型.92.1.1. Docker Stats.92.1.2. Cadvisor.102.1.3. Sensu.112.1.4. Scout.112.1.5. Sematext.112.1.6. Pro

2、metheus .122.2. 监控模块架构设计.132.2.1. 特性.132.2.2. 组件.132.2.3. 架构.13第三章第三章 监控模块功能与内容监控模块功能与内容.153.1. 目前监控功能.153.1.1. 集中监控管理.153.1.2. 统一监控管理界面与告警功能 .153.1.3. 自定义告警策略.153.2. 接口设计.15第 3 页 共 13 页第一章第一章 现状与需求分析现状与需求分析1.1.业务现状业务现状1.1.1.业务背景业务背景随着 DCOS 系统的逐渐成熟，DCOS 系统平台上线业务逐渐增多，依靠过去人工巡检系统的方式发现系统故障、潜在风险及安全隐患的方式效

3、率越来越低下且运维人员的工作强度及压力也在不断增加，为了提高发现系统故障的及时性、系统维护的专业性、规范化、科学性同时也能把运维人员从重复的工作中解放出来去做更多有意义的事情，因此我们亟需引入平台级的监控手段、工具来协助运维工程师解决当前的问题。建设以应用监控为核心，集成集群监控、主机监控、弹性告警等功能的企业级监控系统，在 DCOS 系统中采用统一技术手段实现应用的智能运行管理。1.1.2.主要建设目标与任务主要建设目标与任务为保证自有软件平台运行稳定性，对 DCOS 系统平台进行自动化监控，合理设置监控粒度及监控对象。尽可能的把潜在问题在萌芽状态解决及消除隐患，以此提高 DCOS 系统的安

4、全性与稳定性。监控模块的最终目标如下所示：1. 及时发现潜在的问题化被动为主动维护；2. 为平台性能优化提供直观参考依据；3. 提高系统维护的专业性和规范性；4. 提高用户体验，降低服务宕机时间。第 4 页 共 13 页1.2.需求分析需求分析1.2.1.监控需求监控需求.平台监控告警平台监控告警、集群监控指标集群内部组件的信息采集，下面只是事例，不局限于此：haproxy，采集 Haproxy 基础状态信息，比如 qcur、scur、rate 等nginx，采集 nginx 正常请求、异常请求、异常请求比例、请求平均响应时间、upstream 请求次数、平均响应时间等单台物理机

5、的监控信息目前所需如下：CPUuser 使用率、system 使用率、空闲率、总量Mem总量、使用率Swap总量、使用率Disk总量、使用率、IO 读写的数、量与时间Network网卡进出流量、进出包数、进出错包数、丢弃包数主机进程/以及进程之间的关系拓扑CPU、Mem、耗时、状态、用户等数据FileSystem总量、使用率等容器监控目前所需监控信息如下：CPUuser 使用率、system 使用率、空闲率、总量Mem总量、使用率Disk总量、使用率、IO 读写的数、量与时间Network网卡进出流量、进出包数、进出错包数、丢弃包数进程(容器内一般都为单进程)CPU、Mem、耗时、状态、用户等

6、数据、集群数据聚合单台机器的监控指标难以反应整个集群的情况，我们需要把整个集群的机器（体现为某个 HostGroup 下的机器）综合起来看。比如所有机器的 qps 加和才是整个集群的 qps，所有机器的 request_fail 数量 所有机器的 request_total 数量=整个集群的请求失败率。同样，单容器无法反应整个应用的情况，需要将应用所属的所有容器综合分析。、集群监控配置集群配置 和 策略配置监控集群的节点可操作，监控策略可配置、监控性能能够支持的监控集群大小以及采集间隔、平台级告警第 5 页 共 13 页告警触发条件可配、告警触发事件可配、提供告警级别设置、告警提示方式(邮件、

7、短信等、最好有接口)等.二、应用监控告警二、应用监控告警以下所述为 web 应用实例，但应用监控不仅限于此：1、应用拓扑2、应用健康度根据应用平均负载，应用平均访问延时，告警数量等指标进行综合评分后，计算出来的反映应用健康程度的分值。3、用户访问平均延时用户访问平均时延。4、数据库概况总占用空间：目前存储数据已使用的空间。总查询数：包括增，删，改，查的总访问量。慢查询数 ：导致慢查询的访问量。eplace 请求量 ：replace 请求的数量。insert 请求量 ：insert 请求的数量。delete 请求量 ：delete 请求的数量。select 请求量 ：select

8、请求的数量。update 请求量 ：update 请求的数量。当前连接数 ：当前连接到该 mysql 实例的连接数。连接使用率 ：已建立的连接数占最大连接数的百分比，不同类型的实例的最大连接数不同5、缓存概况表空间 ： 分配给当前业务的总空间已使用空间 ： 当前业务实际使用的空间总记录数 ： 当前应用存储的记录条数，key-value 对数 GET 次数 ： 按 5 分钟查询时表示最近 5 分钟内的读访问量。按天查询时取当天的峰值(次/秒)SET 次数 ： 按 5 分钟查询时表示最近 5 分钟内的写访问量。按天查询时取当天的峰值(次/秒)DELETE 次数 ： 按 5 分钟查询时表示最近 5

9、分钟内的写访问量。按天查询时取当天的峰值(次/秒)总次数 ： 按 5 分钟查询时表示最近 5 分钟内的 GET/SET/DELETE 访问量。按天查询时取当天的峰值(次/秒)超时次数 ： 按 5 分钟查询时表示最近 5 分钟内的 GET/SET/DELETE 超时次数。按天查询时取当天的峰值(次/秒)6、流量监控提供实时流量以及近期流量查询、展示功能7、用户体验监控访问量、时延与页面停留时长等第 6 页 共 13 页1.2.2.需求综合分析需求综合分析.需求边界的界定需求边界的界定需求边界的界定主要是以上任务目标中的模块的范围内，但不限于网络通讯、网络设置、服务器安置、客户端访问

10、地点、客户个性化使用习惯等。项目需求的边界的界定，其主要功能范围有以下内容：1、 监控数据的采集与发送，确保及时性与准确性2、 监控数据的分析以及更新相关数据模型为其他模块提供数据信息3、 可以进行历史数据的查询与维护工作4、 人机界面的友好操作5、 提供 RestApi 访问接口，便于客户端访问6、 可以为其他系统提供实时数据、事项数据、历史数据等各类查询操作接口7、 保证系统的健壮性与可靠性8、 告警参数的可配置9、 数据的备份与恢复第 7 页 共 13 页第二章第二章 总体设计总体设计2.1.技术选型技术选型这一章节我们来比较监控容器的常用工具。将基于以下标准评估这些工具： 1、易于部署

11、2、信息呈现的详细度3、整个部署过程中日志的聚集程度4、数据报警能力5、是否可以监控非 Docker 的资源6、成本2.1.1.Docker Stats我将讨论的第一个工具是 Docker 本身。你可能不知道 Docker 客户端已经提供了基本的命令行工具来检查容器的资源消耗。想要查看容器统计信息只需运行 docker stats CONTAINER_NAME。这样就可以查看每个容器的 CPU 利用率、内存的使用量以及可用内存总量。请注意，如果你没有限制容器内存，那么该命令将显示您的主机的内存总量。但它并不意味着你的每个容器都能访问那么多的内存。另外，还可以看啊都容器通过网络发送和接收的数据总

12、量。 $ docker stats determined_shockley determined_wozniak prickly_hypatiaCONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/Odetermined_shockley 0.00% 884 KiB/1.961 GiB 0.04% 648 B/648 Bdetermined_wozniak 0.00% 1.723 MiB/1.961 GiB 0.09% 1.266 KiB/648 Bprickly_hypatia 0.00% 740 KiB/1.961 GiB 0.04% 1.898 KiB/

13、648 B如果想要看到更为详细的容器属性，还可以通过 netcat，使用 Docker 远程 API 来查看（见下文）。发送一个 HTTP GET 请求/containers/CONTAINER_NAME，其中CONTAINER_NAME 是你想要统计的容器名称。在上述的例子中你会得到缓存、交换空间以及内存的详细信息。 总体评价：1. 易于部署程度： 2. 信息详细程度： 3. 集成度：无 4. 生成警报的能力：无 第 8 页 共 13 页5. 监测非 Docker 的资源的能力：无 6. 成本：免费 2.1.2. Cadvisor我们可以使用 docker stats 命令和远程 API 来

14、获取容器的状态信息。但是，如果你想要在图形界面中直接查看这些信息，那你就需要诸如 CAdvisor 这类的工具。CAdvisor 提供了早 docker stats 命令所显示的数据的可视化界面。运行以下 Docker 命令，并在浏览器里访问 http:/<your-hostname:8080/可以看到 CAdvisor 的界面。你将看到 CPU 的使用率、内存使用率、网络吞吐量以及磁盘空间利用率。然后，你可以通过点击在网页顶部的 Docker Containers 链接，然后选择某个容器来详细了解它的使用情况。 docker run -volume=/:/rootfs:ro -

15、volume=/var/run:/var/run:rw -volume=/sys:/sys:ro -volume=/var/lib/docker/:/var/lib/docker:ro -publish=8080:8080 -detach=true -name=cadvisor google/cadvisor:latestCAdvisor 是一个易于设置并且非常有用的工具，我们不用非要 SSH 到服务器才能查看资源消耗，而且它还给我们生成了图表。此外，当集群需要额外的资 源时，压力表（pressure gauges ）提供了快速预览。而且，与本文中的其他的工具不一样的是 CAdvisor是免费

16、的，并且还开源。另外，它的资源消耗也比较低。但是，它有它的局限性，它 只能监控一个 Docker 主机。因此，如果你是多节点的话，那就比较麻烦了，你得在所有的主机上都安装一个 CAdvisor，者肯定特别不方便。值得注意 的是，如果你使用的是Kubernetes，你可以使用 heapster 来 监控多节点集群。另外，在图表中的数据仅仅是时长一分钟的移动窗口，并没有方法来查看长期趋势。如果资源使用率在危险水平，它却没有生成警告的机制。如果 在 Docker 节点的资源消耗方面，你没有任何可视化界面，那么CAdvisor 是一个不错的开端来带你步入容器监控，然而如果你打算在你的容器中运行任 何关

17、键任务，那你就需要一个更强大的工具或者方法。 总体评价：第 9 页 共 13 页1. 易于部署程度： 2. 信息详细程度： 3. 集成度： 4. 生成警报的能力：无 5. 监测非 Docker 的资源的能力：无 6. 成本：免费 2.1.3. SensuScout 和 Datadog 提供集中监控和报警系统，然而他们都是被托管的服务，大规模部署的话成本会很突出。要运行 Sensu 服务器可以使用容器。这个容器会安装 sensu-server、uchiwa Web 界面、Redis、rabbitmq-server 以及 sensu-api。不幸的是 sensu 不支持Docker。但是，使用插件

18、系统，您可以配置支持容器指标以及状态检查。 Sensu 支持我们所有的评价标准，你可以对我们 Docker 容器和主机收集尽可能多的细节。此外，你能够聚合所有主机的值到一个地方，并对这些检查发出 警报。这些警报并没有 DataDog 或 Scout 的先进，因为你仅能够提醒单独的主机上检查失败。然而，Sensu 的大缺点是部署的难度。虽然我 已经使用 Docker 容器自动部署许多步骤，Sensu 仍然是一个需要我们安装，启动和分开维护 Redis、RabitMQ、Sensu API、uchiwa 与 Sensu Core 的复杂系统。此外，你将需要更多的工具，如 Graphite 来呈现指标

19、值以及生产部署需要定制容器，今天我已经使用了一个容器为了密码的安全以及 自定义的 SSL 证书。除了您重启容器后才能添加更多的检查，你将不得不重新启动 Sensu 服务，因为这是它开始收集新的标准的唯一途径。由于这些原因，我 对 Sensu 的在易于部署的评价相当的低。 评分：1、易于部署程度： 2、信息详细程度： 3、集成度： 4、生成警报的能力：支持但有限 5、监测非 Docker 的资源的能力： 6、成本：免费 2.1.4. ScoutScout 是一款监视服务，并不是一个独立的开源项目。它有大量的插件，除了 Docker 信息还可以吸收其他有关部署的数据。因此 Scout 算是一站式监

20、控系统，无需对系统的各种资源来安装各种不同的监控系统。 Scout 的一个缺点是，它不显示有关每个主机上单独容器的详细信息。此外，每个监控的主机十美元这样略微昂贵的价格也是是否选择 Scout 作为监控服务的一个考虑因素，如果运行一个有多台主机的超大部署，成本会比较高。2.1.5. SematextSematext 也是一款付费监控解决方案，计划收费方案是 3.5 美分/小时。同样也支持 Docker 监控，还包括对容器级事件的监测（停止、开始等等）和管理容器产生的日志。第 10 页 共 13 页2.1.6. Prometheus Prometheus 由 SoundCloud 发明，适合于监

21、控基于容器的基础架构。Prometheus 特点是高维度数据模型，时间序列是通过一个度量值名字和一套键值对识别。灵活的查询语言允许查询和绘制数据。它采用了先进的度量标准类型像汇总（summaries），从指定时间跨度的总数构建比率或者是在任何异常的时候报警并且没有任何依赖，中断期间使它成为一个可靠的系统进行调试。Prometheus 支持维度数据，你可以拥有全局和简单的指标名像container_memory_usage_bytes ，使用多个维度来标识你服务的指定实例。我已经创建了一个简单的 container-exporter 来收集 Docker 容器的指标以及输出给 Prometheu

22、s 来消费。这个输出器使用容器的名字，id 和 镜像作为维度。额外的 per-exporter 维度可以在 prometheus.conf 中设置。如果你使用指标名字直接作为一个查询表达式，它将返回有这个使用这个指标名字作为标签的所有时间序列。使用 Prometheus 的查询语言，你可以对你想的任何维度的数据切片和切块。如果你对一个给定名字的所有容器感兴趣，你可以使用一个表达式像container_memory_usage_bytesname=consul-server ，这个将仅仅显示 name = consul-server 的时间序列。像多维度的数据模型，来实现数据聚合、分组、过滤，不

23、单单是 Prometheus。OpenTSDB 和 InfluxDB 这些时间序列数据库和系统监控工具的结合，让系统监控这件事情变得更加的多元。特性：1、高维度数据模型2、自定义查询语言3、可视化数据展示4、高效的存储策略5、易于运维6、提供各种客户端开发库7、警告和报警8、数据导出Docker 兼容相比其他的数据库、系统、中间件监控，要复杂一些。由于需要表征不同 Container 的性能消耗，来了解不同应用的运行情况，所以数据的聚合、切片（分组）和过滤，在 Docker 监控中成为了必备功能。 除了监控 Docker 以外，DCOS 系统还需监第 11 页 共 13 页控其他组件，如果一个

24、工具在监控 Docker 同时能够监控其他组件，那就更好了，根据以上的对比，选择 Prometheus 与 Cadvisor 进行 DCOS 监控。2.2.监控模块监控模块架构设计架构设计Prometheus 是一个开源的系统监控和报警的工具包，最初由 SoundCloud 发布。2.2.1. 特性Prometheus 的主要特点是：1、多维数据模型（有 metric 名称和键值对确定的时间序列）2、灵活的查询语言3、不依赖分布式存储4、通过 pull 方式采集时间序列，通过 http 协议传输5、支持通过中介网关的 push 时间序列的方式6、监控数据通过服务或者静态配置来发现7、支持图表和 dashboard 等多种方式2.2.2. 组件Prometheus 包含多个组件，其中有许多是可选的：1、Prometheus 主服务器，用来收集和存储时间序列数据2、应用程序 client 代码库3、短时 jobs 的 push gateway4、基于 Rails