如何对产品运营情况进行监控

http://groups.google.com/group/dev4server/browse_thread/thread/8a86bb49a561f312

今天看到maillist里在讨论新产品上线前如何做监控的讨论，很有感触，先帖一段sodme的经典总结和分享吧，原文链接如上。

------------------------------------------------------------------------------------------------------------------------------------------------

一、开题
我们产品前后历经多次面向不同规模用户的测试，每一次的测试也都会让产品更进一步。在已经过去的这些测试里，我曾经对同一个问题一直耿耿于怀：我很希望
公司在每一个新产品上市的时候，能向这个新产品派驻一两个富有经验的技术人员，以指导、协助他们完成产品上市前应该作的准备，但是，很可惜，直到我们成
长为一个相对成熟的运营产品之后，我们都没有得到过任何这方面的帮助，一直是自己摸索，痛苦而又漫长。

好吧，我希望同样的事，不要一而再、再而三的在更多同行身上重演了，所以，我想聊一些新产品上市所应该准备的事情，供大家参考，也留存我们自己的记
忆。

以我们自己的项目为例，我把产品上市前，服务器的性能监控内容分成这样几类：

1. 服务器内存使用、回收的统计、分析机制，更详细的，要统计到各类对象、各玩法、各系统的分别占用情况；
2. 网络流量（含收发包双向流量）的监控、统计、分析机制；
3. CPU使用率的统计、分析机制（结合逻辑架构，细分到各系统、各功能的具体占用）；
4. 数据库存取效率、存取流量，数据内容大小的统计、分析机制

以上是哪些内容应该作监控，至于如何作监控，无非是：尽可能详细、具体的统计出是哪些环节、哪个步骤、哪些系统占用了具体多少的系统资源。统计的工具，
可以采用一些已有的工具，也可以完全自己内建监控体系，我们采用的是后者：自建完整的服务器性能内部监控体系。

具体来说：
在内存使用上，我们尽可能的使用内存池技术来管理引擎层对象的内存使用，对脚本层的内存管理则采用基本内存池的buddy算法（脚本用的是lua），采
用内存池一是方便查证内存泄漏，二是可以给策划一个紧箍咒，方便双方商定各类资源的上限（比如怪的数量）；
在网络流量的统计上，我们分别统计单个玩家上下行各类型网络包单位时间内的包数量、包大小、某场景的玩家聚集数，发现问题后，通过两个方法优化流量：减
少收发包个数，减少单包大小；
在CPU使用率上，我们在帧轮询机制内和服务器运行的大循环内，对各主要系统进行CPU耗用时间监控，各大系统内又会有更细粒度的耗用时间记录，以此逐
层定位性能消耗点；
在数据库操作的效率上，会统计各操作的前后耗用时间，涉及到的数据内容，注意：这里主要是针对逻辑点而言的，而不纯粹是单个的SQL操作时间。

对于一款商业运营的网游产品而言，服务器至少应该保证连续稳定运行一周的时间，这是很多新产品需要跨过的第一道槛，什么时候你作到了连续运行一周不出问
题、稳定、高效，什么时候才算是在技术层面真正过了关，注意，这个一周，一定指的是完完整整的至少7天，差一天都不能成为一款合格的商业产品。

我们产品对以上四个方面内容的监控，并不是一次性全部建完了的，是慢慢摸索出来的。当人数压力越来越大时，总会发现系统一些新的不稳定和异常因素，比如
刚开始并没有这么严格的监控各类型包的数量、大小，但运行了一段时间后发现网络包突然多了，流量突然变大了，于是就会找原因，在找原因的过程中也就会不
断的把各种机制逐渐建立了起来。所幸的是，同行的新产品，在看到这个贴子后，可以不用经历我们的摸索期，而先行建立这样的机制了。:)

我们都知道，网游新产品上市时，普遍面对的一个问题都是新人涌入很多，玩家过于集中，服务器性能各方面的压力都将很大。这时，出于技术人员的本能反应，
我们都会强烈建议策划调整新手进入路线，减少玩家聚集度，以缓解服务器压力。嗯，这种想法严格来说很正当，但是，作为一个想有所作为的产品而言，我给的
建议仍然是，使劲吃奶的力气你都要尽可能的优化下去，中国玩家普遍都喜欢凑热闹，越是热闹的地方越是愿意去，越是热闹的产品越愿意玩，如果一个产品当新
玩家上线时，举目望去凄凄凉凉，空无一人，也会直接影响到玩家对一款产品是否够火的判断。从产品层面来说，我们应该欢迎热闹，而不是相反去拒绝热闹。技
术人员辛辛苦苦作几年，为的就是产品能成功，能赢利，为的也就是这一回，所以，尽管到时会背负很大的压力，也要坚持把性能尽可能的优化下去。

除了性能压力之外，我认为，面向玩家服务而言，我们最应该作的是，不管采用什么方法，都要尽可能完整的确保玩家数据安全。稍微慢一点，挤一点还不伤大
雅，但如果频繁发生数据丢失、回档之类的运营事故，对官方形象和玩家信心的打击将是致命的。但是，安全和稳定，是具体到每一天开发内容之中的，是需要根
植到每一个开发者思想深处的。如果是等到产品已经上市的时候再提安全，可能已经有点晚了。通常情况下，每一个新产品在开始测试时，几乎都会发生服务器异
常当机，相应的，就会发生玩家的数据丢失。

所以，对待玩家的数据安全，我们应该从以下几个方面着手去作：
1. 在研发期，就应该加强开发者的安全教育，安全编码不仅仅是一种习惯，更是一种工作态度，要把玩家数据安全放在第一位，如果有必要，有时宁愿牺牲掉
一些小性能来保证安全；
2. 要建立完整的针对于核心系统代码审核、发布的流程，重要代码由放心的人来作，次要代码能全面监控（自查，互查，流程及代码review）；
3. 所有重要的玩家数据，其获取、流通、消耗的全过程，都应该有尽可能完整的留下日志记录，以便于当发生数据丢失时能帮玩家找回数据，不要偷懒；
4. 要建立能迅速根据core dump文件来定位当机原因的机制，不管是符号表编译、反汇编分析、日志分析、玩法重现中的哪一种，只要能越快定位原
因就用哪一种，甚至可以多管齐下，多人并行定位。

新产品上市，是一场战役，很真实的战役，真实到，可以决定你这几年青春到底价值几何。

好吧，也希望能看到更多朋友聊一聊大家各自在新产品上市时所作的事，或者说一些趣事分享一下经验也挺好的。

二、日志系统设计

我们是自己作的日志系统，作法是这样：

1. 使用日志队列管理所有待写日志，主逻辑线程将待写日志丢入队列，写日志文件的线程从队列取数据写入实际文件；

2. 不同类型的日志写入不同文件，比如物品系统、交易系统、任务系统等是写到不同文件，这样不仅可以控制文件大小而且也方便运营时的日志查询；

3. 日志文件的总量控制上，采用循环日志与非循环日志两种方式。循环日志是指开若干个同类型的日志文件，以编号作区别，比如
trace01.log~trace10.log，每个日志文件记录的行数相对固定，写满一个后再写后一个，写到第10个时再回头写第1个。记录很频
繁、量很大、非永久性的日志，可写入循环日志，比如性能追踪的相关日志等。非循环日志，是指需要长久保存的日志，比如玩家的交易记录等。

4. 严格控制非循环日志的总量，适时调整循环日志与非循环日志的内容，写的频率的非循环日志要看看能不能调整到循环日志中。我们的日志记录比较详细，
其输出量相对来说现在不算小，一周一个服会输出文本类的日志将近7G，我们只会保存最近两个月的相关日志，更远时间的日志视备份系统的硬盘大小决定适时
删除。也就是说，对于客服方面的运营问题，我们只提供最近2个月以内的行为记录确认服务。

5. 日志方面的性能，对于我们服务器性能方面的整体影响来说，不算很大，但也要看日志的输出频率，还是要控制好日志的输出频率和输出量，影响大小不是
首要的，首要的是要建立一套可伸缩的日志输出体系，可以让你适时调整相关的性能影响比例。

三、内存问题的跟踪

1. 我们前后经历三次不同规模的用户测试，两次全服的数据转档，一次全服的服务器合并。这些监控模块，基本上是在这些历次的大型事件中逐一添加的。如
果集中时间添加，我想基本的机制大概最多一两个月就可以完全搭完，更重要的是后期的持续跟进和调整。其实，关键的是，有了这套基本的机制之后，你的心里
就不会发虚了。

2. 定位服务器当机的方法，我们常用的是：使用gdb对core dump文件的反汇编、堆栈调用、寄存器及变量值的分析，当机前后的日志分析。前面
这些是精准分析，剩下的方法就是一些推测类的分析了，比如尝试故障现场的重现，查看最近的代码更新内容，了解来自于玩家的一些异常报告之类。还有最后一
招，不是所有人都能用得上，就是：直觉。它来自于长期产品运营。

四、网络模型的选择

好一点的网络模型（比如IOCP,EPOLL），优势在大规模并发连接方面，并不在于单个连接的数据处理。如果你想在处理大规模并发方面有所提高，建议
还是选择这些已经成熟的网络通信模型。

网络模型的选型，还是要根据实际项目的网络架构、用户规模、逻辑数据的处理特点等来定，不是简单地说可以用这个，不可以用那个，这玩意没有什么绝对的概
念。事实上，在我们的产品中，网络层关于通信的性能是很小的一块，完全没有构成对整体性能的关键性影响。

网络上已有的框架可以参照，但要考虑到驾奴能力。基本上，我们产品对于开发模型的选择思路都是选择自建，这是根据我们的实际情况作出来的：
1. 我需要短时间内对这些内容作到完全可控，我认为再好的第三方库，也没有自己写的知根知底；
2. 方便以后对其进行灵活改造。

当然，这也并不就是所有新团队和新人都要选择的道路，看项目紧迫度、看团队成员的已有技术水平、看项目未来的用户规模等等。

五、传输层和网络层监控

1、sflow受限于某些设备，在我们的环境中，无法全覆盖；
2、netflow能满足需求，大型集群网络中，条目太多，硬件条件不允许，并且只能在3层以上设备中才可使用，如果能在2层设备使用，就不存在问
题；
3、cacti已经在我们的网络流量监控上用了，但是无法满足我们对TCP端口、进程这种颗粒度的需求。
------------------------------------------------------------------------------------------------------------------------------------------------

sodme开题已经十分精采的，其实对于产品和运营情况的监控远不止于些，细化来可以根据服务分层情况进行区分。以web类服务为例，常见的分层如下：1.前台页面；2.接入层；3.逻辑处理层；4.数据持久层。对于不同的分层可以加上不同的监控，套用一位老大的话说，要做到“立体化监控”，这样一旦出问题了就可以在最短的时间内定位出问题。当然所有的监控都要以图表和曲线的形态展现，还要能做到前后几天可以对比，这样才能看到异常出现的时间点。

下面说下每一层可以加上那些监控：

1.前台页面

1.1单页面的访问量

比如一个页面有几个TAB页，每个TAB被点击的次数要进行统计，方便产品和开发人员设计时了解用户行为。页面的访问情况不同，后台的存储、缓存机制会不同。

1.2关键路径的访问情况

比如一个网站的注册页面，可能会分很多个步骤，那用户是在那个环节流失的呢，如果加上监控和统计，那么可以知道用户在那一个环节上注册失败率比较高，从而做出适当的调整，降低用户注册的门槛。

2.接入层

接入层主要是指WEB SERVER这一层，现在常用的有apache/nginx/httpd等，由于接入层不负责主要的业务逻辑，所以cpu和内存不会成为瓶颈，所以接入层主要关心用户的访问行为。

2.1单个CGI/FCGI每秒访问秒数和每日累计访问量

通过每秒钟访问数可以评估系统的压力，同时，也可以计算出所有部署CGI的访问比例，从而可以了解每个FCGI开多少个进程合适。

2.2每次请求处理时延

统计每次请求的处理时延可以获悉服务是否正常，以及感知用户的真实体验，并且通过画流程图的方式可以分析出关键路径，从而保证非关键路径上的出错不会导致用户层长时间等待。

3.逻辑层

逻辑层负现主要的逻辑处理，并与后台数据打交道，所以监控最多，也需要很细致。

3.1网卡流量、收包回包数量和大小

3.2CPU/内存/LOAD AVG/IO状况

这一项反映的机器的运行情况，可以反映系统的瓶颈所在，方便优化系统。

3.3每秒访问数和成功、失败数

可以了解到系统当前的访问压力和运行状况，如果观察失败数有上涨的趋势就要查一下那个环节出问题了。

3.4接口访问的成功、失败数以及时延

由于逻辑层访问后台数据层很频繁，有必要对访问的成功率和访问时延进行监控，并且以报表的形式进行展现，这样那个数据项出了问题都可以一目了然。

4.数据层

数据层主要是DB和CACHE，DB一般采用MYSQL或POSTGRADE，CACHE的选择比较大，如MEMCACHE，还有公司自已写的CACHE。

4.1 CACHE命中率

因为命中率最大程度上反应的CACHE的性能和效率，因为了解命中率可以帮忙开发人员和产品人员了解到热点数据的分步情况甚至是用户的访问特征，从而尽可能的提高命中率。

4.2 IO状况和单个库的访问情况

DB性能最大的瓶颈在于IO，所以一定要对IO的状况加上监控，同时对于每个库的访问情况也加上监控可以了解到比较繁忙的库便于后期分库分表时做为参考。

当然，监控自然越多越好，但是监控本身也是有很大的成本开销的，所以，对每一个产品而言都需要梳理出这个产品的关键路径和瓶颈所在，加上监控，可以增大系统的可用性和易用性。不过对于敏捷开发而言，有时候要求一个产品要快速上市，所以可以加上最必要的监控先抗住加优化，因为服务永远是第一位的。

上面的监控可能不够全面，后续我会继续补充。