DCOS监控模块设计解析.docx
- 文档编号:12579943
- 上传时间:2023-06-06
- 格式:DOCX
- 页数:14
- 大小:124.79KB
DCOS监控模块设计解析.docx
《DCOS监控模块设计解析.docx》由会员分享,可在线阅读,更多相关《DCOS监控模块设计解析.docx(14页珍藏版)》请在冰点文库上搜索。
DCOS监控模块设计解析
DCOS监控模块
设计说明书初稿
邹能人
DCOS监控系统1
系统架构设计说明书1
第一章现状与需求分析5
1.1.业务现状5
1.1.1.业务背景5
1.1.2.主要建设目标与任务5
1.2.需求分析6
1.2.1.监控需求6
1.2.2.需求综合分析8
第二章总体设计9
2.1.技术选型9
2.1.1.DockerStats9
2.1.2.Cadvisor10
2.1.3.Sensu11
2.1.4.Scout11
2.1.5.Sematext11
2.1.6.Prometheus 12
2.2.监控模块架构设计13
2.2.1.特性13
2.2.2.组件13
2.2.3.架构13
第三章监控模块功能与内容15
3.1.目前监控功能15
3.1.1.集中监控管理15
3.1.2.统一监控管理界面与告警功能15
3.1.3.自定义告警策略15
3.2.接口设计15
第一章现状与需求分析
一.1.业务现状
一.1.1.业务背景
随着DCOS系统的逐渐成熟,DCOS系统平台上线业务逐渐增多,依靠过去人工巡检系统的方式发现系统故障、潜在风险及安全隐患的方式效率越来越低下且运维人员的工作强度及压力也在不断增加,为了提高发现系统故障的及时性、系统维护的专业性、规范化、科学性同时也能把运维人员从重复的工作中解放出来去做更多有意义的事情,因此我们亟需引入平台级的监控手段、工具来协助运维工程师解决当前的问题。
建设以应用监控为核心,集成集群监控、主机监控、弹性告警等功能的企业级监控系统,在DCOS系统中采用统一技术手段实现应用的智能运行管理。
一.1.2.主要建设目标与任务
为保证自有软件平台运行稳定性,对DCOS系统平台进行自动化监控,合理设置监控粒度及监控对象。
尽可能的把潜在问题在萌芽状态解决及消除隐患,以此提高DCOS系统的安全性与稳定性。
监控模块的最终目标如下所示:
1. 及时发现潜在的问题化被动为主动维护;
2. 为平台性能优化提供直观参考依据;
3. 提高系统维护的专业性和规范性;
4. 提高用户体验,降低服务宕机时间。
一.2.需求分析
一.2.1.监控需求
一.2.1.1.平台监控告警
①、集群监控指标
集群内部组件的信息采集,下面只是事例,不局限于此:
haproxy,采集Haproxy基础状态信息,比如qcur、scur、rate等
nginx,采集nginx正常请求、异常请求、异常请求比例、请求平均响应时间、upstream请求次数、平均响应时间等
单台物理机的监控信息目前所需如下:
CPU
user使用率、system使用率、空闲率、总量
Mem
总量、使用率
Swap
总量、使用率
Disk
总量、使用率、IO读写的数、量与时间
Network
网卡进出流量、进出包数、进出错包数、丢弃包数
主机进程/以及进程之间的关系拓扑
CPU、Mem、耗时、状态、用户等数据
FileSystem
总量、使用率等
容器监控目前所需监控信息如下:
CPU
user使用率、system使用率、空闲率、总量
Mem
总量、使用率
Disk
总量、使用率、IO读写的数、量与时间
Network
网卡进出流量、进出包数、进出错包数、丢弃包数
进程(容器内一般都为单进程)
CPU、Mem、耗时、状态、用户等数据
②、集群数据聚合
单台机器的监控指标难以反应整个集群的情况,我们需要把整个集群的机器(体现为某个HostGroup下的机器)综合起来看。
比如所有机器的qps加和才是整个集群的qps,所有机器的request_fail数量÷所有机器的request_total数量=整个集群的请求失败率。
同样,单容器无法反应整个应用的情况,需要将应用所属的所有容器综合分析。
③、集群监控配置
集群配置和策略配置
监控集群的节点可操作,监控策略可配置
④、监控性能
能够支持的监控集群大小以及采集间隔
⑤、平台级告警
告警触发条件可配、告警触发事件可配、提供告警级别设置、告警提示方式(邮件、短信等、最好有接口)等
一.2.1.2.二、应用监控告警
以下所述为web应用实例,但应用监控不仅限于此:
1、应用拓扑
2、应用健康度
根据应用平均负载,应用平均访问延时,告警数量等指标进行综合评分后,计算出来的反映应用健康程度的分值。
3、用户访问平均延时
用户访问平均时延。
4、数据库概况
总占用空间:
目前存储数据已使用的空间。
总查询数:
包括增,删,改,查的总访问量。
慢查询数 :
导致慢查询的访问量。
eplace请求量 :
replace请求的数量。
insert请求量 :
insert请求的数量。
delete请求量 :
delete请求的数量。
select请求量 :
select请求的数量。
update请求量 :
update请求的数量。
当前连接数 :
当前连接到该mysql实例的连接数。
连接使用率 :
已建立的连接数占最大连接数的百分比,不同类型的实例的最大连接数不同
5、缓存概况
表空间 :
分配给当前业务的总空间
已使用空间 :
当前业务实际使用的空间
总记录数 :
当前应用存储的记录条数,key-value对数
GET次数 :
按5分钟查询时表示最近5分钟内的读访问量。
按天查询时取当天的峰值(次/秒)
SET次数 :
按5分钟查询时表示最近5分钟内的写访问量。
按天查询时取当天的峰值(次/秒)
DELETE次数 :
按5分钟查询时表示最近5分钟内的写访问量。
按天查询时取当天的峰值(次/秒)
总次数 :
按5分钟查询时表示最近5分钟内的GET/SET/DELETE访问量。
按天查询时取当天的峰值(次/秒)
超时次数 :
按5分钟查询时表示最近5分钟内的GET/SET/DELETE超时次数。
按天查询时取当天的峰值(次/秒)
6、流量监控
提供实时流量以及近期流量查询、展示功能
7、用户体验监控
访问量、时延与页面停留时长等
一.2.2.需求综合分析
一.2.2.1.需求边界的界定
需求边界的界定主要是以上任务目标中的模块的范围内,但不限于网络通讯、网络设置、服务器安置、客户端访问地点、客户个性化使用习惯等。
项目需求的边界的界定,其主要功能范围有以下内容:
1、监控数据的采集与发送,确保及时性与准确性
2、监控数据的分析以及更新相关数据模型为其他模块提供数据信息
3、可以进行历史数据的查询与维护工作
4、人机界面的友好操作
5、提供RestApi访问接口,便于客户端访问
6、可以为其他系统提供实时数据、事项数据、历史数据等各类查询操作接口
7、保证系统的健壮性与可靠性
8、告警参数的可配置
9、数据的备份与恢复
第二章总体设计
二.1.技术选型
这一章节我们来比较监控容器的常用工具。
将基于以下标准评估这些工具:
1、易于部署
2、信息呈现的详细度
3、整个部署过程中日志的聚集程度
4、数据报警能力
5、是否可以监控非Docker的资源
6、成本
二.1.1.DockerStats
我将讨论的第一个工具是Docker本身。
你可能不知道Docker客户端已经提供了基本的命令行工具来检查容器的资源消耗。
想要查看容器统计信息只需运行dockerstats[CONTAINER_NAME]。
这样就可以查看每个容器的CPU利用率、内存的使用量以及可用内存总量。
请注意,如果你没有限制容器内存,那么该命令将显示您的主机的内存总量。
但它并不意味着你的每个容器都能访问那么多的内存。
另外,还可以看啊都容器通过网络发送和接收的数据总量。
$ docker stats determined_shockley determined_wozniak prickly_hypatia
CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
determined_shockley 0.00% 884 KiB/1.961 GiB 0.04% 648 B/648 B
determined_wozniak 0.00% 1.723 MiB/1.961 GiB 0.09% 1.266 KiB/648 B
prickly_hypatia 0.00% 740 KiB/1.961 GiB 0.04% 1.898 KiB/648 B
如果想要看到更为详细的容器属性,还可以通过netcat,使用Docker远程API来查看(见下文)。
发送一个HTTPGET请求/containers/[CONTAINER_NAME],其中CONTAINER_NAME是你想要统计的容器名称。
在上述的例子中你会得到缓存、交换空间以及内存的详细信息。
总体评价:
1.易于部署程度:
※※※※※
2.信息详细程度:
※※※※※
3.集成度:
无
4.生成警报的能力:
无
5.监测非Docker的资源的能力:
无
6.成本:
免费
二.1.2.Cadvisor
我们可以使用dockerstats命令和远程API来获取容器的状态信息。
但是,如果你想要在图形界面中直接查看这些信息,那你就需要诸如 CAdvisor这类的工具。
CAdvisor提供了早dockerstats命令所显示的数据的可视化界面。
运行以下Docker命令,并在浏览器里访问http:
//<your-hostname>:
8080/可以看到CAdvisor的界面。
你将看到CPU的使用率、内存使用率、网络吞吐量以及磁盘空间利用率。
然后,你可以通过点击在网页顶部的DockerContainers链接,然后选择某个容器来详细了解它的使用情况。
docker run \
--volume=/:
/rootfs:
ro \
--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:
latest
CAdvisor是一个易于设置并且非常有用的工具,我们不用非要SSH到服务器才能查看资源消耗,而且它还给我们生成了图表。
此外,当集群需要额外的资源时,压力表(pressuregauges)提供了快速预览。
而且,与本文中的其他的工具不一样的是CAdvisor是免费的,并且还开源。
另外,它的资源消耗也比较低。
但是,它有它的局限性,它只能监控一个Docker主机。
因此,如果你是多节点的话,那就比较麻烦了,你得在所有的主机上都安装一个CAdvisor,者肯定特别不方便。
值得注意的是,如果你使用的是Kubernetes,你可以使用 heapster来监控多节点集群。
另外,在图表中的数据仅仅是时长一分钟的移动窗口,并没有方法来查看长期趋势。
如果资源使用率在危险水平,它却没有生成警告的机制。
如果在Docker节点的资源消耗方面,你没有任何可视化界面,那么CAdvisor是一个不错的开端来带你步入容器监控,然而如果你打算在你的容器中运行任何关键任务,那你就需要一个更强大的工具或者方法。
总体评价:
1.易于部署程度:
※※※※※
2.信息详细程度:
※※
3.集成度:
※
4.生成警报的能力:
无
5.监测非Docker的资源的能力:
无
6.成本:
免费
二.1.3.Sensu
Scout和Datadog提供集中监控和报警系统,然而他们都是被托管的服务,大规模部署的话成本会很突出。
要运行Sensu服务器可以使用容器。
这个容器会安装sensu-server、uchiwaWeb界面、Redis、rabbitmq-server以及sensu-api。
不幸的是sensu不支持Docker。
但是,使用插件系统,您可以配置支持容器指标以及状态检查。
Sensu支持我们所有的评价标准,你可以对我们Docker容器和主机收集尽可能多的细节。
此外,你能够聚合所有主机的值到一个地方,并对这些检查发出警报。
这些警报并没有DataDog或Scout的先进,因为你仅能够提醒单独的主机上检查失败。
然而,Sensu的大缺点是部署的难度。
虽然我已经使用Docker容器自动部署许多步骤,Sensu仍然是一个需要我们安装,启动和分开维护Redis、RabitMQ、SensuAPI、uchiwa与SensuCore的复杂系统。
此外,你将需要更多的工具,如Graphite来呈现指标值以及生产部署需要定制容器,今天我已经使用了一个容器为了密码的安全以及自定义的SSL证书。
除了您重启容器后才能添加更多的检查,你将不得不重新启动Sensu服务,因为这是它开始收集新的标准的唯一途径。
由于这些原因,我对Sensu的在易于部署的评价相当的低。
评分:
1、易于部署程度:
※
2、信息详细程度:
※※※※
3、集成度:
※※※※
4、生成警报的能力:
支持但有限
5、监测非Docker的资源的能力:
※※※※※
6、成本:
免费
二.1.4.Scout
Scout是一款监视服务,并不是一个独立的开源项目。
它有大量的插件,除了Docker信息还可以吸收其他有关部署的数据。
因此Scout算是一站式监控系统,无需对系统的各种资源来安装各种不同的监控系统。
Scout的一个缺点是,它不显示有关每个主机上单独容器的详细信息。
此外,每个监控的主机十美元这样略微昂贵的价格也是是否选择Scout作为监控服务的一个考虑因素,如果运行一个有多台主机的超大部署,成本会比较高。
二.1.5.Sematext
Sematext也是一款付费监控解决方案,计划收费方案是3.5美分/小时。
同样也支持Docker监控,还包括对容器级事件的监测(停止、开始等等)和管理容器产生的日志。
二.1.6.Prometheus
Prometheus由SoundCloud发明,适合于监控基于容器的基础架构。
Prometheus特点是高维度数据模型,时间序列是通过一个度量值名字和一套键值对识别。
灵活的查询语言允许查询和绘制数据。
它采用了先进的度量标准类型像汇总(summaries),从指定时间跨度的总数构建比率或者是在任何异常的时候报警并且没有任何依赖,中断期间使它成为一个可靠的系统进行调试。
Prometheus支持维度数据,你可以拥有全局和简单的指标名像container_memory_usage_bytes ,使用多个维度来标识你服务的指定实例。
我已经创建了一个简单的 container-exporter 来收集Docker容器的指标以及输出给Prometheus来消费。
这个输出器使用容器的名字,id和镜像作为维度。
额外的per-exporter 维度可以在 prometheus.conf 中设置。
如果你使用指标名字直接作为一个查询表达式,它将返回有这个使用这个指标名字作为标签的所有时间序列。
使用Prometheus的查询语言,你可以对你想的任何维度的数据切片和切块。
如果你对一个给定名字的所有容器感兴趣,你可以使用一个表达式像container_memory_usage_bytes{name="consul-server"} ,这个将仅仅显示name=="consul-server" 的时间序列。
像多维度的数据模型,来实现数据聚合、分组、过滤,不单单是Prometheus。
OpenTSDB和InfluxDB这些时间序列数据库和系统监控工具的结合,让系统监控这件事情变得更加的多元。
特性:
1、高维度数据模型
2、自定义查询语言
3、可视化数据展示
4、高效的存储策略
5、易于运维
6、提供各种客户端开发库
7、警告和报警
8、数据导出
Docker兼容相比其他的数据库、系统、中间件监控,要复杂一些。
由于需要表征不同Container的性能消耗,来了解不同应用的运行情况,所以数据的聚合、切片(分组)和过滤,在Docker监控中成为了必备功能。
除了监控Docker以外,DCOS系统还需监控其他组件,如果一个工具在监控Docker同时能够监控其他组件,那就更好了,根据以上的对比,选择Prometheus与Cadvisor进行DCOS监控。
二.2.监控模块架构设计
Prometheus是一个开源的系统监控和报警的工具包,最初由SoundCloud发布。
二.2.1.特性
Prometheus的主要特点是:
1、多维数据模型(有metric名称和键值对确定的时间序列)
2、灵活的查询语言
3、不依赖分布式存储
4、通过pull方式采集时间序列,通过http协议传输
5、支持通过中介网关的push时间序列的方式
6、监控数据通过服务或者静态配置来发现
7、支持图表和dashboard等多种方式
二.2.2.组件
Prometheus包含多个组件,其中有许多是可选的:
1、Prometheus主服务器,用来收集和存储时间序列数据
2、应用程序client代码库
3、短时jobs的pushgateway
4、基于Rails/SQL的GUIdashboard
5、特殊用途的exporter(包括HAProxy、StatsD、Ganglia等)
6、用于报警的alertmanager
7、命令行工具查询
大多数的组件都是用Go来完成的,使得它们方便构建和部署。
二.2.3.架构
下图说明了Prometheus和它的组件的整体架构:
Prometheus通过直接或者短时jobs中介网关收集监控数据,在本地存储所有收集到的数据,并且通过定义好的rules产生新的时间序列数据,或者发送警报。
Promdash或者其他使用API的clients可以将采集到的数据可视化。
第三章监控模块功能与内容
三.1.目前监控功能
三.1.1.集中监控管理
负责收集和处理来自系统中的各类告警信息,并进行告警信息的汇聚和根源分析,帮助运维人员找出故障发生的原因,快速定位故障点并包含网络、主机、数据库及应用管理(系统软硬件配置信息、系统性能指标、故障告警和日志管理)。
三.1.2.统一监控管理界面与告警功能
通过布局合理的图形化界面集中反映(集群、单节点、应用)的网络、系统、数据库和应用的实时状态,通过页面进行告警。
三.1.3.自定义告警策略
一般的监控到的结果是成功或者失败,如Ping不通、访问网页出错、连接不到Socket,发生时这些称之为故障,故障是最优先的告警。
除此之外,还能监控到返回的延时、内容等,如Ping返回的延时、访问网页的时间、访问网页取到的内容等。
利用返回的结果可以自定义告警条件,如Ping监控的返回延时一般是10-30ms之间,当延时大于100ms时候,表示网络或者服务器可能出现问题,引起网络响应慢,需要立即检查是否流量过大或者服务器CPU太高等问题。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- DCOS 监控 模块 设计 解析