从接口异常说说线上问题排查流程

接口超时或异常（以下统称异常），是线上经常遇到的问题，本文探讨如何快速定位线上接口异常问题以及从哪些方面完善监控基础设施，提高服务可观测性，最后介绍排障最佳实践和常见误区。

定位问题步骤

确认异常的影响范围？故障发生后，首先要快速评测故障的影响面，可以根据用户的反馈，故障通报邮件，系统监控面板，以此决定是否提升故障等级和快速制定应对措施。故障影响范围，可以通过以下几个问题阐述，所有用户还是部分用户？所有机房还是单个机房？所有实例还是单个实例？所有接口还是单个接口？

确认调用链中异常的环节？一个请求从客户端打到后端服务，要经历 DNS 解析，多级路由转发和服务调用，任何一个环节都有可能导致调用异常，所以，结合客户端异常信息和调用链监控快速锁定故障所在的环节是必要的。

确认异常的具体原因？锁定故障的具体节点后，需要结合多层次的监控指标，分析产生异常的根本原因。这个过程可能会因为监控基础实施不完善，异常不可重现等原因，花费较长时间。

举 2 个现象相同，原因不同接口异常的例子，现象都是用户侧某接口，在某个时间点，大量超时，持续数秒后自动恢复。通过链路分析和维度分析，最终定位到都是访问某 1 个实例时，上游服务出现了异常，只是具体异常信息不同。

Case1：SocketTimeoutException: Read timed out ，通过查看实例 JVM 监控，发现故障期间，实例正在进行 FULL GC，大约持续了 6s，期间不能正常响应。

Case2：SocketException：Connection reset，查看实例时，发现实例已经被异常终止，实例从注册中心剔除前，打到该实例的请求都会失败。查看实例所在宿主机监控，发现宿主机期间发生重启。

完善监控基础设施

全链路监控。很多时候，一个客户端请求会拆分成多个后端服务调用，网络拓扑结构会很复杂，为了快速定位调用链中的故障点，完善的调用链监控是必要的。当上下游业务方无法理清请求超时的责任方时，一起接入链路监控是不错的选择。业界知名的链路跟踪系统有 Zipkin（Twitter），jaeger（Uber），CAT（大众点评），SkyWalking（Apache），鹰眼（阿里）等。选择链路监控系统时，必须要考虑业务方接入成本，代码侵入性，建议公司范围内选型，所有业务线推广，仅有少量的几个系统接入意义并不大。

多维度监控。故障发生后，为了快速确认异常的影响范围，需要从不同维度查看异常情况。这就要求监控指标支持按照不同维度进行聚合。Prometheus 的多维度数据模型是指标监控的事实标准。指标监控的指标定义，大体包括容量（QPS），耗时（MEAN，TP99），错误量（500 状态码，方法异常等）和资源（CPU 利用率等），业界基本形成共识。而作为指标监控的核心，根据实际情况，定义清晰明确的维度，尤为重要。常见的指标维度有机房，服务名，机器，URL 等。

多层次监控。我们知道软件是分层的，任何一层出现故障，都会导致服务不可用。比如，一个运行在容器里的 java 应用，除了需要监控应用本身的接口请求外，既要对 JVM（GC，堆大小，线程数等）进行监控，也要对宿主机（内存，负载，IO）进行监控。再比如，针对数据库的访问监控，除了客户端的访问耗时，连接池监控，服务端的连接数，吞吐量，慢查询等更加重要。

日志流监控。日志监控提供最细力度的问题记录，是最基本的监控手段。通常是通过其他方式大体定位问题范围后，查看日志确定具体原因。或者是，其他监控基础设施不完善情况，只能通过日志排查定位。为了通过日志宏观分析故障影响范围，日志集中化管理和结构化存储是非常必要的，这样可以根据不同维度，聚合日志事件，大体判定故障的影响范围。

排障最佳实践

减少影响，恢复故障是首先要考虑的。故障发生后，大体判定故障影响和范围后，应该首先考虑恢复故障，减少用户影响，而不是定位故障的具体原因。对于不好重现的故障，应该快速保存故障现场（比如，dump 堆栈）后，恢复故障（比如重启）。

及时同步沟通排障进展，相信团队的力量。排障过程中，注意及时同步排障进展，通过团队讨论，及时排除掉干扰因素，靠团队积累和智慧朝正确方向努力。

基于事实而不是猜测。这点非常重要，不要基于已往经验猜测故障的可能原因，而是要基于客观事实，比如日志异常信息，系统负载时序图等。

排除无关因素的干扰。引起系统异常的原因，通常是多方面的，比如偶发接口超时，网络波动，系统负责高，JVM GC 等，依赖第三方接口响应慢等都有可能触发，故障发生后，应该尽量排除非主要因素的干扰，优先分析解决核心故障因素。

排障过程复盘总结，根本上解决问题。故障恢复或故障原因排查，不是故障处理的结束。好的排障习惯是，故障处理过程中，记录所有异常快照和疑问点，故障恢复后，复盘排查过程，一一解释各个异常点，思考后续排障可以优化的点，是否可以更快恢复故障和定位原因。如果因为监控基础设施不完善而影响排障进度，要确定后续优化措施。

排障常见误区

哪个是因哪个是果？故障发生后，可能会导致其他指标异常，所以，分析故障时，需要分清因果，避免把故障结果当成故障原因。比如宿主机系统负载升高和 JVM 线程数陡增，具体哪个是因，哪个是果，需要结合时间点和其他指标判断。

没有错误不代表没有问题。如前面举例，JVM 发生 GC 时，如果我们只是分析应用日志，并不容易发现问题，应用日志并不会报错。如果我们通过指标监控，分析该实例的错误量，也不会发现错误，因为 GC 期间，应用拒绝响应所有请求，包括我们用来收集指标的/prometheus 端点。所以说，没有错误不代表应用本身没有问题，有异常也不代表应用本身有问题，可能是依赖的系统拒绝响应。