[CNCF LFX Proposal] Opentelemetry - Declarative instrumentation configuration for otelc

### CNCF Project

OpenTelemetry

### Term

2026 Term 3 (Sep-Nov)

### Program Name

Declarative instrumentation configuration for otelc

### Program Description

## Description

[`otelc`](https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation) instruments Go applications at compile time with zero code changes. Today it can only switch instrumentations on and off through environment variables. There is no way to capture a specific HTTP header, redact a sensitive URL query parameter, or gate a semantic convention migration. Configuration granularity has been one of the top adopter asks since v1.0.

OpenTelemetry already defines the data model for this. The [declarative configuration](https://github.com/open-telemetry/opentelemetry-configuration) spec has an `instrumentation/development` node with a cross-language `general` section and a free-form `go` section that each language owns.

This project makes instrumentation configurable in otelc by implementing that node. The mentee will build the subsystem that reads and validates the config file at build time, bakes it into the generated runtime package, and exposes a typed API to hooks, then prove the design on instrumentation that already ships. To keep it maintainable, each instrumentation declares its options in a manifest that generates the schema, the docs catalog, and the defaults, following the Java agent's `metadata.yaml` pattern.

## Qualifications

Comfortable with Go and with YAML or JSON Schema, and familiar with OpenTelemetry basics such as semantic conventions and SDK configuration. Exposure to code generation or Go build tooling is a plus, not a requirement.

## Expected Outcomes

- A working configuration subsystem in otelc, so users can tune instrumentation behavior through a declarative config file instead of coarse environment variables
- A sustainable way for instrumentations to declare their options, keeping schema, defaults, and documentation in sync as the project grows
- Real instrumentations consuming the new configuration, with tests, documentation, and a runnable example
- Backward compatibility with the existing environment-variable controls
- A written RFC recording the configuration model, so future contributors know where new options belong
- Feedback and contributions upstream to the OpenTelemetry declarative configuration spec

### Technologies

Go, OpenTelemetry, JSON

### Skills same as Technologies?

- [x] Yes, the required skills are the same as the technologies listed above.

### Required/Desirable Skills

_No response_

### Mentors

Xabier Martinez Beneitez | @txabman42 | x42.martinez@gmail.com | x42.martinez
Azhar Momin | @amazingakai | azhar-momin@outlook.com | azharmomin

### Upstream Issue URL

https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/issues/705

### Application Prerequisites

- [x] Resume
- [x] Cover Letter
- [ ] School Enrollment Verification
- [ ] Participation Permission from school or employer
- [ ] Coding Challenge
- [ ] Custom Prerequisite (fill in details below)

### Coding Challenge URL

_No response_

### Custom Prerequisite Name

_No response_

### Custom Prerequisite Description

_No response_

### Custom Prerequisite — File Upload

- [ ] Yes — completion of this task requires the mentee to submit a file.

---
**LFX program:** [CNCF - OpenTelemetry: Declarative instrumentation configuration for otelc (2026 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/3db981bf-404b-4c8e-96f8-b0433688e8cf)

Start with the linked upstream issue and the declarative configuration specification's instrumentation/development node, then review otelc's existing environment-variable controls. Done means a validated build-time configuration subsystem, generated runtime API, manifest-driven schema and documentation, instrumentations using it, tests, an example, backward compatibility, and an RFC.

Written by the indexing model from the issue text.