Motadata ObserveOps distributed tracing follows a single request across every service it touches and breaks it into spans, so teams can see exactly where latency or an error began.
Distributed tracing follows a single request as it moves through the services that make up a modern application. Each hop becomes a span, and the spans together form a trace that shows exactly where time was spent and where an error began. Instead of reading each service in isolation, a team reads one continuous path for the transaction a user actually ran.
In a microservices architecture, a single request can cross many services before it returns a response, and an average latency number hides which of those services was slow. Distributed tracing replaces that average with evidence: the specific spans, in order, with the duration of each one, so the investigation starts at the operation that consumed the time rather than at a guess.
Motadata ObserveOps builds distributed tracing on OpenTelemetry standards, so the traces you collect follow an open, well-understood data model rather than a closed format. A single unified MotaAgent carries the instrumentation, and OTel-native paths cover languages such as Ruby and C++, so spans read the same way across every supported language.
Tracing in ObserveOps stays focused on application code behavior: the transactions, service calls, and span timings inside your application. Infrastructure signals such as node CPU, memory, and cluster node health belong to the Hybrid Infrastructure module, and browser-side experience belongs to Real User Monitoring. ObserveOps links these views to the same request while each module keeps its own scope.
Distributed tracing is built on OpenTelemetry standards, giving you an open data model for spans and traces. OTel-native instrumentation is available for languages including Ruby and C++, carried by a single unified MotaAgent, so telemetry stays consistent and portable across every supported language rather than locked to a vendor format.
Each request is followed across every service it touches, so a single trace shows the complete path of a transaction and where time is spent along the way instead of a set of disconnected service metrics.
Span View in APM Explorer breaks each trace into its individual spans so you can read the call sequence, see how long every operation took, and locate the span where latency or an error started. Frequently used trace fields can be pinned in the trace details panel so they stay visible as you move between traces.
ObserveOps maps how services call one another and renders the dependency graph, so the trace of a slow request reads against the service map that produced it and the upstream or downstream service behind a regression is clear.
The trace scatter plot charts traces over time by duration, making slow outliers and clusters of failed requests visible at a glance instead of hidden inside an average. Selecting a time range on the scatter plot filters the trace grid below it, so a visual pattern becomes the exact set of traces you inspect.
Application traces link to the database calls they trigger across 40+ supported database systems, and directly discovered databases connect into APM traces and service topology. A Database Operation Type filter narrows the view to SELECT, INSERT, UPDATE, or DELETE activity, so a trace continues into the data dependency behind it. The database systems themselves are monitored through database monitoring.
The API Endpoint Summary reports per-endpoint behavior, and single-click filters isolate traffic by HTTP method such as GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS, so a trace investigation narrows to the exact route and verb behind an error.
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, so a trace can be read at the level of a business transaction rather than a single service.
Application errors and exceptions are captured with the traces that produced them, so recurring failures surface as patterns. A No Trace Received alert can be configured during service registration to fire when no traces arrive within a defined period, surfacing a silent or mis-instrumented service before the gap goes unnoticed.
eBPF/OBI-based instrumentation discovers and monitors services automatically, with no code changes and no agent install, capturing service-to-service communication, request count, latency, error rate, and traces and spans, and surfacing them in the existing service list, service map, traces, and dashboards.
A single unified MotaAgent instruments your application code and emits spans on OpenTelemetry standards, and OTel-native instrumentation covers languages including Ruby and C++. The agent collects trace and span data as requests flow through your services, and the code-free eBPF/OBI path can discover and monitor services with no agent install at all. For Go, database tracing is not automatic and requires QueryContext or ExecContext together with the otelsql wrapper. When a service is registered, a No Trace Received alert can be configured to fire if no traces arrive for a defined period.
Collected spans are assembled into complete traces and summarized against approved metrics including P99 latency, error rate, throughput measured in requests or transactions per second, and Apdex. Spans are correlated into full request paths, database calls are linked back to the services that issue them, and endpoint traffic is broken down by HTTP method. Selecting a time range on the trace scatter plot filters the trace grid so the analysis narrows to the requests that matter.
Span View, the service topology map, the trace scatter plot, and the filtered trace grid in APM Explorer present the data, letting you move from a broad view of trace duration to the individual spans of one request and on to the database call behind it as a single connected timeline. Heatmaps give a severity-based visual assessment over counters such as response time and error rate without additional telemetry setup, and Saved Views preserve a recurring trace investigation as its search query, filters, view type, and layout.
For applications written in Java, .NET, PHP, Node.js, Python, and Go, distributed tracing spans Host/VM, Docker, and Kubernetes, and that Kubernetes coverage extends to managed distributions on AWS EKS, Oracle OKE, Google GKE, Rancher, and serverless AWS EKS Fargate, where node-level DaemonSet deployment is not possible.
Because collection is standardized on a single unified MotaAgent and OpenTelemetry, the same span model, service topology, and endpoint analysis apply whether a service runs on a virtual machine, inside a container, or in a cloud-native cluster. That gives cloud, hybrid, and containerized applications one consistent trace view rather than a separate tool per environment.
Ruby and C++ services are traced through OTel-native instrumentation on Host/VM and Docker only, which keeps their deployment scope separate and unambiguous.
Span View shows which operation inside a trace consumed the time, so investigation lands on the responsible service rather than the whole request path.
Because tracing is built on OpenTelemetry standards through a single unified MotaAgent, your instrumentation follows an open specification and your teams work with a familiar span and trace model across every language.
The trace scatter plot surfaces slow and failed traces as distinct points, so a P99 latency problem affecting a fraction of requests does not disappear into a mean.
Trace grid filtering ties the scatter plot to the underlying traces, turning a visual pattern into the exact set of requests behind it without a separate search.
Database correlation ties a trace to the queries it runs across 40+ database systems, so a slow service and its data dependency read as one story rather than two isolated views.
Business Service tagging groups related microservices into named units such as Checkout, so a trace can be filtered and analyzed as the business flow it belongs to rather than a scatter of isolated spans.
Full-stack visibility comes from keeping each layer in its own lane and joining them at the seams. Distributed tracing owns application code behavior: spans, service dependencies, endpoint response, and the database calls a request triggers. When the question is about the host or cluster underneath, such as CPU, memory, or node health, that belongs to the Hybrid Infrastructure module, and when the question is about what a real visitor experienced in the browser, that belongs to Real User Monitoring.
ObserveOps links these views so a browser session can connect to its backend trace and a slow span can be read against the infrastructure it runs on, without any one module overstating its scope. The result is a full-stack picture assembled from accurate parts rather than one blurred view.
Distributed tracing in Motadata ObserveOps turns a scatter of service calls into one readable path for every request. Built on OpenTelemetry standards and presented through Span View, service topology, the trace scatter plot, and grid filtering, it lets teams see where latency and errors originate inside their application code, follow a request into the database call behind it, and act on the evidence rather than an average.
Discover how Motadata ObserveOps can help you monitor your infrastructure in real-time and respond to issues instantly.