Skip to main content

什么是 LoongCollector​

LoongCollector是阿里云可观测团队开源的新一代高性能数据采集器，其前身为iLogtail项目。LoongCollector在继承iLogtail强大日志采集与处理能力的基础上进行了全面升级，从原来单一的日志采集场景扩展为涵盖 日志（Logs）、指标（Metrics）、链路（Traces）、性能剖析（Profiles） 的统一可观测数据采集与处理平台，并通过eBPF等能力采集文件、网络、进程等系统事件类数据。

项目地址：https://github.com/alibaba/loongcollector

品牌名称LoongCollector灵感源自东方神话中的"中国龙"（Loong）形象，Logo 中两个字母O如同灵动的双眼。这与LoongCollector的设计理念高度契合：龙眼代表全面精准的数据洞察力；龙的灵活身躯象征对多变环境的高度适应性；龙的强大力量象征在高强度负载下卓越的性能与稳定性。

LoongCollector是LoongSuite（阿里巴巴统一可观测数据采集套件）的核心节点级Agent组件。LoongSuite还包括：

核心特性​

极致性能​

LoongCollector在性能方面拥有显著优势。根据官方基准测试数据，其吞吐量相比其他主流采集器高出约 10倍，而资源消耗降低约 80%。

场景LoongCollectorFluentBitVectorFilebeat
单行日志最大吞吐546 MB/s36 MB/s38 MB/s9 MB/s
多行日志最大吞吐238 MB/s24 MB/s22 MB/s6 MB/s
正则解析最大吞吐68 MB/s19 MB/s12 MB/s不支持

在 10 MB/s 处理负载下的资源消耗对比：

场景LoongCollectorFluentBitVectorFilebeat
单行（512B）3.40% CPU / 29.01 MB RAM12.29% CPU / 46.84 MB RAM35.80% CPU / 83.24 MB RAM性能不足
多行（512B）5.82% CPU / 29.39 MB RAM28.35% CPU / 46.39 MB RAM55.99% CPU / 85.17 MB RAM性能不足
正则（512B）14.20% CPU / 34.02 MB RAM37.32% CPU / 46.44 MB RAM43.90% CPU / 90.51 MB RAM不支持

其性能优势主要来自以下底层设计：

  • 内存池零拷贝（Memory Arena）：共享内存池（SourceBuffer）对同一事件组的字符串只存储一份，通过string_view引用原始数据段，避免冗余拷贝
  • 无锁事件池（Lock-Free Event Pool）：线程感知的分配策略，同线程直接复用，跨线程使用双缓冲池，彻底消除锁竞争
  • 零拷贝序列化：跳过中间Protobuf对象，直接序列化到网络格式输出

生产级可靠性​

LoongCollector源自阿里巴巴15 年以上的生产实践：

  • 支撑阿里巴巴集团全量业务，包括历年双十一大促
  • 阿里云为数万家企业客户提供服务
  • 蚂蚁集团金融交易可观测场景验证
  • 每日采集数据规模达数百PB，部署规模达数千万节点

多租户流水线隔离和自愈网络弹性设计确保了极高稳定性：

  • 高低水位反馈队列防止流水线间相互干扰，独立资源分配与自动背压控制
  • 基于AIMD算法（加法增加、乘法减少）的自适应并发限流，快速故障检测与渐进式恢复
  • 优先级感知的轮询调度，保证公平资源分配

All-in-One 全遥测数据​

LoongCollector秉承All-in-One理念，通过单个Agent实现对多种可观测数据类型的统一采集：

  • 日志（Logs）：文本日志、容器标准输出、Syslog、Journal等
  • 指标（Metrics）：主机监控指标、Prometheus抓取、GPU指标等
  • 链路追踪（Traces）：通过OTLP协议接收链路数据
  • 安全事件：基于eBPF的文件安全、网络安全、进程安全事件采集
  • 网络可观测：基于eBPF的网络流量监控与HTTP协议分析

并深度支持云原生Kubernetes场景，基于标准CRI API实现无侵入的K8s元数据AutoTagging（Namespace、Pod、Container、Labels等）。

需要注意的是，官方资料中的Events更多指统一数据模型中的事件类数据，以及eBPF安全事件、网络事件、Docker/ETW等系统事件采集场景，并不等同于内置支持采集Kubernetes Event资源对象。源码中metric_meta_kubernetes和service_kubernetes_meta采集的是Pod、Node、Service、Deployment等K8s资源元数据及关系，不包含对Event对象的专用监听。如果要采集Node Problem Detector产生的Kubernetes Events，仍建议使用专门的事件导出组件将其转换为日志或OTLP等格式，LoongCollector可以再通过容器标准输出或文件日志方式采集这些导出结果。

可编程数据处理管道​

LoongCollector通过SPL引擎与多语言Plugin引擎双引擎构建完善的可编程体系：

引擎类型实现语言特点
原生插件C++性能最高，资源开销极低，算子较完善
扩展插件Go性能较高，开发门槛低，可灵活定制
SPL 引擎C++（列式/向量化）全面算子能力，管道式设计，无代码处理复杂数据

灵活配置管理​

LoongCollector支持本地配置热加载，也设计了统一的Agent管控协议。开源文档中的ConfigServer用于多实例场景下统一管理采集配置、版本和运行状态；云上或商业形态还可以结合SLS Console、SDK、K8s Operator等入口。

  • 以Agent组形式对采集Agent进行统一管理
  • 远程批量下发、修改采集配置
  • 监控Agent运行状态，汇总告警信息

架构设计​

LoongCollector的整体架构以 流水线（Pipeline） 为核心抽象，每条流水线由一个采集配置文件定义，负责数据的输入、处理、聚合与输出全流程。

LoongCollector支持三种核心部署模式：

Agent 模式（As An Agent）

以DaemonSet或主机进程形式部署在每个节点上，就近采集节点本地的多维可观测数据。充分利用本地计算资源，降低数据传输延迟，随节点动态扩缩容。

集群模式（As A Service）

以多副本Deployment形式部署，作为中心化数据汇聚与处理服务。接收来自各Agent或开源协议（OTLP、Prometheus等）的数据，执行集中式转换、汇聚与路由。

轻量流计算模式（As A Stream Consumer）

与消息队列（如Kafka、Pulsar）配合，利用消息队列的天然缓冲特性平滑处理数据流。借助SPL或多语言Plugin引擎实现轻量级实时聚合、过滤与分发。

插件体系详解​

LoongCollector的流水线由以下五类插件组成。输入、处理、输出插件主要分为原生插件（C++实现）和扩展插件（Go实现）两类；聚合插件和Extension主要属于 Go 扩展插件体系。

输入插件（Input）​

负责从各类数据源采集原始数据，是流水线的数据入口。常见的本地文件、容器标准输出、一次性文件等单例输入在一条流水线中只能配置一个；原生Input与扩展Input也需要满足源码中的拓扑检查规则。

原生输入插件（高性能 C++ 实现）：

插件名说明
input_agentsightAgentSight可观测数据采集
input_file文本日志文件采集，支持通配符；FilePaths当前仅限一个路径规则
input_container_stdio从容器标准输出/标准错误流采集日志
input_cpu_profiling基于eBPF采集CPU Profiling数据
input_file_security基于eBPF采集文件安全事件
input_forward接收来自其他实例或系统的转发数据
input_host_meta定时采集主机、进程及关联关系等元数据
input_host_monitor采集主机CPU、内存、磁盘、网络等指标
input_internal_alarms导出LoongCollector自身告警数据
input_internal_metrics导出LoongCollector自身运行指标
input_network_observer基于eBPF采集网络可观测数据
input_network_security基于eBPF采集网络安全事件
input_process_security基于eBPF采集进程安全事件
input_prometheus按ScrapeConfig抓取Prometheus指标
input_static_file_onetime一次性文件采集

常用扩展输入插件（Go 实现）：

插件名说明
input_command定期执行脚本或命令并采集输出
metric_meta_host采集主机Meta数据
metric_system_v2主机监控指标（CPU、内存、磁盘、网络等）
service_canal采集MySQL Binlog（通过Canal）
service_docker_stdout旧版 Go 容器标准输出采集
service_etw采集Windows ETW实时事件
service_go_profile采集Go应用pprof性能剖析数据
service_gpu_metric采集NVIDIA GPU指标
service_http_server接收HTTP/HTTPS/Unix Socket/TCP请求，支持SLS协议和OTLP等
service_journal采集 Linux systemd Journal日志
service_kafka从Kafka读取数据
service_kubernetes_meta采集Kubernetes资源元数据及关系，不采集Kubernetes Event对象
service_otlp通过HTTP/gRPC接收OTLP日志、指标和链路数据
service_syslog采集Syslog数据

处理插件（Processor）​

对采集到的原始数据进行解析、过滤、转换、富化等操作，可串联多个处理插件构成处理链。

SPL 处理引擎：

插件名说明
processor_spl通过SPL（类似 SQL 的流处理语言）对数据进行灵活处理

常用原生处理插件（C++ 实现）：

插件名说明
processor_parse_regex_native正则表达式解析，提取新字段
processor_parse_json_native解析JSON格式字段，提取子字段
processor_parse_delimiter_native分隔符解析，提取字段
processor_parse_timestamp_native时间字段解析，设置事件__time__
processor_filter_regex_native基于正则的事件过滤
processor_desensitize_native字段内容脱敏处理
processor_timestamp_filter_native基于时间戳过滤事件

常用扩展处理插件（Go 实现）：

插件名说明
processor_regex正则提取字段（扩展版）
processor_jsonJSON格式日志解析
processor_grokGrok语法数据处理
processor_add_fields添加固定字段
processor_appender追加字段
processor_rename重命名字段
processor_drop丢弃指定字段
processor_filter_regex正则过滤日志（扩展版）
processor_desensitize敏感数据脱敏
processor_split_log_regex多行日志切分（如 Java 异常栈）
processor_cloud_meta自动添加云平台元数据信息
processor_log_to_sls_metric将日志字段转换为SLS Metric
processor_rate_limit日志限速，防止突发流量

聚合插件（Aggregator）​

将多条事件聚合为批次后再发送，每条流水线最多配置一个聚合插件，所有输出插件共享。

插件名说明
aggregator_base基础聚合，对单条日志进行聚合
aggregator_context按日志来源（文件路径等）进行上下文聚合
aggregator_content_value_group按指定Key的值对数据进行分组聚合
aggregator_metadata_group按指定Metadata Keys对数据进行重新分组聚合

输出插件（Flusher）​

将处理后的数据发送到目标存储或消息系统，每条流水线至少配置一个输出插件。

原生输出插件（C++ 实现）：

插件名说明
flusher_sls输出到阿里云SLS（日志服务）
flusher_file写入本地文件
flusher_blackhole丢弃数据（用于测试）
flusher_kafka_native使用 C++ 实现输出到Kafka

扩展输出插件（Go 实现）：

插件名说明
flusher_stdout输出到标准输出或文件（调试常用）
flusher_kafka_v2输出到Kafka（推荐版本）
flusher_elasticsearch输出到Elasticsearch
flusher_clickhouse输出到ClickHouse
flusher_doris输出到Apache Doris
flusher_loki输出到Loki
flusher_otlp通过OTLP协议输出日志、指标或链路数据
flusher_http通过HTTP输出到自定义后端
flusher_prometheus通过Prometheus RemoteWrite输出指标
flusher_pulsar输出到Pulsar

扩展插件（Extension）​

为其他插件提供横切能力，如认证、熔断、编解码等。

插件名类型说明
ext_basicauthClientAuthenticator为flusher_http提供Basic认证
ext_request_breakerRequestInterceptor为flusher_http提供请求熔断
ext_groupinfo_filterFlushInterceptor按GroupInfo筛选最终提交数据
ext_default_decoderDecoder内置支持的格式解码器封装
ext_default_encoderEncoder内置支持的格式编码器封装

安装与部署​

直接下载（Linux/macOS）​

生产环境建议从官方 Releases下载当前稳定版预编译包，并核对发布页中的文件名与校验和。国内用户也可以按发布页说明使用阿里云 OSS 地址，常见命名模式如下：

# VERSION、OS、ARCH 请以 GitHub Releases 中实际资产为准
VERSION=<release_version>
OS=linux
ARCH=amd64
wget "https://loongcollector-community-edition.oss-cn-shanghai.aliyuncs.com/${VERSION}/loongcollector-${VERSION}.${OS}-${ARCH}.tar.gz"
tar -xzvf "loongcollector-${VERSION}.${OS}-${ARCH}.tar.gz"
cd "loongcollector-${VERSION}"

Docker 部署​

IMAGE=sls-opensource-registry.cn-shanghai.cr.aliyuncs.com/loongcollector-community-edition/loongcollector:<release_version>

# 使用 Docker 运行，挂载宿主机根目录、容器运行时目录和采集配置目录
docker run -d --name loongcollector \
  -v /:/logtail_host:ro \
  -v /var/run:/var/run \
  -v "$(pwd)/config:/usr/local/loongcollector/conf/continuous_pipeline_config/local" \
  "${IMAGE}"

阿里云镜像仓库通常使用明确版本号标签，不应假设存在可用的latest浮动标签；如需使用latest，请以 Release 正文中列出的GHCR镜像说明为准。

从源码编译​

由于 C++ 编译环境较为复杂，官方推荐通过Docker完成编译：

# 克隆仓库
git clone https://github.com/alibaba/loongcollector.git
cd loongcollector
git submodule update --init

# 编译（需要 Docker 和 Go 1.23+）
make all

# 运行
cd output
nohup ./loongcollector > stdout.log 2> stderr.log &

采集配置详解​

LoongCollector的每条流水线通常对应一个配置文件，支持YAML和JSON两种格式。持续采集配置默认存放于conf/continuous_pipeline_config/local，一次性采集配置存放于conf/onetime_pipeline_config/local；实例级系统参数则位于conf/instance_config，不要与采集配置混放。持续采集配置支持热加载，默认最长约 10 秒生效，可通过实例级参数config_scan_interval调整。

配置文件结构：

字段类型必填默认值说明
enablebool否true是否启用当前配置
globalobject否空全局配置
global.StructureTypestring否v1流水线版本（v1 或 v2）
global.InputIntervalMsint否1000扩展（Go）Input默认调度间隔（毫秒）
global.InputMaxFirstCollectDelayMsint否10000扩展Input首次采集前随机等待上限（毫秒）
global.EnableTimestampNanosecondbool否false是否启用纳秒级时间戳
inputsarray是/输入插件列表；单例输入通常只能配置 1 个，并受原生/扩展拓扑约束
processorsarray否空处理插件列表（可多个，按序执行）
aggregatorsarray否空聚合插件列表（目前最多 1 个，主要与 Go 投递路径组合）
flushersarray是/输出插件列表（至少 1 个）
extensionsarray否空扩展插件列表

使用示例​

示例一：采集文件日志并输出到标准输出​

最简单的使用场景是将本地日志文件内容采集并打印到标准输出，适合调试和验证配置。Tags: true用于在flusher_stdout中显示__tag__字段：

enable: true
inputs:
  - Type: input_file
    FilePaths:
      - /var/log/app/*.log
flushers:
  - Type: flusher_stdout
    OnlyStdout: true
    Tags: true

启动LoongCollector后，向日志文件写入内容：

echo '{"level":"info","msg":"Hello LoongCollector"}' >> /var/log/app/app.log

标准输出将显示采集到的数据（自动附加__tag__:__path__和__time__等元数据字段）：

{"__tag__:__path__": "/var/log/app/app.log", "content": "{\"level\":\"info\",\"msg\":\"Hello LoongCollector\"}", "__time__": "1733385029"}

示例二：正则解析日志并提取字段​

对采集到的文本日志使用原生正则处理器进行字段提取，适合结构化Nginx、Apache等格式的访问日志：

enable: true
inputs:
  - Type: input_file
    FilePaths:
      - /var/log/nginx/access.log
processors:
  - Type: processor_parse_regex_native
    SourceKey: content
    # 匹配格式：127.0.0.1 - - [10/Jan/2024:12:00:00 +0000] "GET /api/v1 HTTP/1.1" 200 512
    Regex: '(\S+)\s+-\s+-\s+\[([^\]]+)\]\s+"(\S+)\s+(\S+)\s+\S+"\s+(\d+)\s+(\d+)'
    Keys:
      - remote_addr
      - time_local
      - method
      - request
      - status
      - body_bytes_sent
flushers:
  - Type: flusher_stdout
    OnlyStdout: true
    Tags: true

示例三：采集 JSON 格式日志并输出到 Kafka​

适合微服务应用输出结构化JSON日志，并将其转发到Kafka消息队列以供下游消费：

enable: true
inputs:
  - Type: input_file
    FilePaths:
      - /var/log/app/service.log
processors:
  - Type: processor_parse_json_native
    SourceKey: content
    # 解析成功后，JSON 中的字段会被提取为独立的 key-value
flushers:
  - Type: flusher_kafka_v2
    Brokers:
      - kafka-broker:9092
    Topic: app-logs
    # 若 Kafka 开启认证，请在 Authentication 下配置 SASL/TLS/Kerberos 等参数
    # Authentication:
    #   SASL:
    #     Username: user
    #     Password: password
    #     SaslMechanism: PLAIN

示例四：采集容器标准输出（Kubernetes 场景）​

在Kubernetes环境中，通过input_container_stdio采集容器标准输出，并自动关联Pod、Namespace等元数据：

enable: true
inputs:
  - Type: input_container_stdio
    ContainerFilters:
      # 通过 Pod Label 过滤只采集特定应用的容器日志
      IncludeK8sLabel:
        app: my-service
      # 限定采集的命名空间，未配置时表示采集所有命名空间
      K8sNamespaceRegex: ".*"
flushers:
  - Type: flusher_stdout
    OnlyStdout: true
    Tags: true

示例五：多行日志采集（Java 异常堆栈）​

Java 应用的异常堆栈日志往往跨越多行。源码文档推荐优先在input_file的Multiline配置中完成多行聚合；旧式processor_split_log_regex仍可用，但需要放在processors列表第一项。

enable: true
inputs:
  - Type: input_file
    FilePaths:
      - /var/log/java/application.log
    Multiline:
      Mode: custom
      # 以日期时间开头的行作为每条日志的起始行
      StartPattern: '^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}'
flushers:
  - Type: flusher_stdout
    OnlyStdout: true
    Tags: true

示例六：SPL 引擎处理数据​

使用processor_spl插件通过SPL语法对数据进行灵活的解析、过滤和字段处理：

enable: true
inputs:
  - Type: input_file
    FilePaths:
      - /var/log/app/access.log
processors:
  - Type: processor_spl
    Script: |
      *
      | parse-regexp content, '([\d\.]+) \S+ \S+ \[(\S+) \S+\] \"(\w+) ([^\\"]*)\" ([\d\.]+) (\d+) (\d+) (\d+|-) \"([^\\"]*)\" \"([^\\"]*)\"' as ip, time, method, url, request_time, request_length, status, length, ref_url, browser
      | project-away content
flushers:
  - Type: flusher_stdout
    OnlyStdout: true
    Tags: true

参考资料​