CN112486634A - 一种实现容器云平台整体监控的方法 - Google Patents

Abstract

本发明涉及云计算和容器领域，具体提供了一种实现容器云平台整体监控的方法，其特征在于，包括docker+K8S基础监控和容器内应用监控两部分；所述docker+K8S基础监控中，通过cAdvisor获取docker基础监控数据，通过kube‑state‑metrics获取K8S的资源对象和对应监控数据；所述容器内应用监控通过Zabbix来实现监控。与现有技术相比，本发明能快速实现高效部署，从而简化容器云平台运维人员的工作，提供工作效率，节省了大量的人力成本，减少了开发周期。

Description

一种实现容器云平台整体监控的方法

技术领域

本发明涉及云计算和容器领域，具体提供一种实现容器云平台整体监控的方法。

背景技术

当前容器云成为IT的主要基础设施平台,以Docker为代表的容器技术，加上以Kubernetes为代表的容器编排技术，是目前最流行的容器云建设方案。云平台的特点是快速部署、弹性伸缩、动态调整、运维自动化，对应的监控也需要是动态发现、自动化部署的。

Zabbix是面向IP的监控，更适合与物理机/虚拟机环境的监控，可以通过开发自定义脚本采集数据从而实现各类型监控。

但是zabbix agent本身进程有限，agent进程按Server端配置串行取值，采集的效率决定于自定义脚本的执行效率，即使单个监控项采值很快，但若Host同时存在上千个agent类型监控项，还是会造成大部分agent监控项取值延迟，需根据监控项数量调整采值间隔优化。

发明内容

本发明是针对上述现有技术的不足，提供一种实用性强的实现容器云平台整体监控的方法。

本发明解决其技术问题所采用的技术方案是：

一种实现容器云平台整体监控的方法，包括docker+K8S基础监控和容器内应用监控两部分；

所述docker+K8S基础监控中，通过cAdvisor获取docker基础监控数据，通过kube-state-metrics获取K8S的资源对象和对应监控数据；

所述容器内应用监控通过Zabbix来实现监控。

进一步的，在docker+K8S基础监控中，在每个K8S集群上默认部署prometheus实现这部分监控采集，通过Zabbix Http Agent方式调用prometheus API来获取数据，接入Zabbix Server从而复用之前建设的功能。

作为优选，在容器内应用监控中的应用包括数据库、中间件或是某个应有系统，通过在容器中增加环境变量monitor_type来定义。

进一步的，在容器内应用监控中，在每个K8S集群上默认部署两种采集方式的Proxy容器，一种是Pull采集方式，对应着Stateful set部署方式；另一种是Push采集方式，对应着deployment部署方式。

进一步的，Pull的方式包括odbc的数据库监控、JMX的中间件监控和通过http方式实现的容器监控。

进一步的，在Pull的方式中用PVC持久化配置文件，若一个集群中有多个Proxy，则Proxy采集分工。

进一步的，Push的方式接受应用容器通过trapper方式主动推送过来的监控数据，这种方式的Proxy是无状态的

进一步的，Push的方式中，如果有多个Proxy，通过增加pod副本数横向扩展。

进一步的，Pull和Push方式采集到的数据都接入到Zabbix Server中。

本发明的一种实现容器云平台整体监控的方法和现有技术相比，具有以下突出的有益效果：

本发明能快速实现高效部署，从而简化容器云平台运维人员的工作，提供工作效率，节省了大量的人力成本，减少了开发周期。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

附图1是一种实现容器云平台整体监控的方法的流程示意图；

附图2是一种实现容器云平台整体监控的方法中Zabbix访问prometheus serverAPI获取数据流程示意图。

具体实施方式

为了使本技术领域的人员更好的理解本发明的方案，下面结合具体的实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例都属于本发明保护的范围。

下面给出一个最佳实施例：

如图1-2所示，本实施例中的一种实现容器云平台整体监控的方法，分为docker+K8S基础监控和容器内应用监控两部分来分别实现。

(1)docker+K8S基础监控的实现：

由于prometheus对docker和k 8s监控的天然集成，通过cAdvisor可以直接获取docker基础监控数据，通过kube-state-metrics可以直接获取K8S的资源对象和对应监控数据，因此我们在每个K8S集群上默认部署prometheus实现这部分监控采集，然后通过Zabbix Http Agent方式调用prometheus API来获取数据，接入Zabbix Server从而复用之前建设的功能，实现后续的告警阈值配置和数据接入集中监控平台。

(2)容器内应用监控的实现：

所有的应用监控我们都通过Zabbix实现，这里的“应用”可以是数据库、中间件、也可以是某个应用系统，通过在容器中增加环境变量monitor_type来定义，比如monitor_type＝mysql就代表这个容器的“应用”是mysql，我们将对它进行mysql监控。

在每个K8S集群上默认部署两种采集方式的Proxy容器，一种是Pull采集方式，对应着Stateful set部署方式；另一种是Push采集方式，对应着deployment部署方式。

Pull的方式包括基于odbc的数据库监控、JMX的中间件监控、还有通过http方式实现的容器监控，其中用到了PVC来持久化一些配置文件。如果一个集群中需要多个Proxy，则需要Proxy采集分工实现负载均衡。

Push的方式接受应用容器通过trapper等方式主动推送过来的监控数据，这种方式的Proxy是无状态的，因此如果需要多个Proxy，可以直接通过增加pod副本数横向扩展。

Push的方式接受应用容器通过trapper等方式主动推送过来的监控数据，这种方式的Proxy是无状态的，因此如果需要多个Proxy，可以直接通过增加pod副本数横向扩展。

两种方式采集到的数据也都是接入到Zabbix Server中。

(3)注意事项：

①因自动发现并监控容器内应用需要通过宿主机上agent监控脚本与容器交互取回被监控端口等信息，需在脚本中尽量减少宿主机与容器的交互次数，避免对容器造成影响。

②监控容器内应用时调用了api创建单独的应用Host及创建后查询Host状态，应合理设置lld Item频率，本身不需要频繁调用，确保监控保持有效状态即可。

③根据集群规模和采集数量，Prometheus需考虑在各集群的高可用和负载均衡设计架构。

其中，Prometheus具体部署方案为：

我们目前的K8S资源对象以及K8S集群内的容器性能监控底层采集是基于promethus的，监控指标包括容器性能指标(cpu、memory、filesystem、network)，K8S资源对象指标(node、pod、deployment、statefulset、service)。

每个K8S集群上默认部署prometheus，需要在K8S集群内部署prometheus server和kube-state-metrics两个组件：

prometheus server：负责采集和存储监控数据，同时提供HTTP API数据访问接口供zabbix使用。

kube-state-metrics：负责向prometheus server提供k8s集群级别的各种资源对象的监控数据。

Zabbix通过http agent方式访问prometheus server API获取数据。

具体方案：

1、启动default命名空间下的kubernetes enpoints和kubernetes service，这两个资源在获取cAdvisor监控数据过程中起到网络连通的作用，如果不启动，会导致prometheus无法获取到cAdvisor提供的监控指标数据。一般来说，这两个资源都是默认启动的。

2、集群中的每个工作节点需要启动kubelet，因为cAdvisor集成在kubelet中，如果不启动kubelet将无法采集到cAdvisor监控数据。一般来说，kubelet在各个节点是默认启动的。

3、Prometheus server部署(deployment方式)

对于prometheus server，需要满足以下条件

·使用statefulset类型的部署方式，以满足线上管理要求

·同时绑定ClusterIP类型的service和NodePort类型的service，以实现其既可以与集群内部通讯，又可以与集群外部通讯

·使用本地数据存储，以保证其时序数据库的数据安全不丢失

·prometheus服务所需要用的配置信息存储在ConfigMap中，以方便配置信息的变更

·同时部署configmap-reload容器，以便自动加载配置信息到prometheus服务(当ConfigMap有修改时)

4、kube-state-metrics部署(deployment方式)

对于kube-state-metrics，需要满足以下条件

·绑定ClusterIP类型的service，以便可以在集群内部访问(它不需要集群外部的访问)

·使用deployment类型的部署方式，以满足线上管理要求

5、Prometheus server服务发现配置

·prometheus server的配置文件中至少需要开启以下job

·Prometheus server需要启用kubernetes-nodes-cadvisor服务发现，用于容器指标数据的采集。

上述具体的实施方式仅是本发明具体的个案，本发明的专利保护范围包括但不限于上述具体的实施方式，任何符合本发明的一种实现容器云平台整体监控的方法权利要求书的且任何所述技术领域普通技术人员对其做出的适当变化或者替换，皆应落入本发明的专利保护范围。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (9)

1.一种实现容器云平台整体监控的方法，其特征在于，包括docker+K8S基础监控和容器内应用监控两部分；

所述docker+K8S基础监控中，通过cAdvisor获取docker基础监控数据，通过kube-state-metrics获取K8S的资源对象和对应监控数据；

所述容器内应用监控通过Zabbix来实现监控。

2.根据权利要求1所述的一种实现容器云平台整体监控的方法，其特征在于，在docker+K8S基础监控中，在每个K8S集群上默认部署prometheus实现这部分监控采集，通过ZabbixHttp Agent方式调用prometheus API来获取数据，接入Zabbix Server从而复用之前建设的功能。

3.根据权利要求2所述的一种实现容器云平台整体监控的方法，其特征在于，在容器内应用监控中的应用包括数据库、中间件或是某个应有系统，通过在容器中增加环境变量monitor_type来定义。

4.根据权利要求3所述的一种实现容器云平台整体监控的方法，其特征在于,在容器内应用监控中，在每个K8S集群上默认部署两种采集方式的Proxy容器，一种是Pull采集方式，对应着Stateful set部署方式；另一种是Push采集方式，对应着deployment部署方式。

5.根据权利要求4所述的一种实现容器云平台整体监控的方法，其特征在于，Pull的方式包括odbc的数据库监控、JMX的中间件监控和通过http方式实现的容器监控。

6.根据权利要求5所述的一种实现容器云平台整体监控的方法，其特征在于，在Pull的方式中用PVC持久化配置文件，若一个集群中有多个Proxy，则Proxy采集分工。

7.根据权利要求6所述的一种实现容器云平台整体监控的方法，其特征在于，Push的方式接受应用容器通过trapper方式主动推送过来的监控数据，这种方式的Proxy是无状态的。

8.根据权利要求7所述的一种实现容器云平台整体监控的方法，其特征在于，Push的方式中，如果有多个Proxy，通过增加pod副本数横向扩展。

9.根据权利要求8所述的一种实现容器云平台整体监控的方法，其特征在于，Pull和Push方式采集到的数据都接入到Zabbix Server中。

Images