对接过一些开放 api 接口后, 发现他们每个接口都会带一个 requestId 用来追溯这个请求;
非常适合 bug 的时候用来排查问题, 可以看见原始的请求响应报文从而还原一个真实的出错环境
例如:
{ "code":1, "msg":"OK", "data":null, "requestId":"xxxxxxxxx" } 但是对于这种请求日志, 量一般会特别大 文件都顶不住, 并且需要考虑到负载均衡不想每台服务器都单独记录日志; 希望他们统一保存起来 方便日后检索
有什么数据库可以实现这种?
 | 1 ALLROBOT Mar 31, 2022 用正则表达式匹配 bug 报告，然后保存？ |
 | 3 tomore1 Mar 31, 2022 via iPhone 一般来说是错误的才存，正确的一般不存的；而且都有有效期，可能 1 个月后就删了，没你想象中那么大 |
| 4 ALLROBOT Mar 31, 2022 蹲一个答案 |
 | 5 fishCatcher Mar 31, 2022 via iPhone 文件顶不住是读写还是容量？ 一般是先写到共享内存里，然后另起一个进程落盘，每个小时的日志单独存储一个文件。单机容量存 1 到 3 天的日志应该还是能顶住的，这样上机器查问题也比较方便。 后续要把这些日志都扔到 es 里面，一个 id 可以把整个链路查出来。 |
 | 6 xuanbg Mar 31, 2022 elk |
 | 7 lizuoqiang Mar 31, 2022  1 文件顶不住？ 那怕找不到几个顶得住的哦。 推荐就是 ELK 那一套，filebeat 采集 elasticsearch 存储 kibana 做可视化 |
 | 8 meshell Mar 31, 2022 难道是要 ELK |
 | 9 Xusually Mar 31, 2022 via iPhone 多大的量？文件顶不住？ |
 | 10 markgor Mar 31, 2022 刚好之前自己遇到过， 一开始单独接口写日志，规划如下： /var/log/api_xxx/YMD/requestID.log 出现异常硬盘 block 不够 后来修改为 /var/log/api_xxx/YMD.log 出现 YMD.log 文件过大，查找时困难 后来修改为 /var/log/api_xxx/YMD/req.log 每超过 5MB 则 rename 后再新建一个 req.log 发现硬盘不到 10 天就被打满了 最后直接用了腾讯云的日志服务.... 另外 @tomore1 #3 的不够全面，很多时候异常的报错是会实时触发通知，不是靠日志查的， 而靠这些日志查的一般是定责问题， 比如我和 JD 直连，下单后传订单去 JD ，JD 接口确认价格信息后确定了订单返回确认，但后续 JD 取消了订单并表示从未接收过创建请求，此时就需要查这种日志，找出确定订单请求的那个，提供给 JD 。 上面举例不够严谨，这种一般酒店预订类的会出现，立即确定的房型哪怕是代理放错价格，只要来单了就不能拒单，供货不了就要赔偿，结算周期一般是月的，所以一般保存 3 个月的交易请求日志。 |
Select Language