📚 课程目录第4章日志采集与存储

4、日志采集与存储：日志采集方式（文件、syslog、agent）、传输协议、集中存储方案（ELK、Loki等）

在旭日设备的日常运维中，日志是判断系统健康状态、追踪模型推理异常、定位现场故障的第一手证据。然而，设备往往分散在不同网络区域，日志格式千差万别，从内核的 dmesg 输出到应用层的 inference.log，再到网络设备的 Syslog 报文，若缺乏统一的采集与存储体系，排障将如同大海捞针。本章将围绕日志的采集方式、传输协议以及集中存储方案展开，帮助运维人员构建一条从设备现场到分析终端的可靠日志链路。

上图展示了日志从采集、传输到存储的完整链路。在实际运维中，我们需要根据设备性能、网络状况和日志重要性，灵活选择采集方式与传输协议。下面将逐一展开说明。

4.1 日志采集方式：文件、Syslog 与 Agent 的选型逻辑

核心原理：日志采集的本质是解决“日志在哪里”和“如何高效读取”的问题。旭日设备通常包含三类日志源：应用日志（如模型推理的输入输出、异常堆栈）、系统日志（如内核消息、服务状态）、网络设备日志（如交换机、防火墙的 Syslog）。不同的日志源决定了采集方式的选择。

文件采集：适用于应用日志，通过 tail -F 或 Filebeat 等工具持续监听日志文件的增量内容。优点是无需修改应用代码，缺点是占用少量 I/O 资源，且对日志轮转（logrotate）需要特殊处理。
Syslog 采集：适用于网络设备和 Linux 系统日志。设备通过 UDP/TCP 514 端口主动发送日志到采集服务器。优点是标准化程度高，缺点是 UDP 模式下可能丢包，且日志内容缺乏结构化。
Agent 采集：适用于需要深度定制的场景，如采集 GPU 利用率、模型推理延迟等指标。Agent 通常以守护进程方式运行，支持插件化采集，但会占用设备 CPU 和内存资源。

判断方法：在选型时，可参考以下决策流程：

若日志以文件形式存在且格式固定，优先选择文件采集（如 Filebeat）。
若设备支持标准 Syslog 协议且日志量不大（< 1000条/秒），可选择 Syslog 采集。
若需要采集系统指标（CPU、内存、GPU）或自定义事件，则必须使用 Agent。

采集方式	适用场景	资源占用	可靠性	典型工具
文件采集	应用日志、模型日志	低	高（可记录偏移量）	Filebeat, Fluentd
Syslog	网络设备、Linux 系统	极低	中（UDP 可能丢包）	Rsyslog, syslog-ng
Agent	指标采集、自定义事件	中	高（可缓存重传）	Telegraf, Node Exporter

经验提醒：对于旭日设备上的模型推理日志，建议使用文件采集方式，并配置 ignore_older 参数（如 24 小时），避免采集过期日志浪费资源。同时，务必开启文件采集的“日志轮转”支持，防止日志文件被切割后采集中断。

4.2 传输协议：从 UDP 到 Kafka 的可靠性演进

核心原理：日志传输协议决定了日志从设备到集中存储的“运输方式”。选择的关键在于平衡实时性与可靠性。UDP 传输延迟低但可能丢包，TCP 传输可靠但占用连接资源，而消息队列（如 Kafka）则提供了削峰填谷和异步解耦的能力。

操作流程：在旭日设备现场，建议按以下步骤配置传输：

评估日志量：通过 wc -l /var/log/xxx.log 或监控工具估算峰值日志速率（条/秒）。
选择协议：若速率 < 500 条/秒，使用 TCP 直连；若速率 > 2000 条/秒，建议引入 Kafka 作为缓冲层。
配置 TLS：对于包含敏感信息的日志（如模型输入数据），必须启用 TLS 加密传输，防止中间人窃听。

# Filebeat 输出到 Kafka 的配置示例
output.kafka:
  hosts: ["192.168.1.10:9092", "192.168.1.11:9092"]
  topic: "rixu-device-logs"
  partition.hash:
    reachable_only: true
  compression: gzip
  max_message_bytes: 1000000
  required_acks: 1

风险提示：切勿在生产环境直接使用 UDP 传输关键日志（如设备异常掉电记录）。UDP 在突发流量下丢包率可达 5%-10%，且无法追溯。若必须使用 UDP，务必在接收端增加“日志序号”校验，以便发现丢失并触发补拉。

4.3 集中存储方案：ELK 与 Loki 的架构对比与实战

核心原理：集中存储的核心目标是解决“日志去哪查”和“如何快速查”。ELK（Elasticsearch + Logstash + Kibana）是经典方案，提供全文检索和复杂聚合；Loki 则采用标签索引 + 对象存储，更轻量且与 Prometheus 生态无缝集成。

案例拆解：某旭日设备现场出现模型推理偶发超时，需要定位是硬件故障还是模型版本问题。运维团队采用 ELK 方案，具体过程如下：

背景与约束：设备分布在 3 个机房，共 120 台，日志量约 800 GB/天。现有 Grafana 监控面板已展示 CPU 和内存，但缺少日志关联。
初始现象：用户反馈“推理响应时间从 50ms 波动到 2s”，但监控指标显示资源使用率正常。
关键数据：通过 Filebeat 采集 /var/log/rixu/inference.log，日志中包含 model_version、latency_ms、device_id 字段。
分析判断：在 Kibana 中按 model_version 分组统计平均延迟，发现 v2.3.1 版本的延迟明显高于 v2.3.0。进一步查看日志，发现 v2.3.1 版本在每次推理前会额外加载一个 200MB 的字典文件，导致首次推理延迟增加。
实际操作：在 Kibana 中创建可视化仪表盘，将 latency_ms 与 model_version 关联，并设置告警阈值（p99 > 500ms）。同时，在 Logstash 中增加 grok 解析规则，提取 model_version 字段。
结果对比：定位问题后，开发团队优化了字典加载逻辑，延迟恢复至 50ms 左右。后续通过 ELK 的告警规则，提前发现其他设备上的同类问题。
风险与代价：ELK 集群需要至少 3 个 ES 节点（16GB 内存以上），且索引生命周期管理（ILM）需定期清理旧索引，否则磁盘占用会持续增长。

ELK 与 Loki 的选型对比：

维度	ELK	Loki
索引机制	倒排索引，全文检索强	标签索引，仅索引标签
存储成本	高（需 SSD 加速）	低（对象存储即可）
查询语法	Lucene / KQL	LogQL（类 PromQL）
适用场景	复杂聚合、业务分析	K8s 环境、快速排障
运维复杂度	高（需管理 ES 集群）	低（单二进制文件）

  实战建议：对于旭日设备运维，若已有 Grafana 监控体系，优先选择 Loki 作为日志存储，因为它可以直接复用现有的告警规则和仪表盘。若需要深度分析日志内容（如 SQL 注入检测），则 ELK 更合适。无论选择哪种方案，都建议在采集端统一使用 JSON 格式输出日志，便于解析。

4.4 常见误区与总结复盘

常见误区：

误区一：所有日志都采集。实际上，debug 级别日志量是 info 的 10 倍以上，应仅在生产环境采集 info 及以上级别。
误区二：忽略日志时区。旭日设备可能跨时区部署，若不在采集端统一转换为 UTC 或本地时间，排障时会出现时间错乱。
误区三：存储无限期。日志应设置保留周期（如热数据 7 天，冷数据 30 天），否则存储成本失控。

总结复盘：日志采集与存储的最终目标是“在需要时能快速找到证据”。建议运维团队定期（每月）进行日志链路演练：模拟一台设备日志中断，检查采集端是否告警、存储端数据是否完整。同时，建立日志字段规范，确保 device_id、model_version、timestamp 等关键字段在所有日志中保持一致，这是后续自动化排障的基础。

风险说明：当使用 Agent 采集时，务必设置资源限制（如 CPU 最大 5%、内存最大 200MB），防止 Agent 异常占用导致设备推理性能下降。建议在 Agent 配置中启用 cpu_quota 和 mem_limit 参数。