OpenTelemetry

Term 3 · Sep-Nov · 2 projects

• Declarative instrumentation configuration for otelc

  LFX Mentorship · Listed in the official cohort

  @txabman42Source IssueLFX portal

  otelc 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 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.

  • Go
  • OpenTelemetry
  • JSON

• Zero-code AI Agent observability for otelc

  LFX Mentorship · Listed in the official cohort

  @NameHaibinZhangSource IssueLFX portal

  Design and build an AI provider adapter interface in otelc (opentelemetry-go-compile-instrumentation) — OpenTelemetry's compile-time, zero-code instrumentation for Go — that emits the gen_ai.* semantic conventions (spans, metrics, events) through a single shared abstraction, so AI providers and libraries plug into a common contract instead of being instrumented ad hoc. The already-merged OpenAI instrumentation (#604) is migrated onto this interface as the reference implementation, then the adapter is extended to additional providers and libraries: anthropic-sdk-go, Gemini, and the MCP / LangChain frameworks. MCP/LangChain require non-HTTP hooks (following the Kafka/Redis instrumentation patterns) rather than the HTTP-based path. This design-first framing gives the mentee real architecture and problem-solving work — defining the adapter contract, mapping heterogeneous provider APIs onto shared semconv, and validating it across libraries — rather than repetitive per-library instrumentation. Community demand is concrete and vendor-neutral: the OpenAI instrumentation (#604) closed community issue #327, and the request pipeline is active (#706 for aws-sdk-go-v2, #553 MongoDB shipped). Deliverables follow a week-by-week plan where each milestone ships a runnable demo + green CI so progress is visible at a glance: adapter interface + OpenAI migration → anthropic-sdk-go → Gemini → MCP → LangChain, each with instrumentation rules, tests under the paired test/ directory, and an example app emitting gen_ai.* spans. Privacy posture: message bodies are off by default and strictly opt-in via OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT — nothing is captured unless the operator turns it on.

  • Go
  • OpenTelemetry
  • compile-time instrumentation
  • gen_ai semantic conventions
  • API/interface design

Term 2 · Jun-Aug · 2 projects

• Expanding Go Compile-Time Instrumentation Support and Improving otelc Tooling

  LFX Mentorship · Listed in the official cohort

  @kakkoyunSource IssueLFX portal

  The OpenTelemetry Go Compile Instrumentation project provides otelc, a compile-time auto-instrumentation tool for Go applications. It injects OpenTelemetry instrumentation during the Go build process without requiring manual source-code changes in the target application. As the project moves toward its v1.0 release and continues feature-parity work with mature compile-time instrumentation efforts such as Orchestrion and Loongsuite, the next phase is to broaden real-world library coverage while hardening the tooling and contributor workflow needed to maintain those integrations over time. This mentorship focuses on adding several mentor-approved integrations from the project roadmap and backlog, such as messaging, database/cache, logging, Kubernetes client, or GenAI SDK libraries, while improving otelc whenever the integration work exposes gaps in rule authoring, hook implementation, testing, or debugging. The mentee will also document the science behind compile-time instrumentation: how Go symbols and versions are matched, how hooks are injected, how OpenTelemetry semantic conventions are applied, and how compatibility is verified across library releases.

  • Go
  • OpenTelemetry concepts and semantic conventions
  • or willingness to learn
  • Understanding of Go AST/DST
  • code transformation
  • or compiler/build tooling
  • +2

• UX Research & Information Architecture: How Users Discover and Use OpenTelemetry Instrumentation Information

  LFX Mentorship · Listed in the official cohort

  @jaydelucaSource IssueLFX portal

  The Ecosystem Explorer helps users discover and get detailed documentation around various OpenTelemetry components. As the project expands to more ecosystems (Python, JavaScript, GenAI), information density will increase significantly, requiring patterns and approaches tailored to more than just the initial Java Agent use case. This mentorship involves conducting UX research to understand how users actually want to consume and use this information, covering: how users currently find information about components or instrumentation (LLMs, GitHub, docs, vendor sites, trial and error); what questions they are trying to answer (what telemetry will I get, how do I configure it, what changed between versions); what personas exist (app developers instrumenting code, platform engineers running collectors, SREs debugging production); how similar tools present dense technical information (npm registry, crates.io, Go pkg site, Docker Hub); and how LLMs are being used in this area and what the experience has been with them. The research will inform how we structure information, what features to prioritize, and how to present complex telemetry data in an accessible way.

  • UX research (user interviews
  • synthesis)
  • information architecture
  • competitive/comparative analysis
  • technical writing
  • wireframing or prototyping tools (helpful)
  • +1

Term 1 · Mar-May · 1 project

• Tooling for detecting impact of behavioral changes in Go libraries

  LFX Mentorship · Listed in the official cohort

  @mx-psiSource IssueLFX portal

  Maintenance of a stable Go library often involves value-judgement calls regarding what changes can impact downstream consumers. While some existing tooling like apidiff can go some way towards preventing breakage, these tools work purely in terms of API-level breakage such as changing the type of a symbol. Inspired by tooling in other language ecosystems such as Rust this proposal sets out to build a tool that can give statistical information about the impact of any change on downstream consumers by running the build pipelines and test suites of dependents before and after a particular change. This would empower maintainers to make better informed choices about changes and foster an ecosystem. We think this is specially important for the OpenTelemetry project since the OpenTelemetry Go modules and the OpenTelemetry Collector modules are foundational modules used within the CNCF on other projects (e.g Kubernetes, Jaeger) as well as outside of it. The intent is to build a tool that could be used as well by other CNCF projects since Go is the *lingua franca* of the foundation, enabling all projects to have a flourishing ecosystem.

  • Working Golang skills including testing and building Go code
  • Working knowledge of CI/CD systems
  • Containerization and securely running untrusted code

Term 3 · Sep-Nov · 1 project

• Developing Guidelines for OTel Survey Analysis and Communication

  LFX Mentorship · Listed in the official cohort

  @avillelaSource IssueLFX portal

  Various special interest groups (a.k.a. SIGs) in the OpenTelemetry project run surveys to understand the experience of the end-users better. To run surveys efficiently, SIG End-user provides guidelines and assistance to people running surveys. In the past, SIG End-user focused on providing guidelines around survey design. Now we would like to move forward and cover survey data analysis and communication findings.

  • Being comfortable to talk with end-users and stakeholders in English.
  • Interest or currently working in UX
  • user research
  • or data analytics
  • Familiarity with spreadsheets (Google Sheets
  • Excel)
  • +4

Term 1 · Mar-May · 1 project

• One Logging Bridge per Language

  LFX Mentorship · Listed in the official cohort

  @jpkrohlingSource IssueLFX portal

  One of the goals set for the OpenTelemetry project in 2024 is to have at least one logging bridge per Language SIG, so that our end-users can start using OTLP Logging natively in their applications. While some languages have such a bridge already, some have the desire to implement at least one bridge but are lacking the engineering resources to do so. This internship starts by taking a look at the current state, marking which languages have a bridge already and which are lacking. The next step is to propose and implement at least one bridge for at least one language that doesn't have such a bridge yet.

  • One (or more!) of the missing languages supported by OpenTelemetry
  • C++
  • Erlang
  • Go
  • JavaScript
  • PHP
  • +2

Term 0 · 2022 Spring (Mar-May) · 1 project

• Help drive OpenTelemetry PHP to Beta

  LFX Mentorship · Listed in the official cohort

  @bobstrecanskySource IssueLFX portal

  Help to drive our project board for OpenTelemetry PHP. This includes validating spec compliance and writing PHP code to implement some of these features

  • PHP

Term 0 · 2021 Spring (Mar-May) · 1 project

• Work through OpenTelemetry User Research Documentation and Implement Fixes

  LFX Mentorship · Listed in the official cohort

  @bobstrecanskySource IssueLFX portal

  Implement the fixes suggested in the user research documentation to make this project more consumable for end users.

  • PHP

Term 0 · 2020 Q3–Q4 · 3 projects

• OpenTelemetry C++ SDK ETW exporter

  CommunityBridge · Listed in the official cohort

  @maxgolovSource IssueCommunityBridge

  Add exporter for ETW (Event Tracing for Windows) as one of the optional recommended exporters that languages may decide to implement as part of SDK. Initial set of languages to support: C++ and/or C#. ETW exporter allows any open source project running on Windows (e.g. Docker) to leverage OpenTelemetry C++ SDK, emitting telemetry events (traces, logs) over ETW channel. Subsequently a listener Agent may forward events to fluent, ELK stack, or other destination. For example, events may be transformed and forwarded OTLP protocol collector. Min-bar is to implement the necessary OT C++ SDK changes (C++) and a test listener (C#). Additional scope may include some concrete examples of instrumentation: Docker ETW logs driver, or an additional out-of-proc forwarder from ETW provider listener to OTLP receiver. Simple projection for node.js (console log to OT C++ SDK - ETW) may also be designed, time-permitting.

  • some C++ or C# coding experience. Windows development environment is needed.

• OpenTelemetry SDK PHP Exporter

  CommunityBridge · Listed in the official cohort

  @bobstrecanskySource IssueCommunityBridge

  Develop some of the exporters for PHP that are found in the (Spec Compliance Matrix) that are not yet completed for PHP. There are some really neat exporter implementations that would be excellent candidates for creation / improvements: OTLP (priority) Zipkin Jaeger Prometheus

  • PHP

• OpenTelemetry to FluentBit exporter

  CommunityBridge · Listed in the official cohort

  @SergeyKanzhelevSource IssueCommunityBridge

  Define a data format and create an exporter for traces and metrics from OpenTelemetry to FluentBit. This will allow customers to use existing log delivery pipeline to upload telemetry collected by the rich set of various OpenTelemetry SDKs. Pipeline we want to enalbe is SDK->FluentBit->OpenTelemetry Collector->Jaeger to see traces.

  • Go

Term 0 · 2020 Q1 · 1 project

• Implementing zPages for OpenTelemetry, integrations registry, libraries compatibility tests, and OpenTelemetry C# integration with Azure, Amazon, and Google Cloud metadata services

  CommunityBridge · Listed in the official cohort

  Source