断网、断电，不断数据——LoongCollector 极限边缘场景可靠采集方案

背景

在云计算和物联网快速发展的今天，越来越多的业务场景将计算和数据采集能力推向了边缘侧。从智能制造的产线设备、新能源汽车的车载系统，到遍布各地的零售终端和智能家居设备，这些终端设备产生的可观测数据（日志、指标、追踪）对于业务运营、故障诊断和用户体验优化至关重要。

然而，终端设备的环境极其复杂：

• 网络环境不稳定：终端设备常常运行在弱网、间歇性断网的环境中。移动网络信号波动、WiFi连接不稳定、跨地域网络延迟高等问题普遍存在。
• 电源供应不保障：许多终端设备依赖电池供电或面临意外断电风险。
• 资源极度受限：边缘设备的 CPU、内存、存储、网络带宽都极为有限。

在这种极限条件下的可观测数据采集面临极大的挑战。比如车辆在偏远地区行驶时，长时间处于弱网或断网状态，网络信号时断时续，车辆熄火断电时，内存中缓存的监控数据全部丢失；在隧道、地下停车场等场景下，数据采集中断，关键的故障诊断数据无法回传。

本文将详细介绍 LoongCollector 如何针对弱网、断电等边缘场景，提供完整的可靠采集解决方案。

终端设备可观测数据采集的三大挑战

挑战一：复杂的网络环境

终端设备运行环境的网络条件远比数据中心复杂：

• 弱网场景：移动网络信号不稳定、WiFi 信号弱、跨地域长链路等导致网络带宽低、延迟高、丢包率高。
• 间歇性断网：设备移动、网络切换、临时性网络故障导致周期性网络中断。
• 长时间离线：某些场景下设备需要长时间离线工作，积累大量待上传数据。

比如车载终端设备在偏远地区运输途中，可能很长时间都处于弱网或断网状态，网络正常的状态很少；在车辆熄火或者维修的情况下，车载终端设备也会断电。

挑战二：可观测数据可靠交付

在弱网、断电等不稳定环境下，保证数据的可靠交付和一致性是最大的挑战：

• 数据丢失风险：网络中断、设备断电、进程异常等都可能导致数据丢失。
• 顺序性保障：时序数据（如指标、追踪）需要保持采集时的时间顺序。

挑战三：网络带宽限制

终端设备的网络带宽通常受到严格限制：

• 流量成本高：4G/5G 移动网络的流量费用远高于数据中心专线。
• 带宽竞争：采集数据上传需要与业务数据传输竞争有限的带宽资源。
• 上传速率限制：某些运营商或网络环境会对上传带宽进行限制。

在这样的环境下，如何高效压缩数据、智能控制发送速率、避免带宽被采集流量占满，成为必须解决的问题。

LoongCollector：

为边缘场景优化的可靠采集方案

LoongCollector 是阿里云开源的高性能、高可靠可观测性数据采集器，在支撑阿里云内部千万级规模部署的同时，针对边缘场景进行了深度优化。

核心能力概览

统一的可观测数据采集

LoongCollector 提供了完整的可观测数据采集能力：

• 主机监控：实时采集 CPU、内存、磁盘、网络等系统指标，支持 100+ 系统指标项。
• Prometheus 协议：完全兼容 Prometheus 生态，可采集所有支持 Prometheus 采集的应用指标。
• 日志采集：高效的文本日志采集能力，支持多种日志格式和解析方式。

超低资源消耗

针对资源受限的终端设备，LoongCollector 进行了极致的性能优化：

这意味着在相同的硬件条件下，LoongCollector 可以支持更多的采集任务，或者在资源更受限的设备上稳定运行。

企业级稳定性保障

• 生产级验证：支撑阿里云内部 1000 万+ 实例的可观测数据采集。
• 高可用性：单实例高可用性，支持故障自恢复。
• 久经考验：经历多年双11大促、突发流量等极端场景验证。

解决方案架构：数据持久化 + 异步发送 + 智能重试

针对弱网、断电、断网等边缘场景，LoongCollector 采用了“数据持久化 + 异步发送 + 智能重试”的核心架构设计。

分离采集与发送：将数据采集和网络发送完全解耦，采集过程不受网络状态影响。

本地持久化：日志数据天然具备本地持久化的能力。此处主要指指标等无持久化能力的数据，此方案会将所有采集到的指标，先写入本地文件，确保断电、重启也不丢失。

异步消费：独立的发送线程从持久化文件中读取数据并发送，失败时自动重试。

智能反压：网络异常时，自动控制数据读取速度，避免内存占用过高。

指标数据落盘持久化

传统的指标采集方案（如 Telegraf、Prometheus Pushgateway）通常将采集到的指标数据直接发送到服务端。这种架构在稳定网络环境下工作良好，但在边缘场景下存在致命缺陷：

• 断网丢数据：网络中断时，新采集的指标数据无法发送，只能丢弃或缓存在内存中。
• 断电丢数据：设备意外断电时，内存中缓存的数据全部丢失。
• 内存压力大：长时间断网时，内存缓存会迅速膨胀，最终导致 OOM。

LoongCollector 创新性地将主机监控指标和 Prometheus 指标进行本地文件持久化，实现了指标数据的可靠存储：

• 定时抓取主机和应用指标数据。
• 文本格式落盘到本地文件系统。
• 自动轮转机制，支持单文件大小和文件个数配置，保留最近固定格式的文件，自动删除过期文件，避免磁盘空间被历史数据占满。

文件采集异步消费机制

在持久化指标数据后，如何高效、可靠地将数据发送到服务端是下一个关键问题。传统方案面临的挑战包括：

• 发送阻塞采集：如果发送线程与采集线程耦合，网络慢会拖慢采集速度。
• 顺序性保证：指标数据通常有时间顺序要求，需要确保按采集时间顺序发送。
• 断点续传：网络恢复后，需要从断开位置继续发送，不能重复或遗漏。

LoongCollector 采用了文件采集的方式来异步消费持久化的指标数据，关键技术点如下：

• Checkpoint 机制：LoongCollector 维护了细粒度的 checkpoint，记录每个文件的读取位置，这确保了即使在文件读取过程中进程崩溃或断电，重启后也能从断开位置继续读取，不会丢失数据。
• 文件顺序保证：通过文件轮转顺序，确保按采集时间顺序发送数据：
• 优先处理时间早的文件
• 同一时间段的文件按序号递增处理
• 支持使用原始数据中的时间，避免时间戳乱序导致的数据可视化问题

智能反压与流量控制

在弱网环境下，如果不加控制地读取和发送数据，会导致：

• 内存占用激增：读取速度远大于发送速度，数据堆积在内存中。
• 发送队列溢出：队列满后数据被丢弃或进程崩溃。
• 带宽占满：采集流量占满带宽，影响业务正常通信。

LoongCollector 实现了多层次的智能反压机制：

发送并发度自适应：借鉴 TCP 拥塞控制算法，LoongCollector 根据网络状态动态调整发送并发度，这种自适应机制确保了：

• 快速响应：网络正常时充分利用带宽，快速发送数据。
• 快速收敛：网络异常时迅速降低发送频率，避免无效重试。
• 自动恢复：网络恢复后自动增加并发，无需人工干预。

• 队列反压：当发送队列积压达到阈值时，LoongCollector 会暂停文件读取，这避免了内存无限制增长，确保系统在长时间弱网环境下也能稳定运行。
• 流量限速：LoongCollector 支持配置最大发送速率，避免采集流量影响业务 ilogtail_config.json：

{  "max_bytes_per_sec": 1048576 # 限制最大发送速率为 10MB/s}

LoongCollector 终端部署最佳实践

这里以主机监控+一个应用的 Prometheus 采集为例。

LoongCollector 启动参数建议

在 /usr/local/ilogtail 目录下修改 ilogtail_config.json。

a. 关闭丢弃旧数据 discard_old_data。

b. 调大与服务端断开连接重启的间隔 config_server_lost_connection_timeout，建议取 604800 秒，7 天。

c. 调大读取阻塞重启的间隔 force_quit_read_timeout，建议取 604800 秒，7 天。

d. 限制最大发送速率 max_bytes_per_sec。主机监控+一个 Java 应用的流量为 0.88KB/s，所以建议取 1MB/s，避免异常使用流量。

e. "working_ip", 在移动终端场景，IP 会不断变化，在机器上建议给固定 IP。

ilogtail_config.json

1. {  
2. "discard_old_data": false,
3. "config_server_lost_connection_timeout": 604800,
4. "force_quit_read_timeout": 604800,
5. "max_bytes_per_sec": 1048576, 
6. "cpu_usage_limit": 0.4, 
7. "mem_usage_limit": 384,  
8. "working_ip": 192.168.0.1
9. }

采集配置

本地配置-主机监控采集配置

在 /etc/ilogtail/config/local 目录下创建例如 input_host_monitor.yaml 文件，将主机指标首先采集到本地文件路径下，例如 /usr/local/ilogtail/metrics/host.log。

1. enable: true

2. inputs: 

3. - Type: input_host_monitor   

4. Interval: 15

5. flushers: 

6. - Type: flusher_file   

7. MaxFileSize: 104857600   

8. MaxFiles: 10   

9. FilePath: /usr/local/ilogtail/metrics/host.log

本地配置-自定义指标采集配置

在 /etc/ilogtail/config/local 目录下创建例如 input_prometheus.yaml 文件，将主机指标首先采集到本地文件路径下，例如 /usr/local/ilogtail/metrics/metric.log。

input_prometheus.yaml

1. enable: true
2. inputs:
3. - Type: input_prometheus
4. ScrapeConfig:
5. job_name: node
6. host_only_mode: true
7. scrape_interval: 15s
8. scrape_timeout: 10s
9. static_configs:
10. - targets: ["localhost:12345"]
11. flushers:
12. - Type: flusher_file
13. MaxFileSize: 524288000
14. MaxFiles: 10
15. FilePath: /usr/local/ilogtail/metrics/metric.log

服务端管控配置-文件采集配置

1. {
2. "aggregators": [],
3. "global": {},
4. "logSample": "",
5. "inputs": [
6. {
7. "Type": "input_file",
8. "FilePaths": [
9. "/usr/local/ilogtail/metrics/*.log"
10. ],
11. "MaxDirSearchDepth": 0,
12. "FileEncoding": "utf8",
13. "EnableContainerDiscovery": false
14. }
15. ],
16. "processors": [
17. {
18. "Type": "processor_parse_json_native",
19. "SourceKey": "content",
20. "KeepingSourceWhenParseFail": true
21. }
22. ]
23. }

注意事项

1. 处理插件不要使用拓展插件，因为拓展插件会拉起 Golang 模块，导致内存占用升高。

2. 移动终端场景，IP 会不断变化，机器组建议使用标识型机器组。

LoongCollector 资源监控测试报告

CPU：平均 0.02 核，峰值 0.028 核

内存：平均 31.5MB，峰值 35MB

网络：平均 1.07KB/s，峰值 1.10KB/s

a. 压缩前：平均 12.99KB/s，峰值 13.13KB/s

b. 实际发送：平均 1.07KB/s，峰值 1.10KB/s

磁盘：平均 6.07KB/s，峰值 13.03KB/s

总结与展望

边缘场景的可观测数据采集，是一个长期被低估的技术挑战。网络的不稳定性、电源的不可靠性、数据一致性的复杂性，让传统的采集方案在边缘环境下频繁失效。LoongCollector 通过“数据持久化 + 异步发送 + 智能重试”的创新架构，系统性地解决了这些问题：

• 保证了可观测数据可靠交付
• 本地持久化保证断网不丢数据
• 异步发送机制实现采集与发送解耦
• 智能重试和反压确保网络恢复后数据完整上传
• 有效地进行了流量控制
• 高效压缩减少传输数据量
• 智能流量控制避免带宽占满，影响业务

但是，LoongCollector 的采集方案还有更多的优化空间：

1. 当前的持久化采集方案需要配置两个 Pipeline（采集 Pipeline + 文件读取 Pipeline），虽然灵活但增加了用户的理解和配置成本。LoongCollector 正在进行流水线优化，支持单流水线内部持久化能力，方便用户配置。

2. 终端设备对于 STS 鉴权是强需求，LoongCollector 正在适配阿里云 STS 动态鉴权，支持临时凭证自动刷新，避免终端 AccessKey 泄露风险。

3. 在流量成本敏感的场景，每一个百分点的压缩率提升都意味着显著的成本节省，LoongCollector 也正在探索更加极致的压缩策略，进一步降低网络流量。