系统问题排查定位流程

1. 系统问题排查范围定义

本次交流中描述的故障，主要是指系统级别的故障，对于某个具体的业务功能的故障，不在本次讨论范围内。下面描述的故障定位、排查，主要是指跨模块、跨项目级别的故障的定位、排查，包括软件、硬件的全方位的故障原因排查。侧重点是在系统的性能负荷方面的问题排查，因此，对于业务功能的跨模块方面的问题排查（例如：由于资源数据问题，导致告警中的资源数据关联失败，这个属于功能方面的问题），不在本次的讨论范围之内。

2. 系统问题排查背景

系统在正常交付运行一段时间（例如： 2天或3个月）后，突发故障（例如：现场自己巡检时发现或者用户投诉），在现场采集应急措施（例如：重启系统）后，系统可以暂时应对使用，但是，问题隐患依然存在，再次重现故障只是时间长短而已。

在出现这类问题后，如何定位、排查、消除隐患，对于大多数功能研发程序员或者现场工程人员，常常找不到头绪，无从下手，找不到突破口。为此，本次交流，描述一些常见的系统故障排查方法，以便指导各维护团队高效地排查系统故障。

对于相同的故障的表现，在不同的现场，或者在同一个现场的不同时期，产生的原因也是不同的（根据传输网管的故障排查经验，一个相同的故障出现100次，大约只有20%的原因是相同的）。因此，本次交流只是提供一个排查指导方法，学习一下系统故障排查的思维意识。

3. 案例引入：传输网管告警堆积

3.1. 案例背景

传输网管系统包括配置、性能、告警、WEB等等多个子系统，而告警是转发给其他系统的，一旦告警出现问题，一般5分钟内就会被用户发现，很快就会收到用户的投诉。因此，整个系统出现问题，或者其他子系统出现问题，导致告警子系统无法正常运转，用户不一定能够发现，投诉最多的，就是告警子系统了。而用户投诉的告警子系统的问题，基本上就是一个问题：告警挂了。下面，就围绕这个“告警挂了”这个主题，列举5个不同的原因导致的“挂”。

附加描述2下：

传输网管每天的告警量，一般都有200万以上，甚至有些省份有将近400万。而设备的性能一般，在正常时，只是能勉强运行，一旦出现了一些异常压力，例如：告警风暴，大数据统计，大配置数据同步等等，告警就无法及时处理，堆积在应用进程里，最终导致应用周转不过来，挂掉。在2014年下半年开始，统一提高了硬件配置，同样的应用，而这类的投诉却直线下降了。有的省份原来1个月投诉2次，而提高硬件环境后3个月也没有一次投诉了。

服务进程挂，并不是指服务进程不存在了，退出了，更多的是指服务不正常工作了。但是，只要服务不工作了，现场就喜欢说 “xx服务挂了，死了”之类的，真是拿这个没办法。因此，在收到现场的描述后，需要与当事人确认症状的表现，使用了什么具体的操作命令获取的结果，从而根据当事人的描述，系统员重新定义问题的症状，做到心中有数。同理，“守护”也并不是指发现进程不存在了再启动，而是根据某个症状进行后续操作。

3.2. 某个SQL语句耗时比较长造成的问题

​

上图是从告警服务的后台日志里分析出来的问题。从图上可以看到，某一个SQL语句耗时较长（大约耗时3秒），所以，导致于告警处理速度跟不上。出现这种情况一般是新上一个版本或者补丁造成的。

对于这种问题，现场人员就可以直接定位出来，通过查看SQL语句的执行计划，分析执行慢的原因。一旦问题定位了，解决方法一般就是增加索引即可，极端情况是修改应用程序，绕开耗时多的地方。容易处理的问题。

对于这种时间差相差很大的，比较容易看出，下面再举一个时间差不大的。

17:32:02.643 INFO [华为告警预处理-JN-T2000-2-P_1] CircuitQueryImplFM - SQL= select memberobjectid from ftpmembers where ftpobjectid in ('1=1','UUID:c009fe64-04ce-11e1-acfa-001f290c9939') union all select memberobjectid from ftpmembers where ftpobjectid in ( select ftpobjectid from ftpmembers where memberobjectid in ('1=1','UUID:c009fe64-04ce-11e1-acfa-001f290c9939')) 
 17:32:02.932 INFO [华为告警预处理-JN-T2000-2-P_1] CircuitQueryImplFM - SQL.RESULT=0

从告警服务的后台日志里，这个SQL语句耗时其实也不长，只有290毫秒，但是，还需要结合调用频率来综合分析。基本上每条告警都会涉及到这个语句2次，这样的量就相当大了，对数据库的开销就巨大。这种问题的发现，就需要拿出鸡蛋里挑骨头的精神来发现问题。这个问题的解决方法也类似，增加索引即可。

create index idx_ftpmembers_memberid on ftpmembers(memberobjectid) online;

update statistics for table ftpmembers(memberobjectid);

3.3. 由于某个数据引发的异常

告警运行正常了2周后，突然有一天，用户投诉告警挂了，而此期间没有更新过任何补丁，无法找出具体的原因。为此，只好先通过守护，确保告警挂了之后，不被用户发现。在守护的同时，收集告警日志，终于发现了问题。

03:30:21.647 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：1

03:30:21.938 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：1

03:30:21.957 INFO [pool-5-ForwardZHJK-2] CimInterfaceUtils - 过滤重复的电路后：1

03:30:22.010 INFO [pool-5-ForwardZHJK-2] CimInterfaceUtils - 过滤重复的电路后：1

03:30:22.695 INFO [pool-5-ForwardZHJK-1] CimInterfaceUtils - 过滤重复的电路后：26166

03:30:24.025 INFO [pool-5-ForwardZHJK-2] CimInterfaceUtils - 过滤重复的电路后：1

03:30:24.056 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：1

03:30:24.082 INFO [pool-5-ForwardZHJK-2] CimInterfaceUtils - 过滤重复的电路后：1

03:30:24.107 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：1

03:30:25.659 INFO [pool-5-ForwardZHJK-2] CimInterfaceUtils - 过滤重复的电路后：1

03:30:25.729 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：1

通过守护故障的最后挂的时间点收集到的日志里，终于发现了一个问题，是应用逻辑中，出现了一个大数据造成的。如果认为问题定位到此就结束了的话，那么，还不是一个非常合格的系统员。因为，从上面的日志可以看到，是有多个线程在并行处理的，这里只是挂掉了一个线程而已。因此，还需要进一步排查下去。

通过前期收集的日志，进一步收集证据进行辅证。终于发现了，在更多的时间里出现了类似的大数据。（gzgrep.sh是自己写的一个小脚本，从海量日志中搜索用于辅证的东西）

cswg19943#[/opt/tnms2/TNMS_LOG/backuplog]gzgrep.sh

01:18:11.215 INFO [pool-5-ForwardZHJK-5] CimInterfaceUtils - 过滤重复的电路后：26365

01:18:13.412 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：26365

01:18:16.792 INFO [pool-5-ForwardZHJK-1] CimInterfaceUtils - 过滤重复的电路后：26382

01:18:19.433 INFO [pool-5-ForwardZHJK-3] CimInterfaceUtils - 过滤重复的电路后：26382

02:20:29.444 INFO [pool-5-ForwardZHJK-5] CimInterfaceUtils - 过滤重复的电路后：26365

02:20:33.579 INFO [pool-5-ForwardZHJK-4] CimInterfaceUtils - 过滤重复的电路后：26365

02:20:38.513 INFO [pool-5-ForwardZHJK-1] CimInterfaceUtils - 过滤重复的电路后：26382

通过进一步的日志搜索，可以看到在3：00之前就已经有大数据问题出现了，只是到3：30左右，估计最后撑不住了，死掉了。

定位了问题之后，修改方法就是去查看出现大数据是否正常，如果是正常的，大数据无法避免，那么就需要去跟用户谈谈是否可以修改业务逻辑，如果不能调整业务逻辑，那么就需要改用其他方案了。对于这个问题，是通过增加临时表的方案来解决的。

3.4. 瞬间数据量异常

告警运行正常一段时间后，现场反馈说，告警延迟了，但是，现场却无法提供更多的信息，连具体是在什么时间点出现的问题都说不上来。好吧，既然现场说不上来，那就再继续观察呗。看看还能不能重现，有没有什么规律。

经过一周的时间，现场说不上来什么规律，只是经常听到抱怨说，“死，死死死，挂，挂挂挂，用户意见非常大”。好吧，那看来，这个问题很严重，必须得解决，只能靠系统员自己登录到现场环境上，寻找蛛丝马迹。终于，从数据量上找出了问题所在：

在21：08–21：13，这6分钟的告警吓人，也就是属于典型的告警风暴。而且，过一段时间就会来一次。既然发现了这个异常，把现象跟现场反映了。现场进一步查了告警量异常的时间段的告警，发现大部分告警的发生时间几乎都与北京时间不一致，发邮件找厂家整改，也让用户知悉了。整改后，系统正常。

3.5. 输出日志写入循环占用大量IO操作

用户投诉告警挂了，想从告警的后台日志来查看，但是，发现在某段时间里，告警的后台日志莫名奇妙没有备份到，而其他的时间的后台日志都能正常备份到。单独针对此现场，制定增强版本的日志备份脚本（特例特办，考虑到现场的硬盘空闲空间足够，对日志进行大冗余备份），终于找出了问题。

原来，在遇到一个特殊的数据时，出现了大循环写调试日志的情况。一共输出了46万多行的这样的调试信息，等于在刷磁盘，把磁盘的IO都全占用了，从而挤占了其他使用磁盘的功能，告警服务自然也就无法正常工作了。在正常的时候，也就只有几条这样的调试信息。

找出有问题的程序代码如下：

​ 修改方法就是注释掉这个debug输出。当然了，问题改动到这一步还没有结束，还进一步分析了数据，原来是一条测试数据造成的，把这条测试数据清理掉后，服务正常。

3.6. 大数据操作

上面的几个图并不与告警服务相关，都是跟WEB服务相关的。但是，用户投诉的是告警延迟上报。

在接到用户投诉后，先从告警服务的后台日志查看问题，找出问题时刻点与平常时刻点的日志进行对比，发现告警处理耗时普遍慢，怀疑数据库处理速度跟不上导致。于是，从数据库层面找出占用大量IO，耗时长的SQL语句，进一步定位出大SQL语句出自WEB模块，分析WEB的后台日志，定位出问题原因。修改方法就是在WEB层面进行数量限制，不允许一次进行特大数据导出，限定在5万条以内，可以分开多次执行。

4. 排查问题人员职责分工

• 系统故障排查员：

负责整个系统运行过程中的所有疑难杂症问题的定位排查，提供定位问题的证据原因（可以是历史排查问题的经验），提供程序修改方案给研发，提供调整内容给现场实施人员。排查的范围主要包括：系统整体的性能负荷分配，多个模块间的问题定位，第3方软件的问题排查，系统的硬件配置能力评估等。

• 模块维护负责人：

熟悉整个模块的开发设计，对本模块内的所有现场的问题负责，协助系统故障排查员定位排查问题。

• 模块功能研发程序员：

负责功能研发，对于初次上线的功能出现问题进行排查。

• 现场工程师：

负责发现问题，验证问题，搭建远程连接环境。负责初步排查问题，收集现场环境，描述问题，持续观察问题的发展过程。在问题解决后，积累经验以后，首先排查相同的故障是否在以前已经发生过。

5. 问题排查流程图

​

​

6. 问题排查关键点

1. 现场接到问题后，需要先自行处理一下，而不是直接转发问题。

2. 现场在上报问题时，对问题的描述的准确度，可以很大的减少最终定位问题的时间。

3. 在问题得到解决后，需要将问题的根本原因反馈到参与过解决问题的人员，积累经验，为后续自行解决提供基础。

4. 现场最好能指定一个对技术感兴趣的人，专门负责问题自行排查、归拢及经验积累的工作。

6.1. 现场人员排查关键点

1. 现场接到问题后，需要先自行处理一下，主要包括

​ a) 问题的外在直观表现，从感官上看到的问题，进行问题确认。确认问题，是可以提供具体的数据或有日志或有操作步骤的，尽量不要使用“用户说”，“有人反映”等词语。

​ b) 现场人员头脑风暴一下，最近有没有类似的问题，分析一下问题的严重性，从而决定后续工作。如果影响到业务的正常运行，需要立即重启应用，后续再收集日志。如果只是发现有隐患，可以自己分析一下，或者询问对口人员制定下一步安全措施。

​ c) 如果条件允许，尽量现场人员先内部交流一下问题。在内部交流过程中，除了可以让更多的人学习问题涨经验外，更主要的是可以通过多人的讨论，更精准的收集到问题发生时的运行背景状态。

2. 在简单粗暴的处理问题后，需要详细的描述问题并进行上报，对问题的描述的准确度，可以很大的减少最终定位问题的时间。在问题的描述中，问题目前的影响的描述很重要，对后续人员处理问题的进展以及处理方法有很大影响。

3. 在协调外部人员查看问题时，如果问题能够想办法搞到远程登录的方法，一定要提供远程连接方法，不能图个方便，认为已经提供了背景信息或者电话交流过了就OK了，实际上，同一个事情，不同的人的理解有可能是相差很大的，只有当事人亲自登录上去，重新确认。远程登录亲自操作与远程询问反馈结果比较，还有一个最大的差别就是实效性。例如，执行A、B两条命令的结果，亲自操作可以知道是间隔了多久执行的命令，执行每条命令的耗时等有个感官的认识，方便后续操作。远程登录操作还有一个好处就是可以方便进行一系列的操作，而不仅仅是局限于A、B、C命令，这对于排除疑虑具有非常大的作用。当然了，远程登录操作，还可以较大的释放现场人员的配合时间。

4. 在问题得到解决后，现场人员要积极的参与问题验证，而并不是别人说解决了就没事了。通过参与问题验证，可以学习到解决问题的思路，用到的工具，积累经验，为后续自行解决提供基础。

6.2. 研发人员排查关键点

1. 现场人员发现问题并找到研发人员后，研发人员首先要摸底这个问题是新功能还是上线使用后遇到的问题。对于很久以前已经部署，但是从未正式使用的功能，也属于新功能。

2. 对于新功能中出现的问题，重点通过操作步骤中进行排查。对于上线后遇到的问题，重点排查现场的数据引发的问题。

3. 研发人员排查问题，主要通过前台重现和后台日志文件两种方式排查问题。

4. 研发人员排查的主要是应用的功能问题，而功能上的问题更多的是由于现场的数据特性引发。因此，更多的工作是需要现场配合研发人员，协助排查数据是否有异常。

5. 研发人员也会遇到性能问题，这个可以通过后台日志，分析出哪一步耗时较多，一般都是在数据库语句上。对于耗时较多的语句，需要与现场一起配合，结合现场的数据环境重现，查看SQL语句的执行计划，找出耗时较多的原因。

6. 研发人员应重点比对出现故障时的日志和正常情况下的日志有何差异，作为排查问题的切入点之一。

6.3. 系统员排查问题顺序

1. 首先是通过某个功能的应用日志中发现问题的可能性。这一步对解决问题相当重要，但是，这一步也是技术重点，需要先了解功能的流程，才能够读懂日志。

2. 如果无法直接通过模块内日志定位问题，可以进一步发散到本子系统的日志里，有无error、exception（必须忽略大小写），先把本子系统的异常排除掉。

3. 在无法通过应用日志的方式发现问题的情况下，分析近期应用是否有更新过功能，是否有增加过功能，是否有修改过配置文件，是否有调整过什么参数，等等，从背景层面分析问题可能性。

4. 如果还是无法定位出问题，可以统计正常时的数据量和出问题时的数据量是否有20%以上的差别。

5. 如果数据量对比中，看不出问题，改成从数据库层面查找问题。先头脑风暴一下，是否存在其他子系统更新过东西，导致对数据库的开销大增，从而挤占本子系统对数据库的使用。

6. 进一步制定详细的数据库运行参数收集工作，主要包括：连接数量，耗时长语句，频率高语句。如果无法直接发现定位问题，则还需要进一步增加守护，等待问题重现，并收集信息。

7. 初期的守护是粗暴的，主要是靠人力来完成。在此期间，现场人员要高度重视问题，一旦问题重现（可能又收到了用户投诉，心理上要先有准备），立即按照系统员的要求（或者直接要求系统员登录现场），收集信息。

8. 系统员根据收集的信息，找出问题重现时的特征值，制定自动无人守护，收集常态化数据和问题时数据。

9. 系统员根据收集的数据进行对比，有可能收集的信息还无法定位出问题，则进一步修改守护脚本里的信息收集工作。

10. 在数据收集的工作中，除了收集应用相关的程序日志外，还需要同时收集数据库的运行状态，甚至还可能会需要检查操作系统层面内核参数问题，收集磁盘IO消耗、CPU利用率等指标。

11. 收集信息，除了使用操作系统提供的命令外，还可能会需要编写小工具，测试小工具的准确性（不能部署一个没有标准值的小工具），部署小工具，收集运行指标。

12. 在上面的排查过程中，随时定位问题的边界，即提供解决问题的方向，避免很多人陷入此问题中，少走弯路。

13. 在问题解决后，除了问题不再发生，还需要尽量多的从其他侧面来佐证问题得到解决。

6.4. 系统员排查关键点

1. 系统员对某个业务功能不是很了解，不如现场人员和研发人员知道的透彻，而问题通常是通过某个业务功能来投诉的。因此，系统员接收到问题后，需要首先了解出现问题时的表现，系统正常后的表现，问题解决后的验证方法。

2. 在了解了问题后，需要分析问题的背景，同时，从现场人员处获取设备部署情况，结合应用场景，从研发人员中获取日志中存在疑惑的东西。总之，从多方面获取问题现象，问题背景。特别是背景信息，越多越好。

3. 如果不是某一个很变态的业务功能导致的性能负荷压力问题，那么，摸底现场的设备能够承受的数据量，就非常关键。而这个摸底工作，能够通过自动化脚本来完成的事情，就不要找现场人员配合，就算现场人力充足也不行。自动化脚本的好处主要是：（1）会按照预定的方式在工作，不存在人员操作的二义性。（2）会按照预定的时间里工作，不存在时间周期不可控。（3）收集的信息里，90%以上都是垃圾信息，不会让人产生烦躁。（4）出现问题的时刻点，信息收集不会滞后，这个相当重要。

4. 远程登录操作，结合问题的时间点，综合查看（不能局限于某一个模块）同一时间点，是否还有其他怪异地方。从应用日志中捡漏错误或异常信息，很有必要。然后，往前查找问题爆发前的某个时间点的日志和数据量进行对比，摸底常态下系统运行指标。

5. 系统员头脑风暴定位问题非常重要，在了解了问题之后，需要立即给出一个超过50%的可能原因，并制定落实实施验证内容。

6. 如果从目前已有的信息中无法定位问题，需要收集更多的信息进行分析，这时，系统员需要在现场制定部署小工具，或者编写收集信息的小脚本，收集问题恶化趋势，找出量变到质变的临界值。由于不同的现场，设备性能和业务功能相差太大，大约50%的临界值不可复制，需要不断的摸索。也就是说，在问题解决之前，问题还会出现多次，需要告知现场有个心理预期。

7. 在多次重现问题的过程中，需要从重现过程中找时间规律，数据规律。在这个期间，问题会发生，业务的完整性会受影响，但是， 95%的不完整数据，用户是不会发现的。在这种情况下，如果能够通过守护的方法避免用户投诉，那么，就一定要制定守护措施，哪怕需要花费一天的时间来编写守护程序。

8. 问题解决后，将解决问题的方法进行总结，对小工具进行改造备用，反馈给更多的人，共同提高经验。

7. 软硬件共享部署影响

7.1. 虚拟机部署

7.2. 虚拟化平台硬件部署

在使用虚拟化平台后，一台宿主机上同时运行多个虚拟机。当虚拟机上的某个服务出现性能问题时，有可能是这个服务引发的性能问题，也有可能是宿主机上的其他虚拟机占用大量资源导致本虚拟机性能下降造成的问题。但是，公布可使用的最高权限是单个虚拟机，也就是说，只能在虚拟机内部进行操作查看，我们只能登录到这个虚拟机上进行查找定位问题，无法跨越虚拟机进一步查看是不是其他虚拟机造成的问题。

7.3. 应用软件部署

在一个综合应用系统中，应用服务程序都会分为多个子系统或多个模块，他们之间交换信息通过接口（接口服务或中间件）或共享（文件或数据库）方式。对于接口方式的数据，多存在于内存中，对于共享方式的数据，文件系统方式可以分散存储，唯独数据库方式最头疼。研发人员一般是局限在某一个模块内进行问题排查，而忽略了由于其他模块抢占数据库导致数据库性能无法满足处理条件。

8. 系统问题排查总结

1. 在分析故障原因时，通常可从一个或一系列症状入手，对它们进行跟踪以发现问题发生的原因。如果是一系列症状，也必须选定其中的一个作为切入点。切入点，一定是要那种可以量化的东西，而不能是“也许”、“估计”、“负荷高”这类的字眼。换句话说，出现这些字眼，表示问题没有辅证。

2. 寻找问题中，错误日志即是一种简单易行、快速有效的手段，通过查看错误日志往往能一针见血地迅速解决问题。换句话说，能直接通过业务的程序日志定位问题的，就不要麻烦全面排查的方式。

3. 建立故障解决、相关知识积累与共享的运维知识库，提高运维工作人员整体的工作效率。同时通过规范和明确运维人员的岗位职责，为绩效考核提供量化依据，从管理制度上调动运维人员的工作积极性。换句话说，希望每一个现场，能够出一位专门对口的人员，现场的问题能够先经过此人的过滤，由此人专门负责对外问题的联络与跟踪。

4. 罗马不是一日建成的，问题不是一下子就定位的，是要通过长期的观察，找规律，推测，佐证来实现的。就好比看病，一个疑难杂症，就算挂了一个专家号，也不是一下子就能找到病根的，也是花上时间，通过不断的监控指标的变化趋势来最终下药的。

5. 解决一个大问题，往往没有现成的大工具，相反，这就需要日常不断的积累，积累自己熟悉或百度出一些小工具，然后，再将这些小工具结合起来，也许就能成功。

6. 预防性维护。系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，即选择那些还有较长使用寿命，目前尚能正常运行，但可能将要发生变化或调整的系统进行维护，目的是通过预防性维护为未来的修改与调整奠定更好的基础。预防性维护过程中，同样会有业务数据丢失，只不过，丢失的业务数据，不影响大局。也就是说，是通过分析得失的多少来选择方案，也就是90%与10%的选择，而并不是1与0的选择。例如：告警服务通过预防性检查发现了隐患，如果继续下去的话，进程会造成挂掉，肯定引发用户投诉。如果此时立即重启的话，重启期间的数据会丢失，期间丢失的数据有可能是致命的，也有可能是无关紧要的。如果是无关紧要的数据，用户不会发现，也就不会投诉。如果刚好出现了致命的数据丢失，用户同样会投诉。因此，这其实就是一个选择题，选择不同的场景下的应对。

7. 在摸索问题时，问题的边界划分很重要，尽量少的出现致命的原则方向问题。如果对某些方向把握不准时，要通过逻辑推理+小工具实践的方式来进行。只有在边界方向定好了，才能缩短解决问题的时间。

8. 在问题解决后，除了通过问题没有再次发生外，还要尽可能的通过其他方式来佐证问题已经得到了解决。例如：可以通过程序的日志，可以收集系统的开销等等。

9. 如何能够快速地定位这些问题，分析问题发生的原因，进而快速地解决问题，恢复系统正常运行呢？这需要一定的经验积累和技巧，在积累了足够的常态数据后，头脑风暴就水到渠成了。

10. 对于系统员来说，需要将经常用到的小工具，需要整理归档好，很可能在A省份用到了，在B省份也会用到。另外，对于自己开发的小工具，要尽量具备良好的可扩展性，命令工具的使用说明可以直接通过类似help的参数来直接学习到，而不要去翻阅说明文档。打包好的小工具里不仅仅包括运行class，还要包括java源程序，因为很有可能在下次使用的时候会需要进行增强功能。

11. 对于系统员来说，运用自己已知的知识，学会变通排除问题很重要。例如：

（1）目前集中数据库是一种趋势，无法拿到数据库DBA权限，也就无法准确的获取数据库在某个时间的运行状态。这时，可以通过JDBC连接到数据库上，周期性轮询数据库的会话总数，周期性的运行一个耗时5秒左右的查询语句，将时间点，会话数，耗时长对比等信息收集到一个文件中，通过查看这些信息，获取数据库的运行状态。

（2）为了定位出是哪些SQL语句执行时间长，造成数据库的压力大，但是又无法通过DBA权限获取数据库运行报告。在这种情况下，可以通过周期性抓取当时正在执行的SQL语句，输出出来，然后，通过对比，统计出运行时间过长的SQL语句，提供给相关研发人员分析修改。

（3）目前云环境是一种趋势，云环境里最大的一个特点就是多套业务共享CPU、磁盘，而磁盘的瓶颈尤为影响大。在多套业务争抢磁盘时，为了定位出是本业务系统开销磁盘多，还是因为其他业务系统开销磁盘从而挤占本业务系统的处理能力，可以变通写一个专门测试磁盘能力的小工具，周期收集磁盘读写能力，通过数据规律结合本业务系统的业务评比，初步定位出是云环境的问题还是本业务系统的问题。

（4）数据库连接数过多，到底是什么模块占用大造成的呢？如果直接询问研发人员，估计获取不到准确可靠的消息（因为除了跟业务功能有关系，还跟现场的数据量关系更大）。这时，可以通过建立的连接的端口号，反向找出是哪个进程建立的，再定位出具体的模块进程后，进一步与研发人员分析详细信息。