→
Vendor agent → OTel SDK
The OpenTelemetry SDK for your language replaces the vendor tracer library. Auto-instrumentation covers HTTP servers, HTTP clients, databases, message queues, and gRPC for every supported language.
// four numbers, no proprietary agent
The four numbers APM is supposed to give you.
You do not need 47 dashboards to run a service. You need four numbers: requests per second, error rate, p95 latency, and saturation. Telemtra gives you those without a proprietary agent in your runtime - just the OpenTelemetry SDK and an OTLP exporter you already trust.
- Per-service and per-operation request rate
- Error rate with status code breakdown
- p50, p75, p90, p95, p99 latency from OTLP histograms
- Runtime saturation metrics (CPU, memory, GC) via OTel runtime instrumentation
- Service dependency mapping from trace edges
// map → trace → span → root cause
From a slow endpoint to the root cause in three clicks.
The hard part of APM has never been the dashboard. It is the path from "the endpoint is slow" to "this database query is the reason." Telemtra builds that path on the trace waterfall and the Service Map, not on heuristics or AI guesses.
- Click the slow service on the map → see its dependency edges
- Click the red edge → jump to a representative slow trace
- Click the long span in the waterfall → see the SQL, the HTTP call, or the queue interaction that caused it
- Logs emitted inside the span are linked by trace ID, so no "logs from around that time" guessing
// migration
What replaces what.
Migrating from a traditional APM tool to OTel-native APM is mostly a swap of moving parts, not a rewrite.
→
Proprietary wire → OTLP
OTLP over HTTP or gRPC carries traces, metrics, and logs. The same format every OTel-compatible backend accepts, so a future backend switch is a one-line exporter change.
→
Per-host APM seat → flat ingest
No per-host APM surcharge. The whole platform is included on every plan and pricing is based on workspace tier and GB ingested.
// the workflows, broken out
Each one has its own page.
APM is not one feature - it's six working together. Click any to read the moment of pain it solves.
→ →
Traces
Span waterfall, p95/p99 latency, status and duration filters. The diagnosis surface for slow endpoints.
→ →
Metrics
OTLP gauges, sums, and histograms with p50–p99 chart modes. The numbers behind every dashboard.
→ →
Service Map
Live dependency graph drawn from trace edges. Where APM starts.
→ →
Dashboards
Combine metrics, log queries, and Service Map widgets into one canvas per team.
→ →
Alerts
Threshold and rate alerts on latency, errors, and metric values. Email and signed webhook.
→ →
Logs
OTLP log records linked to traces by trace ID. No 'logs from around that time' guessing.
// honest comparison
How it compares to traditional APM.
The honest version, including where Telemtra is narrower.
=
What's the same
Request rate, error rate, latency percentiles, service dependency mapping, slow-trace drilldown, alerting on latency and errors. The core APM workflows are all here.
~
What's different
OpenTelemetry is the wire format, not a side input. Pricing is flat by ingest, not per-host. The instrumentation is open standard and portable to other OTel backends.
!
What's narrower (today)
Continuous profiling, real user monitoring, synthetic tests, and security signals are not in scope yet. If those are dealbreakers, traditional APM tools have more breadth. Honest alternatives comparison →
// frequently asked
Questions about APM.
Agents, OTel, Datadog comparison, and what Telemtra actually measures.
Is Telemtra an APM tool?
Yes. Application Performance Monitoring is one of the use cases Telemtra is built for - request latency, error rate, throughput, dependency mapping, and slow-trace diagnosis are all native workflows. The difference from traditional APM is that Telemtra accepts standard OpenTelemetry data, with no proprietary agent or tracer library.
What is OpenTelemetry-native APM?
Traditional APM ships vendor agents (Datadog Agent, New Relic Agent, Dynatrace OneAgent) that auto-instrument your application and report in a proprietary format. OpenTelemetry-native APM uses the OpenTelemetry SDK or auto-instrumentation libraries in your application and exports OTLP - the open standard - so the backend is replaceable without re-instrumenting.
Do I need a Telemtra APM agent?
No. Telemtra has no proprietary agent. Use the OpenTelemetry SDK for your language (Python, Node.js, Go, Java, .NET, Ruby, Rust, PHP) or the OpenTelemetry Collector, point the OTLP exporter at Telemtra, and APM signals - traces, metrics, logs - start flowing.
How is Telemtra APM different from Datadog APM?
Three differences. First, Telemtra accepts only OpenTelemetry; Datadog primarily accepts its own format and adds OTLP as an alternative. Second, pricing is flat per workspace and per GB ingested - no per-host APM surcharge. Third, Telemtra is newer and narrower than Datadog; it covers core APM well but does not yet have RUM, synthetics, or continuous profiling parity.
What does Telemtra measure for APM?
Request rate, error rate, and latency (p50, p75, p90, p95, p99) per service and per operation. Dependency mapping between services via Service Map. Span-level breakdown via the trace waterfall. Database query latency, HTTP client call latency, and message queue interaction latency where the OTel instrumentation reports them. Custom metrics and custom spans for business operations.
Can I use Telemtra APM with my existing logging tools?
Yes. The OpenTelemetry Collector can fan out logs to Telemtra and to another backend simultaneously. Many teams keep their existing log stack during evaluation and switch the trace and metric paths first.
// next step
See your APM signals in 60 seconds.
Point any OpenTelemetry exporter at Telemtra and watch request rate, errors, and p95 latency appear in real time.