如何应对并发(6) - 琐碎的日常
发布日期：2016-01-31 10:56:43 +0000
这应该是应对并发系列最后一篇。
我知道我的技术文章既没有太多的技术含量，也不够前沿。和各路大牛不能相比，但是我也很想和新入行的年轻人分享一个观点，千万不要认为，作为一个高大上的架构师，每天就是追踪前沿，研究新技术，搞所有人都不明白的黑科技，实际上，你日常工作的大部分，是去看一些琐碎的日志，去跟踪和分析一些常见或不常见的问题，然后引入你的思考和判断，看看有什么成熟或前沿的技术，能够应对你现有的问题，并为你后续的目标提升做出保障。
随着硬件能力的不断发展，实际上，很多历史上非常头疼和困扰的技术问题，已经完全迎刃而解，也就是说很多十年前让高级架构师们特别挣扎的障碍现在可能都不存在了。也许我们通过书本去学习一些旧的策略，方案都已经显得不合时宜，但是，你日常对问题细节的敏锐度，分析问题的思路，以及对待问题思考的方法，依然是通用的，一个好的架构师，不在于他学过什么，而在于他如何发现问题，分析问题，而这些，其实功夫都在日常。
回顾一下这个系列
那么接上一个章节，认识负载。
现在说一下，一些具体操作的细节，我们日常是如何认识负载，如何跟踪这些数据的。
我相信很多运维工程师说，他们有会使用非常多监控系统，可以出各种监控报表，但是如果你自己没有认真对业务系统做足够的监控分析，这些监控系统大多是都是摆设，并不能给系统优化和架构提供足够的帮助。
而实际上，自己编写一些针对具体业务系统简单的监控，并不复杂，非常简单，而且也不需要做太复杂的一些展示效果，只要最简单的基本数据留存，对很多疑难排查和性能分析就会帮助很大。我说一下我们日常会做什么监控
1、数据库服务器，包括数据中间件服务器
我们以mysql为例，因为我们用的就是mysql。
1.1 基本的数据库连接数监控，以及内存，cpu占用监控，每分钟cron跑一下。
设置一个阈值，比如说，最大数据库连接数是1024，阈值就是256，超过阈值的情况下，记录所有的show processlist到指定文件，这个特别重要，当你出现数据库链接过多的时候，你可能除了重启别无他法，你必须回溯当时发生了什么。
强调一点，mysql允许root用户比普通用户多一个链接数，这样保证系统崩溃的时候有自救方式，所以，业务系统一定不能使用root链接数据库，而监控系统建议使用root来跟踪，这样即便出现最大链接情况，依然可以将show porcesslist 留下来，便于优化分析。
此外，监控程序可以执行自恢复能力，比如说当最大链接时直接在数据库里kill掉一些僵死查询，释放资源，恢复链接状态，前提是，你确信你的系统允许提供有损服务。 此外，不要依赖自恢复机制，这种机制只能救急，事后必须分析系统瓶颈，并做出有效方案提升整体系统的支撑性。
processlist的状态和所对应的问题，我这个系列没有写，其实有很多需要思考的，在09-10年我做数据库调优的时候，基本上大部分时间都是跟不同的mysql status的链接过多做分析和作斗争； 如果要单拆出来都可以独立写一篇文章，不过如果写出来估计是我公众号上访问量最低的文章了。有兴趣的可以看 “如何应对并发4” 里点原文链接，在百度文库我有完整分享。
1.2 binlog的分析
这不需要实时分析，但我有个习惯，还是会不定期分析一下，特别是当binlog增长速度很快的时候，我们知道binlog是mysql的写入，更新的日志，也是数据库同步的依据。一个有经验的dba，看一下binlog日志的大小和更新的时间，就能评估出这个数据库的更新频次。
如果没经验也没关系，有空的时候，把binlog服务器复制到空闲服务器，（如果数据库服务器很空闲也可以直接操作，但尽量不要在线上操作，以免负载冲击对线上业务造成干扰。） 用mysqldump 将binlog输出为标准的SQL格式，然后就可以做数据分析
第一，每秒钟多少数据更新请求；
第二，最多的更新请求请求的是哪个数据表；
第三，最多的更新请求的SQL格式是什么；
第四，是否存在短时间内大量重复主键的更新请求。（可以考虑合并操作部分，参见请求合并及异步处理）
1.3 慢查询日志分析
看慢查询的形成原因，是受累于整体系统环境的影响，还是受累于锁表的影响，还是本身索引的问题，或者查询本身其他的问题。
2、web服务器，包括负载均衡服务器
2.1 web日志
建议打开执行时间监控，也就是可以看到网页和动态脚本的执行时间。（友情提醒一下，动态脚本的执行时间和网络速度有关，因为输出完成后脚本才算执行截至，而输出的过程是包含了网络传输过程，这一点务必要注意）
分析不同动态脚本的执行频次，并找出频次最高的几个程序。
分析不同动态脚本的执行时间分布，并找出执行时间最长且频次最高的几个程序。
2.2 埋点分析
找到平均执行时间较长，且频次较高的程序，做埋点分析，也就是对程序每个步骤，每个调用，埋点记录时间分布，然后将问题目标缩小到具体的调用和请求上。
当然也可以用一些性能评估的程序来做测试，但是和埋点不同是埋点更能体现真实网络环境下的问题。
日志分析+埋点分析，可以将当前web响应卡慢的问题精准定位，这样对解决问题就有非常重要的帮助，你都定位到具体的请求和调用了，你再找解决方案就明晰了。
2.3 SQL查询输出
通常对数据库查询会有一个对象或函数封装，我会不定期在封装的调用内对查询语句做一个输出，写到临时文件里（/dev/shm 目录下，尽量避免对i/o影响），然后看一下
第一，每秒多少查询请求
第二，最多查询表是哪个
第三，最多查询的SQL是什么，索引是否合理
第四，是否存在同一主键的大量重复查询（可以用缓存来做）
2.4 错误异常日志分析
error日志，包括webserver的error日志，也包括动态脚本的，比如php的error日志，这里往往你会看到很多网络蠕虫入侵和攻击的尝试，以及SQL注入的测试。 有些错误信息应该引起你极大的警觉，比如你会发现你其实存在SQL注入漏洞而攻击者只是猜测错了一点点没有得逞而已。
2.5 链接状态监控
当前web链接数，以及链接的资源消耗。
存在这样的情况，有些脚本本身业务逻辑不复杂，按照最简单的编写方式，吃的资源按理说并不多，但是因为使用了较为庞大的框架，导致每个请求都调用了大量的资源，在连接数较多的时候，导致系统资源耗尽，形成雪崩效应。
这就是我老说的，万恶的框架。
当然，因为web请求比较容易做负载均衡，在现在硬盘，内存都很便宜的情况下，很多架构师会说，我加几台前端就好了，所以可能只有我这种远古时代的个人站长才会对这个特别敏感。
3、内存、缓存服务器
3.1 链接状态和资源监控
3.2 命中率监控
如果缓存的命中率太低，没有效率，应该问一下程序员，多半是设计有问题。很多人以为加了缓存就会提升效率，其实如果命中率不高的话是浪费效率，你本身多一次查询，请求，然后没有命中还要回到原始的数据库查询，这怎么会提高效率？
4、一些通用的监控
内存，cpu，硬盘占用监控
（临时文件导致硬盘满导致服务器崩溃的案例不要太多！）
swap分区占用的监控
你觉得服务器内存挺宽的，但是莫名其妙swap分区占用过高，你整个服务器性能直线跳水下降。 因此导致系统崩溃的案例也是数不胜数。
系统资源占用监控
比如最大文件打开数，最大文件句柄数，syn连接数等，要对一些系统阈值有了解，也许某个系统阈值达到了而你系统资源其实还很宽松，但你服务器已经没法响应了。这就是所谓服务器很闲但是拒绝服务的原因。
5、自恢复系统
当数据库链接过多，webserver链接过多，或其他一些常见问题出现时，如果有一个cron任务，能自动杀掉阻塞进程，就可以以较少的服务拒绝为代价，让系统快速恢复运行，对于很多中小企业来说，运维可以睡个安稳觉，程序员不用半夜起来处理问题，还是很有意义的。
但是这里必须强调，自恢复系统并不能治本，切忌产生依赖性，出现问题快速恢复，但是要给以业务系统足够的提示，当运维负责人或程序员上班时，应给予足够的提示，并快速回放问题现场，（参照如上的监控），寻找问题原因，并做出优化方案，以免问题重现。
自恢复系统是一个对技术不十分成熟，业务发展迅速的平台，特别重要的一个处理思路，你可以用较低的成本完成服务较高的可靠性，并能减少技术人员加班频次，但必须强调的是，你必须有后续的跟进解决方案，否则问题积累到一定程度，就会变成自恢复-崩溃死循环。
6、监控系统的资源占用
必须强调，监控系统本身的资源开销也是需要考虑的，否则可能本身系统没事，因为你做了监控反而挂了。
比如说，netstat -an 这种操作，在链接较多，负载较高的系统中我是不敢用的。比如说，埋点分析我通常会根据在线负载压力考虑采用随机值抽取一个百分比来做埋点，既保证样本的充分度又要保证对在线负载压力影响较小。再比如说，所有类似埋点分析或查询输出，我都是定位到/dev/shm目录，用内存而不是物理i/o， 当然，数据规模也要控制，否则把内存吃满也是大问题，
但是我还是要强调，监控非常重要！
有些人觉得监控占用开销，所以尽可能不开任何日志，比如不开web日志，不开binlog，不开error日志，他们认为这样可以提升效率，然后出问题来问，那怎么弄，我个人认为，在绝大部分业务情况下，binlog，web日志，error日志不会是业务系统的负载瓶颈所在，其对于高负载的系统而言，资源开销只是很小的比例，打开这些日志是非常有意义的。（binlog日志的存储方式要选对，否则可能对系统负载产生致命影响，有兴趣的可以看 “如何应对并发4” 里点原文链接，在百度文库我有完整分享。）
以上是以前我做过的系统监控的一些总结，因为当时主要以web服务为主，对于其他类型的服务并没有特别多的研究，但我个人认为基本思路和逻辑是一致的。