如何部署云端的监控策略？

1月13日，云应用数据监控企业 Datadog 宣布获得 9450 万美元融资，云端监控的市场究竟有多大？在 Web Scale IT 的潮流中，云端监控已经越来越成为一种必需。下面我们来看看 Monitoring Strategies in the Cloud 这篇文章关于云端监控的真知灼见。

笔者之前写过一篇云计算对运营模式的影响，分析了为何弹性的云模型会比封装与交付(package and ship)软件模型需要更多工程技术。此外，由于云供应商提供的是实时24*7自动伸缩方案，所以，弹性云模式还需要更加先进的监控策略。

在使用预安装软件时，用户要负责监控基础架构和应用程序，当使用量达到一定阈值时，用户还要负责容量规划以确保采购和准备更多的基础设施。而在云模式下，云供应商必须实时执行这些任务，并且在达到一定临界值时，立即进行自动化系统伸缩。云端监控的最好策略是主动出击策略，就是当问题对系统和用户体验产生广泛影响之前，先发制人。

需要监控的种类有：

• 安全

• 性能

• 容量

• 正常运行时间

• 吞吐量

• 服务水平协议(SLAs)

• 用户指标

• 日志文件分析

• 关键性能指标（KPIs）

各个云栈层也需要监控：

• 用户层

• 应用层

• 应用堆栈层

• 基础设施层

此外，还有三个不同的区域需要监控：

• 云供应商环境

• 云应用环境

• 用户体验

因时制宜的监控策略

基于云来构建系统的最佳实践就是尽可能标准化，这样，高水平的自动化才能落实。其中，两个亟需标准化监控的重要领域便是错误捕获和日志记录。在云端日志策略一文中，笔者对此话题进行了简单的讨论，摘抄如下：

…构建一个公用服务用来编写应用程序消息：采用通用的日志消息格式、标准的 http 错误代码、RFC5424 严重性级别，并且采用通用词汇来描述错误，以便于优化搜索，获得一致的结果。

上面这些建议都非常重要。在一个拥有成百上千台服务器的高度分布式环境中，如果错误消息没有统一的标准，那么，日志内容就难以在决定模式时起到应有的作用，几乎是毫无价值的。下图是一个云堆栈，除了数据库层，其它层都是多租户架构的：

数据库层是根据用户进行分片的。这是用来最小化所有非数据库层中虚拟机数量的通用方式，同时，还提供一个隔离层来保障用户在数据层的附加安全。但是，日志呢？这些服务上的所有日志都应该通过管道输送到一个中央日志服务器（主日志文件和备份），它很有可能存储在一个 NoSQL 数据库上，便于检索。日志服务器是一个共享资源，所以，所有的日志记录都应该存储在同一个 NoSQL 数据库中。采用标准的错误消息命名规范和标准化日志消息，日志应用程序可以从日志共享环境中给终端用户提供具体的用户日志。

为了实现这种策略，开发团队必须实现策略标准和设计规范。另外，非常重要的是，必须在开发初期就要落实到位，否则，等到服务器数量增长到成百上千时，再进行改动风险就非常高了。

主动 vs 被动

基于云端的监控必须要采取主动方式。通常，当用户思考如何进行云端监控时，他们会用 Nagios 监控虚拟机的磁盘、CPU、内存等。这些是必不可少的，但仅仅这样做，还远远不够。所有的运行任务都应该被监控和基线化，每一个 API 都应该被追踪，每部分基础设施都应该被监测，用户指标都应该予以密切关注，对每个可疑活动都要追查其发生的原因。

对于 APIs，主动监控可以追踪每分、每秒的调用数，以及每个时段的平均表现。无论何时，只要系统检测到一个异常值，无论是调用次数异常，还是调用表现异常，都应该向相关人员发出告警。例如，如果一个 API 通常每分钟被调用 1000次，但在最近一分钟内，只被调用了 5 次，那么，很有可能是 API 出现问题，或者是上游的一些东西阻止了代码调用该 API。另一方面，如果该 API 突然被调用了 10000 次，那么就应该发出告警了。有可能是新用户突增，也可能是流量猛增，但开发人员应该检查系统的其它部分是否可以顺利扩容以适应这些增长。此外，也不排除有人进行恶意攻击，开发人员应当检查日志，看看是否有可疑行为。

追踪KPIs

主动监控的另一个例子是追踪 KPIs。每个企业都会有自己的 KPIs 指标，例如下面这几种：

• 每客户成本——云成本除以云平台上的客户数

• 每客户收入

• 跳出率

• 每天处理的平均交易量

KPIs 是长期追踪的基准化指标。KPI 的不良趋势可以揭露产品策略问题或者系统问题。与用户活动相关的 KPI 也应该进行监视、日志记录并且与每次部署相关联。用户活动下降的原因有很多，可能是因为最新发布的版本存在代码缺陷、性能问题，也可能是用户难以接受或适应产品的变化。通过主动监控 KPI，企业可以对问题做出快速积极的响应，避免灾难性结果或用户流失。

监控和云服务模式

对于基于 laaS 构建解决方案的企业，大量的开发和监控工具是必备的，DevOps 团队的核心职责是实施综合监控视图以方便运营团队监控系统。如果企业基于 PaaS 构建解决方案，那么 DevOps 团队只需对应用层实施自动化监控，运营团队可以直接查看应用监控并检查 PaaS 上系统的运行状况。如果企业使用了 SaaS 解决方案，那么运营团队至少要 ping 一下 SaaS 的 url，如果该 SaaS 解决方案是任务关键型的，他们就需要监控 SaaS 解决方案所提供的系统运行状况信息（如果该功能存在的话）。

总结

监控是所有云端项目不可缺少的一部分。监控措施应当尽早落实，不断提升。目前，还没有一个监控工具可以满足云端解决方案的所有需求。用户可以结合使用 SaaS 解决方案、开源解决方案甚至一些本土的解决方案来满足平台的所有需求。管理一个没有监控工具的云端解决方案，就好比夜晚在高速路上驾驶一辆没有开灯的车一样。你或许可能平安到家，但是几率也许渺茫！

Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。
本文系国内 ITOM 行业领军企业 OneAPM 工程师编译整理。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客