Resources · Integration patterns
OpenTelemetry collection
Standard telemetry through a collector with masking, sampling and export to a chosen backend.
Integration status: Future
Future: the ingestion contract is designed (docs/AI_OBSERVABILITY.md) but no collector or gateway is built.
Description
Services send metrics, logs and traces over OTLP to a collector that masks, filters, samples and exports. For AI systems, metadata (status, time, tokens) is collected without content.
Prerequisites
- A chosen backend.
- Agreed attributes and names.
- Personal data rules.
When to use it
- Several services and tools.
- Tracing across services is needed.
- Vendor independence is wanted.
When not to use it
- One application with enough built-in logs.
- Nowhere to store the telemetry.
- Request content is needed but not permitted.
Reference diagram
An illustration of the components and the flow — not a running system.
01Sources
- SDKs in services
- Infrastructure agents
02Collector
- Per-organisation authentication
- Masking
- Limits and idempotency
03Backend
- Metrics
- Logs
- Traces
The diagram as a list
| Stage | Components |
|---|---|
| Sources | SDKs in services, Infrastructure agents |
| Collector | Per-organisation authentication, Masking, Limits and idempotency |
| Backend | Metrics, Logs, Traces |
Security controls
- Every source authenticated per organisation.
- Masking before export; no AI request content by default.
- Size limits and per-organisation quotas.
Observability
- Volume per source.
- Rejected records.
- Collector latency.
Failure modes
| Failure | Mitigation |
|---|---|
| Volume explosion | Sampling and quotas. |
| Personal data in attributes | Masking rules and tests. |
| Data sent twice | Idempotency keys. |