常见的主要监控数据获取方式

监控与告警是运维小伙伴每天都会用到的平台能力，从使用频率这个维度看，监控告警类平台的使用频率要大于各类运维自动化系统。多数自动化运维系统是由例行维护动作触发，而监控告警类平台是 7×24 小时都要使用，运维人员每天收告警、查异常、确认异常、分析事件等都得靠它。

监控系统从实施的角度来看主要可以分为三类。

• 主动上报：通过在应用程序内部埋点，或者服务主动上报自身运行情况的方式，将运行状态同步至监控系统。这种方式就效果来说应该是最好的，只要应用能实现，想要什么指标都可以，缺点也比较明显，实施周期长。尽管大部分企业里最不缺的就是编码资源，但开发团队的“套路”我们都明白——需求要排期，催急了也伤感情，而且仅适用于自己能够掌控的系统，对于高度产品化的系统或硬件，可能无法通过此方式实现。

• 被动抓取：不用埋点，而是从外部探测或主动获取服务的运行情况，如通过 ping 或 ssh 等。行业内也自发形成了一些信息上报或获取机制，比如 SNMP、IPMI 等。此外还可以通过采集日志或客户端部署 agent 等方式实现，尽管也有一定的实施工作，但并不需要代码层的改动。

• 旁路捕获：通过镜像网络流量的方式，将系统之间的调用流量均镜像到专用设备或服务器，而后对接收到的流量进行解析和分析。这种方式听起来最简单，但是无法适用于所有场景，比如应用间传输通信都是加密流量，那么镜像设备必须能够对报文进行解密，否则就无法实现流量分析；又比如一些系统的状态变化本身不产生流量，那么此种方式就无法监控。因此，旁路捕获这种方式更多是用来做性能监控、业务级交易监控等。不过整体来看，因为该方式对现有应用系统以及网络结构的侵入性是最小的，因此对于较大型企业（历史包袱较重）来说，可能是投入最小、见效最快的一种。

对于上述提到的这几种监控方式，在实践过程中，具体怎么选、选哪种完全取决于企业自身的监控场景和需求。要了解监控的对象，找到监控基准指标，设定合理的告警阈值；要站在使用者的角度，全面梳理、分析监控场景，在抽象的基础上构建功能，力争满足大部分的使用者场景，解决实际的问题。