在前十一篇文章中，我们分别搭建了 LGTM 栈的各个组件，并学习了 eBPF 的零侵扰观测能力。但所有可观测性数据都面临同一个问题：如何从分散的服务中采集并发送到正确的后端？数据采集是连接"数据源"和"可观测性后端"的桥梁，它的设计直接影响数据的完整性、实时性和成本。本文从数据采集的通用架构出发，系统对比 Grafana Alloy（一站式）、Fluent Bit（轻量级日志）、Vector（高性能管道）三大采集工具，并通过 Kubernetes 实战帮你选出最合适的采集方案。
一、数据采集的通用架构
无论使用哪种采集工具，数据采集的架构都可以抽象为四个层次：
text
数据源 → 采集器（Agent）→ 处理器（Transform）→ 导出器（Export）→ 后端
-
数据源：日志文件、容器 stdout、系统指标、应用 Trace、eBPF 事件等。
-
采集器（Agent） ：从数据源读取原始数据。通常以 DaemonSet 形式部署在每个 Kubernetes 节点上。
-
处理器（Transform） ：对数据进行过滤、采样、解析、结构化、添加标签等处理。
-
导出器（Export） ：将处理后的数据发送到后端（Loki、Tempo、Mimir、Prometheus 等）。
在 Kubernetes 环境中，采集器通常以 DaemonSet 部署在每个节点上，确保每个 Pod 的日志和指标都能被采集。
二、三大采集工具对比
三、Grafana Alloy：一站式遥测采集
Grafana Alloy 是 Grafana Labs 推出的 OpenTelemetry Collector 发行版 + Prometheus 管道，在 LGTM 栈中扮演着"统一数据入口"的角色。
3.1 Alloy 的核心优势
原生 OTel 支持：完全兼容 OpenTelemetry 数据模型和语义约定
统一采集：一个 Agent 同时采集 Metrics、Logs、Traces
声明式配置：使用 OpenTelemetry 标准的 YAML 配置
深度集成 LGTM：与 Loki、Tempo、Mimir 无缝对接
3.2 Alloy 配置示例
yaml
# alloy-config.yaml
alloy:
config:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 1s
send_batch_size: 1024
memory_limiter:
limit_mib: 512
exporters:
loki:
endpoint: http://loki:3100/loki/api/v1/push
tempo:
endpoint: http://tempo:4317
tls:
insecure: true
prometheus:
endpoint: http://mimir:9009/api/v1/push
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [tempo]
logs:
receivers: [otlp]
processors: [batch]
exporters: [loki]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]四、Fluent Bit：轻量级日志采集的王者
Fluent Bit 是 CNCF 项目，以极低的资源消耗（二进制文件 ~5MB，内存占用 ~5MB）在大规模日志采集场景中占据统治地位。
4.1 Fluent Bit 的核心特点
极低资源消耗：C 语言实现，运行时内存不足 5MB
高性能：单核可处理数万条日志/秒
丰富输入源：tail、systemd、TCP、UDP、HTTP 等
多输出后端：Loki、Elasticsearch、Kafka、S3、Stdout 等
4.2 Fluent Bit Kubernetes 配置
yaml
# fluent-bit-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: fluent-bit-config
data:
fluent-bit.conf: |
[SERVICE]
Flush 5
Daemon off
Log_Level info
Parsers_File parsers.conf
[INPUT]
Name tail
Path /var/log/containers/*.log
Parser docker
Tag kube.*
Mem_Buf_Limit 50MB
Skip_Long_Lines On
[FILTER]
Name kubernetes
Match kube.*
Merge_Log On
Keep_Log Off
K8S-Logging.Parser On
K8S-Logging.Exclude On
[OUTPUT]
Name loki
Match *
Host loki.default.svc.cluster.local
Port 3100
Tenant_ID ""
Labels {job="fluent-bit", namespace="$namespace", pod="$pod"}4.3 Fluent Bit 的性能数据
在生产环境中，Fluent Bit 单实例可处理 5-10 万条日志/秒，内存占用稳定在 10-20MB，是 ELK 生态中 Filebeat 的轻量级替代方案。
五、Vector：高性能可观测数据管道
Vector 是 Datadog 开源的高性能数据管道工具，用 Rust 编写，支持日志和指标的采集、转换和路由。
5.1 Vector 的核心特点
性能极高：Rust 实现，单核可处理数万事件/秒
端到端正确性：保证数据不丢失（at-least-once 语义）
丰富转换能力：支持过滤、采样、解析、聚合、重命名等
多后端支持：可同时输出到多个后端
5.2 Vector 配置示例
toml
vector.toml
sources.kubernetes_logs
type = "kubernetes_logs"
transforms.parse_json
type = "remap"
inputs = "kubernetes_logs"
source = '''
. = parse_json!(.message) ?? .
'''
transforms.filter_errors
type = "filter"
inputs = "parse_json"
condition = '.level == "error" || .level == "warn"'
sinks.loki
type = "loki"
inputs = "filter_errors"
endpoint = "http://loki:3100"
encoding = { codec = "json" }
labels = { namespace = "{{ kubernetes.pod_namespace }}", app = "{{ kubernetes.container_name }}" }
六、采集工具的选型决策
6.1 选型决策树
text
你需要采集什么类型的数据？
├── 仅日志 → Fluent Bit（资源最优）或 Vector（功能更丰富）
├── 日志 + 指标 → Vector 或 Alloy
├── 日志 + 指标 + 追踪 → Alloy（一站式方案）
└── 仅指标 → Prometheus Node Exporter / cAdvisor
6.2 具体场景建议
七、Kubernetes 采集最佳实践
DaemonSet 部署：采集器以 DaemonSet 形式在每个节点部署一个实例。
资源限制：为采集器设置 CPU 和内存限制，避免采集器影响业务 Pod。
标签注入：在采集阶段注入 Kubernetes 元数据（namespace、pod、container）。
采样与过滤：在采集器层面过滤低价值日志（如健康检查），减少后端存储压力。
缓冲与重试：配置采集器的缓冲和重试机制，避免后端故障导致数据丢失。
监控采集器自身：监控采集器的资源使用和错误日志，避免采集器成为新的故障点。
八、小结
数据采集架构：数据源 → 采集器 → 处理器 → 导出器 → 后端，四个层次分工明确。
Grafana Alloy：一站式遥测采集，OTel 原生，适合 LGTM 栈用户。
Fluent Bit：轻量级日志采集，C 语言实现，资源消耗极低，适合大规模日志场景。
Vector：高性能数据管道，Rust 实现，适合复杂的数据转换和路由需求。
选型决策：仅日志选 Fluent Bit；日志+指标选 Vector；日志+指标+追踪选 Alloy。
Kubernetes 部署：DaemonSet + 资源限制 + 标签注入，确保采集的可靠性和效率。