Add Model Context Protocol (MCP) project proposal #3128
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,135 @@ | ||
| # OpenTelemetry Collector Model Context Protocol (MCP) Server | ||
|
|
||
| ## Background and description | ||
|
|
||
| The OpenTelemetry project consists of a large number of components, including collector, SDKs, and instrumentation libraries, which are often configured and managed separately. This distribution of components poses a major operational challenge which is universally recognized by the community [1], [2]. | ||
|
|
||
| Large language models (LLMs), present a significant opportunity to simplify the adoption, implementation, and management of the OpenTelemetry stack. An AI agent could, for example, analyze telemetry data, facilitate configuration changes, or assist and simplify the instrument process. | ||
|
|
||
| However, to support this process, a standardized interface is required for LLMs to interact with the OpenTelemetry ecosystem. The Model Context Protocol (MCP) provides an idiomatic approach for this interaction. | ||
|
|
||
| At the moment, the OpenTelemetry project does not have an official, standard MCP server. This has led to the creation of several independent, open-source projects to fill the gap. | ||
|
|
||
| ### Existing OpenTelemetry MCP Servers | ||
|
|
||
| The proliferation of these projects demonstrates strong community interest and the clear potential of this technology: | ||
|
|
||
| * [pavolloffay/opentelemetry-mcp-server](https://github.com/pavolloffay/opentelemetry-mcp-server): Focuses on collector configuration. | ||
| * [austinlparker/otel-mcp](https://github.com/austinlparker/otel-mcp): Handles collector configuration and data profiling. | ||
| * [mottibec/otelcol-mcp](https://github.com/mottibec/otelcol-mcp): Focuses on collector configuration. | ||
| * [shiftyp/otel-mcp-server](https://github.com/shiftyp/otel-mcp-server): Provides data profiling, but requires OpenSearch. | ||
|
There was a problem hiding this comment. Happy to answer any specific questions about this project! |
||
| * [liatrio-labs/otel-instrumentation-mcp](https://github.com/liatrio-labs/otel-instrumentation-mcp): Manages instrumentation. | ||
| * [traceloop/opentelemetry-mcp-server](https://github.com/traceloop/opentelemetry-mcp-server): Provides data profiling by connecting to Jaeger, Tempo and Traceloop. | ||
|
|
||
| Each of these servers uses a different approach, particularly for collector configuration and data profiling. | ||
| This fragmentation creates confusion for users in terms of installation and configuration. It is less effective | ||
| as multiple competing tools fill up context window and provide overlapping functionality. | ||
|
|
||
| ### Project Scope and Architecture | ||
|
|
||
| The scope of this project is to create OpenTelemetry MCP server(s) to simplify deployment and day-2 operations. | ||
|
Member
There was a problem hiding this comment. As we'll likely would end up with different MCP servers for different use-cases, I'd love to establish an unified interface as part of this project. Both, for a streamlined development of (multiple) servers AND a consistent way for the end-user to setup/configure the server(s)
Member
Author
There was a problem hiding this comment. Agree on the consistent configuration and deployment. However, I am not sure what you mean by the |
||
| The MCP server should also provide data profiling/intelligence capabilities to support the day-2 operation use-cases. | ||
|
|
||
| ### Goals, objectives, and requirements | ||
pavolloffay marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| The goals are divided into categories. However, some common goals apply to all created MCP(s): | ||
|
|
||
| * A common installation and configuration | ||
|
|
||
| #### Collector | ||
|
|
||
| * Deployment, configuration and management | ||
| * Simplify writing OpenTelemetry Transformation Language (OTTL) | ||
| * Simplify writing PII rules based on the received data | ||
|
|
||
| #### Instrumentation | ||
|
|
||
| * SDK configuration | ||
| * Auto-instrumentation configuration | ||
| * Identify instrumentation issues: single span traces, broken traces, high cardinality attributes | ||
|
|
||
| #### Semantic conventions | ||
|
|
||
| * Weaver schema generation | ||
| * Context optimized querying of the official semantic conventions registry | ||
|
|
||
| ## Deliverables | ||
|
|
||
| * Collector MCP server | ||
| * Configuration use-cases | ||
| * Data profiling use-cases: writing PII rules, high cardinality attributes, broken traces, single span traces | ||
| * Standalone MCP Server | ||
| * Instrumentation use-cases | ||
| * Collector provisioning and configuration use-cases | ||
| * Understanding changes in released artifacts | ||
|
|
||
| ## Staffing / Help Wanted | ||
|
|
||
| This project requires a blend of OpenTelemetry collector, documentation and instrumentation expertise and expertise in building MCP server. | ||
|
|
||
| ### SIG | ||
|
|
||
| This project will be led by a cross-cutting effort coordinating with the Collector, and language SIGs. A | ||
| new dedicated SIG or working group will be formed to help manage and move this project forward. | ||
|
|
||
| ### Required staffing | ||
|
|
||
| #### Project Leads(s) | ||
|
|
||
| * [@pavolloffay](https://github.com/pavolloffay) (Red Hat) | ||
| * [@niwoerner](https://github.com/niwoerner) (OllyGarden) | ||
|
|
||
| #### TC Sponsor | ||
|
|
||
| TBD | ||
|
|
||
| #### GC Liaison | ||
|
|
||
| * @austinlparker (Austin Parker - Honeycomb) | ||
|
|
||
| #### Engineers | ||
|
|
||
| * [adrielp](https://github.com/adrielp) | ||
| * [shiftyp](https://github.com/shiftyp) | ||
|
|
||
| #### Other Staffing | ||
|
|
||
| ### Industry outreach (Optional) | ||
|
|
||
| Following users have built OpenTelemetry MCP servers: | ||
|
|
||
| * [otel-mcp](https://github.com/austinlparker) - author of [otel-mcp](https://github.com/austinlparker/otel-mcp) | ||
| * [mottibec](https://github.com/mottibec) - author of [otelcol-mcp](https://github.com/mottibec/otelcol-mcp) | ||
| * [shiftyp](https://github.com/shiftyp) - author of [otel-mcp-server](https://github.com/shiftyp/otel-mcp-server) | ||
|
|
||
| There will be [OpenTelemetry MCP blog post](https://github.com/open-telemetry/opentelemetry.io/pull/8331/) which promote the SIG. | ||
|
|
||
| ## Expected Timeline | ||
|
|
||
| This timeline assumes project approval and resource allocation as outlined in the staffing section. Until staffing is | ||
| confirmed and expected time commitments are known, this timeline is in flux. | ||
|
|
||
| Phase 1: Static collector configuration (Months 1-2) | ||
| - OpenTelemetry collector configuration | ||
|
|
||
| Phase 2: Data profiling via collector (Months 1-2) | ||
| - OpenTelemetry collector extension which provides API to query and profile the processed telemetry data | ||
|
There was a problem hiding this comment. Just as context, this was the focus of my particular project. An MCP server that generated OpenSearch / ElasticSearch queries to feed relevant telemetry data into an agent (tested with Claude). I used it specifically with Claude Code to combine telemetry intelligence with code context to answer root cause question about incidents, analyze performance of code changes, ect. This is probably where I could contribute the most in terms of thought partnership, although my effort could be used towards various goals. |
||
| - Data volume attribution | ||
|
|
||
| Phase 3: Instrumentation (Months 1-2) | ||
| - Identify broken traces | ||
| - Identify single span traces | ||
| - Identify high cardinality traces | ||
| - Instrumentation configuration | ||
|
|
||
| ## Labels | ||
|
|
||
| `mcp` for all PRs and issues related to this project. | ||
|
|
||
| ## GitHub Project (Post-Approval) | ||
|
|
||
| TBD | ||
|
|
||
| ## SIG Meetings, Roadmap, and Other Info (Post-Approval) | ||
|
|
||
| TBD | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.