关于服务器性能、安全、稳定的全面监­控

关于服务器性能、安全、稳定的全面监-控 选项

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

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

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

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

定位服务器当机的方法，我们常用的是：使用gdb对core dump文件的反汇编、堆栈调用、寄存器及变量值的分析，当机前后的日志分析。前面
这些是精准分析，剩下的方法就是一些推测类的分析了，比如尝试故障现场的重现，查看最近的代码更新内容，了解来自于玩家的一些异常报告之类。还有最后一
招，不是所有人都能用得上，就是：直觉。它来自于长期产品运营的经验和直观感受，有时没啥特别的原因，就是偶然一个念头想到了可能是某部分的原因，于是
就会去求证，我想很多开发者也都经历过这样的情况。呵呵。

网络流量监控cacti的总体监控，配上产品内置的细节监控，我认为总体上已经完全可以满足运营需求。
cacti提供了相对完善的外部扩展方法，如果想针对进程监控流量，只要形成流量日志即可，cacti可以将此日志再以图形化的方式表现出来。

很多东西是来自于执著和坚持的产物，这里面经验是一方面，态度是一方面。
公司应该有若干个checklist，基本就是包含你列的这些项，通过了，才允许上线运营。

http://groups.google.com/group/dev4server/browse_frm/thread/8a86bb49a561f312?hl=zh-CN  sodme 大宝