本篇文章，将给大家分享有道容器服务API监控方案，这个方案同时具有轻量级和灵活性的特点，很好地体现了Kubernetes集群化管理的优势，解决了静态配置的监控不满足容器服务监控的需求。并做了易用性和误报消减、可视化面板等一系列优化，目前已经超过80%的容器服务已经接入了该监控系统。
—1—背景Kubernetes已经成为事实上的编排平台的领导者、下一代分布式架构的代表，其在自动化部署、监控、扩展性、以及管理容器化的应用中已经体现出独特的优势。
在Kubernetes容器相关的监控上，我们主要做了几块工作，分别是基于Prometheus的Node、Pod、Kubernetes资源对象监控，容器服务API监控以及基于Grafana的业务流量等指标监控。
在物理机时代，我们做了分级的接口功能监控——域名级别接口监控和机器级别监控，以便在某个机器出现问题时，我们就能快速发现问题。
上图中，左边是物理机时代对应的功能监控，包括域名级别接口监控和3台物理机器监控。右边是对应的Kubernetes环境，一个Service的流量会由Kubernetes负载均衡到pod1，pod2，pod3中，我们分别需要添加的是Service和各个Pod的监控。
由于Kubernetes中的一切资源都是动态的，随着服务版本升级，生成的都是全新的Pod，并且Pod的IP和原来是不一样的。
综上所述，传统的物理机API不能满足容器服务的监控需求，并且物理机功能监控需要手动运维管理，为此我们期望设计一套适配容器的接口功能监控系统，并且能够高度自动化管理监控信息，实现PodAPI自动监控。
—1—技术选型为了满足以上需求，我们初期考虑了以下几个方案。
手动维护各个Service和Pod监控到目前物理机使用的PodMonitor开源监控系统。
重新制定一个包含Kubernetes目录树结构的系统，在这个系统里面看到的所有信息都是最新的，在这个系统里面，可以做我们的目录树中指定服务的发布、功能监控、测试演练等。
沿用PodMonitor框架，支持动态获取Kubernetes集群中最新的服务和Pod信息，并更新到监控系统中。
方案分析
针对方案一，考虑我们服务上线的频率比较高，并且Kubernetes设计思想便是可随时自动用新生成的Pod（环境）顶替原来不好用的Pod，手动维护Pod监控效率太低，该方案不可行。
第二个方案应该是比较系统的解决办法，但需要的工作量会比较大，这种思路基本全自己开发，不能很好的利用已有的功能监控系统，迁移成本大。
于是我们选择了方案三，既能兼容我们物理机的接口功能监控方案，又能动态生成和维护Pod监控。
—3—整体设计思路Kubernetes监控包括以下几个部分：
Kubernetes容器监控整体构成
其中API功能监控，是我们保证业务功能正确性的重要监控手段。
通常业务监控系统都会包含监控配置、数据存储、信息展示、告警这几个模块，我们的API功能监控系统也不例外。
我们沿用APIMonitor框架功能，并结合了容器服务功能监控特点，和已有的告警体系，形成了我们容器API功能监控系统结构：
API监控系统模块组成
首先介绍下目前我们物理机使用的APIMonitor监控：
一个开源的框架：
转载请注明：http://www.0431gb208.com/sjszyzl/533.html
