各位大佬 请教一个 PHP 记录 api 日志的问题

[edk24]

对接过一些开放 api 接口后, 发现他们每个接口都会带一个 requestId 用来追溯这个请求;

非常适合 bug 的时候用来排查问题, 可以看见原始的请求响应报文从而还原一个真实的出错环境

例如:

{
	"code":1,
    "msg":"OK",
    "data":null,
    "requestId":"xxxxxxxxx"
}

但是对于这种请求日志, 量一般会特别大 文件都顶不住, 并且需要考虑到负载均衡不想每台服务器都单独记录日志; 希望他们统一保存起来 方便日后检索

有什么数据库可以实现这种?

[ALLROBOT]

用正则表达式匹配 bug 报告，然后保存？

[edk24]

@ALLROBOT 不是这个意思, 是想实现类似阿里云 腾讯云(CLS)的统一日志服务;

[tomore1]

一般来说是错误的才存，正确的一般不存的；而且都有有效期，可能 1 个月后就删了，没你想象中那么大

[ALLROBOT]

蹲一个答案

[fishCatcher]

文件顶不住是读写还是容量？
一般是先写到共享内存里，然后另起一个进程落盘，每个小时的日志单独存储一个文件。单机容量存 1 到 3 天的日志应该还是能顶住的，这样上机器查问题也比较方便。
后续要把这些日志都扔到 es 里面，一个 id 可以把整个链路查出来。

[xuanbg]

elk

[lizuoqiang]

文件顶不住？ 那怕找不到几个顶得住的哦。 推荐就是 ELK 那一套，filebeat 采集 elasticsearch 存储 kibana 做可视化

[meshell]

难道是要 ELK

[Xusually]

多大的量？文件顶不住？

[markgor]

刚好之前自己遇到过，
一开始单独接口写日志，规划如下：
/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 个月的交易请求日志。

[tomore1]

@markgor 确实，如果错误日志特别多，，，那显然代码有问题了，，，数据打点分析类的日志才要全量保存，不过这种显然不是存本地了

[markgor]

@tomore1 #11 哈哈哈，是啊，我前段时间就是困在这，根本原因在于自行部署日志分析系统成本太高了，还不如直接用第三方的。