这是一个创建于 955 天前的主题，其中的信息可能已经有所发展或是发生改变。
对接过一些开放 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 个月的交易请求日志。 |
Select Language