No proprietary agent, no closed wire format, no rip-and-replace if you ever want to leave. Here's the architecture, what we store versus what stays yours, and an honest read on where compliance actually stands, not a badge wall.
Most APM vendors bundle instrumentation, collection, transport, and storage into one closed product. ObjectZIA is four separate, standard layers, ObjectZIA is only one of them.
The OpenTelemetry SDK, auto- or manually-instrumented. Owned by the CNCF, not us. Works with any backend that speaks OTLP.
The OpenTelemetry Collector, ours or self-hosted in your own network, batches and forwards spans. Swap it without touching your services.
OTLP over gRPC or HTTP, a standard wire format. No proprietary encoding, no SDK lock to a specific vendor's schema.
This is where ObjectZIA lives. It's the only layer that's us, and the only one you'd need to change to switch away.
Contributed to OpenTelemetry by the time it reached CNCF's highest maturity tier.
Individual contributors across the project, up from 17 when it joined CNCF in 2019.
By contributor velocity, second only to Kubernetes itself, at graduation.
There's no ObjectZIA-specific SDK to install. Any of these gets you traces in minutes, and none of it becomes useless if you switch backends later.
Language-level agents for Java, Node.js, Python, .NET, and Go wrap your existing code and start emitting spans with no source changes.
Add custom spans and attributes exactly where you need visibility, using the same OpenTelemetry SDK you'd use with any other backend.
Already emitting OTLP somewhere else? Add ObjectZIA as a second exporter, or repoint the one you have. One config change, no re-instrumentation.
The OpenTelemetry Collector is the one hop between your services and ObjectZIA. You choose who runs it.
Export directly to our OTLP endpoint. Nothing to run or patch yourself, we manage the collector tier.
Run the collector inside your own network. Filter, sample, or redact span attributes before anything leaves your environment, then forward the rest to us.
This is the part vendors with proprietary agents can't offer, because their format was never yours to begin with.
OTLP in, OTLP out. Bulk export ships your trace data back in the same OTLP/protobuf format it arrived in, not a reformatted or ObjectZIA-specific schema.
No minimum retention to unlock export. Cancel anytime and pull everything out first. No "contact sales" gate on your own telemetry.
Filtering happens on your side of the wire. With a self-hosted collector, sampling and redaction decisions are made in your network, before data reaches us at all.
For what we store and for how long once data does reach us, see the retention details on The Project page →
Both are supported. OpenTelemetry's zero-code agents cover Java, Node.js, Python, .NET, and Go for a fast start; the SDK is there when you want custom spans or attributes.
Yes. Add ObjectZIA as a second OTLP exporter in your existing collector config, no changes to your instrumentation, and compare the two side by side before cutting over.
Yes, this is one of the two supported collection paths above. Filtering, sampling, and redaction happen inside your network before anything reaches ObjectZIA.
You can export everything in OTLP format before or after cancelling. There's no minimum retention period gating access to your own trace data.
OTLP is a CNCF-governed wire format implemented by dozens of backends, not something ObjectZIA controls. The same instrumented service can export to us, to an open-source backend, or to another vendor without touching application code.
Traces are where ObjectZIA is strongest today. OTLP metrics and logs ingestion is on our roadmap; ask us for the current status if that's a requirement.
If you're already emitting OTLP, request early access and we'll help you point a collector at us.
Keep me posted