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.

SDK-native means that instrumentation runs inside the application process — Composer, npm, pub — 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. No host daemon is required.

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.
• Honest scope. You are not buying profiling, log ingestion, or Kubernetes metrics under an APM label.

How Talaria does it

Talaria’s ceiling is Sentry-class performance for the stacks you already instrument: PHP and Silverstripe, browser JavaScript, Dart and Flutter. Errors, issues, and session replay stay proprietary. Traces adopt OpenTelemetry concepts and W3C Trace Context so a browser navigation and a PHP request can share one traceId.

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 — not a fourth public meter. 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 PHP time.

Turn it on

Tracing is off until you set enableTracing or tracesSampleRate > 0. Error transactions are always sampled once tracing is on; successful ones default to 10%. See the SDK guides for your platform.

Talaria::init([
    'dsn' => getenv('TALARIA_DSN') ?: 'https://api.newtalaria.com',
    'apiKey' => getenv('TALARIA_API_KEY'),
    'enableTracing' => true,
    'tracesSampleRate' => 0.1, // 10% of successful requests; errors always traced
]);

What this is not

Talaria does not collect host or Kubernetes metrics, continuous profiles, or a general-purpose log product. Those are useful tools. They are not this product. If you already run an OpenTelemetry Collector, you can send OTLP/HTTP JSON traces to /otlp/v1/traces — native SDKs remain the supported path.