CLOUD SECURITY LAB

传递信号的路径：OpenTelemetry与Grafana Alloy

—

by

cslab
in

在上一篇文章中，我们解释了连接日志、追踪和指标对于同时了解安全事件的范围和原因至关重要。那么，应用程序生成的三种信号会沿着怎样的路径传输到可观测性后端呢？此时，OpenTelemetry和Grafana Alloy这两个名字经常会一起出现。

OpenTelemetry，简称OTel，是一个用于创建、表示和传输可观测性信号的厂商中立规范和工具生态系统。Grafana Alloy是该生态系统中的一个Collector发行版，它是一个可执行程序，负责接收来自各处的信号，进行处理，然后将其发送到目的地。简而言之，如果OpenTelemetry是通用的运输规则，那么Alloy就是理解这些规则的转运中心。

本文将进行一个最小化的实践，演示应用程序如何通过OTLP发送信号，以及在Podman中运行的Alloy如何接收、处理和转发这些信号。实践将仅限于确认本地调试输出，最后还将指出在生产环境中必须加强的安全和故障应对点。产品行为和示例已根据2026年9月3日的官方文档进行了验证。

应用程序的三个可观测性信号通过中央收集管道传输到多个分析存储库的示意图

OpenTelemetry与Alloy并非同一事物

OpenTelemetry并非单一的服务器产品。它是一个将API、SDK、自动检测、数据模型、语义约定、OTLP（OpenTelemetry Protocol）和Collector等多种元素捆绑在一起的项目。应用程序SDK负责创建Span、Metric和Log Record，通过Resource属性说明它们来自哪个服务和环境，并通过Trace Context连接服务之间的请求关系。

OpenTelemetry Collector是一个厂商中立的代理，它通过管道连接接收这些信号的Receiver、进行转换和过滤的Processor以及向外发送的Exporter。存储和查询并非Collector的主要任务。实际的存储和搜索由Tempo、Mimir、Loki、Jaeger、Prometheus或接收OTLP的商业服务等后端负责。

Grafana Alloy根据官方说明，是OpenTelemetry Collector的一个发行版，同时提供Prometheus管道以及Loki、Pyroscope等Grafana生态系统的连接功能，是一个开源的遥测Collector。尽管带有Grafana的产品名称，但它也可以将数据发送到其他兼容的后端。反之，使用OTel也并非必须使用Alloy。您可以选择上游Collector或其他发行版。
类别 OpenTelemetry Grafana Alloy 可观测性后端
— — — —
本质 规范·API·SDK·协议·Collector生态系统 基于OTel Collector的可执行发行版 存储·搜索·可视化系统
主要职责 标准化信号生成方式和数据表示·传输 接收、转换、过滤、批处理、路由、导出 长期存储、查询、仪表盘、告警
是否必须一起使用 除Alloy外也可选择其他Collector 除OTel外也支持Prometheus·Loki系列组件 可根据需求替换
需要记住的界限 OTel不是单一存储 Alloy不是分析界面或权限账本 后端不替代检测代码

单个信号的完整传输路径

例如，假设一个支付API处理一个请求。OTel SDK会创建一个包含“checkout-api”资源和TraceId的Span。Exporter通过OTLP/gRPC或OTLP/HTTP将其发送给Alloy。Alloy的OTLP Receiver接收到信号后，Memory Limiter会控制过度的内存使用，Batch Processor会将多个记录打包以减少传输次数。最后，Exporter将其发送到选定的后端。

애플리케이션 계측
  → OTLP/gRPC 또는 OTLP/HTTP
  → Alloy OTLP Receiver
  → Memory Limiter
  → Batch Processor
  → Exporter
  → Tempo·Mimir·Loki 또는 다른 호환 Backend

这里重要的不是“将三个信号放入一个地方”，而是保持相同的关联上下文，例如服务名称、环境和TraceId。Collector的经过并不会自动连接不相关的日志和追踪。在检测阶段必须正确生成和传播上下文。

OTLP支持gRPC和HTTP两种传输方式。通常，gRPC接收端口为4317，HTTP接收端口为4318。然而，端口开放的事实并不意味着认证和加密。在网络边界之外接收时，需要单独设计TLS、认证和访问控制。

为什么应用程序不直接发送到后端

在小型开发环境中，SDK可以直接导出到后端。OpenTelemetry官方文档也说明，在初始阶段直接传输是一个可行的选择。但是，如果每个服务都包含后端地址和认证方式，那么更改范围会变大，重试、批处理和过滤策略也会分散在各个应用程序中。

通过设置Collector层，应用程序可以快速将信号传递给附近的OTLP Endpoint，然后返回其主要任务。重试、批处理、敏感信息过滤以及分发到多个目的地都由Collector管理。但是，由于Collector会成为新的瓶颈和故障点，因此必须监控队列积压、拒绝/丢弃数量、内存和Exporter失败情况。

批处理的位置也很重要。Grafana文档强烈建议所有使用OTel组件的Alloy都配置Batch Processor，并指导将其放置在Memory Limiter和采样等可能丢弃数据的Processor之后。这样才能有效地打包最终剩余的数据。

实践：在Podman中开启Alloy转运中心

本次实践不使用外部后端或云凭证。这是一个封闭式验证，OTLP接收到的数据将由Alloy的Debug Exporter输出到容器日志中。请勿发送敏感的生产数据，仅使用示例信号。

步骤1：准备工作目录和配置文件

在一个新目录中创建config.alloy。

mkdir -p alloy-lab
cd alloy-lab
logging {
  level  = "info"
  format = "logfmt"
}

otelcol.receiver.otlp "lab" {
  grpc {
    endpoint = "0.0.0.0:4317"
  }

  http {
    endpoint = "0.0.0.0:4318"
  }

  output {
    metrics = [otelcol.processor.memory_limiter.lab.input]
    logs    = [otelcol.processor.memory_limiter.lab.input]
    traces  = [otelcol.processor.memory_limiter.lab.input]
  }
}

otelcol.processor.memory_limiter "lab" {
  check_interval = "1s"
  limit          = "256MiB"

  output {
    metrics = [otelcol.processor.batch.lab.input]
    logs    = [otelcol.processor.batch.lab.input]
    traces  = [otelcol.processor.batch.lab.input]
  }
}

otelcol.processor.batch "lab" {
  timeout         = "1s"
  send_batch_size = 512

  output {
    metrics = [otelcol.exporter.debug.lab.input]
    logs    = [otelcol.exporter.debug.lab.input]
    traces  = [otelcol.exporter.debug.lab.input]
  }
}

otelcol.exporter.debug "lab" {
  verbosity = "detailed"
}

此配置是一个有向图：Receiver → Memory Limiter → Batch → Debug Exporter。Alloy原生引擎使用Alloy语法而不是YAML将组件的输出连接到下一个组件的输入。截至2026年9月，虽然也有直接执行上游Collector YAML的`alloy otel`引擎，但官方文档将其标记为实验性，因此本次实践使用稳定的原生引擎。

步骤2：首先验证配置

运行前，使用容器的`validate`命令检查语法和组件连接。将替换为官方发布中验证过的固定版本。`latest`会降低实践的重现性，因此本文命令中不使用。

podman run --rm 
  -v "$PWD/config.alloy:/etc/alloy/config.alloy:Z,ro" 
  docker.io/grafana/alloy:v1.19.0 
  validate /etc/alloy/config.alloy

如果成功，将无配置错误地退出。如果失败，请检查行号和组件名称，然后不要进入下一步。

步骤3：运行Alloy

podman run --rm -d --name alloy-lab 
  -p 127.0.0.1:12345:12345 
  -p 127.0.0.1:4317:4317 
  -p 127.0.0.1:4318:4318 
  -v "$PWD/config.alloy:/etc/alloy/config.alloy:Z,ro" 
  docker.io/grafana/alloy:v1.19.0 
  run --server.http.listen-addr=0.0.0.0:12345 
  --storage.path=/var/lib/alloy/data 
  /etc/alloy/config.alloy

将主机绑定限制为127.0.0.1的原因是为了防止将用于实践的未经认证的OTLP Receiver和调试UI暴露到外部。在浏览器中打开http://127.0.0.1:12345可以查看组件状态和连接图。

步骤4：仅通过提示词检测示例应用程序

在您使用的LLM编码工具中输入以下提示词。在运行生成的代码之前，请检查文件列表和依赖项，并确保没有秘密值或外部传输地址。

请用Python创建一个最小的HTTP服务器。使用OpenTelemetry官方SDK和OTLP Exporter，并将服务名称设置为`alloy-lab-app`。当收到`/work`请求时，创建一个父Span、一个子Span、一个Counter Metric和一个包含TraceId的结构化Log，然后通过OTLP/HTTP将它们发送到`http://127.0.0.1:4318`。请一并编写所需的`requirements.txt`、执行命令和请求命令，但不要使用外部服务或凭证。

确认生成结果与各语言的官方包名称和当前API相符后，在隔离的虚拟环境中运行。多次调用`/work`，然后使用以下命令查看Alloy输出。

podman logs -f alloy-lab

预期结果是`alloy-lab-app`资源以及创建的Span、Metric和Log Record出现在Debug Exporter的输出中。比较TraceId以确认来自单个请求的信号是否连接。调试输出仅用于学习目的，不适用于大量生产流量。

步骤5：停止和清理

实践结束后，按如下方式停止。`–rm`选项将同时删除已停止的容器。

podman stop alloy-lab

切换到后端时会发生什么变化

将实践中的Debug Exporter替换为OTLP Exporter后，就可以在Alloy后面连接实际的后端。您可以将所有三个信号发送到支持OTLP的单个Endpoint，或者将日志路由到Loki，追踪路由到Tempo，指标路由到Prometheus兼容的存储，进行不同的路由。

此时，Endpoint、协议和认证方式必须遵循后端文档。例如，HTTP/HTTPS Endpoint对应`otelcol.exporter.otlphttp`，gRPC Endpoint对应`otelcol.exporter.otlp`。API Token不应以明文形式写入配置文件，而应使用环境变量或组织的秘密管理系统。在多个租户共享的环境中，应在可信的Gateway强制执行接收认证和租户识别，并且不要盲目信任客户端发送的租户属性。
部署方式 优点 注意事项 适用环境
— — — —
应用程序直接发送到后端 组件少，启动快 认证、重试、目的地设置分散在各个服务中 个人开发，短期验证
每主机Agent 靠近应用程序，可快速移交 需要按节点数量部署和更新 VM，Kubernetes DaemonSet
中央Gateway 集中管理策略和Exporter 需要考虑瓶颈、单点故障和租户隔离 多团队共享平台
Agent + Gateway 分离本地收集和中央策略 需要两层容量和故障应对 大规模生产环境

投入生产前的安全与可靠性检查清单

  • 将OTLP Receiver和Alloy管理UI仅绑定到必要的接口和网络。
  • 对Collector之间或远程客户端连接应用TLS和认证。
  • 日志正文、Span属性、Resource属性中不包含Token、会话或个人信息。
  • 过滤和掩码应尽可能从检测源头开始应用，而不仅仅是在导出前一次性应用。
  • 根据流量特性调整Memory Limiter、Batch、传输队列和重试机制。
  • 监控接收量、拒绝/丢弃量、队列积压、导出失败、重启次数和内存使用。
  • 制定服务名称和环境名称等Resource属性的组织标准，不要滥用高基数的值作为Metric Label。
  • 固定容器版本或Digest，以只读方式挂载配置，并以最小权限运行。
  • 在生产环境中禁用Debug Exporter，因为它可能会在详细输出中暴露原始数据。
  • 通过故障实验模拟后端延迟/中断，以确认数据丢失和对应用程序的影响范围。

遥测数据可能包含用户标识符、URL、查询、错误内容和内部网络结构。OpenTelemetry官方安全文档也将PII暴露、数据篡改、合规性和DoS列为Collector安全的主要原因。可观测性管道同样是需要保护的数据管道。

结论：分离理解标准与传输程序

OpenTelemetry是一个标准和生态系统，它使得日志、追踪和指标能够以通用方式创建、连接和传输。Grafana Alloy是实际接收、处理和路由这些信号的Collector发行版。OTel不是后端，Alloy也不是Grafana专用通道，并且仅仅设置Collector并不能自动完成关联和安全。

最小的起点是本地OTLP Receiver和Debug Exporter。在此确认Resource、TraceId和三个信号的到达后，在保留Memory Limiter和Batch的同时，替换为实际的后端Exporter。下一步可以探讨如何在Grafana中相互移动和查询到达Tempo、Loki和Prometheus系列存储的信号。

官方参考资料

分类: 云/opentelemetry

标签: OpenTelemetry, Grafana Alloy, OTLP, Observability, Collector, Log, Trace, Metric

Comments

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注