【借力打力】记一次由于堆栈信息不详细的错误排查方法，利用访问日志进行定位问题

堆栈信息不详细的错误排查方法，利用访问日志进行定位问题"/>

【借力打力】记一次由于堆栈信息不详细的错误排查方法，利用访问日志进行定位问题

【借力打力】记一次由于堆栈信息不详细的错误排查方法，利用访问日志进行定位问题

• 1，背景
• 2，排查步骤
• • 2.1 调用方问题
  • 2.2 Nginx手段
  • 2.3 运维工具辅助
  • 2.4 嵌入tomcat日志记录
• 3，结果

1，背景

异常信息每隔50分钟显示一次，如图所示。

能够看出是控制器上出现参数转换失效的问题，但是具体的是哪一个控制器在异常堆栈信息中也没有打印出来，这给问题定位带来了一定的难度。

2，排查步骤

2.1 调用方问题

系统接收几个供应商的数据推送，推送失败的会进行数据补偿，首先想到是不是某个供应商推送数据失败，使用调度任务每隔50分钟进行请求，导致一致出现数据失败和请求。这种情况不好排查，但是还是咨询了其中一个，他的日志没有出现异常，但他提供了一个很好地思路，使用Nginx进行定位。

2.2 Nginx手段

通过Nginx的代理访问日志文件能够看到接口调用的详情，但是笔者的Nginx没有对特殊的后端接口进行代理，该方法本来是一种很好地方法，但是在这种情况下失效了。

2.3 运维工具辅助

想到运维人员记录了访问日志，反馈的结果就是没有在给定的时间范围内没有发现数据交互。排除了外来供应商调用接口的情况。

2.4 嵌入tomcat日志记录

既然通过Nginx的代理可以进行排查，于是想到了利用tomcat进行问题定位，举一反三，通过以下配置进行开启。

开启嵌入tomcat配置项为：

server:#开启tomcat日志记录功能tomcat:basedir: C:\zcadmin\zcAdmin-logs\tomcatbackground-processor-delay: 30port-header: X-Forwarded-Portprotocol-header: X-Forwarded-Protoprotocol-header-https-value: httpsredirect-context-root: trueremote-ip-header: X-Forwarded-Foruri-encoding: UTF-8accesslog:enabled: truebuffered: truedirectory: .\logfile-date-format: .yyyy-MM-ddpattern: '%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-Agent}i" %D ms'prefix: access_logrename-on-rotate: falserequest-attributes-enabled: falserotate: truesuffix: .log

打印的日志格式为：

127.0.0.1 - - [03/Nov/2023:15:05:06 +0800] "GET /api/big-screen/getLatestAssetAlertLog HTTP/1.1" 200 5532 "http://localhost:8013/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" 16 ms

3，结果

通过时间戳就可以锁定异常调用的接口。