在Cloudfoundry V1版本中，所有的基础服务都是由CF平台本身来维护，每个服务有两个重要组件：gateway,node 。 因此CF平台本身对这两个组件提供了很好的支持支持与监控，所有监控数据通过collector组件来统一获取与发送。
然而遵循一个更加开发的原则，在Cloudfoundry V2版本中，CF平台本身不在维护与管理所有的基础服务，而是交由第三方去搭建与维护这些服务，而平台本身仅仅提供了与这些第三方服务沟通的一个桥梁，也就是Service_broker, 因此平台本身也就不再提供对这些基础服务的监控, 自然Collector组件中也无法再获取到对这些基础服务的监控。
针对目前这种情况，个人认为可监控的对象包含两个部分：
(1) Service_broker：
对Servcie-broker的监控主要是为了获取： 服务的方案数信息、服务的实例信息(能否创建服务实例、最多可创建服务实例数、当前已创建服务实例数、健康的服务实例数等)、服务绑定的应用数信息等等。
(2) 自搭建的服务系统 ： 例如mysql服务的话就是一个mysql集群
对子搭建服务系统监控主要是为了获取： 整个服务系统健康状态、服务系统中各个模块指标数据信息等等。
对于Service_broker监控数据采集方案：
方案一：
在service_broker项目内部，编写代码将需要监控的数据直接发送到监控系统。
方案二：
在service_broker项目内部，连接CF平台中的NATS组件，将监控数据信息发布到NATS中，然后同时修改Collector组件源码，在collector组件中订阅servce-broker发布的消息，由Collector组件统一获取监控数据发送到监控
方案一，实现更加简单直接，但是service_broker作为CF平台中的一部分，缺乏统一管理意识。
方案二，实现略微复杂，符合CF平台内部统一的原则，并且平台中所有监控数据统一出口，便于统一管理。
对于自搭建监控服务系统监控：
使用指标采集器，采集系统监控数据发往监控系统，该部分采集较为独立。
OK，略微整理，工作进行中....
723
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
