容器云平台监控架构的设计及优化
本文是2020容器云职业技能大赛架构师岗课程之《容器云平台监控架构设计及优化》的试读。 本次大赛学习平台由上百位来自用户社区及共创厂商的技术专家联手打造，是一场集学习、认证与比赛一体化的产业级学习运动。其中架构师岗课程共24个，完成课程学习+自测，获取岗位结业证书。具体请戳>>>学课程，拿认证！胜任容器云架构师的这些技能，你皆可掌握→
2020 容器云职业技能大赛架构师岗课程系列之——《容器云平台监控架构设计及优化》
课程出品人
吴涛，光大科技有限公司研发工程师。在金融科技行业从事技术研发，对云计算容器技术感兴趣，喜欢户外爬山，看书，狼人杀。2020 容器云职业技能大赛百位专家委员会成员。
随着容器化的大力发展，容器云平台已经基本由Kubernetes作为统一的容器管理方案。当我们使用Kubernetes进行容器化管理时，传统监控工具如Zabbix无法对Kubernetes做到统一有效的全面监控，全面监控Kubernetes也就成为我们需要探索的问题。使用容器云监控，旨在全面监控Kubernetes集群、节点、服务、实例的统计数据，验证集群是否正常运行并创建相应告警。本章旨在于介绍容器云平台监控的架构设计及优化。
监控是运维体系中是非常重要的组成部分，通过监控可以实时掌握系统运行状态，对故障提前预 警，以及历史状态的回放，还可以通过监控数据为系统的容量规划提供辅助决策，为系统性能优化提供真实的用户行为和体验。为容器云提供良好的监控环境是保证容器服务的高可靠性、高可用性和高性能的重要部分，通过对本章的学习，能够快速认识当前容器环境下都有哪些监控方案，并对主流的监控方案有一个系统的了解和认识。
4.7 性能优化与容量预估
试读章节：
1 概述
2 价值和意义
监控是运维体系中是非常重要的组成部分，通过监控可以实时掌握系统运行状态，对故障提前预警，以及历史状态的回放，还可以通过监控数据为系统的容量规划提供辅助决策，为系统性能优化提供真实的用户行为和体验。为容器云提供良好的监控环境是保证容器服务的高可靠性、高可用性和高性能的重要部分，通过对本章的学习，能够快速认识当前容器环境下都有哪些监控方案，并对主流的监控方案有一个系统的了解和认识。
3 监控方案选型
3.1 容器云监控方案有哪些
（1）Zabbix
Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。
Zabbix核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，除此之外，为了扩展监控项，Agent还支持执行自定义脚本。Server主要负责接收Agent发送的监控信息，并进行汇总存储，触发告警等。
Zabbix Server将收集的监控数据存储到Zabbix Database中。Zabbix Database支持常用的关系型数据库，如MySQL、PostgreSQL、Oracle等，默认是MySQL，并提供Zabbix Web页面（PHP编写）数据查询。
Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。所以从Zabbix 4.2版本后开始支持TimescaleDB时序数据库，不过目前成熟度还不高。
（2）Open-Falcon
Open-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，主要组件包括了：
1）Falcon-agent是用Go语言开发的Daemon程序，运行在每台Linux服务器上，用于采集主机上的各种指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等，目前已经支持200多项监控指标。并且，Agent支持用户自定义的监控脚本。
2）Hearthbeat server简称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，由Ethan Galstad开发并维护。Nagios是一个老牌监控工具，由C语言编写而成，主要针对主机监控（CPU、内存、磁盘等）和网络监控（SMTP、POP3、HTTP和NNTP等），当然也支持用户自定义的监控脚本。
它还支持一种更加通用和安全的采集方式NREP（Nagios Remote Plugin Executor），它首先在远端启动一个NREP守护进程，用于在远端主机上面运行检测命令，在Nagios服务端用check nrep的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.1 prometheus介绍
Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库。于2016年加入Cloud Native Computing Foundation，作为继Kubernetes之后的第二个托管项目，具有强大的数据采集、数据存储、数据展示、告警等功能，天生完美支持kubernetes。
主要特点：
◎ 多维数据模型：通过度量名称和键值对标识的时间序列数据
◎ PromSQL：一种灵活的查询语言，可以利用多维数据完成复杂的查询
◎ 不依赖分布式存储，单个服务器节点可直接工作
◎ 基于HTTP的pull方式采集时间序列数据
◎ 推送时间序列数据通过PushGateway组件支持
◎ 通过服务发现或静态配置发现目标
◎ 多种图形模式及仪表盘支持
组件：
◎ Prometheus生态包括了很多组件，它们中的一些是可选的
◎ Prometheus主服务器，用于抓取和存储时间序列数据
◎ 用于检测应用程序代码的客户端库
◎ 用于支持短声明周期的push网关
◎ 针对HAProxy，StatsD，Graphite，Snmp等服务的特定exporters
◎ 警告管理器
◎ 各种支持工具
多数Prometheus组件是Go语言写的，这使得这些组件很容易编译和部署。
4.2 架构设计
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：主机的kubernetes cpu resource使用率
node.resource.request.memory.utilization：主机的kubernetes memory resource使用率
服务健康状态：
（1）Kubernetes集群服务的健康状态
Control Plane UP：集群健康状态
（2）Kubernetes服务组件的健康状态
API Server UP：API Server状态
Controller Manager UP：Controller Manager状态
Schedulers UP：Schedulers状态
Kubelet UP：kubelet状态
Kube-proxy UP：Kube-proxy状态
（3）主机Node节点的健康状态
Node UP：node节点的状态
（4）docker服务进程的健康状态
Docker UP：Docker状态
（5）Deployment相关的健康状态
Deployment Replicas：deployment副本数
（6）Pod的健康状态
Pod Ready：pod的状态
下面选取以上指标中的部分进行举例：
容器cpu使用率：
instance="192.168.234.122:10250",
job="expose-kubelets-metrics",namespace="kube-ops",node="node1",
pod_name="jenkins2-696b8fbdbb-hd9hm",service="expose-kubelets-metrics"}
主机过去5分钟的负载：
node_load5{endpoint="metrics",host_ip="192.168.234.121",instance="192.168.234.121:9796",
job="expose-node-metrics",namespace="cattle-prometheus",node="master",
pod="exporter-node-cluster-monitoring-b4m72",service="expose-node-metrics"}
Deployment 副本数：
kube_deployment_spec_replicas{deployment="coredns",endpoint="http",host_ip="192.168.234.122",
instance="192.169.1.249:8080",
job="expose-kubernetes-metrics",namespace="kube-system",node="node1",
pod="exporter-kube-state-cluster-monitoring-5c988dbc56-ckrz6",
service="expose-kubernetes-metrics"}
Pod的状态：
kube_pod_status_ready{condition="true",endpoint="http",host_ip="192.168.234.122",
instance="192.169.1.249:8080",
job="expose-kubernetes-metrics",namespace="default",node="node1",
pod="toolbox-f95b876-mrkxn",service="expose-kubernetes-metrics"}
（试读章节完。篇幅所限，如需系统学习可以直接免费下载全文，学习中有疑问，可以参加在线辅导答疑。）
针对本课程社区已组织专家线上答疑活动：
学习过程中如有疑问，就扫描添加社区管理员为好友，加入到我们为您精心准备的学习班吧！有专家在线及时解答您在学习中的各种疑惑。
2020 容器云职业技能大赛
架构师岗课程系列
课程1：容器云解决方案架构设计及建设交付课程包括：容器云平台高可靠性设计容器云平台的稳定性设计容器云平台的安全性设计容器云平台的高可用设计容器云平台的性能设计容器云产品架构分析容器云平台网络架构设计、优化容器云平台存储架构设计、优化容器云平台监控架构设计、优化容器云平台安全合规规划设计
OpenShift中的NBU数据备份
容器云平台周边环境集成规划设计
OpenShift中使用Veritas Access存储识别以下二维码
了解更多”2020年容器云职业技能大赛“信息：
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场