OpenTelemetry-native monitoring captures application spans, traces, and attributes on open standards, so OTel telemetry flows into ObserveOps APM without a translation layer.
OpenTelemetry has become the common language for application telemetry, and Motadata ObserveOps Application Performance Monitoring speaks it natively. Instrumentation is built on OpenTelemetry standards, so the traces, spans, and attributes your services emit flow into ObserveOps without a translation layer in between, which is what "OpenTelemetry monitoring" means in practice: OTel data in, OTel-shaped analysis out.
This page covers the OpenTelemetry side of APM: OTel-native instrumentation, the languages it reaches, custom business context carried on the OTel SDK, and distributed tracing built on open standards. Everything here stays at the application-code layer. Host, node, and pod-scheduling health belong to the Hybrid Infrastructure module, and browser-side experience belongs to Real User Monitoring, both of which cross-link into APM traces without APM claiming their ground.
For teams standardizing on OpenTelemetry, this means the instrumentation you already understand maps directly onto what ObserveOps collects, analyzes, and visualizes, delivered through a single unified MotaAgent rather than a collection of per-language agents to manage separately.
Application telemetry is captured through OpenTelemetry-native instrumentation, so spans and attributes are collected on open standards rather than a proprietary format that has to be converted before use.
Ruby and C++ services are instrumented OTel-native, extending open-standard tracing to two runtimes that OpenTelemetry tooling often leaves out.
Domain-specific attributes, KPIs, and identifiers are pushed from your source code through the OpenTelemetry SDK into APM, stored as indexable aggregate counters, and made available in the Custom Attribute Manager.
Distributed tracing is built on OpenTelemetry standards, so a request that crosses several services is stitched into one trace with its spans intact from entry point to downstream dependency.
OTel-instrumented microservices can be grouped into named Business Services such as Checkout or Payment Processing, which then become a first-class dimension for filtering, grouping, and analytics across APM dashboards.
Span data collected on OpenTelemetry standards is assembled into a service topology map, so how OTel-instrumented services depend on one another is visible without separate configuration.
Per-endpoint behavior is reported from the same OpenTelemetry traces used elsewhere in APM, with single-click filters to isolate traffic by HTTP method such as GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS.
Two OTel-instrumented services, or two Business Services built from them, can be compared side by side with independent time ranges, and severity-based heatmaps assess counters such as response time and error rate without additional telemetry setup.
Database calls triggered by OpenTelemetry-instrumented services link back to the traces that issued them across 40+ supported database systems, and directly discovered databases connect into that same trace and topology view.
For OTel-instrumented Java services, JVM Analysis reports garbage collection, heap, and thread behavior next to the trace data, so a Java-specific runtime condition reads alongside the OpenTelemetry spans it affected.
Saved Views in APM Explorer preserve search queries, filters, view types, and layout for a recurring OTel trace investigation, and Custom Reports support Chart, Grid, Top-N, Counter, and Aggregation formats built on the same indexable counters that Custom Business KPI Injection produces.
Because collection is OpenTelemetry-native, the instrumentation your teams write stays aligned with an open standard rather than locked to one vendor format.
Custom Business KPI Injection via the OTel SDK lets the metrics that matter to your domain travel with the trace, so technical spans and business identifiers sit side by side.
Distributed tracing on OpenTelemetry standards follows a request across service boundaries, so P99 latency, error rate, and throughput can be read at each hop instead of guessed at.
Grouping OTel-instrumented microservices into Business Services means analysis follows how the organization thinks about Checkout or Payment Processing, not just individual service names.
Compare view sets an OTel-instrumented service, or a Business Service, against itself across two time ranges, so a post-deploy regression is visible at a glance.
A single unified MotaAgent collects OpenTelemetry-shaped telemetry across every supported language, reducing the number of separate tools and formats a team has to reconcile.
Saved Views in APM Explorer preserve the search queries, filters, and layout used to investigate a known OTel trace pattern, so the next occurrence does not start from a blank explorer.
OTel-native instrumentation extends across the core APM language set: Java 8+, .NET 8/9, PHP 8.1-8.4, Node.js 18.19+/20.6+, Python 3.9+, and Go 1.18+, all traced on OpenTelemetry standards through the single unified MotaAgent.
Ruby and C++ are instrumented OTel-native as well, on Host/VM and Docker, bringing the same open-standard trace model to runtimes that are frequently left out of OpenTelemetry tooling.
OpenTelemetry-native instrumentation captures spans, traces, and attributes from application code across the supported languages. Custom Business KPI Injection via the OTel SDK adds domain-specific attributes and identifiers from source code, and a single unified MotaAgent carries the telemetry into ObserveOps.
For Ruby and C++, OTel-native collection runs on Host/VM and Docker.
Distributed tracing built on OpenTelemetry standards correlates spans into complete request paths across services. Injected business KPIs are stored as indexable aggregate counters, and application performance is read through approved measures such as P99 latency, error rate, throughput, and Apdex at the service and endpoint level. Business Service tags roll that analysis up to the domain level when configured.
Traces, spans, and service topology are presented in the APM Explorer, while OTel-instrumented microservices grouped into Business Services drive filtering and analytics across dashboards. Injected custom attributes surface in the Custom Attribute Manager for query and reporting, and severity-based heatmaps give a fast visual read on response time and error rate.
OpenTelemetry-native monitoring stays inside the application-code layer that APM owns: traces, spans, service dependencies, endpoint behavior, and injected business KPIs, all captured on open standards. When the question turns to the host or cluster underneath an OTel-instrumented service, that belongs to the Hybrid Infrastructure module, and when the question is what a real visitor experienced in the browser, that belongs to Real User Monitoring.
ObserveOps links these views so an OTel trace can be read against the infrastructure it ran on and the browser session it served, without APM extending its scope past the application code it instruments.
OpenTelemetry-native monitoring in Motadata ObserveOps takes instrumentation your teams already build on open standards and turns it into distributed traces, business-aware KPIs, and service-level analysis. With OTel-native coverage that reaches Ruby and C++ and business context carried on the OTel SDK, APM stays grounded in the application code while linking out to infrastructure and frontend where the request continues.
Discover how Motadata ObserveOps can help you monitor your infrastructure in real-time and respond to issues instantly.