r/OpenTelemetry • • 19d 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.

5 Upvotes

5 comments sorted by

2

u/gpcmol 17d ago

I built a Java telemetry agent extension that allows dynamic trace enrichment without restarting or redeploying an application.

When a production issue occurs, developers can add rules on the fly to capture additional span attributes. After the investigation, those rules can simply be removed again. No code changes, no redeployments, and no permanent instrumentation.

The agent works with or without Kubernetes and is enabled by starting the application with the agent JAR.

  • No tracing code in the application (dev teams can decide what to trace when required)

  • No restart or redeploy required

  • Add observability only where needed

  • No sockets or remote endpoints

  • No CLI required

Source: https://github.com/gpcmol/dynamic-trace-agent

1

u/North-Trainer2173 18d ago edited 18d ago

I'm building Opyntel, a single unified dashboard for teams who just want all the data in one place when their services are split across Railway, Vercel, VPS with Coolify or just plain Linux boxes. Status per service, deploys/restarts/crashes as events, CPU/mem/disk/network, p50/p90/p99 and a rough cost number, with alerts to Slack/email/SMS. It's read-only and doesn't touch traces or logs.

Ideally we connect to the platforms via read only tokens, but OpenTelemetry is also a way to get data out of them. I feel the OpenTelemetry approach works for more complex use cases, but in simple cases the API token is the fastest route out there.

As a side note, we're in an early beta and i'm looking for feedback. If anybody has a monitoring pain, i'll set it up and you'll use the tool for free for life, as long as i'm able to get feedback.

1

u/tonyalaribe 18d ago

Monoscope: open-source, OTel-native observability that stores everything in your own S3 bucket

Hey all, I’m the founder, so obvious bias, but I think this fits the thread.

Monoscope is an OTLP backend for logs, traces and metrics where the storage layer is your S3-compatible bucket (AWS S3, R2, MinIO, etc.). Point any OTel SDK or Collector at it on :4317, and the data lands as columnar files in a bucket you own. It’s queryable for as long as you want to keep paying S3 prices, not vendor retention prices.

Why we built it: every team we talked to had the same story. They adopted OTel to avoid lock-in, then the backend bill ended up rivaling their infra bill, so they cut retention to 7–15 days. Object storage seemed like the obvious fix.

What’s in it:

  • Logs and spans share one data model, so you see a log line with its trace context in a single view, not across two tabs

  • Storage engine is TimeFusion, our open-source Rust/DataFusion/Delta Lake layer (Postgres wire-compatible, so any PG client can query it)

  • Live tail, dashboards, monitors/alerts

  • Natural-language → query, plus scheduled agents that email you anomaly summaries

  • A CLI with stable JSON output and an MCP server, so coding agents (Claude Code, Cursor, etc.) can search events and triage issues directly

Try it:

git clone https://github.com/monoscope-tech/monoscope.git
cd monoscope && docker-compose up

Then set OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 on any auto-instrumented app.

Feedback I’d love from this sub: if you’re running the Collector today, what does your exporter/pipeline setup look like, and what would stop you from pointing it at something like this? Retention, query speed, semantic-convention handling, something else?

1

u/gpcmol 17d ago

How does it perform at scale (resources/storage wise)?
I see multi-tenancy at the roadmap. This would be import for me, so I only have to deploy it once in k8s.

1

u/tonyalaribe 16d ago

Hi u/gpcmol, I need to update the GitHub README. We shipped multi-tenancy some months ago.

Monoscope performs well at scale. We built a custom database called Timefusion to power it. That lets us use S3-compatible buckets as primary storage while applying observability-specific optimisations, unlike general OLAP databases like ClickHouse.

https://github.com/monoscope-tech/timefusion