web项目开发写接口时，为什么需要在关键位置打印日志-2022新项目

一、业务场景

　　最近在开发新功能，新功能主要就是写app的首页查询接口，接口比较多有十几个，首页会有各种查询，新增操作比较少。由于用户量

比较大，据说并发量不小，所以首页的很多查询都做了缓存处理，用来提升查询效率。这次写的接口还是比较复杂，需要进行数据的各种处理，

比如排序，过滤，各种其他业务的处理。并且调用的时候，不是自己项目调用，而是提供给其他项目组调用，需要进行联合调试。

二、需求分析

　　项目的大致调用情况如下:

 　　自己所在的项目组属于项目B这个位置，数据首先从项目A过来，然后在项目B这里存储、加工处理后，在给项目C提供调用，最后返回

给APP.这其中还是省略了各种网关拦截之类的操作。总之APP想拿到项目B的数据，经过的流程会比较多，如果任意一个环节出现问题，都有

可能导致手机APP获取不到数据。因此在写调用接口的时候，打印日志就很有必要了，主要作用就是用于排查问题。如果出现问题之后，排查

问题最简单、快捷的方式就是通过日志来定位问题。由于项目的限制，生产环境的数据库是看不了的，只能通过日志来进行排查问题。

三、解决方案

 　　那写接口的时候，需要打印哪些日志呢？

.a.第一个地方就是请求参数的日志，请求一个接口时，参数信息有哪些，这个是在排查问题的时候，首先要看的关键信息。可以查看请求的参数

对不对，是不是符合接口的要求等等。

.b.第二个需要打印日志信息的地方就是获取的数据信息，比如某一个接口请求时，返回的数据信息。如果信息信息比较多，则只需要打印返回的

数据量信息即可，比如返回多少条，或者打印其中一条数据信息。数据处理的时候，一般都是统一处理，如果某一条数据没问题，那其他数据也

不会有问题。在比如新增数据的时候，将新增数据返回的ID打印在日志中，非常方便排查问题。

.c.第三个需要打印的就是关键位置的操作，比如从缓存中获取数据时的key信息，需要打印到日志中；获取的一些关键的缓存数据也需要打印在

日志中，可以排查缓存中的数据是否正确。自己在进行数据过滤之前会打印一下数据总数，数据返回前会打印一下数据的总数，看看是否正常。

在进行过滤操作的时候，如果有明显异常的操作，也会打印错误日志。

.d.异常信息需要打印在日志中，将异常信息打印在日志中，非常有助于排查具体问题，到底是哪些原因引起的异常等等。

.e.一些比较耗时的操作或者是非常重要的操作，添加一个操作时间统计，便于排查、分析某个操作所花的时间是多久，是否影响程序的正常执行等等。

上面就是自己在开发中打印日志的一些操作，有更好建议的小伙伴欢迎留言讨论。

 

2022-10-23.

　　记录最近几次真实问题排查的情形。

情形一：测试人员在测试系统性能的时候，发现有两个接口的性能不达标，让我们开发人员去排查是什么原因导致的。自己拿到接口信息之后，立即去

排查问题，因为这两个接口都是自己写的，对于接口里面的逻辑还是比较清楚的。问题是出在将我们的系统迁移到一个新的服务器上去之后，查询才变

得非常缓慢，有几次请求差不多大概20S的时间，虽然有些夸张，但这也是事实。

　　首先能够想到的就是查看日志，可是自己没权限查询新服务器的日志，只能等待负责人去进行查看日志信息。不久之后，负责人发了几张日志的截图

丢在群里面，从打印的日志信息来看，自己写的代码打印的日志还不足以排查当前遇到的问题。这就很尴尬，没办法只能继续添加打印的日志，然后重新

部署后去查看日志信息。在这个接口中，调用了多个方法来处理数据，比如A->B->C->D等等，首先获取数据，可能是从缓存中取的，也可能是查询数据库的。

其次是数据过滤，再次是数据处理，最后一步是数据转换。由于自己只打印了少量日志，不能准确的判断出问题是出在哪里。改进后，在这四个方法后面

都添加了关键位置的日志打印信息，就可以知道每一个方法执行时所花的时间大概是多少。重新部署后，再次测试，果然发现问题，问题就出在数据过滤

的时候，执行时间太久导致出现问题。找准问题后，自己也知道怎么去优化代码，从哪里下手，花了约一个小时之后，问题解决。

　　自己从这次吸取到的经验教训就是，关键位置一定需要打印日志，这非常有助于排查各种BUG，不然之后这些地方的日志也需要重新补上，这样才能

较为准确的去定位错误信息，才能更好的判断是什么原因导致的问题。问题找到后，修复问题相对来说就会轻松一些。