Grafana Alloy是Grafana Labs推出的一款开源可观测性数据采集器，它的定位很明确：用一个组件同时处理日志、指标、追踪三类信号。在此之前，社区里常见的做法是Prometheus负责指标、Promtail或Fluent Bit负责日志、OpenTelemetry Collector负责追踪，三套工具各自部署、各自配置、各自升级，运维负担不小。Alloy把这些能力合并到一个二进制里，并且原生兼容Prometheus、Loki、Tempo、Mimir以及OTLP协议，成为构建统一可观测性管道的一个务实选择。
Alloy是什么：从Grafana Agent到统一采集器
要理解Alloy的价值，得先了解它的来龙去脉。Grafana Agent最初是基于Prometheus代码库改造的，后来演化为Flow模式，采用一种叫River的声明式配置语言。Alloy正是Grafana Agent Flow的继任者，在2024年发布后逐步取代了Agent，成为官方主推的采集方案。
Alloy的核心设计理念是"组件化管道"。每个组件负责一个具体任务，比如抓取指标、采集日志、写入远端存储，组件之间通过标签传递数据，就像Unix管道一样把多个组件串联成一条数据流水线。这种设计的好处是配置即架构，整条管道的结构在配置文件里一目了然，排查问题时能快速定位到具体环节。
与OpenTelemetry Collector相比，Alloy的优势在于对Grafana生态的原生集成，同时对OTel Collector的处理器、导出器做了兼容封装，也就是说你可以直接在Alloy里复用已有的OTel组件配置，迁移成本大大降低。另外Alloy自带Web UI，可以在浏览器里实时查看每个组件的健康状态和数据吞吐量，这对调试管道非常有帮助。
三大信号的采集配置实战
下面通过一个实际场景演示Alloy的用法：在Kubernetes集群中采集容器日志、抓取服务指标、接收应用上报的追踪数据，统一发送到Grafana Cloud或自建的Loki、Prometheus、Tempo。
首先是指标采集。Alloy内置了prometheus.scrape和prometheus.remote_write组件，配置方式与Prometheus原生配置高度相似：
prometheus.scrape "default" {
targets = [{
__address__ = "127.0.0.1:9090",
}]
forward_to = [prometheus.remote_write.default.receiver]
}
prometheus.remote_write "default" {
endpoint {
url = "http://prometheus:9090/api/v1/write"
}
}
这段配置会从本机9090端口抓取指标并推送到远端Prometheus。如果目标是Kubernetes中的Pod，可以配合discovery.kubernetes组件做服务发现，自动感知Pod的创建与销毁，不需要手动维护地址列表。
日志采集使用loki.source.kubernetes组件，它会自动发现集群中的所有Pod并读取容器标准输出日志：
loki.source.kubernetes "pods" {
targets = discovery.kubernetes.pods.targets
forward_to = [loki.write.default.receiver]
}
loki.write "default" {
endpoint {
url = "http://loki:3100/loki/api/v1/push"
}
}
追踪数据的接收则交给otelcol.receiver.otlp组件。应用通过OTLP协议上报trace，Alloy接收后可以做批量处理再导出到Tempo：
otelcol.receiver.otlp "default" {
grpc {
endpoint = "0.0.0.0:4317"
}
http {
endpoint = "0.0.0.0:4318"
}
output {
traces = [otelcol.exporter.otlp.default.input]
}
}
otelcol.exporter.otlp "default" {
client {
endpoint = "tempo:4317"
}
}
把这三段配置放在同一个配置文件里，Alloy启动后就同时具备了三种信号的采集能力，这就是"统一"的实际含义：一个进程、一份配置、一套运维逻辑。
管道处理与生产部署建议
采集只是第一步，真实环境中几乎都要对数据做清洗和加工。指标方面，prometheus.relabel组件可以在抓取前后重写标签，比如给所有指标打上集群名称、环境标识，方便后续做多租户查询。日志方面，loki.process组件支持解析JSON、提取字段、过滤敏感信息，常见的做法是从nginx访问日志中提取状态码和耗时，转成结构化标签后写入Loki，查询效率比纯文本检索高得多。
追踪数据的处理依赖OTel兼容的处理器组件，例如otelcol.processor.batch做批量发送以降低网络开销，otelcol.processor.tail_sampling实现尾部采样，只保留出错或慢请求的trace。尾部采样在生产环境特别重要，全量保留trace的成本很高，合理的采样策略能把存储费用压缩一个数量级，同时不丢失关键问题现场。
部署层面有几点经验值得参考。第一，Alloy建议以DaemonSet形式跑在Kubernetes的每个节点上，这样日志读取是本地的，避免了跨节点网络传输。第二，利用discovery.relabel和注解配合，让业务方通过给Pod打标签来决定是否被采集，实现自助式接入。第三，资源限制要提前规划，日志高峰期的内存占用容易成为瓶颈，建议给容器设置合理的内存上限并启用批量发送。第四，配置变更要走版本管理，Alloy支持配置热加载，配合GitOps流程可以做到平滑升级不丢数据。
总结来看，Grafany Alloy用组件化管道的思路把三类可观测性信号的采集和处理收敛到一个入口，既保留了Prometheus生态的易用性，又兼容OpenTelemetry的标准组件。对于正在搭建或整合可观测性体系的团队来说，从Alloy起步是一条投入产出比很高的路径，值得在实际项目中优先评估。
Grafana Alloy可观测性OpenTelemetry修改时间：2026-09-14 08:04:30