微信号:infoqchina

介绍:有内容的技术社区媒体

监控也是一个权衡的过程

2013-08-20 16:42 InfoQ

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


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中文站编辑。到处串门的互联网信徒,相信规则的力量。


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 【Python爬虫实战】爬取糗事百科段子 React Native 高质量学习资料汇总 前沿沙龙┃百度孟庆魁:大数据做更精准的金融服务 Python使用UDP广播实现服务器自动发现 Java中的String为什么是不可变的? — String源码分析