日志断档怎么排
日志丢失按「设备产生 → 传输 → 接收 → 入库」四段排查：设备侧确认有没有产生、有没有真的发出；链路侧确认中间设备是否把它拦了；接收侧确认服务进程、磁盘与解析是否正常；入库侧确认轮转与保留策略没有把日志正常删掉。
优先怀疑两处
现场排查时先怀疑两处：中间链路的策略变更把日志端口拦掉了，以及日志服务器磁盘写满后接收进程静默丢弃日志。这两类原因不会在设备上留下任何异常提示，设备显示「一直在发送」，平台却什么都没有，最容易让人误判成设备故障。
基本信息
| 设备段 | 外发功能是否开启、级别是否过低、发送计数是否增长 |
|---|---|
| 链路段 | 中间设备的端口策略、地址转换、带宽占用 |
| 接收段 | 服务进程状态、监听端口、磁盘空间、解析错误 |
| 验证手段 | 在设备出口与服务器入口分别抓包，确认报文是否发出与收到 |
典型使用场景
- 日志平台上一个时段整段缺失
- 单台设备日志消失，其他设备正常
- 设备显示在发送但平台收不到
- 平台磁盘写满后日志静默丢失
- 变更网络策略后日志中断
- 轮转周期调整后历史日志无法检索
排查顺序
排查顺序
# 1. 设备侧确认有日志产生（对照本地缓冲区与发送计数）
# 2. 在设备出口抓包，确认报文是否真的发出
# 3. 在服务器侧抓包，确认是否收到
# 4. 检查接收进程、监听端口、磁盘空间与解析规则
# 5. 核对轮转与保留策略，排除「日志被正常删除」分段与典型原因
| 分段 | 典型原因 |
|---|---|
| 设备段 | 外发未开启、级别设置过低导致没有生成 |
| 链路段 | 中间设备策略拦截、地址转换改变源地址 |
| 接收段 | 服务未运行、监听端口不符、本地防火墙拦截 |
| 入库段 | 磁盘写满、解析失败、轮转删除过快 |
UDP 传输的丢失量可以用设备侧发送计数与服务器接收计数对比估算，不必逐条比对。
先怀疑设备不产生日志、实际是链路被策略拦截，是最常见的排查方向跑偏，双向抓包能立刻纠正。
日志接收端口与来源地址的变更要留记录：安全策略调整与日志中断之间的时间关系，是排查中最有价值的线索。