前言

日常Bug排查系列都是一些简单Bug排查，笔者将在这里介绍一些排查Bug的简单技巧，其中不乏一些看起来很低级但很容易犯的问题。

问题现场

有一天运维突然找到我，要我协助排查一个问题。业务开发怀疑Nginx会重复相同的请求，就感觉Nginx自己重试了一样。而PE给我看了下他们的配置，并没有配置任何重试。

第一感觉

我第一感觉就是应该不是Nginx的问题。但是开发怎么得出Nginx重试这个结论的呢？

跟随业务开发思路

于是笔者翻了下他们的邮件，他们是通过PE提供的Nginx Access日志和业务应用日志来推断的。其中搜索Nginx用了grep '30/Nov/2999 07:33:45' access.log | grep '业务条件' 这个命令。发现在这一秒内，对应的业务日志有两笔，而access.log只有一笔。

从日志上搜索确实如此。但笔者看了他们的搜索命令后，就发现他们犯了一个很常见的问题。那就是，请求会跨秒！

请求跨秒了

这是个很常见容易犯的错误，尤其是在请求有几百毫秒响应时间的情况下。于是笔者用grep搜索了下一秒的access.log中的数据。

很明显的，由于第二个请求花了641ms,导致access.log落在了46s的区间。grep 45s是无法找到这个请求的。

总结

日志是我们排查问题的重要手段，在海量的日志提取信息时候必须考虑好过滤条件。如若不然，则会影响我们的判断。