用大数据思维做运维监控是怎样一种体验?（1）

我们将从以下三个层面论述大数据对运维的意义：

• 工程数据，譬如工单数量，SLA可用性，基础资源，故障率，报警统计
• 业务数据，譬如业务DashBoard,Trace调用链，业务拓扑切换，业务指标，业务基准数据，业务日志挖掘
• 数据可视化

当然，这篇文章谈的是运维都有哪些数据，哪些指标，以及数据呈现。并没有谈及如何和大数据相关的架构做整合，从而能让这些数据真的变得活起来。

在步入正式的探讨前，有一点我觉得值得强调：

虽然这里讲的是如何将大数据思维/架构应用于运维，平台化运维工作，但是和大数据本质上没有关系，我们只是将大数据处理的方式和思想应用在运维工作上。所以，即使你现在所在的公司没有数据团队支撑，也是完全可以通过现有团队完成这件事情的。

很多公司运维的监控具有如下特质：

只能监控基础运维层次，通过zabbit等工具提供服务器、CPU、内存等相关的监控。这部分重要，但确实不是运维的核心。

对业务的监控是最复杂的，而现在很多公司的要么还处于Shell脚本的刀耕火种阶段，要么开发能力较强，但是还是东一榔头西一棒子，不同的业务需要不同的监控系统，人人都可以根据的自己的想法开发一个监控的工具也好，系统也好，平台也好。总之是比较凌乱的。

使用第三方的监控平台。这个似乎在Rails/NodeJS/Pythone相关语系开发的产品中比较常见。我不做过多评价，使用后冷暖自知。

当然也有抽象得很好的，比如点评网的运维监控据说就做得相当好，运维很闲，天天没事就根据自己的监控找开发的茬，让开发持续改进。不过他们的指导思想主要有两个：

运维自动化。怎么能够实现这个目标就怎么搞，这严重依赖于搞的人的规划能力和经验。

抽象化，根据实际面临的问题做出抽象，得到对应的系统，比如需要发布，于是又发布系统，需要管理配置文件，所以有配管系统，需要日志分析所以有了有日志分析系统。然而这样是比较零散的。

有点扯远，我们还是把焦点放在监控上。

如果以大数据的思维去思考，我们应该如何做好监控这件事情?

图1

《大数据对于运维的意义》这篇文章也讲了，主要有工程数据，业务数据。所有的数据源都有一个共性，就是日志 。无论文本的也好，二进制的也好。所以日志是整个信息的源头。日志包含的信息足以让我们追查到下面几件事情：

• 系统健康状况监控
• 查找故障根源
• 系统瓶颈诊断和调优
• 追踪安全相关问题

从日志我们可以挖掘出什么?

我觉得抽象起来就一个：指标。指标可以再进行分类：

• 业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等
• 应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等
• 系统资源层面：如cpu、内存、swap、磁盘、load、主进程存活等
• 网络层面： 如丢包、ping存活、流量、tcp连接数等

每个分类里的每个小点其实都是一个指标。

（待续）

（摘编自 公众微信号：36大数据 作者：祝威廉 / 编辑 严进军）