DEBUG left on.
One runtime switch exports every debug line, and what it prints, to a backend that bills by volume.
Maestro: telemetry governance at the source, for Java
Decide what your Java services emit. Before they ship, and while they run.
Maestro reads your compiled JARs and proposes which business methods to trace and what they may capture. Your team locks that plan for each environment. Maestro builds it for the stock OpenTelemetry Java agent, with no source changes, and holds inside each JVM which log records may leave.
The trial needs a card at signup. To talk first, write to chris@oteligence.com.
- Stock OpenTelemetry Java agent
- No source changes
- Your telemetry never passes through Oteligence
Building the system of record for what Java services emit.
Held for each environment
- Methods traced
- Proposed from your bytecode, with the reason for each
- Captures
- Opt-in; sensitive names refused
- Log export floor
- Held inside each JVM
- Debug windows
- Signed, time-boxed, self-closing
- Build
- Signed, checked by the GitHub Action
- Record
- Who locked it and when, with any production confirmation
Telemetry goes from your JVMs to your collector and backend, never through Oteligence.
The risk today
What a service emits changes without a decision.
Changes nobody reviewed.
What a service traces, captures or logs changes with a setting or a deploy, without a decision.
No record.
When it changes, nobody can say who changed it, on which service, or for how long.
Built today, hosted and in your private cloud
Traces, logs and the record, locked per environment.
Traces
What is traced and captured
- Proposed from your compiled code. Deterministic scoring for the goal you choose, with the reason for each selection.
- Locked per environment by a person, with promotion and rollback.
- Production confirmation. A first production lock, a more than twofold growth, a change to sensitive methods or a new capture needs the locking person's recorded confirmation.
- Every locked method accounted for. Built, attached to the services that load its library, or refused with the reason, in the selection ledger. Interface methods are built on every implementation.
- Captures are opt-in. Sensitive names, your own terms included, are refused; card numbers and secrets are scrubbed; user and customer IDs are hashed under your key once you set it.
- Attribution on every span. The team, cost centre and product you assign, typed in or read from Kubernetes labels.
Logs
What may leave the JVM
- A floor inside each JVM. A runtime DEBUG switch reaches the developer's console, not your OpenTelemetry export. A Logback level change at runtime is recorded.
- Before DEBUG goes on, see which log statements in your own code it would open, sensitive-named values first.
- A check in CI. The GitHub Action and the CLI warn or fail per environment.
- Debug windows that close themselves. Signed and time-boxed. Beyond the environment's limits, a second Org Admin approves.
- Flagged statements stay out. A statement below the floor that carries a sensitive-named value stays withheld, even inside a debug window.
- Meter, cap and admission. A log meter by team and service in the generated collector, a records cap you set, and a Kubernetes admission policy.
These cover the OpenTelemetry log export of Java services under a lock. Logs a separate shipper reads from stdout are outside them.
Evidence
What you keep
- One record per lock and an exportable audit trail, with a Reader role for auditors.
- Every environment in one view: its lock, its last build and that build's drift.
- Signed builds. Every Maestro build is signed, and the GitHub Action checks it against its record.
- A verifier and worksheets in every bundle, which you run on your own data.
- The generated source of each extension.
- Files that outlast us. The extensions name no Oteligence address and run on the stock agent if you stop.
The demonstration
DEBUG reaches the console, not your export.
On a production-flagged environment with an INFO floor, an engineer sets a logger to DEBUG at runtime. The console fills, the export carries none of it, your backend receives a span recording the change, and the lock record names who set the floor.
Before deploy, the same rule. The GitHub Action fails a build whose deployment files set DEBUG, and passes it at INFO.
- Logger
- Set from INFO to DEBUG at runtime
- Console
- Fills with DEBUG lines
- OpenTelemetry export
- Carries none of them: held at the INFO floor
- Your backend
- Receives a span recording the change
- Lock record
- Names who set the floor
How it works
From compiled JARs to a locked, signed build.
- 01
Analyze
Upload compiled JARs or WARs, or a source archive through the CLI. Maestro reads each service and the calls between services.
- 02
Select
Pick a goal: debug latency, track errors, business flows or general visibility. A deterministic engine scores every method and proposes what to trace, with the reason for each.
- 03
Lock
A person locks the plan for each environment, with its captures and log policy. Large or sensitive production changes wait for their recorded confirmation. Promote and roll back.
- 04
Build
Maestro builds and signs the bundle below. Your pipeline downloads and deploys it, or on Kubernetes the OpenTelemetry Operator rolls it out.
- 05
Check
The GitHub Action checks every downloaded file against its build record and signature, and your repository against the environment's log policy. The bundle's verifier checks a sample of your own telemetry.
What every bundle holds
Files you inspect, keep and deploy with your own tools. Generated extension JARs add nothing to the price.
- Extension JAR + agent config
One per service: the locked selections, captures and log floor, for the stock OpenTelemetry Java agent.
- Collector configuration
Tail sampling that keeps every error and slow trace. Masking of secret-named keys and card-shaped values. Health-check traces dropped. Sized from your peak requests per second, with a load-balancing tier for more than one sampling replica. Request, error and latency metrics computed before sampling.
- selection-ledger.json
Every locked method: built, attached to the services that load its library, or refused with the reason.
- Lock record + build record
Who locked the plan, any production confirmation, each JAR's SHA-256, and the hash of every file in the build.
- Telemetry inventory + verifier
What the extensions may emit and what the collector removes, with a script you run on a sample of your collector's output.
- Worksheets
Spans and bytes per request, extension off and on, from your own staging samples.
- Generated source
The source of each extension, to read and review beside the JAR.
How it fits
Works in front of the stack you keep.
Pipelines and backend rules act after a record leaves the service; Maestro decides before deploy and holds the decision inside the JVM, in front of the pipeline you already run.
Covered services run the stock OpenTelemetry Java agent with the Maestro extension in place of your APM's own agent, exporting to New Relic, Datadog (through its Agent or directly), Dynatrace, Honeycomb, Jaeger or any OTLP endpoint over gRPC or HTTP. On Kubernetes, roll out through the OpenTelemetry Operator, with no change to a service's image.
Option 1: Hosted
- UploadYour pipeline uploads compiled JARs to the Oteligence control plane for analysis.
- Download and checkIt downloads a signed build (extension JARs and agent configuration) and a collector configuration. The GitHub Action checks each file.
- DeployYour pipeline deploys them to your JVMs and collector. Telemetry goes to your backend, never through Oteligence.
Oteligence runs the control plane, signs every Maestro build and publishes the public key in the GitHub Action's README. It receives no telemetry.
Option 2: Private cloud
- InstallRun the whole platform on one Linux VM you operate, from the weekly installation bundle (Docker Compose).
- Upload and downloadYour pipeline uploads compiled JARs to the VM and downloads a build signed with the VM's own key. The GitHub Action checks each file.
- DeployYour pipeline deploys to your JVMs and collector. Nothing in the installation is configured to contact Oteligence.
The whole platform on one Linux VM you operate, from a weekly installation bundle (Docker Compose). Nothing in it is configured to contact Oteligence. It uses your own S3-compatible bucket and fetches three public helper images from Docker Hub once, unless you load them first. Backend images are signed and each carries an SBOM. It signs every build with a key it creates. Accounts are local; single sign-on is not available on the VM yet.
Security and data
What we hold, and what never reaches us.
| Topic | Hosted | Private cloud |
|---|---|---|
| Where it runs | Amazon Web Services, region us-east-2. Each organization has its own database schema and storage bucket. | One Linux VM you operate, with your own bucket and database. |
| What it holds | Compiled JARs or WARs, or a source archive through the CLI; the analyses; service and environment names and selections; locks and the audit trail; members' names and emails; and, with the GitHub Action, each CI run's repository, branch, commit, user and run address. | The same, on your machine and in your bucket. |
| Telemetry | Receives none. Spans and logs go from the agent to the collector and backend you configure. | Receives none, and nothing in the installation is configured to contact Oteligence. |
| Protection | Encrypted in transit (HTTPS only, TLS 1.2 or 1.3) and at rest. API keys are stored only as a digest. | The installer refuses a bucket that allows public access, keeps no versions or has no default encryption. |
| Accounts | Sign-in through Clerk. Payment through Stripe, whose own form takes the card number, so it never reaches Oteligence. | Local accounts with passwords an administrator sets. Single sign-on is not available on the VM yet. |
| Deletion | Environment delete is self-serve: that environment's JARs, generated extensions and version history are removed. Cancelling during the trial removes the organization's hosted data. Billing records and audit events are kept. | The same environment delete in the app. You hold the database, the bucket and the machine. |
| Attestations | Oteligence does not hold a SOC 2 report. The security pack answers a review's first questions. | Signed backend images, an SBOM for each image, and a SHA-256 for every file in the bundle. |
Limits to know
- Logs a separate shipper reads from stdout are outside the log controls.
- Maestro does not scan values for sensitive data. Captures are refused by name and type, and masking acts on recognizable shapes such as card numbers and secrets.
- Someone with deployment rights can remove the extension or override its settings. The CI check, the admission policy and the verifier detect that; they do not prevent it.
If you stop
The extensions and configuration are files you keep. They name no Oteligence address and run on the stock OpenTelemetry Java agent, so your services keep running and exporting. Remove the extension from the agent's settings and the service runs the stock agent.
Request the security pack
Data handling, retention and deletion, attestations, and answers to a review's first questions, from chris@oteligence.com.
Compatibility
- Reads class files from Java 8 through Java 27.
- Extensions compiled for Java 8, 11 or 17, never newer than your JAR needs.
- OpenTelemetry Java agent 2.17.0 through 2.33.1.
- Web services built on Spring, JAX-RS, Micronaut or plain Java, packaged as JARs or WARs.
- Calls between services over the common Java HTTP clients, Kafka, Axon, Spring application events and Spring Cloud Gateway routes, plus in-process queue hand-offs.
- Java only.
Pricing
Priced per JAR.
Data volume, hosts and seats do not change the price.
Hosted, self-service
$10per JAR per month
Billed for 12 months up front. For example, 12 JARs locked in one environment is $1,440, charged on day 31.
- A 30-day trial with every feature and goal. A card is required at signup, and we email you before the first charge.
- Cancel in the app before day 31 and pay nothing. Cancelling ends access and removes the account's hosted data, so download your bundles first; files you downloaded keep running without us.
- After the trial, the 12-month term cannot be cancelled. It renews each year unless you turn renewal off.
- A JAR added mid-term is charged for the months left, after you confirm.
Enterprise and private cloud
Order form on request
For Maestro inside your own network, or a purchase through your procurement process.
- The whole platform on one Linux VM you operate, from the weekly installation bundle.
- The private-cloud pilot runs on the standard terms: a 30-day trial with a card, then 12 months per JAR.
- Security pack and procurement paperwork on request.
Counted
- Each locked JAR, once for every active environment it is locked in.
- An internal library JAR, only when your locked plan traces one of its methods.
Adds nothing
- Generated extension JARs.
- Rebuilds.
- New versions of a JAR already managed.
Unsure how your build maps to JARs? Write to chris@oteligence.com and we will count it with you.
Questions
What platform teams ask first.
Do we change application code?
No source changes. You add the extension and its configuration to the OpenTelemetry Java agent you deploy, through your own pipeline or, on Kubernetes, the OpenTelemetry Operator.
We already drop and sample in our pipeline.
Keep it. Pipelines and backend rules act after a record leaves the service. Maestro acts in the JVM, at the moment of the change, tied to the lock and the code, with a debug window that expires. It covers the Java services under a lock and does not replace your pipeline.
We run our own collector fleet.
The log floor, the level-change record, the log inventory and the CI check still work. The generated collector's meter, masking and sampling apply only if you run it.
Is this another agent?
No. Covered services run the stock OpenTelemetry Java agent with the Maestro extension. Remove the extension and the service runs the stock agent.
Our logs go to stdout.
Logs a separate shipper reads from stdout are outside the floor. If the agent also exports them over OpenTelemetry, that export is a second copy: turn it off for those services and keep the level-change record, the log inventory and the CI check, or move the services to the OpenTelemetry path, where the floor applies.
What is the performance impact?
On our eight-JAR test application (agent 2.32.0, JDK 21, one laptop run), the extension added half a millisecond or less at p50, p95 and p99 to orders of about 125 ms, over the stock agent alone. Measure it on your own staging; the worksheets in every bundle compare spans and bytes per request with the extension off and on.
Does our telemetry pass through Oteligence?
No. Spans and logs go from the agent to the collector and backend you configure. The hosted service receives what you upload, your names and selections, and each CI run's details; the private-cloud installation is not configured to contact Oteligence at all.
Does AI choose or change instrumentation?
No. A deterministic engine scores your methods and your people lock the plan. No model scores, selects or applies anything.
What happens when the trial ends?
We email you before the first charge. If you do nothing, the 12-month term starts on day 31 and is charged up front. Cancel in the app before day 31 and you pay nothing: access ends and the account's hosted data is removed, so download your bundles first. Files you downloaded keep running without us.
Talk to us
Bring one Java application.
30 minutes with your platform, engineering and security leads: the demonstration, the evidence a pilot must produce on your staging, and our security pack.
A pilot runs on a VM you operate, outside production, and ends against three measurements on your services:
- What Maestro would instrument, beside what your custom instrumentation covers today.
- Spans and bytes per request on your staging, with the stock agent and with the extension, for the same requests.
- One service's business-method traces arriving in the backend you keep.
Or write to chris@oteligence.com