对接过一些开放 api 接口后, 发现他们每个接口都会带一个 requestId
用来追溯这个请求;
非常适合 bug 的时候用来排查问题, 可以看见原始的请求响应报文从而还原一个真实的出错环境
例如:
{
"code":1,
"msg":"OK",
"data":null,
"requestId":"xxxxxxxxx"
}
但是对于这种请求日志, 量一般会特别大 文件都顶不住, 并且需要考虑到负载均衡不想每台服务器都单独记录日志; 希望他们统一保存起来 方便日后检索
有什么数据库可以实现这种?
1
ALLROBOT 2022-03-31 00:36:26 +08:00
用正则表达式匹配 bug 报告,然后保存?
|
3
tomore1 2022-03-31 00:47:27 +08:00 via iPhone
一般来说是错误的才存,正确的一般不存的;而且都有有效期,可能 1 个月后就删了,没你想象中那么大
|
4
ALLROBOT 2022-03-31 01:05:29 +08:00
蹲一个答案
|
5
fishCatcher 2022-03-31 01:23:57 +08:00 via iPhone
文件顶不住是读写还是容量?
一般是先写到共享内存里,然后另起一个进程落盘,每个小时的日志单独存储一个文件。单机容量存 1 到 3 天的日志应该还是能顶住的,这样上机器查问题也比较方便。 后续要把这些日志都扔到 es 里面,一个 id 可以把整个链路查出来。 |
6
xuanbg 2022-03-31 06:42:24 +08:00
elk
|
7
lizuoqiang 2022-03-31 09:43:50 +08:00 1
文件顶不住? 那怕找不到几个顶得住的哦。 推荐就是 ELK 那一套,filebeat 采集 elasticsearch 存储 kibana 做可视化
|
8
meshell 2022-03-31 11:20:44 +08:00
难道是要 ELK
|
9
Xusually 2022-03-31 11:21:39 +08:00 via iPhone
多大的量?文件顶不住?
|
10
markgor 2022-03-31 13:32:20 +08:00
刚好之前自己遇到过,
一开始单独接口写日志,规划如下: /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 个月的交易请求日志。 |