API

Definition

An API, or application programming interface, is the defined contract through which one piece of software talks to another. In observability the term shows up in two distinct roles: the OpenTelemetry API that code uses to produce telemetry, and the service APIs whose health and latency observability exists to measure.

What it means in observability

The OpenTelemetry API is the thin, stable layer your application and library code calls to create spans, record metrics, and emit logs. It deliberately does nothing on its own: without an SDK installed, every call is a cheap no-op. That design lets frameworks and shared libraries ship instrumentation by default, safely, because the cost and the backend decision only materialize when an application wires up an SDK. In the other sense of the word, APIs are the seams of modern systems. Requests enter and leave services through HTTP and RPC interfaces, which makes API boundaries the natural place to measure traffic, errors, and duration.

How it works in practice

For the OpenTelemetry sense, the pattern is instrument against the API, configure the SDK at startup. Library authors depend only on the API package, and applications add the SDK and exporter. For the service sense, API calls appear in telemetry as spans with a server or client span kind, carrying attributes such as the HTTP method, route, and status code, named according to the semantic conventions. Those spans are what power endpoint level views of request rate, error rate, and latency percentiles.

Where it gets hard

The overloaded terminology genuinely confuses teams: an engineer reading about the OpenTelemetry API in one document and API monitoring in another is looking at two unrelated concepts sharing three letters. On the instrumentation side, depending on the full SDK where only the API is needed couples libraries to implementation details they should not know about. On the measurement side, unbounded route attributes, such as raw URLs with customer IDs embedded in them, create cardinality problems that inflate cost and slow queries.

Where Tsuga fits

Tsuga sits downstream of both meanings. Telemetry produced through the OpenTelemetry API arrives over OTLP with nothing extra to install, and Tsuga's service views break traffic, errors, and latency down by endpoint and operation, so API health is visible without extra configuration.