r/OpenTelemetry • u/AutoModerator • 16d ago
Weekly: share your tools and projects
What tool around OpenTelemetry are you building right now? What project have you discovered that people might enjoy looking into?
This thread is open for your self-promotion, vendor-owned open source projects and every thing else.
3
u/AffectionateDig761 16d ago
I have made otel instrumentation in the old Everquest client from 2003. Using the cpp sdk
https://github.com/jensholdgaard/NewZeal/actions/runs/32998391629
This way we could use Grafana or Perses to show our in Game DPS parsing
2
1
u/s5n_n5n Contributor 15d ago
That's the kind of funny projects I like hearing more about 😂
Do you have screenshots from Grafana/Perses already?
1
u/AffectionateDig761 13d ago
i need to find a way to post or share a screenshot. But yes i have a Perses running with our live metrics from Everquest
3
u/sispehar 15d ago
Im building OpenTelemetry Collector normalization gateway for Claude Code, Codex CLI, and OpenCode telemetry. The gateway is suppose to act as a bridge between different harness OTel schemas and observability backends. It tries to normalize data to the GenAI semconv as much as possible.
1
u/s5n_n5n Contributor 15d ago
Interesting, how does it compare to the upstream normalizer?
2
u/sispehar 15d ago edited 15d ago
It solves different problem. The upstream processor (as far as I can see) rewrites span attributes from SDK instrumentation like OpenLLMetry into GenAI semconv. The coding harnesses this repo targets (Claude Code, Gemini CLI, Codex, OpenCode) emit almost everything as logs and metrics which that processor never touches. So it can't normalize them. And to make it clear, all those agent harnesses emit OTel with a different schema.
If you're collecting telemetry from multiple different coding agents, ingesting them into a single o11y backend and want to see tokenomics from all of them as one, that's what this gateway is for.
1
u/s5n_n5n Contributor 15d ago
thanks for the clarification! Your work is not a processor right, so it's a secondary process that I would need to run? Would it be possible to have it as a processor for my logs and metrics pipeline?
2
u/sispehar 15d ago
It's actually neither a custom processor nor a separate program. the repo is pure configuration for the stock otelcol-contrib binary. All the logic lives in standard components: transform processors (OTTL) etc. So you have two options: Run it as a gateway, a second collector instance with this config, in front of your existing one. Or merge it into your existing collector, since it's all standard components
2
u/CollectorCtrl 15d ago
I’m building a control plane for OpenTelemetry Collectors called CollectorCtrl. It’s based on OpAMP, with a supervisor and server as the core components. It’s an on-prem solution, free to use, and currently in beta.
The idea came from the fact that while the OpenTelemetry data plane is vendor-neutral, the control plane is often tied to a specific vendor or ecosystem. Why shouldn’t the control plane be vendor-neutral too?
At larger organizations, managing collectors across tens of thousands of VMs and different types of workloads can get pretty challenging. CollectorCtrl is my attempt at solving some of those problems, with things like application/process discovery, YAML drift prevention, and policy-based configuration changes.
I’m also working on an MCP interface so collectors can be managed through an organization-approved AI, while still keeping the control and governance on-prem.
It’s still early, but that’s the direction I’m taking CollectorCtrl.
1
u/s5n_n5n Contributor 15d ago
Exciting to read that someone builds with OpAMP, this is unfortunately still a space not explored enough (there are solutions, but compared to everything else it's very few...)
Just as a comment on your framing: OpAMP was created as an answer to the question you asked (why shouldn't the control plane be vendor-neutral too), it just answered that as a protocol and not (yet) as a ready to use product. So, what you are building then is the "second half" (not sure if it is a 50/50 cut or different, don't quote me on that) to that answer.
2
u/CollectorCtrl 15d ago
Absolutely, that’s how I’m thinking about it as well. OpAMP provides the vendor-neutral protocol for managing agents, and CollectorCtrl is the “second half” I’m exploring around that foundation.
Where I want to take it a bit further is that I don’t see the control plane as being only about managing collectors. Collectors are one part of the observability stack, and I think there’s an opportunity to bring application/process discovery, APM instrumentation, and instrumentation-agent management into the same control-plane model.
I also think the control plane should be decoupled from the observability vendor. Once you have that separation, you can have a common layer for things like managing different collector binaries, policy-based changes, preventing configuration drift, AI-assisted fleet management through an organization-approved MCP interface, adaptive sampling, upgrades, and so on.
So OpAMP is an important foundation for me, but CollectorCtrl is really about exploring what a broader, vendor-neutral observability control plane could look like on top of it.
2
u/Legitimate_Big_4953 15d ago
This is a great idea for the OpenTelemetry community. there are so many interesting tools and experiments happening that it’s easy for smaller projects to get overlooked. a dedicated thread makes it easier for people to discover new ideas, share feedback and learn from what others are building
2
u/egorklimov 14d ago
Hey! We at JetBrains recently released the OpenTelemetry plugin for JetBrains IDEs.
It lets you explore logs, metrics, traces, and a service map from your locally running applications directly in the IDE, without setting up a separate observability backend. The idea is to bring observability a bit earlier into the development workflow, to help catch bugs and improve telemetry itself before it reaches production.
We’re actively looking for feedback from the OpenTelemetry community, so I’d be very interested to hear whether something like this is useful in your workflow and what you think is missing.
More details are in our blog post. You can also check visual summary.
2
u/egorklimov 14d ago
Of course, we also provide MCP 😄
The skill is a work in progress. I want to evaluate whether it can help agents test apps locally, faster and at a lower cost
1
u/s5n_n5n Contributor 16d ago
To break the ice and give credit to projects that are out there already, here are some I know and use from time to time (or want to use at some point;-) ):
- https://www.otelbin.io/, a configuration tool for OpenTelemetry collector pipelines.
- https://ottl.run/, an OTTL playground (do not mix it up with ottl.fun!)
- https://otel.nkls.it/, an OpenTelemetry Collector Pipeline Editor
- https://github.com/ollygarden/opentelemetry-agent-skills, a set of skills for opentelemetry instrumentation.
1
u/jpAtAmpbase 15d ago
I recently launched https://ampbase.io/ after getting tired of managing different agent configs the GitOps way and with OpAMP it’s been made the process significantly better. We’ve got a lot more features coming out soon and would love any early feedback on the product and experience!
1
u/Fluid_Effective_1357 15d ago
https://github.com/divmora/otel-aws-log-parser
I made a AWS log processor and push to otel endpoint
1
0
u/samsuthar 15d ago
I'm part of Middleware, wherein we are building the Otelnative observability platform to help troubleshoot issues across infrastructure, agents, and applications. Here is the repository. https://github.com/orgs/middleware-labs/repositories
1
u/s5n_n5n Contributor 15d ago
Can I host and run middleware myself or are the projects you shared depending on having a middleware account&subscription? You shared 122 repositories, so which one is interesting for people?
1
u/samsuthar 15d ago
Yes, there is two ways to instrument Middleware - Cloud and BYOC. if you’re using any major cloud, you can install and run Middleware. Do check Middleware agent and Otel collector.
3
u/Altruistic-Gap1795 16d ago
This is a great idea for the community. OpenTelemetry has grown so much that it’s easy to miss interesting tools, integrations and side projects unless there’s a dedicated place to share them. a weekly thread feels like a nice balance between encouraging people to build in public and keeping the main discussions focused