监控也是一个权衡的过程

上周有朋友反馈说鸡汤太多了，今天来点干的。

Kevin Nilson 是 Just.me 公司的工程副总裁，也是硅谷 Java 用户组、硅谷 JavaScript 用户组和硅谷 GDG 的组织者，也是 Web 2.0 Fundamentals 一书的作者。Just.me 是一个社交类应用，有 iOS、Android 和 HTML5 版本，虽然用户数量目前还不是很多，不过因为其创始人也是 TechCrunch 的联合创始人，在影响力和产品理解方面都相当出众，所以也引起了不少关注。

在今年 7 月的 JavaOne 大会上，我跟 Kevin 聊了一些有关监控的话题，包括公共云平台下做监控需要注意什么，针对移动端如何做监控，监控工具是拿开源项目改还是自己做还是用商业方案等话题。其中一个话题是问他们监控哪些指标，Kevin 回复的相当详细，在这里跟大家分享一下。

首先，因为我们要监控的指标很多，所以你需要一个 dashboard，可以一眼看到所有指标的状态。监控的指标嘛，系统方面的肯定是最基础的，比如 CPU，那这个 dashboard 上肯定会有 CPU，负载状态，实例的健康度等等。

对我们来说，有一个指标是比较难监控到，但是又很重要的，就是活跃的请求数（active request）。想要了解每一个服务在一段时间内的活跃请求数具体有多少个，这是挺难的，但我认为也是最有价值的一个指标。当你的流量激增的时候，或者是当服务出现问题的时候，活跃请求数也会开始堆积，因为请求的处理时间变长了。对这个指标进行全局的查看是一个很有意思的事情，尤其是在 Java 当中为什么有固定数量线程池，就是因为有时候某个特定的请求（包括来自 API 的请求）可能会把整个服务都搞死，这是很恐怖的事情。所以，避免一个服务把整个站点搞死是很重要的事情。

还有很多服务，我不在乎它们跑的性能好不好。有的时候，你要区分考虑 get 和 post/put 的情况。当你往服务器发送信息的时候，这个过程往往是异步的，在后台的，用户并不知道这个动作实际上花了多长时间。而当用户从服务器取信息的时候，这个动作往往是需要用户等待的。所以，get 的速度指标会重要得多。

但反过来看，put 的动作意味着用户在把数据发给系统，这些从商业的角度而言又是比较重要的。在发送消息这个功能上，我们希望知道用户在什么时候发布消息，发布了多少消息，点了多少 like，发了多少评论，关注了多少人等等，我们需要知道这些数据。至于用户刷新页面刷了多少次，这个我们是不关注的。所以归根结底，这是一个权衡的过程。

然后，要说说我们用的、来自 Square 的 Cubism 工具。刚才我说要能够一眼看到所有的数据，那么 Cubism 所做的就是让数据叠加呈现，以颜色区分，你能够在一个页面上列出非常多的指标。

从运维监控的角度差不多是这样。至于商业的角度，主要还是看你的运营目标了。我们的 dashboard 从启动以来，上面的内容大概有 30% 都跟一开始不一样了。有些是我一开始以为我们会遇到问题的指标，但后来一直没遇到，所以移除了；有些是我们曾经遇到过问题，但后来解决掉了，所以也移除了。

现在剩下的指标，一个是 CPU——各个服务的 CPU 数据可以叠加显示，比如 MySQL CPU，EC2 服务器的 CPU，Lucene 索引服务的 CPU，Neo4j 的 CPU 等等，都可以垒起来。说到底，CPU 数据就是一个 0 到 100 之间的数值，如果没有超过 75%~80%，也没什么可担心的，所以一眼看过去就可以知道是否有问题。

然后是负载均衡，健康实例的数量，活跃请求的数量——这部分数据也是将不同服务的数据挤压到一起显示的，如果一个数值蹿升，则会触发警报。

还有 DynamoDB。这个我想多说两句。首先，DynamoDB 的支付方式实在是不怎么样，根本是违反云的精神的：你一次购买比如 100 个 DynamoDB 的读单元，无法自动扩展。如果你用到了 100 个，系统会停止给你返回结果，扔给你异常；如果你一个都没用到，也还是得为 100 个付钱。如果你不是全球性的站点，可能白天活跃晚上不活跃，你就要不停地去修改它的配置。这点实在让我很上火，因为我不得不老去盯着它有没有到达阀值。然后就是，DynamoDB 其实自己有配备 CloudWatch 监控窗口，但这个东西也够难用。我们的表很多，如果要用 CloudWatch 来看，光是开浏览器窗口都要开几十个，完全没有可用性。所以，我基于 Graphite 自己做了一个监控 DynamoDB 的工具，将来自各个表的数据整合到了一个窗口里面。

有一段时间，我们的 dashboard 上放了很多安全层面的监控数值：每一个需要通过 JAS 安全的请求，都要去看它用的时间。当时，我们的认证层有一些问题，一个请求过一遍安全层可能会花几秒钟的时间，这种情况下再去看其他性能指标就毫无意义了。后来这个问题修复了，我们就把这一项从 dashboard 移除了。

还有一项就是客服工单的开启数量。如果在一段时间内，忽然涌现出大量的客服工单，那很可能出现了你其他监控所没有发现的问题。所以我把这个数据也加进来。

最后，考虑到鼓舞士气的原因，我把一些市场数据也放进了 dashboard，比如装机量，注册用户数，整个系统处理消息的数量、回复的数量等等。这个主要是为了吸引团队成员的注意力，让他们有个理由多看看 dashboard。我们把 dashboard 放在办公室的大屏幕上，所有的团队成员都能看到。大家休息喝咖啡的时候，就会在屏幕下，谈论这些数据。这能勾起他们的好奇心，顺便引导他们去看上面的那些数据。

本日作者简介

杨赛（@lazycai），InfoQ 中文站编辑。到处串门的互联网信徒，相信规则的力量。