状态统计和buffer堆积状态（网络）、程序的内存分布，最耗内存的对象（内存）、当前是哪个程序在占用磁盘io、gc情况。
这里主要是linux和java的一些辅助工具：top/perf/netstat/iotop/jmap/jstat等等。
- 3分钟了解请求的链路情况，网络传输、系统调用、库函数调用、应用层的函数调用的调用链、输入、输出、时长。
这里也有linux和java的一些辅助工具，tcpdump/strace/ltrace/btrace/housemd等。最近我们也在完善用于集群的调用链分析工具trace，希望在足够完善之后能开源出来。
- 3分钟检索当前系统的快照情况：线程栈情况、某个变量的值、存储或者缓存里的某个值是什么。同样是系统和java提供的一些已有工具，jmap/jstack/gdb/pmap等。
可能大家觉着这个指标定的有些低，有不少信息都是一个命令就可以看到了，这里特别强调一下，我指的是从头脑中有要看的想法，到看到并理解实际信息的时间。google一下命令的用法、安装工具之类的时间也要算进去:P
刚才说到关键点是如何提高效率，熟练工是一个方法，但是降低工具的使用成本更有效一些。我们做了一些排查问题相关的工具和系统，相信很多公司也有类似的内部系统。
之前qcon上展示过监控之类的大型系统，今天展示几个日常用的小玩意。
查询具体的业务数据，比如查询某个id当前的消息计数：
分析当前机器上的jvm的线程、堆或者其它信息：
总之，关于known-unknown只强调一点：如果要做用于排查问题的工具，如果一次查询的时间超过3分钟，那实际排查的过程中很有可能就没法发挥这工具的价值。
3.3.unknown-unknown
unknown-unknown，这个指的是自己不知道还有哪些不知道的事情，也就是超出自己知识体系的事情。
我个人有个体会，高负载系统中出现的问题中，有很大一部分问题产生的原因是我原先根本不了解的，比如jvm里某个bug，或者一些内核在实现中有一些特殊的机制，之前听都没听过。
这里有个误区，超出知识体系并不意味着不能分析问题。但是在遇到一些棘手的问题，超出了以往的知识体系，这时很有可能会产生焦虑感，认为这个问题不科学、无法解决，并且有很可能会做一些没有价值的事情，比如反复检查日志、反复重启、甚至开始论证这个问题不可能发生之类。
这个时候其实就没有很具体的方法了，不过还是一些思路给大家分享一下：对于这类场景可以做减法，尽可能缩小范围，当范围可控之后，再去了解相应的原理。
这里有几个具体方式：
- 尝试重现问题，修改变量尝试是否能复现
- 对比正常系统和异常系统的不同，找出异同点
- 通过已有知识剔除异常中正常的部分，缩小异常范围
- 看书或者教程，了解原理；看源码，了解实现机制
还是举个案例，前几天分析的一个tomcat突然请求变慢的问题，日志里无异常、性能没有瓶颈、线程数正常、通过工具也没找到什么新线索，还是不知道慢在哪了。
当时我的做法是先尝试复现问题，不管是测试环境压测、tcpcopy还是保留现场等等都可以用于复现现场，qcon上讲过这里也不重复了。
问题复现之后尝试缩小范围：一次http请求的过程包括tcp三次握手、应用accept连接、接收request、应用层处理、发送response、关闭连接这个过程，于是我用tcpdump和strace直接跟踪了网络包状况和系统调用，梳理了某一次调用的时间轴，发现时间浪费在三次握手和accept之间。
之后查看这部分tomcat源代码，找到了tomcat的一个bug：bio方式下如果应用有stackoverflow，那么线程会退出，但是连接计数没有减掉，导致新请求不能被accept。
以上是关于known-known,known-unknown,unkonwn-unknown，我的一些理解，在排查的时候可能会交替的遇到这几种场景，不过只要掌握好各自特点，逐个击破就好。
4.建议
下面给出一些系统设计方面的建议，其实在上面的内容中已经体现了，在这里只是总结一下。
首先，问题排查是复杂的，不可控的，所以不要把排查和解决混在一起，尽量先解决、再排查。解决的方式基本上都是那么几板斧：重启、回滚、扩容、降级、迁移，具体方案就不展开了。
其次，系统要尽可能的对外暴露内部状态和干预手段，比如说少打了一句日志，没把变量输出出来，那么出现问题的时候很不但要用某些复杂的工具去查询变量，而且很有可能要多绕一个大圈。
再次，系统是不稳定的，所以对于高可用架构设计来说，隔离是必须的，不管是何种依赖方式，都需要考虑“实在不行了”的情况。qcon上讲过，这里也不多说了。
最后，问题的原因、传播路径和现象不是一一对应的。同一个问题，这次的表现是多打了一行WARN日志，下次可能就是一次系统雪崩。墨菲定律，如果有可能出问题，那一定会出问题。
最后附上qcon的演讲地址，如果没看过，可以跟今天说的内容对比着看一下。 http://www.infoq.com/cn/presentations/typical-problems-of-weibo-in-large-scale-high-load-system
5.Q&A
Q1:刚查了一下，那个wtool工具是自己写的吗？ 基于哪些工具实现的？
A1:这个是自己写的，主要是基于脚本和现有工具的整合。github上有个开源版： https://github.com/qdaxb/wtool
Q2:在线jvm的信息排查，是在开源工具上进行的封装，还是自己写的工具？
A2:主要都是开源的，一小部分是自己写的。
Q3:抗峰时的分流以及日常架构上的分流设计方案（包括应用端和数据库DAO层设计思路）
A3:这个和本次分享的主题关系不是很大，稍后单独沟通吧。
Q4:第一个业务查询工具如何做到能够持续好用？
A4:一是把框架和逻辑分离，增加逻辑时不用改代码，写一个脚本就可以简单的完成二是尽可能的优化工具的效率，这个是问题排查工具的核心价值。
Q5:系统出错了，你们排除问题时，怎么保证不影响线上呢？
A5:首先是要解决问题，通过运维的一些介入手段把服务恢复，同时尽量保留现场（比如保留一台出问题的机器只摘除不重启） 其次是在通过监控或者日志初步定位原因之后在线下复现问题，这时候排查就没有什么心理负担了。
Q6:不同语言如php/java的应用，还有不同的层面如网络/操作系统／数据库的问题的排查，都有什么模式和异同？
A6:我理解思路上都是类似的：找线索、推测原因、再找线索证明，区别主要是问题的原因具体用到的工具可能不一样,现象基本上都是那么几种：慢了、死了、处理出错了。
Q7:业务系统的日志，是通过外挂工具收集，还是要侵入到业务里面写日志？如果侵入的业务里面，有没有一些日志方案推荐？
A7:有一部分是外挂工具，还有一部分是业务里面，不过业务里面指的也是业务的框架层去集中输出这些日志，具体写业务的人不用管。 日志方案我们主要用的scribe，也有一部分用logstash，运行的都挺好。
Q8:线上出现请求block或请求慢时，一般会保留哪些现场数据？如果线下难以重现，线上问题的时间窗口也滑过去了，是不是可能会变成无解问题？
A8:一般来说，