IT运维监控体系初识

1.IT 运维监控体系概述

IT 运维包括了很多方面，比如安装部署、配置管理、运维监控等。有句话说，“无监控，不运维”，可见运维监控在 IT 运维中的重要。本文就着重聊聊运维监控体系。IT 运维监控体系可以从三个对象维度去划分：性能（Metrics）、链路（Traces）、日志（Logs），参考图 1、图 2、图 3、图 4 所示：

图 1：企业 IT 运维的三个维度

来源：爱数学院

图 2：三个维度的表现形式

来源：爱数学院

图 3：三个维度解决的不同问题

来源：爱数学院

图 4：如何利用三个维度解决问题

（来源：爱数学院）

Metrics 是最早期的运维关注点，其主要关注系统是否发生了问题，属于红海市场。

Traces 是处于高速发展阶段，其主要关注系统发生问题的链路及源头，主要使用 APM（Application Performance Management，简称 APM）工具，通过对关键业务系统进行监测、告警与优化，不断改善业务可靠性与稳定性，为客户提供良好的服务，提升核心竞争力。

Logs 相对而言，能够获得更多的安全、运维甚至运营信息，其主要关注的是系统发生问题的原因，所以门槛比较高，是目前相对的蓝海市场。

2. Metrics

说起 Metrics，不得不提到Zabbix，这是一款开源的运维工具，支持分布式监控，为广大互联网企业所使用。Zabbix 的监控原理就是和监控对象建立通讯，进行数据采集。其通讯的方式包括 agent、SSH/telnet、SNMP（常用于网络设备，比如交换机）、IPMI（常用于电源、风扇等）、JMX（常用于 JVM 虚拟机）。Zabbix 的缺点在于底层是采用了数据库存储，所以不是很适合大量频繁地存储或读取日志（侧重点还是在 Metrics）。另外，Zabbix 对容器、微服务的监控能力较弱。

除了 Zabbix，目前常见的还有Nagios、Cacti、Prometheus等。随着这几年云原生的兴起，擅长云原生监控的 Prometheus 受到了大家的欢迎。而阿里云也适时地推出了ARMS Prometheus，全面对接开源 Prometheus 生态，支持类型丰富的组件监控，提供多种开箱即用的预置监控大盘，且提供全面托管的 Prometheus 服务。当然，Prometheus 仍然是 Metrics 层面的，告警功能并不算完美，更谈不上分析功能了。

3. Traces

随着企业业务的发展，规模扩大，业务越来越多，所采用的组件也越来越多开始走向分布式化，如微服务、消息收发、分布式数据库、分布式对象存储、分布式缓存、跨域调用等，这些组件共同构成了繁杂的分布式网络，一个业务请求可能会涉及到几个、几十个服务的协同处理，这种情况下，我们需要使用能动态展示服务的链路，能分析服务链路的瓶颈并对其进行调优，能快速定位故障链路的的运维工具。由此，APM 工具就应运而生了。APM 工具既可以监控前端的譬如移动端 APP、浏览器，也可以监控应用后端。

APM 的数据获取一般通过探针埋点，又称 Agent 方式来获取。这种方式能够提供非常完整与细粒度的监控数据采集，提供代码级的问题定位。但此方式对应用有侵入性，如果埋点代码异常，会对应用本身的性能和稳定性产生影响。该方式可以再细分为两类：代码侵入式和字节码增强式。前者代表的产品有Zipkin、cat。后者代表的产品有 PinPoint，skywalking。产品的比较可以参考如下：

《调用链选型之 Zipkin，Pinpoint，SkyWalking，CAT》

《全链路追踪技术选型：pinpoint vs skywalking》

《监控系统比较 Skywalking Pinpoint Cat zipkin》

近年来，国内以 SaaS 模式提供 Traces 监控的厂商也崭露头角，虽然也是通过探针埋点的方式获取数据，但其商业模式已经发生了变化。目前国内比较知名的厂商有听云、云智慧、OneAPM等。

另外，不通过探针埋点获取数据的 APM 工具也逐渐兴起，国内代表的产品有RStone。其获取数据的方式主要采用旁路部署，不对网络拓扑、系统等进行任何改变，也不用安装任何软件，只需要在关键节点上旁路部署设备，参考图 5 所示：

图 5：RStone 监控方式

(来源：RStone 官网）

4. Logs

传统运维监控主要还是 Metrics，近年来开始重视 Traces，但是上述两种仍然存在以下一些问题：

监控断层 ——IT 基础设施的监控和应用层的监控不通，或由不同的团队来监控

缺乏统一 —— 根据监控对象不同，监控工具各不相同

告警泛滥 —— 缺乏告警收敛、故障治愈等智能运维手段

通过 Logs，可以有效地解决上述问题。目前市面常见的工具有 Splunk、ELK、日志易、AnyRobot。

Splunk，日志监控产品的佼佼者，主要就是针对公司的日志文件进行分析，通过它，可以快速的通过一个 Centralized Application 进行各种各样的统计和查询，同时也可以产生各种报告，方便大家对整个数据进行性能评估。不仅是数据量，而且还有查询速度，查询方便程度，统计报告等各种各样你可能想到的功能。不仅是公司的日志文件分析，它目前作为一家面向企业端客户的 SaaS 企业，为客户在搜索、监视、分析和解释各种机器生成的大量数据提供软件解决方案。不止 IT 公司，DevOps 解决方案，还有电信、能源、金融、政府等各个领域。Splunk 的优秀吸引了鼎鼎大名的 ARK 的木头姐曾在一天豪掷 5500 万美元，在 ARK 的四大 ETF 中同时加仓 Splunk。

但 Splunk 并不是强大到不可战胜的。Splunk 产品使用涉及到多个组件及工具，每一个组件会涉及到收费，成本较高。成熟的商业开源正逐步蚕食 Splunk 的市场，其中最著名的就是 ELK。

ELK，ElasticSearch，Logstash，Kibana 的缩写，分别提供搜索，数据接入和可视化功能，构成了 Elastic 的应用栈。虽然这三个都是单独的开源项目，但它们实际上在 Elastic 的同一屋檐下为所有组件提供了极具凝聚力的路线图，其检索结果的评分机制更是优于 Splunk。由于是开源的，所以得到了许多开发力量的支持，相较于 Splunk，ELK 给开发者更好的参与感。

在国内市场上，同样存在着两款优秀的日志监控产品 —— 日志易和 AnyRobot，两者都是基于日志的大数据运维分析产品，其区别罗列一部分如下：

日志易可谓是 Splunk 的忠实模仿者，一直在模仿，但从未超越。AnyRobot 基于 ELK 开发，充分发挥了 ELK 的优势。

日志易的产品形态包括软件版和 SaaS 版，AnyRobot 不仅有软件版和 SaaS 版，还有一体机版。

日志易的计费模式是按照数据流量收费，AnyRot 的收费按照用户实际需要分析的数据量所消耗的计算单元进行收费。

日志易在数据流管理方面有单独的产品 “数据工厂”，AnyRobot 这块有空白。

日志易在金融行业的案例较多，AnyRobot 在政府、教育、医疗行业的案例较多。

日志易在涉密行业销售有阻碍，AnyRobot 具有在涉密行业销售的通行证。

日志易对抗 Splunk 的方式是替换策略，研发和 Splunk 体验感类似的产品来代替 Splunk，AnyRobot 的方式是纳管策略，不替换但可以纳管 Splunk。

5. 结尾

Metrics 监控仍然是目前大部分运维正在做的主要工作，Zabbix 等工具还将继续沿用。

基于 Traces 乃至基于 Logs 的监控运维会越来越被重视和接受，传统运维监控正在向智能运维，即 AIOps 转变。

运维工具从软件版向 SaaS 版转变。

国内市场上，国产化在兴起，优秀的厂商和产品也在不断地涌现。