在现有监控系统下，如何进行容器云应用监控实施？

建议基于容器云定位选择合适的工具和方法，如果容器云将来会作为公司的业务系统运行基础支撑平台，建议纳入整体监控平台。如果仅仅是作为一个服务于某几项业务的简单工具，不需要投入太多

监控是运维体系中是非常重要的组成部分，通过监控可以实时掌握系统运行状态，对故障提前预警， 以及历史状态的回放，还可以通过监控数据为系统的容量规划提供辅助决策，为系统性能优化提供真实的用户行为和体验。为容器云提供良好的监控环境是保证容器服务的高可靠性、高可用性和高性能的重要部分，容器云监控的方案可以推荐几种:
（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）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远程执行命令的方式，这种方式更加安全。

（3）Prometheus
Prometheus是一个很受欢迎的开源监控和警报工具包，继Kubernetes之后成为第二个正式加入CNCF 基金会的项目，2017年底发布了基于全新存储层的2.0版本，能更好地与容器云平台配合。能实现docker status、cAdvisor的监控功能，并且Prometheus原生支持Kubernetes监控，具有Kubernetes对象服务发现能力，Kubernetes的核心组件也提供了Prometheus的采集接口。单个Prometheus可以每秒抓取10万的metrics，能满足一定规模下k8s集群的监控需求，并且具备良好的查询能力，提供数据查询语言PromQL， PromQL提供了大量的数据计算函数，大部分情况下用户都可以直接通过PromQL从Prometheus里查询到需要的聚合数据。

不知贵司现有监控系统的构成，如果没有上线prometheus的话，建议通过该软件搭建贵司的容器云应用监控，如果该软件自带的功能不满足需求，可以通过开发operator 来进行扩展。
如果贵司现有监控平台能增加功能菜单，可以把prometheus集成进去，这样监控运维同事比较容易统一查看。

容器监控数据采集可以使用目前最主流的prometheus，数据的处理以及和应用的关联需要由额外的监控处理平台来做。这个平台可以是现有的监控平台，但是需要针对容器的特点做改造，主要的思路是面相应用和K8S对象(如node、控制器、Pod、Container)，采用分层架构展示和管理（比如置维护，置生产），而不是传统的主机/IP地址。如果无法改造，就需要引入新的容器专用监控处理平台。

应用监测关注应用语言运行时、应用框架与业务代码；
Kubernetes 监测关注容器化应用的容器运行时、容器管控层与系统调用，两个监测均服务于应用，关注应用的不同层次，两个产品互为补充。Prometheus 是指标采集，存储，查询的基础设施，应用监测与 Kubernetes 监测的指标类数据均依赖 Prometheus。

        我们的项目是以Zabbix为基础监控工具设计和建设的，但鉴于prometheus对docker和k8s监控的天然集成，我们打算引入prometheus和Zabbix结合起来，prometheus只负责docker+K8S基础监控数据采集, Zabbix负责容器内应用监控数据采集，采集的数据集中接入Zabbix进行告警触发，并复用我们基于Zabbix开发的潜望者Zabbix运维管理平台，集中进行监控配置管理、阈值管理、巡检管理、数据对接等工作，大幅减少基于prometheus的定制开发工作，实现快速实现、高效部署的云平台整体监控。
按照容器监控的内容，我们分为 docker+K8S基础监控 和 容器内应用监控两部分来分别实现。

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

由于prometheus对docker和k8s监控的天然集成，通过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采集方式（对应着Statefulset部署方式），另一种是Push采集方式（对应着deployment部署方式）。

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

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

在银行等金融行业实际应用中，大多数容器云的监控并没有自成一体，而是对接了现有的监控系统，施行了统一监控。因为银行等金融行业，不仅有较新型的云原生业务，还有大量的传统业务；如果针对容器云单独建设一套监控体系，耗费的各种资源成本较高，也不利于统一管理。至于容器云相关监控是否要自成一体，还结合各个企业的实际的业务情况做决定。

基于EBPF技术的云原生监控能力应该是未来的主流了。

监控系统目前很多都是和K8S等用户集群部署在一起的，这种有它的优点，就是独立、简单，但缺点也明显，就是不能独立出来的话，当K8S用户集群挂了，自己也因部署在其中，自己也挂了。

所以一般需要对接到公司整体的监控平台。至于监控系统细节，这里不做过多细化，可参见网上其他资源。