日志要分三类收
推理服务的日志至少分三类：引擎应用日志、网关访问日志、系统内核与驱动日志。三类统一打上实例、版本与时间标签后集中检索，保留周期按磁盘容量与合规要求分别设定。少收一类，出事时就会缺关键证据。
基本信息
| 第一类 | 引擎应用日志 |
|---|---|
| 第二类 | 网关访问日志 |
| 第三类 | 系统内核与驱动日志 |
| 统一标签 | 实例、版本、时间 |
| 保留策略 | 按类型分别设定 |
典型使用场景
- 排查推理失败时需要关联引擎与应用两侧
- 确认流量形态靠访问日志
- 查硬件事件必须看内核日志
- 合规审计要求访问日志按周期保留
- 把日志检索入口写进值班手册，出事时不用现找
- 定期抽样检查采集完整性，确认三类日志都在进来
系统侧常用命令
系统侧常用命令
journalctl -u <服务名> -n 100 --no-pager
dmesg -T | tail -50
# 采集管道不要把内核日志里的驱动报错行过滤掉三类日志各管什么
| 类型 | 主要内容 | 典型用途 |
|---|---|---|
| 应用日志 | 请求处理与异常栈 | 定位业务失败 |
| 访问日志 | 状态码与耗时 | 流量与错误统计 |
| 内核日志 | 驱动与硬件事件 | GPU 故障取证 |
内核日志里的驱动报错行是 GPU 故障的关键证据：采集管道别把它过滤掉，出事后也无法补采。
保留策略按类型区分：错误与告警长留，访问日志按合规周期滚动，避免全量长期堆积拖垮检索性能。
日志里避免记录完整提示词与用户内容：既要考虑隐私与合规，也要控制体积，通常只记标识与长度。
多机部署要集中采集：在多实例环境下逐台翻日志效率极低，先集中再检索。
关键字段尽量固定下来：字段一改，跨版本、跨实例的对比就全部失效，需要重新对齐口径。