OpenTelemetry Collector Receiver 完全指南数据入口的配置、命名与 Pipeline 接入原理【免费下载链接】opentelemetry-collectorOpenTelemetry Collector项目地址: https://gitcode.com/GitHub_Trending/op/opentelemetry-collector接收器Receiver是数据进入 OpenTelemetry Collector 的第一道关口它负责以指定的协议格式接收数据将其转换为 Collector 内部统一的数据格式再交给管道Pipeline中定义的处理器Processor与导出器Exporter继续流转。本文以本仓库receiver/目录为核心系统讲解 receiver 的核心概念、YAML 配置语法、实例命名规则以及如何在 pipeline 中启用 receiver并辅以 OTLP Receiver 与底层源码实现帮助你掌握从收到数据到进入管道的完整链路。Receiver 在 Collector 架构中的角色在 OpenTelemetry Collector 中receiver 是数据的来源端。官方文档在 receiver/README.md 中给出的定义是A receiver is how data gets into the OpenTelemetry Collector. Generally, a receiver accepts data in a specified format, translates it into the internal format and passes it to processors and exporters defined in the applicable pipelines.即 receiver 负责两件事接收以指定格式如 OTLP gRPC/HTTP、Zipkin、Prometheus、syslog 等接受外部数据转换将收到的数据翻译成 Collector 的内部数据格式traces / metrics / logs 三信号然后交给管道中后续的 processor 和 exporter。这一职责在源码中有清晰的体现。receiver/receiver.go 定义了三种信号的 receiver 接口Traces接收 trace将任意格式翻译为 Collector 内部 trace 格式如把 Zipkin spans 转换为ptrace.TracesMetrics接收 metric将任意格式翻译为内部 metrics 格式如把 Prometheus metrics 转换为pmetric.MetricsLogs接收日志将任意格式翻译为内部 logs 数据格式如读取 syslog 并转换为plog.Logs。三者都内嵌了component.Component接口意味着每个 receiver 本质上是 Collector 组件体系中的一员遵循统一的生命周期管理启动、关闭等。从数据流方向看整个 Collector 的典型链路是外部数据源 → receiver → processor(s) → exporter → 后端系统 接收并转换 处理 导出receiver 处于链路的起点是数据如何进入 Collector的唯一通道。更多关于 processor 与 exporter 的细节可参考 processor/README.md 与 exporter/README.md。本仓库内置的 Receiver 与生态扩展本仓库opentelemetry-collector core内置了一个在生产中最为关键的 receiverOTLP Receiver通过 gRPC 或 HTTP 使用 OTLP 协议 接收数据支持 traces、metrics、logs 以及处于 alpha 阶段的 profiles 信号。此外仓库中还提供了用于测试与教学的最小实现 nopreceiver以及辅助测试组件 receivertest。值得注意的是官方文档明确指出更多 receiver 位于 contrib 仓库opentelemetry-collector-contrib例如 Prometheus Receiver、Jaeger Receiver、Zipkin Receiver、Kafka Receiver 等。本仓库作为 core只维护核心能力其余生态接收器通过发行版distributions组合使用。Receiver 配置顶层 receivers 标签所有 receiver 都在 Collector 配置文件的顶层receivers:标签下进行声明。官方文档强调了一个硬性约束There must be at least one enabled receiver for a configuration to be considered valid.也就是说一个合法配置中至少要有一个已启用的 receiver。这一约束在源码层面有直接对应service/pipelines/config.go 中的PipelineConfig.Validate()检查len(cfg.Receivers) 0时返回errMissingServicePipelineReceiversmust have at least one receiver错误。基础配置语法官方文档给出的examplereceiver示例展示了两种声明方式——无名称的默认实例以及带名称的具名实例receivers: # Receiver 1. # receiver type: examplereceiver: # setting one: value one endpoint: 1.2.3.4:8080 # ... # Receiver 2. # receiver type/name: examplereceiver/settings: # setting two: value two endpoint: 0.0.0.0:9211语法要点examplereceiver直接以类型名作为键这是该类型默认未命名实例examplereceiver/settings以类型/名称形式声明第二个实例其中settings是自定义名称每个实例下的配置项如endpoint取决于具体 receiver 类型不同 receiver 有各自的可配置字段。配置的组成部分与校验从源码结构看receiver 配置遵循 Collector 统一的组件配置模型每个 receiver 通过createDefaultConfig()提供默认配置见下文 OTLP Receiver 示例每个配置结构体实现component.Config接口并可提供Validate()方法做自校验。例如 receiver/otlpreceiver/config.go 中 OTLP Receiver 的校验逻辑是grpc与http两个协议至少必须指定一个否则返回错误must specify at least one protocol when using the OTLP receiver。与真实配置的对照仓库自带的本地示例 examples/local/otel-config.yaml 是 receiver 配置的实际用法receivers: otlp: protocols: grpc: endpoint: localhost:4317 http: endpoint: localhost:4318Receiver 实例的完整名称Full Name与唯一性官方文档用较大篇幅阐述了 receiver 实例的**全名full name**规则这是正确引用 receiver 的关键A receiver instance is referenced by its full name in other parts of the config, such as in pipelines. A full name consists of the receiver type, / and the name appended to the receiver type in the configuration. All receiver full names must be unique.即全名 接收器类型 / 配置中附加的名称全名在配置的其他部分尤其是 pipeline中被引用所有 receiver 全名必须唯一。对于上文示例Receiver 1 的全名是examplereceiver类型本身无附加名称Receiver 2 的全名是examplereceiver/settings。在底层这个类型 名称的组合由component.ID表示参见 component/identifiable.go而component.MustNewID(otlp)、component.NewIDWithName(type, name)等工厂方法用于构造这种唯一标识。多实例场景的典型用途包括同一 receiver 类型在不同的端口/地址上分别监听例如同时开一个内网网段的 OTLP 实例和一个公网网段的 OTLP 实例。通过 Pipeline 启用 Receiver仅声明在receivers:下还不足以让数据流动receiver只有在被加入某个 pipeline 后才会被启用。官方文档明确指出Receivers are enabled upon being added to a pipeline.pipeline 在service:段下声明合法的信号类型为traces、metrics或logs。官方示例service: pipelines: # Valid pipelines are: traces, metrics or logs # Trace pipeline 1. traces: receivers: [examplereceiver, examplereceiver/settings] processors: [] exporters: [exampleexporter] # Trace pipeline 2. traces/another: receivers: [examplereceiver, examplereceiver/settings] processors: [] exporters: [exampleexporter]要点总结pipeline 的receivers列表中以全名引用 receiver 实例同一个 receiver 实例可以被多个 pipeline引用如上述两条 trace pipeline 都使用了两个实例数据会分发给各 pipeline每个 pipeline 都必须至少有一个 receiver 和一个 exporter 才是合法配置——这同样由 service/pipelines/config.go 的校验逻辑保证errMissingServicePipelineExporters对应 exporter 缺失的情形pipeline 也支持具名如traces/another用于建立多条同信号但处理链不同的管道。结合真实示例examples/local/otel-config.yaml 中的 pipeline 配置展示了完整的启用方式service: pipelines: traces: receivers: [otlp] processors: [memory_limiter] exporters: [debug] metrics: receivers: [otlp] processors: [memory_limiter] exporters: [debug] logs: receivers: [otlp] processors: [memory_limiter] exporters: [debug]这里同一个otlpreceiver 同时被 traces、metrics、logs 三条 pipeline 引用说明一个 receiver 可以同时服务多种信号前提是该 receiver 类型支持相应信号。深入 OTLP Receiver默认端口与协议配置作为本仓库唯一的官方内置 receiverOTLP Receiver 值得单独展开因为它是绝大多数 Collector 部署的默认数据入口。其完整文档见 receiver/otlpreceiver/README.md。最小启用配置启用 OTLP Receiver 只需在receivers:下声明即可协议通过列表显式指定receivers: otlp: protocols: grpc: http:协议grpc / http不写即禁用。若两者都不配置则配置校验失败见 receiver/otlpreceiver/config.go 的Validate()逻辑。默认端点endpointOTLP Receiver 的可配置项包括endpoint其默认值因协议而异gRPC 协议默认localhost:4317HTTP 协议默认localhost:4318。这些默认值定义在 receiver/otlpreceiver/factory.go 的createDefaultConfig()中grpcCfg.NetAddr.Endpoint localhost:4317、httpCfg.NetAddr.Endpoint localhost:4318。endpoint使用host:port语法完整语法规范参考 gRPC naming 文档在生产环境如容器、K8s中配置 endpoint 时应遵循安全最佳实践例如不要暴露在公网、考虑拒绝服务攻击防护。复用共享配置模块OTLP Receiver 的进阶能力通过复用本仓库的共享配置模块自动获得gRPC 设置含 CORS来自 config/configgrpcHTTP 设置来自 config/confighttpTLS / mTLS 设置来自 config/configtls认证设置来自 config/configauth。这意味着诸如tls:、auth:、keepalive:、max_recv_msg_size_mib:、cors:等字段都可以直接在 OTLP receiver 的协议配置中按上述模块的文档使用。从源码看receiver/otlpreceiver/config.go 中HTTPConfig内嵌了confighttp.ServerConfigProtocols结构中 grpc 字段类型为configgrpc.ServerConfig正是这一复用关系的直接证据。按信号定制 URL 路径HTTP 协议下OTLP Receiver 为每种信号提供了独立的 URL 路径配置项用于修改信号数据的上报路径traces_url_path默认/v1/tracesmetrics_url_path默认/v1/metricslogs_url_path默认/v1/logsprofiles_url_path默认/v1/profilesprofiles 信号默认值定义在 receiver/otlpreceiver/factory.go 的常量中并通过 receiver/otlpreceiver/config.go 的SanitizedURLPath类型实现encoding.TextUnmarshaler进行解析与规范化自动补全前导/。写入数据的方式为POST到对应地址POST [address]/[traces_url_path] # 写入 traces POST [address]/[metrics_url_path] # 写入 metrics POST [address]/[logs_url_path] # 写入 logs POST [address]/[profiles_url_path] # 写入 profiles默认 HTTP 端口为4318。若使用otlphttpexporter作为对端发送数据则应在 exporter 中分别用traces_endpoint、metrics_endpoint、logs_endpoint、profiles_endpoint设置与 receiver 地址和 URL 路径匹配的完整地址详见 exporter/otlphttpexporter。HTTP/JSON 与 CORS 配置OTLP Receiver 除 gRPC 外还支持通过 HTTP/JSON 接收 trace 等信号的导出调用HTTP/JSON 与 gRPC 使用相同的地址协议由接收时自动识别序列化格式需为 OTLP JSON。当需要从浏览器前端直连上报时可为 HTTP 端点配置 CORS跨域资源共享receivers: otlp: protocols: http: endpoint: localhost:4318 cors: allowed_origins: - http://test.com # Origins can have wildcards with *, use * by itself to match any origin. - https://*.example.com allowed_headers: - Example-Header max_age: 7200配置项说明allowed_origins允许的来源列表支持*通配符如https://*.example.com单独使用*匹配任意来源allowed_headers除浏览器 CORS 默认安全列表外额外允许的请求头max_age告知浏览器对预检preflight请求响应进行缓存的时间秒上例为7200秒。底层一个实例服务多信号从实现层面看receiver/otlpreceiver/factory.go 中维护了一个sharedcomponent.Mapreceivers变量用于按配置缓存已创建的otlpReceiver实例。其注释说明了原因Factory会被分别调用CreateTraces()、CreateMetrics()、CreateLogs()但三者必须共用同一个 receiver 实例而不是创建多个独立对象只有当 receiver 被 shutdown 时才从 map 中移除以便同一配置可被重新创建。这也解释了为什么同一个otlp实例可以同时被 traces/metrics/logs 多条 pipeline 引用。工厂模式Receiver 如何被创建要理解 receiver 的启用机制还需了解其工厂Factory模式。每个 receiver 类型都通过receiver.NewFactory注册创建逻辑receiver/receiver.go 定义了Factory接口包含按信号区分的创建方法CreateTraces(ctx, set, cfg, next consumer.Traces) (Traces, error)CreateMetrics(ctx, set, cfg, next consumer.Metrics) (Metrics, error)CreateLogs(ctx, set, cfg, next consumer.Logs) (Logs, error)每个方法还配套一个稳定性级别查询方法如TracesStability()用于声明该 receiver 对该信号的支持成熟度。若某 receiver 不支持某信号对应创建方法返回pipeline.ErrSignalNotSupported见 receiver/receiver.go 中未注册创建函数时的默认行为。工厂通过WithTraces、WithMetrics、WithLogs等FactoryOption注册各信号的创建函数receiver/receiver.go。OTLP Receiver 的工厂实现receiver/otlpreceiver/factory.go即通过xreceiver.NewFactory配合四个With*选项注册了 traces、metrics、logs 与 profiles 四种信号的创建器。值得注意的是receiver 工厂创建函数签名中的next consumer.Traces参数——它代表了该 receiver 在管道中的下游消费者正是这个参数把 receiver 与 pipeline 中的 processor/exporter 链路连接起来。相关测试 receiver/receiver_test.go 验证了未注册信号时返回pipeline.ErrSignalNotSupported、以及 ID 不匹配时报错的工厂行为。从配置到运行的完整流程小结结合以上内容一个 receiver 从配置到真正生效的完整流程可以归纳为声明在配置顶层receivers:下按类型或类型/名称声明一个或多个实例解析Collector 依据类型找到对应工厂receiver.NewFactory创建调用CreateDefaultConfig()生成带默认值的配置再以用户 YAML 覆盖默认值校验配置结构的Validate()方法执行自检如 OTLP 必须至少配置一个协议启用在service.pipelines.信号的receivers:列表中通过全名引用该实例pipeline 校验确保每个管道至少有一个 receiver创建与关联Collector 调用工厂的CreateTraces/CreateMetrics/CreateLogs将 receiver 实例与管道下游消费者consumer.Xxx关联起来运行receiver 在指定 endpoint 监听收到数据后转换为内部格式并推送给管道下游。常见配置核查清单在实际部署中可对照以下清单排查 receiver 相关问题顶层receivers:下至少声明了一个 receiver且该实例被至少一条 pipeline 引用否则配置校验报must have at least one receiverpipeline 的receivers列表中使用的名称与receivers:段中的全名类型/名称完全一致所有 receiver 全名全局唯一不存在重复实例名每个 pipeline 同时包含至少一个 receiver 与至少一个 exporterOTLP Receiver 的protocols下至少配置了grpc或http之一生产环境中 endpoint 监听地址按实际网络环境设置并配合 TLS/认证防护。通过本文你应当已经掌握 receiver 的概念定位、配置与命名规则、pipeline 接入方式以及 OTLP Receiver 的具体配置细节与底层工厂机制——这足以支撑你独立完成 Collector 数据入口的配置与问题排查。【免费下载链接】opentelemetry-collectorOpenTelemetry Collector项目地址: https://gitcode.com/GitHub_Trending/op/opentelemetry-collector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenTelemetry Collector Receiver 完全指南：数据入口的配置、命名与 Pipeline 接入原理
OpenTelemetry Collector Receiver 完全指南数据入口的配置、命名与 Pipeline 接入原理【免费下载链接】opentelemetry-collectorOpenTelemetry Collector项目地址: https://gitcode.com/GitHub_Trending/op/opentelemetry-collector接收器Receiver是数据进入 OpenTelemetry Collector 的第一道关口它负责以指定的协议格式接收数据将其转换为 Collector 内部统一的数据格式再交给管道Pipeline中定义的处理器Processor与导出器Exporter继续流转。本文以本仓库receiver/目录为核心系统讲解 receiver 的核心概念、YAML 配置语法、实例命名规则以及如何在 pipeline 中启用 receiver并辅以 OTLP Receiver 与底层源码实现帮助你掌握从收到数据到进入管道的完整链路。Receiver 在 Collector 架构中的角色在 OpenTelemetry Collector 中receiver 是数据的来源端。官方文档在 receiver/README.md 中给出的定义是A receiver is how data gets into the OpenTelemetry Collector. Generally, a receiver accepts data in a specified format, translates it into the internal format and passes it to processors and exporters defined in the applicable pipelines.即 receiver 负责两件事接收以指定格式如 OTLP gRPC/HTTP、Zipkin、Prometheus、syslog 等接受外部数据转换将收到的数据翻译成 Collector 的内部数据格式traces / metrics / logs 三信号然后交给管道中后续的 processor 和 exporter。这一职责在源码中有清晰的体现。receiver/receiver.go 定义了三种信号的 receiver 接口Traces接收 trace将任意格式翻译为 Collector 内部 trace 格式如把 Zipkin spans 转换为ptrace.TracesMetrics接收 metric将任意格式翻译为内部 metrics 格式如把 Prometheus metrics 转换为pmetric.MetricsLogs接收日志将任意格式翻译为内部 logs 数据格式如读取 syslog 并转换为plog.Logs。三者都内嵌了component.Component接口意味着每个 receiver 本质上是 Collector 组件体系中的一员遵循统一的生命周期管理启动、关闭等。从数据流方向看整个 Collector 的典型链路是外部数据源 → receiver → processor(s) → exporter → 后端系统 接收并转换 处理 导出receiver 处于链路的起点是数据如何进入 Collector的唯一通道。更多关于 processor 与 exporter 的细节可参考 processor/README.md 与 exporter/README.md。本仓库内置的 Receiver 与生态扩展本仓库opentelemetry-collector core内置了一个在生产中最为关键的 receiverOTLP Receiver通过 gRPC 或 HTTP 使用 OTLP 协议 接收数据支持 traces、metrics、logs 以及处于 alpha 阶段的 profiles 信号。此外仓库中还提供了用于测试与教学的最小实现 nopreceiver以及辅助测试组件 receivertest。值得注意的是官方文档明确指出更多 receiver 位于 contrib 仓库opentelemetry-collector-contrib例如 Prometheus Receiver、Jaeger Receiver、Zipkin Receiver、Kafka Receiver 等。本仓库作为 core只维护核心能力其余生态接收器通过发行版distributions组合使用。Receiver 配置顶层 receivers 标签所有 receiver 都在 Collector 配置文件的顶层receivers:标签下进行声明。官方文档强调了一个硬性约束There must be at least one enabled receiver for a configuration to be considered valid.也就是说一个合法配置中至少要有一个已启用的 receiver。这一约束在源码层面有直接对应service/pipelines/config.go 中的PipelineConfig.Validate()检查len(cfg.Receivers) 0时返回errMissingServicePipelineReceiversmust have at least one receiver错误。基础配置语法官方文档给出的examplereceiver示例展示了两种声明方式——无名称的默认实例以及带名称的具名实例receivers: # Receiver 1. # receiver type: examplereceiver: # setting one: value one endpoint: 1.2.3.4:8080 # ... # Receiver 2. # receiver type/name: examplereceiver/settings: # setting two: value two endpoint: 0.0.0.0:9211语法要点examplereceiver直接以类型名作为键这是该类型默认未命名实例examplereceiver/settings以类型/名称形式声明第二个实例其中settings是自定义名称每个实例下的配置项如endpoint取决于具体 receiver 类型不同 receiver 有各自的可配置字段。配置的组成部分与校验从源码结构看receiver 配置遵循 Collector 统一的组件配置模型每个 receiver 通过createDefaultConfig()提供默认配置见下文 OTLP Receiver 示例每个配置结构体实现component.Config接口并可提供Validate()方法做自校验。例如 receiver/otlpreceiver/config.go 中 OTLP Receiver 的校验逻辑是grpc与http两个协议至少必须指定一个否则返回错误must specify at least one protocol when using the OTLP receiver。与真实配置的对照仓库自带的本地示例 examples/local/otel-config.yaml 是 receiver 配置的实际用法receivers: otlp: protocols: grpc: endpoint: localhost:4317 http: endpoint: localhost:4318Receiver 实例的完整名称Full Name与唯一性官方文档用较大篇幅阐述了 receiver 实例的**全名full name**规则这是正确引用 receiver 的关键A receiver instance is referenced by its full name in other parts of the config, such as in pipelines. A full name consists of the receiver type, / and the name appended to the receiver type in the configuration. All receiver full names must be unique.即全名 接收器类型 / 配置中附加的名称全名在配置的其他部分尤其是 pipeline中被引用所有 receiver 全名必须唯一。对于上文示例Receiver 1 的全名是examplereceiver类型本身无附加名称Receiver 2 的全名是examplereceiver/settings。在底层这个类型 名称的组合由component.ID表示参见 component/identifiable.go而component.MustNewID(otlp)、component.NewIDWithName(type, name)等工厂方法用于构造这种唯一标识。多实例场景的典型用途包括同一 receiver 类型在不同的端口/地址上分别监听例如同时开一个内网网段的 OTLP 实例和一个公网网段的 OTLP 实例。通过 Pipeline 启用 Receiver仅声明在receivers:下还不足以让数据流动receiver只有在被加入某个 pipeline 后才会被启用。官方文档明确指出Receivers are enabled upon being added to a pipeline.pipeline 在service:段下声明合法的信号类型为traces、metrics或logs。官方示例service: pipelines: # Valid pipelines are: traces, metrics or logs # Trace pipeline 1. traces: receivers: [examplereceiver, examplereceiver/settings] processors: [] exporters: [exampleexporter] # Trace pipeline 2. traces/another: receivers: [examplereceiver, examplereceiver/settings] processors: [] exporters: [exampleexporter]要点总结pipeline 的receivers列表中以全名引用 receiver 实例同一个 receiver 实例可以被多个 pipeline引用如上述两条 trace pipeline 都使用了两个实例数据会分发给各 pipeline每个 pipeline 都必须至少有一个 receiver 和一个 exporter 才是合法配置——这同样由 service/pipelines/config.go 的校验逻辑保证errMissingServicePipelineExporters对应 exporter 缺失的情形pipeline 也支持具名如traces/another用于建立多条同信号但处理链不同的管道。结合真实示例examples/local/otel-config.yaml 中的 pipeline 配置展示了完整的启用方式service: pipelines: traces: receivers: [otlp] processors: [memory_limiter] exporters: [debug] metrics: receivers: [otlp] processors: [memory_limiter] exporters: [debug] logs: receivers: [otlp] processors: [memory_limiter] exporters: [debug]这里同一个otlpreceiver 同时被 traces、metrics、logs 三条 pipeline 引用说明一个 receiver 可以同时服务多种信号前提是该 receiver 类型支持相应信号。深入 OTLP Receiver默认端口与协议配置作为本仓库唯一的官方内置 receiverOTLP Receiver 值得单独展开因为它是绝大多数 Collector 部署的默认数据入口。其完整文档见 receiver/otlpreceiver/README.md。最小启用配置启用 OTLP Receiver 只需在receivers:下声明即可协议通过列表显式指定receivers: otlp: protocols: grpc: http:协议grpc / http不写即禁用。若两者都不配置则配置校验失败见 receiver/otlpreceiver/config.go 的Validate()逻辑。默认端点endpointOTLP Receiver 的可配置项包括endpoint其默认值因协议而异gRPC 协议默认localhost:4317HTTP 协议默认localhost:4318。这些默认值定义在 receiver/otlpreceiver/factory.go 的createDefaultConfig()中grpcCfg.NetAddr.Endpoint localhost:4317、httpCfg.NetAddr.Endpoint localhost:4318。endpoint使用host:port语法完整语法规范参考 gRPC naming 文档在生产环境如容器、K8s中配置 endpoint 时应遵循安全最佳实践例如不要暴露在公网、考虑拒绝服务攻击防护。复用共享配置模块OTLP Receiver 的进阶能力通过复用本仓库的共享配置模块自动获得gRPC 设置含 CORS来自 config/configgrpcHTTP 设置来自 config/confighttpTLS / mTLS 设置来自 config/configtls认证设置来自 config/configauth。这意味着诸如tls:、auth:、keepalive:、max_recv_msg_size_mib:、cors:等字段都可以直接在 OTLP receiver 的协议配置中按上述模块的文档使用。从源码看receiver/otlpreceiver/config.go 中HTTPConfig内嵌了confighttp.ServerConfigProtocols结构中 grpc 字段类型为configgrpc.ServerConfig正是这一复用关系的直接证据。按信号定制 URL 路径HTTP 协议下OTLP Receiver 为每种信号提供了独立的 URL 路径配置项用于修改信号数据的上报路径traces_url_path默认/v1/tracesmetrics_url_path默认/v1/metricslogs_url_path默认/v1/logsprofiles_url_path默认/v1/profilesprofiles 信号默认值定义在 receiver/otlpreceiver/factory.go 的常量中并通过 receiver/otlpreceiver/config.go 的SanitizedURLPath类型实现encoding.TextUnmarshaler进行解析与规范化自动补全前导/。写入数据的方式为POST到对应地址POST [address]/[traces_url_path] # 写入 traces POST [address]/[metrics_url_path] # 写入 metrics POST [address]/[logs_url_path] # 写入 logs POST [address]/[profiles_url_path] # 写入 profiles默认 HTTP 端口为4318。若使用otlphttpexporter作为对端发送数据则应在 exporter 中分别用traces_endpoint、metrics_endpoint、logs_endpoint、profiles_endpoint设置与 receiver 地址和 URL 路径匹配的完整地址详见 exporter/otlphttpexporter。HTTP/JSON 与 CORS 配置OTLP Receiver 除 gRPC 外还支持通过 HTTP/JSON 接收 trace 等信号的导出调用HTTP/JSON 与 gRPC 使用相同的地址协议由接收时自动识别序列化格式需为 OTLP JSON。当需要从浏览器前端直连上报时可为 HTTP 端点配置 CORS跨域资源共享receivers: otlp: protocols: http: endpoint: localhost:4318 cors: allowed_origins: - http://test.com # Origins can have wildcards with *, use * by itself to match any origin. - https://*.example.com allowed_headers: - Example-Header max_age: 7200配置项说明allowed_origins允许的来源列表支持*通配符如https://*.example.com单独使用*匹配任意来源allowed_headers除浏览器 CORS 默认安全列表外额外允许的请求头max_age告知浏览器对预检preflight请求响应进行缓存的时间秒上例为7200秒。底层一个实例服务多信号从实现层面看receiver/otlpreceiver/factory.go 中维护了一个sharedcomponent.Mapreceivers变量用于按配置缓存已创建的otlpReceiver实例。其注释说明了原因Factory会被分别调用CreateTraces()、CreateMetrics()、CreateLogs()但三者必须共用同一个 receiver 实例而不是创建多个独立对象只有当 receiver 被 shutdown 时才从 map 中移除以便同一配置可被重新创建。这也解释了为什么同一个otlp实例可以同时被 traces/metrics/logs 多条 pipeline 引用。工厂模式Receiver 如何被创建要理解 receiver 的启用机制还需了解其工厂Factory模式。每个 receiver 类型都通过receiver.NewFactory注册创建逻辑receiver/receiver.go 定义了Factory接口包含按信号区分的创建方法CreateTraces(ctx, set, cfg, next consumer.Traces) (Traces, error)CreateMetrics(ctx, set, cfg, next consumer.Metrics) (Metrics, error)CreateLogs(ctx, set, cfg, next consumer.Logs) (Logs, error)每个方法还配套一个稳定性级别查询方法如TracesStability()用于声明该 receiver 对该信号的支持成熟度。若某 receiver 不支持某信号对应创建方法返回pipeline.ErrSignalNotSupported见 receiver/receiver.go 中未注册创建函数时的默认行为。工厂通过WithTraces、WithMetrics、WithLogs等FactoryOption注册各信号的创建函数receiver/receiver.go。OTLP Receiver 的工厂实现receiver/otlpreceiver/factory.go即通过xreceiver.NewFactory配合四个With*选项注册了 traces、metrics、logs 与 profiles 四种信号的创建器。值得注意的是receiver 工厂创建函数签名中的next consumer.Traces参数——它代表了该 receiver 在管道中的下游消费者正是这个参数把 receiver 与 pipeline 中的 processor/exporter 链路连接起来。相关测试 receiver/receiver_test.go 验证了未注册信号时返回pipeline.ErrSignalNotSupported、以及 ID 不匹配时报错的工厂行为。从配置到运行的完整流程小结结合以上内容一个 receiver 从配置到真正生效的完整流程可以归纳为声明在配置顶层receivers:下按类型或类型/名称声明一个或多个实例解析Collector 依据类型找到对应工厂receiver.NewFactory创建调用CreateDefaultConfig()生成带默认值的配置再以用户 YAML 覆盖默认值校验配置结构的Validate()方法执行自检如 OTLP 必须至少配置一个协议启用在service.pipelines.信号的receivers:列表中通过全名引用该实例pipeline 校验确保每个管道至少有一个 receiver创建与关联Collector 调用工厂的CreateTraces/CreateMetrics/CreateLogs将 receiver 实例与管道下游消费者consumer.Xxx关联起来运行receiver 在指定 endpoint 监听收到数据后转换为内部格式并推送给管道下游。常见配置核查清单在实际部署中可对照以下清单排查 receiver 相关问题顶层receivers:下至少声明了一个 receiver且该实例被至少一条 pipeline 引用否则配置校验报must have at least one receiverpipeline 的receivers列表中使用的名称与receivers:段中的全名类型/名称完全一致所有 receiver 全名全局唯一不存在重复实例名每个 pipeline 同时包含至少一个 receiver 与至少一个 exporterOTLP Receiver 的protocols下至少配置了grpc或http之一生产环境中 endpoint 监听地址按实际网络环境设置并配合 TLS/认证防护。通过本文你应当已经掌握 receiver 的概念定位、配置与命名规则、pipeline 接入方式以及 OTLP Receiver 的具体配置细节与底层工厂机制——这足以支撑你独立完成 Collector 数据入口的配置与问题排查。【免费下载链接】opentelemetry-collectorOpenTelemetry Collector项目地址: https://gitcode.com/GitHub_Trending/op/opentelemetry-collector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考