文章来源
《高可用架构（第1卷）》由数十位一线架构师的实践与经验凝结而成，选材兼顾技术性、前瞻性与专业深度。
作者介绍
秦迪，微博平台及大数据技术专家，负责架构的改进工作。
背景
作为典型的互联网后端服务之一，微博平台部署了大规模的基于Linux系统的集群，使用Java作为主要语言，使用了一些外部的框架比如Tomcat、Storm、Hbase等，也应用了一些自研的系统，比如RPC框架Motan、服务发现Config Service等。不同企业和行业采用的方案可能有区别，但从问题排查这个角度来说都是类似的。
《高可用架构（第1卷）》由数十位一线架构师的实践与经验凝结而成，选材兼顾技术性、前瞻性与专业深度。
作者介绍
秦迪，微博平台及大数据技术专家，负责架构的改进工作。
背景
作为典型的互联网后端服务之一，微博平台部署了大规模的基于Linux系统的集群，使用Java作为主要语言，使用了一些外部的框架比如Tomcat、Storm、Hbase等，也应用了一些自研的系统，比如RPC框架Motan、服务发现Config Service等。不同企业和行业采用的方案可能有区别，但从问题排查这个角度来说都是类似的。
问题分类
☆ known-known
就是你想要知道且已经获取到的一些信息。比如日志业务表现、监控图上反映出来的信息。一般来说，比较容易获取的信息大概有以下这些。
服务表现：问题的具体表现（出错、超时等）、应用日志、依赖服务的状态等。
系统状态：操作系统指标（系统管理的各种资源的状态、系统日志等）、VM指标（主要是GC）。
硬件指标：CPU、内存、网络、硬盘是否达到瓶颈。
总结一下关于known-known类的线索：主要是在不丢失信息的情况下，对信息做定量和归类分析，定位进一步的排查方向。
☆ known-unknown
是指你想要知道但目前还不知道的信息，一般指不能直接看到的信息。可能你会疑惑为什么会有这个分类，它跟上面有什么区别。
如何获取这些隐藏的信息，我个人的经验是使用工具，不管是系统还是应用都可以给我们提供很多工具，在QCon的演讲里也提到了一些。无论是系统提供的，还是第三方的，或是自己开发的都可以辅助我们发现更多的线索。
关于known-unknown只强调一点：如果要做用于排查问题的工具，若一次查询的时间超过3分钟，那在实际排查的过程中很有可能无法发挥此工具的价值。
☆ unkonwn-unknown
在高负载系统出现的问题中，有很大一部分问题的产生原因是原先根本不了解的，比如JVM里的某个Bug，或者某些内核在实现中有一些之前听都没听过的特殊机制。这个时候其实就没有很具体的方法了，不过还是说一些思路跟大家分享一下：对于这类场景可以做减法，尽可能缩小范围，当范围可控之后，再去了解相应的原理。
总结
在排查的时候大家可能会交替地遇到这几种场景，不过只要掌握诀窍，逐个击破就好。
本文节选自《高可用架构（第1卷）》
想及时了解晓通宏志更多资讯，请扫描网站右下角二维码关注“晓通宏志”官方微信。
在线留言
京公网安备 11011402013802号