Maestro by Oteligence · Java Observability

5× deeper traces.
Zero code changes.

Drop one or several compiled JARs. Pick your observability goals and APM. Maestro builds the cross-service call graph, scores every method against your goals, and generates an OTel extension JAR per service that adds method-level spans at runtime. No source access. No annotations. No rewrites.

Start Instrumenting Free → How it works
✓
OTEL config · all repos free
✓
Free to start · no card required
✓
Java 11–21 · no card
Maestro analysis · banking-app · 4 services
◼ Reading 4 JARs          ✓ 247 methods · 4 services ◼ Cross-service graph     ✓ 7 edges (Feign + Kafka) ◼ Goal-weighted scoring   ✓ Debug Latency + Track Errors ◼ Selecting methods       ✓ 18 across 4 services ◼ Generating extensions  ✓ 4 × ~18 KB ──────────────────────────────────── COMPLETE banking-app · < 8 s ──────────────────────────────────── Per service: fund-transfer 7 · account 6 · transaction 4 · notification 1 Cross-svc: 7 edges (Feign 5 · Kafka 2) Downloads: ├─ fund-transfer-ext.jar   ← 18 KB ├─ account-ext.jar ├─ transaction-ext.jar ├─ notification-ext.jar ├─ javaagent.config └─ collector.config
5×
More spans per request vs. OTel agent alone
Live test · Spring Boot 3.4 · Jaeger
0
Lines of application code changed
Extension plugs into OTel Agent Extension API
67%
Estimated MTTR reduction at fleet scale
Method-level bottleneck identification
~30%
Observability platform cost reduction
Precision spans vs. blanket instrumentation
Works With
Java 11–21Spring BootQuarkusMicronautOTel Agent 2.xKubernetesDockerJaegerGrafana TempoPrometheusDatadogNew RelicDynatraceAWS · GCP · Azure Java 11–21Spring BootQuarkusMicronautOTel Agent 2.xKubernetesDockerJaegerGrafana TempoPrometheusDatadogNew RelicDynatraceAWS · GCP · Azure
The Problem

The OTel agent sees your service.
It can't see inside it.

The standard OpenTelemetry Java Agent instruments frameworks — HTTP, JDBC, Kafka. It treats your business logic as a black box. You know an endpoint was slow. You don't know which method.

1
Span per HTTP request from the standard OTel agent
You see "POST /api/orders took 309 ms" — nothing else. No call hierarchy. No method breakdown. The next step: add debug logging, rebuild, redeploy.
10–30×
Span overhead from blanket @WithSpan on all methods
The naive fix floods APMs with noise, inflates bills 10–30× baseline, and degrades AI anomaly detection — without improving diagnostic quality.
30 min
Average time lost per incident to debug-logging cycles
Add logging → rebuild → redeploy → reproduce → collect → remove. Each cycle: 50–100 GB burst logs at $0.10–$0.25/GB. 50 incidents/month = thousands avoidable.
How It Works

JARs in. Cross-service traces out.
Under 5 minutes.

No source code access. No code changes. No new agents. Maestro extends the OTel Java Agent you already run — adding a precise, scored instrumentation layer on top.

01
Upload your JAR(s)

Drag one or several compiled JARs into the Maestro web app. For multi-service systems, drop them all at once — Maestro builds the cross-service call graph (Feign ↔ controller, Kafka producer ↔ consumer, JPA / Redis / MongoDB) automatically. Source code never leaves your environment; Maestro reads bytecode only.

🔒 Bytecode only · Source never required 🔗 Multi-JAR · Cross-service call graph
Quickstartweb app
# 1. Open Maestro · no install needed
app.oteligence.com → New Project

# 2. Drag in your JAR(s) — one or many
Drag .jar files → "Upload"

# 3. Walk through the steps
Pick Observability Goals →
Pick APM backend →
Review Cross-Service Preview →
Generate & Download
02
Pick goals + APM — preview before generating

Select your Observability Goals (Debug Latency, Track Errors, General Visibility) and your APM backend (Datadog, New Relic, Grafana, Dynatrace, …). Maestro's scoring engine then evaluates every method against those goals — weighting exception handling, branching, I/O boundaries, sync blocks. The Cross-Service Preview screen shows exactly which methods score across all your services; toggle any individual method on or off before generating.

3 observability goals · stack to broaden coverage Per-method toggles on the preview screen
Goal-weighted scoringengine
Goal-driven signal weights (example: Debug Latency + Track Errors)
────────────────────────────────────────
HTTP / RPC handlers   high  (latency)
DB / external I/O      high  (latency)
Exception handling     high  (errors)
Cross-service edges    high  (both)
Branching complexity   medium
Framework internals    excluded

4 services · 247 methods · 18 selected · ~1.3× overhead
03
Download pre-built Extension JAR(s) + Summary

Maestro produces one ~18 KB OTel Extension JAR per service, already compiled — plugs into the OTel Agent's Extension API. You also get the resolved javaagent.config, the OTel Collector config for your APM, and an HTML Instrumentation Summary — an interactive report with every instrumented method, scoring breakdown, and cross-service edges.

No build step · Extension JARs ready to run HTML summary with full method & edge breakdown
Suggested folder layout.o11y/
.o11y/ ← place downloaded files anywhere; this is a common spot
├─ fund-transfer-ext.jar   ← 18 KB · per-service extension
├─ account-ext.jar
├─ transaction-ext.jar
├─ notification-ext.jar
├─ javaagent.config        ← OTel agent settings
├─ collector.config        ← OTel Collector (for your APM)
└─ Instrumentation-Summary.html
04
Run with OTel agent — one flag

One -D flag added to your existing startup command. The extension plugs into the OTel Agent Extension API. Oteligence spans appear tagged [oteligence], nested inside HTTP server spans.

Jaeger · Grafana Tempo · Datadog · New Relic
Run commandbash
$ java \
-javaagent:opentelemetry-javaagent.jar \
-Dotel.javaagent.extensions=.o11y/fund-transfer-ext.jar \
-Dotel.javaagent.configuration-file=.o11y/javaagent.config \
-Dotel.service.name=fund-transfer \
-jar your-application.jar

# Traces appear: library.name = [oteligence]
Live Test Results — Jaeger

One request. Three services.
Now traceable.

Spring Boot 3.4 banking app — fund-transfer + account + transaction (3 JARs uploaded to Maestro together). Same multi-service request, all traces exported to Jaeger via OTel Collector. Every span is from a live test run — Feb 26, 2026.

Before — OTel Agent Only
v2.17.0 · 1 span
TraceID: 0e50ff3b092ce6b4f7a315755c76cc55

POST /api/transfers [310 ms]
http.response.status_code=200 · http.route=/api/transfers

  (no child spans — business logic invisible · cross-service calls untracked)
Diagnosis: "The transfer endpoint took 310 ms." Which service caused it — fund-transfer, account, transaction, or the network between them? Which method? No idea. Next: add log lines across every service, redeploy each one, correlate by request ID across three logstreams.
1
span total
0
services traced
After — OTel Agent + Oteligence
3 × ~18 KB extensions · 8 spans across 3 services
TraceID: cfdfbb8a7b05043a84b087d81246596d

POST /api/transfers [310 ms] [fund-transfer]
FundTransferServiceImpl.process [305 ms]
validateBusinessRules [4 ms]
AccountClient.getUser [120 ms] ⇢ Feign → account
AccountController.getUser [115 ms] [account]
accountRepo.findById [12 ms]
LedgerClient.recordEntry [178 ms] ⇢ Feign → transaction
LedgerController.recordEntry [175 ms] [transaction]
processLedgerEntry [172 ms] ← 56% of total latency. Found across services.
Diagnosis: processLedgerEntry() in transaction-service consumed 172 ms of the 178 ms Feign call to it. The bottleneck isn't in fund-transfer at all — it's three frames deep into a sibling service. Found in one trace, across services, zero code changes.
8
spans across services
3
services traced
📊
Span overhead comparison: Oteligence adds 1.2–1.5× baseline span volume. Blanket @WithSpan adds 10–30×. You get 5× more diagnostic insight at a fraction of the ingestion cost. Estimated APM cost reduction: ~30%.
Observability Goals

Tell Maestro what you care about.
The engine scores from there.

Maestro doesn't pick methods in a vacuum — it scores them against the goals you select. Stack goals to broaden coverage; focus on one to instrument less. Methods relevant to any selected goal score higher.

⏱
Debug Latency

Find slow requests. HTTP handlers + DB queries scored deeply.

💥
Track Errors

Exception capture on every service method.

👁
General Visibility

Balanced depth across all method types.

🔗
Multi-service? Drop several JARs together — Maestro matches @FeignClient calls to controller endpoints, Kafka producers to consumers, JPA / Redis / MongoDB databases, and previews the full cross-service call chain before generating. Per-method toggles available on the preview screen.
What Maestro Produces

Four plain files.
No proprietary formats.

Every Maestro output is a standard file you can commit to source control, review in a PR, or pipe into any build tool. No lock-in.

📦
{service}-ext.jar
~18 KB · OTel Extension JAR · one per service
Pre-built OTel Extension JAR per uploaded service. Plugs into the OTel Java Agent via the official Extension API. One -D flag. No new agent, no new infrastructure. Spans appear tagged [oteligence].
-Dotel.javaagent.extensions=fund-transfer-ext.jar
⚙️
javaagent.config
Text · OTel agent configuration · app side
Full OTel Java Agent configuration — exporter endpoint, protocol, service name, sampler, instrumentation toggles (JDBC, HTTP, JVM metrics, Micrometer, propagators). Resolved for your goals + APM. Regenerated each time you re-run analysis — do not edit manually.
-Dotel.javaagent.configuration-file=.o11y/javaagent.config
📡
collector.config
YAML · OTel Collector configuration · Collector side
Resolved configuration for the OTel Collector — tail-sampling rules, PII redaction, batching, and the exporter block for your chosen APM (Datadog, New Relic, Grafana, Dynatrace, …). Deploys to your Collector (sidecar / DaemonSet / gateway) — not into the app container.
--config=/conf/collector.config
📋
Instrumentation Summary
Interactive HTML · method-level report
Every instrumented class and method, complexity scores, goal-weighted scoring breakdown, cross-service edges detected, and the exact java -javaagent command to run your instrumented application. Save alongside your extension JAR as permanent documentation.
open instrumentation-summary.html
For Your Role

SRE. Developer.
Platform. Manager.

How Maestro shows up in real workdays — the scenarios, the decisions, the shifts. 4 roles · ~5 min read. Pick yours.

Read the User Stories →
What's Live

Available today.
Ship-ready.

Everything below is live at app.oteligence.com. No waitlist, no beta flags.

Live Now
Available at app.oteligence.com today
📦
Multi-JAR upload
Drop one or many JARs together. Maestro builds the cross-service call graph automatically.
🎯
Observability Goals
3 goals: Debug Latency, Track Errors, General Visibility. Goal-weighted scoring picks what matters — stack goals to broaden coverage.
🔗
Cross-Service Preview
Feign ↔ controller, Kafka producer ↔ consumer, JPA / Redis / Mongo. Per-method toggles before generating.
📦
18 KB OTel Extension JAR per service
One pre-built JAR per uploaded service. Plugs into OTel Agent Extension API. No agent replacement. No code changes.
⚙️
Project Configuration UI
Per-project OTel agent settings: exporters, protocols, instrumentation toggles.
👥
Teams & Admin Controls
Organizations, RBAC (Owner/Editor/Viewer), API tokens, audit logs.
Want to see what's coming next?
We ship fast and priorities evolve with customer feedback. Let's talk about what matters most to your team.
Talk to Us →
FAQ

Engineer questions.
Direct answers.

No. Maestro reads compiled .jar files via bytecode inspection. Your source code never leaves your environment. You upload the same artifact your JVM runs — Maestro analyzes the binary. This works on legacy services where source may not be available, and gives security teams confidence that proprietary logic stays internal.
Goals tell the scoring engine what to optimise for. Pick one or several of: Debug Latency, Track Errors, General Visibility. The engine applies MAX(weight) per signal across selected goals: methods relevant to any selected goal score higher. Stack goals for broader coverage; focus on one to instrument less. You can still toggle individual methods on or off in the Cross-Service Preview before generating.
Yes — that's the multi-JAR flow. Upload several compiled JARs at once and Maestro builds the cross-service call graph: matches @FeignClient outbound calls to the receiving @RestController endpoints, Kafka producers to consumers, JPA / Redis / MongoDB databases. The Cross-Service Preview shows the chain with protection indicators (Retry, Circuit Breaker, Unprotected) before you generate. One Extension JAR is produced per service, all aware of each other.
Per upload, downloaded from the Web UI:
{service}-ext.jar              — ~18 KB OTel Extension JAR (one per service)
javaagent.config               — OTel Java Agent configuration (resolved for your goals + APM)
collector.config               — OTel Collector configuration for your APM
Instrumentation-Summary.html   — Interactive report: methods · scores · cross-service edges
The Extension JARs are pre-built — no compile step needed on your side. Drop them anywhere in your project (we suggest .o11y/) and reference them from the run command (see next question).
java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.javaagent.extensions=.o11y/fund-transfer-ext.jar \
  -Dotel.javaagent.configuration-file=.o11y/javaagent.config \
  -Dotel.service.name=fund-transfer \
  -jar your-application.jar
Oteligence spans appear in Jaeger, Grafana Tempo, Datadog, etc. with library.name = [oteligence], nested as children of the OTel agent's HTTP server span. The collector.config is for your OTel Collector deployment (tail sampling, PII redaction, APM export), not for the app container.
Maestro generates extensions targeting Java 11 through Java 21+, working with OpenTelemetry Java Agent v2.x. Framework-aware for Spring Boot, Spring MVC, Quarkus, and Micronaut. Any JVM-based application works — framework awareness provides additional scoring heuristics for those specific patterns.
Yes — in two ways:

1. Precision spans replace debug-logging cycles. With method-level traces always present, you eliminate the add-logging → rebuild → redeploy cycle — saving hours of engineer time per incident.

2. Scored instrumentation controls span volume. Oteligence adds 1.2–1.5× baseline. Blanket @WithSpan on all methods adds 10–30×. Fewer noisy spans means less data ingested by your APM platform.
A GitHub Action (oteligence/maestro-action) is in active development — it'll let every push run analysis automatically, generate fresh per-service Extension JARs, and feed them into your existing Docker / Kubernetes deploy. For now you can run the Web UI analysis once per release and commit the downloaded artifacts (we suggest under .o11y/) so the team shares the same extensions and configs.
Yes, today Maestro supports Java (Java 11–21+) only. Additional language support is prioritized by user demand — email support@oteligence.com to let us know what you need.