open-telemetry / opentelemetry-collector-contrib

问题：微服务架构中，不同服务使用不同的监控系统（如Jaeger、Prometheus、Zipkin），数据分散难以统一分析。

方案：使用contrib中的各种接收器（receivers）同时接收来自Jaeger、Prometheus、Zipkin等不同格式的监控数据，统一转换为OpenTelemetry标准格式。

示例：一个电商系统同时使用Jaeger做链路追踪、Prometheus收集指标，通过部署Collector Contrib，可以同时接收这两种数据，统一处理后发送到同一个后端存储。

问题：原始监控数据缺少业务上下文（如用户ID、订单号），导致排查问题时难以定位具体业务影响。

方案：使用contrib中的处理器（processors）对数据进行过滤、转换、丰富，比如添加自定义属性、采样、重命名指标等。

示例：在金融交易系统中，通过attributesprocessor为所有交易相关的trace添加交易类型和金额标签，方便后续按业务维度分析性能问题。

问题：公司已有特定的监控或日志系统（如Elasticsearch、Splunk、DataDog），需要将OpenTelemetry数据适配到这些系统。

方案：使用contrib中针对各种后端的导出器（exporters），将标准化后的数据发送到目标系统，无需为每个后端单独开发适配器。

示例：将应用性能数据通过contrib中的elasticsearchexporter发送到公司已有的ELK栈，同时通过datadogexporter发送给云监控服务。

问题：标准Collector功能有限，需要特定数据处理逻辑或对接私有系统。

方案：利用contrib丰富的组件库，通过Collector Builder选择需要的接收器、处理器、导出器，构建符合业务需求的定制化数据收集管道。

示例：游戏服务器需要收集玩家行为日志，使用contrib中的filelogreceiver读取日志文件，通过filterprocessor过滤敏感信息，最后用kafkaexporter发送到消息队列供数据分析。