容器平台如何和已有监控系统进行对接？这个架构如何规划设计？

首先监控是分层的，可以分为系统层面、应用层面、服务层面。

对于系统层面，主要是针对资源使用情况、网络连通性、节点健康情况的监控，传统的监控系统在这方面已经非常完备，我们直接可以利用传统的监控系统对容器平台的宿主机进行系统层面的监控，对接大屏幕等。至于单个容器本身使用的资源等，我个人觉得这些数据对进行弹性伸缩、迁移等容器平台内部动作是比较关心的，而对于外部资源监控意义不大，所以我个人认为多数场景下单个容器的资源使用情况、健康状况这样的信息没有多大必要送到外部的传统监控。系统层面的监控还有一层意思是容器平台本身的监控，即控制节点和相关服务的监控，这些在容器管理系统是必备的功能，用户可以根据需要决定是否需要把这部分信息上报到传统监控进行统一展示。

对于应用层面，容器平台本身通常都带有类似K8S的replication control这样的机制保持某个服务运行实例数量的能力，所以通常情况下容器平台都能保证应用和应用下每个微服务的运行正常。但我个人认为关于应用层面的健康监控，还是需要来对接传统的监控系统，进行适当的告警输出，例如当遇到应用逻辑错误而导致启动反复失败、或资源不足导致启动总是不成功等问题时，容器平台本身的replication control机制就不能解决问题了。这种情况就需要我们把应用的故障信息传递到传统监控，并根据问题的严重情况进行不同等级的告警通知等，由相关的应用人员介入来解决问题，比如升级补丁或回退等。那么怎样和传统监控的对接？方法就因用户的喜好而异了，例如可以写一个独立运行的程序，定时调用容器平台的接口，获得应用中每个微服务的当前实例数、预期实例数、应用的资源使用总量等，调用相应接口把数据传递到传统监控，在传统监控中设立告警策略，例如当运行实例数低于预期实例数持续2分钟后，抛出告警等。

对于服务层面，是监控应用提供的服务是否运行正常。例如某个提供WEB服务的应用，在一些时候虽然应用和应用中微服务的运行实例数量正常，但它的WEB服务已经失去响应，或者返回的是错误的状态，这种情况在多数容器平台中是无法监测到的，这个需要我们丰富容器故障的监测手段，或者自己编写服务访问+检测逻辑来判断，并把检测出现的问题上报到传统监控，在传统监控中设立相应的告警策略、告警等级。

可以参考以上内容回复！