容器云平台监控架构的设计及优化Word文件下载.docx
《容器云平台监控架构的设计及优化Word文件下载.docx》由会员分享，可在线阅读，更多相关《容器云平台监控架构的设计及优化Word文件下载.docx（11页珍藏版）》请在冰豆网上搜索。
（2）Open-Falcon
Open-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，主要组件包括了：
1）Falcon-agent是用Go语言开发的Daemon程序，运行在每台Linux服务器上，用于采集主机上的各种指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等，目前已经支持200多项监控指标。
并且，Agent支持用户自定义的监控脚本。
2）Hearthbeatserver简称HBS心跳服务，每个Agent都会周期性地通过RPC方式将自己的状态上报给HBS，主要包括主机名、主机IP、Agent版本和插件版本，Agent还会从HBS获取自己需要执行的采集任务和自定义插件。
3）Transfer负责接收Agent发送的监控数据，并对数据进行整理，在过滤后通过一致性Hash算法发送到Judge或者Graph。
4）Graph是基于RRD的数据上报、归档、存储组件。
Graph在收到数据以后，会以rrdtool的数据归档方式来存储，同时提供RPC方式的监控查询接口。
5）Judge告警模块，Transfer转发到Judge的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。
这里为了避免重复告警引入了Redis暂存告警，从而完成告警的合并和抑制。
6）Dashboard是面向用户的监控数据查询和告警配置界面。
（3）Nagios
Nagios原名为NetSaint，由EthanGalstad开发并维护。
Nagios是一个老牌监控工具，由C语言编写而成，主要针对主机监控（CPU、内存、磁盘等）和网络监控（SMTP、POP3、HTTP和NNTP等），当然也支持用户自定义的监控脚本。
它还支持一种更加通用和安全的采集方式NREP（NagiosRemotePluginExecutor），它首先在远端启动一个NREP守护进程，用于在远端主机上面运行检测命令，在Nagios服务端用checknrep的plugin插件通过SSL对接到NREP守护进程执行相应的监控行为。
相比SSH远程执行命令的方式，这种方式更加安全。
（4）Prometheus
Prometheus是一个很受欢迎的开源监控和警报工具包，继Kubernetes之后成为第二个正式加入CNCF基金会的项目，2017年底发布了基于全新存储层的2.0版本，能更好地与容器云平台配合。
能实现docker
status、cAdvisor的监控功能，并且Prometheus原生支持Kubernetes监控，具有Kubernetes对象服务发现能力，Kubernetes的核心组件也提供了Prometheus的采集接口。
单个Prometheus可以每秒抓取10万的metrics，能满足一定规模下k8s集群的监控需求，并且具备良好的查询能力，提供数据查询语言PromQL，PromQL提供了大量的数据计算函数，大部分情况下用户都可以直接通过PromQL从Prometheus里查询到需要的聚合数据。
3.2方案对比并确定
通过以下方面对上述监控方案进行对比：
1）从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C语言转移到Go。
不得不说，Go凭借简洁的语法和优雅的并发，在Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。
2）从系统成熟度上看，Zabbix和Nagios都是老牌的监控系统，系统功能比较稳定，成熟度较高。
而Prometheus和Open-Falcon都是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。
3）从系统扩展性方面看，Zabbix和Open-Falcon都可以自定义各种监控脚本，并且Zabbix不仅可以做到主动推送，还可以做到被动拉取，Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力。
4）从数据存储方面来看，Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能，Nagios和Open-Falcon都采用RDD数据存储，Open-Falcon还加入了一致性hash算法分片数据，并且可以对接到OpenTSDB，而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。
5）从配置复杂度上看，Prometheus只有一个核心server组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦，尤其是Open-Falcon。
6）从社区活跃度上看，目前Zabbix和Nagios的社区活跃度比较低，尤其是Nagios，Open-Falcon虽然也比较活跃，但基本都是国内的公司参与，Prometheus在这方面占据绝对优势，社区活跃度最高，并且受到CNCF的支持，后期的发展值得期待。
7）从容器支持角度看，由于Zabbix和Nagios出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。
Open-Falcon虽然提供了容器的监控，但支持力度有限。
Prometheus的动态发现机制，不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。
Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。
而Nagios则在网络监控方面有广泛应用，伴随着容器的发展，Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。
总体来说，对比各种监控系统的优劣，Prometheus可以说是目前监控领域最锋利的“瑞士军刀”了。
4基于prometheus的容器云平台监控架构设计
4.1prometheus介绍
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。
于2016年加入CloudNativeComputingFoundation，作为继Kubernetes之后的第二个托管项目，具有强大的数据采集、数据存储、数据展示、告警等功能，天生完美支持kubernetes。
主要特点：
◎多维数据模型：
通过度量名称和键值对标识的时间序列数据
◎PromSQL：
一种灵活的查询语言，可以利用多维数据完成复杂的查询
◎不依赖分布式存储，单个服务器节点可直接工作
◎基于HTTP的pull方式采集时间序列数据
◎推送时间序列数据通过PushGateway组件支持
◎通过服务发现或静态配置发现目标
◎多种图形模式及仪表盘支持
组件：
◎Prometheus生态包括了很多组件，它们中的一些是可选的
◎Prometheus主服务器，用于抓取和存储时间序列数据
◎用于检测应用程序代码的客户端库
◎用于支持短声明周期的push网关
◎针对HAProxy，StatsD，Graphite，Snmp等服务的特定exporters
◎警告管理器
◎各种支持工具
多数Prometheus组件是Go语言写的，这使得这些组件很容易编译和部署。
4.2架构设计
（1）图片左侧是各种数据源主要是各种符合Prometheus数据格式的exporter，除此之外为了支持推动数据类型的Agent，可以通过Pushgateway组件，将Push转化为Pull。
Prometheus甚至可以从其它的Prometheus获取数据，组建联邦集群。
Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。
（2）图片上侧是服务发现，Prometheus支持监控对象的自动发现机制，从而可以动态获取监控对象。
（3）图片中间是Prometheus
Server，Retrieval模块定时拉取数据，并通过Storage模块保存数据。
PromQL为Prometheus提供的查询语法，PromQL模块通过解析语法树，调用Storage模块查询接口获取监控数据。
（4）图片右侧是告警和页面展现，Prometheus将告警推送到alertmanger，然后通过alertmanger对告警进行处理并执行相应动作。
数据展现除了Prometheus自带的webui，还可以通过grafana等组件查询Prometheus监控数据。
Prometheus支持使用联邦集群的方式，对Prometheus进行扩展。
如图，在每个集群（数据中心）部署单独的Prometheus，用于采集当前集群（数据中心）监控数据，并由上层的Prometheus负责聚合多个集群（数据中心）的监控数据。
这里部署多个联邦节点是为了实现高可用。
联邦集群的核心在于每一个Prometheus都包含一个用于获取当前实例中监控样本的接口/federate。
对于联邦Prometheus而言，无论是从其他的Prometheus实例还是Exporter实例中获取数据实际上并没有任何差异。
适用场景：
Prometheus在记录纯数字时间序列方面表现非常好。
既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。
对于现流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。
Prometheus是为服务的可靠性而设计的，当服务出现故障时，可以快速定位和诊断问题。
搭建过程对硬件和服务没有很强的依赖关系。
不适用场景：
（1）如果需要100％的准确度（例如按请求计费），Prometheus不是一个好的选择，因为收集的数据可能不够详细和完整。
在这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余监控。
（2）Prometheus只针对性能和可用性监控，默认并不具备日志监控等功能。
（3）Prometheus认为只有最近的监控数据才有查询的需要，本地存储的设计初衷只是保持短期（一个月）的数据，并非针对大量的历史数据的存储。
如果需要报表之类的历史数据，则建议使用远端存储。
（4）Prometheus没有定义单位，需要使用者自己去区分或者事先定义好监控数据单位。
4.3监控点有哪些
从容器云平台本身的业务需求分析来看，至少应该通过Prometheus获取到以下监控数据：
性能指标：
（1）容器相关的性能指标数据
container.cpu.utilization：
容器的cpu使用率
container.memory.utilization：
容器的memory使用率
（2）Pod相关的性能指标数据
pod.cpu.utilization：
pod的cpu使用率
pod.memory.utilization：
pod的memory使用率
（3）主机Node节点相关的性能指标数据
node.cpu.utilization：
主机的cpu使用率
node.memory.utilization：
主机的memory使用率
node.load.1：
主机过去1分钟的负载
node.load.5：
主机过去5分钟的负载
node.load.15：
主机过去15分钟的负载
node.resource.request.cpu.utilization：
主机的kubernetescpuresource使用率
node.resource.request.memory.utilization：
主机的kubernetesmemoryresource使用率
服务健康状态：
（1）Kubernetes集群服务的健康状态
ControlPlaneUP：
集群健康状态
（2）Kubernetes服务组件的健康状态
APIServerUP：
APIServer状态
ControllerManagerUP：
ControllerManager状态
SchedulersUP：
Schedulers状态
KubeletUP：
kubelet状态
Kube-proxyUP：
Kube-proxy状态
（3）主机Node节点的健康状态
NodeUP：
node节点的状态
（4）docker服务进程的健康状态
DockerUP：
Docker状态
（5）Deployment相关的健康状态
DeploymentReplicas：
deployment副本数
（6）Pod的健康状态
PodReady：
pod的状态
下面选取以上指标中的部分进行举例：
容器cpu使用率：
container_cpu_user_seconds_total{container_name="
jenkins"
endpoint="
https-metrics"
instance="
192.168.234.122:
10250"
job="
expose-kubelets-metrics"
namespace="
kube-ops"
node="
node1"
pod_name="
jenkins2-696b8fbdbb-hd9hm"
service="
}
主机过去5分钟的负载：
node_load5{endpoint="
metrics"
host_ip="
192.168.234.121"
instance="
192.168.234.121:
9796"
expose-node-metrics"
cattle-prometheus"
master"
pod="
exporter-node-cluster-monitoring-b4m72"
Deployment副本数：
kube_deployment_spec_replicas{deployment="
coredns"
http"
192.168.234.122"
192.169.1.249:
8080"
expose-kubernetes-metrics"
kube-system"
exporter-kube-state-cluster-monitoring-5c988dbc56-ckrz6"
service="
Pod的状态：
kube_pod_status_ready{condition="
true"
default"
toolbox-f95b876-mrkxn"
升级会员 