# Architecture: API, SDK, Collector, OTLP — OpenTelemetry

Source: https://www.skillbyai.com/en/opentelemetry/f-arch

> How the pieces fit.

## From code to backend

Libraries and applications call the **API** (stable interfaces that do nothing if no SDK is installed, so libraries can instrument safely). The application configures the **SDK**, which implements sampling, processing and **exporters**. Data is usually sent with **OTLP** (OpenTelemetry Protocol) over gRPC (port 4317) or HTTP (port 4318) to the **Collector**, a separate process that receives, processes and exports telemetry to one or more backends. **Semantic conventions** standardise attribute names such as `http.request.method` and `service.name`.

## The data path

Typical deployment.

```text
app code --> OTel API --> OTel SDK (sampler, processors, OTLP exporter)
                               |  OTLP gRPC :4317 / HTTP :4318
                               v
                      OpenTelemetry Collector
             receivers -> processors -> exporters
                               |
          +--------------------+--------------------+
          v                    v                    v
   traces backend        metrics backend       logs backend
   (Jaeger / Tempo)      (Prometheus / Mimir)  (Loki / vendor)
```

## Libraries depend on the API only

Library authors should never configure an SDK; the application owner decides how telemetry is processed and exported.

**Quiz:** Which default port does OTLP over gRPC use?

- [ ] 4318
- [ ] 9090
- [ ] 8080
- [x] 4317

*Answer:* 4317. 4318 is OTLP over HTTP.