Semantic Convention-Driven Collector Configuration Generator

Develop an OpenTelemetry Collector configuration generator that automatically produces pipelines, processors, and extensions based on OpenTelemetry Semantic Conventions (defined in YAML/JSON schemas). This ensures that telemetry data adheres to semantic standards without manual configuration.

The OpenTelemetry Semantic Conventions define standardized attributes for traces, metrics, and logs. However, manually configuring the Collector to enforce these conventions is error-prone and time-consuming.

By analyzing the Semantic Convention Registry from opentelemetry-specification

• Auto-generate attribute processors (e.g., renaming, enriching, or dropping non-compliant attributes)
• Detect required resources (e.g., service.name)
• Optimize pipelines for signals (traces, metrics, logs)
• Validate configurations against semantic rules

Why

• Eliminates manual errors in attribute mapping
• Ensures compliance with semantic conventions
• Reduces boilerplate in Collector setups
• Works with existing OTel tooling (Weaver, Collector Builder)

Proposed Solution
A CLI tool / library that:

• Parses Semantic Convention YAMLs
• Generates OTel Collector configs with:
• Attribute processors (insert/update/drop attributes)
• Resource detection
• Signal-specific optimizations
• Outputs a valid config.yaml with semantic enforcement

Flow:

• Input: Semantic convention YAMLs (from spec repo)
• Processing:
  • Extract required attributes
  • Map to OTel processor rules

Output: A working Collector config

Since Weaver already processes semantic conventions, we can extend it to:

Export Collector Config Fragments

weaver generate collector-config --output otelcol.yaml

Validate Existing Configs

weaver validate-config --file otelcol.yaml

Start by reviewing how Weaver currently processes the Semantic Convention Registry from opentelemetry-specification. Clarify the proposed weaver generate collector-config and weaver validate-config entry points, then define the required attributes, processor rules, signal pipelines, and validation behavior. Done means producing a valid otelcol.yaml and validating existing Collector configurations.