What SDK-native APM actually is

When a checkout page is slow, the first question is not “is the node out of CPU?” It is “which request, which query, which dependency?” Application performance monitoring answers that question. Infrastructure monitoring answers a different one. Talaria is built for the first.

The problem

Production systems fail in two ways that look similar from a pager and are nothing alike in a dashboard. Hosts run hot. Apps wait on databases, payment APIs, and client rendering. Mixing those signals into one product is how teams end up paying for metrics they never query.

Google’s SRE workbook popularized the four golden signals of latency, traffic, errors, and saturation. Weaveworks later distilled the application-facing three into RED — rate, errors, and duration — because saturation is a host concern. The USE method (utilization, saturation, errors) is the complementary host view. Confusing RED with USE is how APM pages grow CPU charts nobody asked for.

What it is

APM, in the sense product teams actually buy, is timing of application work: incoming requests, the queries and outbound calls those requests make, and the real-user vitals of the pages that triggered them. OpenTelemetry calls each timed unit a span and the whole request a trace. Semantic conventions name the attributes so backends can query them portably.

SDK-native means that instrumentation runs inside the application process, not as a sidecar, node agent, or Kubernetes DaemonSet. Official Talaria SDKs start a transaction around the request or navigation, record child spans for database and HTTP work, and send a sampled batch to spans/ingestBatch.

What it gives a team

• A shared language for “the app is slow”: throughput, error rate, and p95 — not a wall of host graphs.
• A path from a grouped issue to the trace that produced it, and from a release to crash-free health.

How Talaria does it

Official SDKs emit a transaction (the root span) and child spans for database and outbound HTTP work. Traces follow OpenTelemetry concepts — span, trace, span kinds, and semantic conventions — and W3C Trace Context (traceparent) joins a browser navigation and an API request on one traceId. If you already run an OpenTelemetry Collector, OTLP/HTTP JSON traces are accepted at /otlp/v1/traces.

The dashboard Performance view shows RED series, a transaction list, slow queries and N+1, dependency peers, and Web Vitals from the browser SDK. Release health lives next to issues. Performance is included on every plan, and public pricing stays accepted events and retained replays.

How to read it

Start on the project Performance overview. If throughput dropped and error rate rose together, look at traces with status error. If p95 rose while errors stayed flat, open a slow transaction waterfall and read the longest child span. If only the browser is unhappy, open Web Vitals — that is client time, not the API.

Turn it on

Tracing stays off until you turn it on under Project settings. Error transactions are always sampled once tracing is on; successful ones follow the project rate (10% until you change it). See the SDK guides for install.

Talaria::init([
    'dsn' => 'https://ingest.newtalaria.com',
    'apiKey' => getenv('TALARIA_API_KEY'),
]);

Native SDKs remain the supported path. The OTLP endpoint is for collectors already in the network.