OTel-Native by Design – Producten bouwen die exporteren naar elke Observability Stack

Als u zelf-gehoste software of een SaaS-product bouwt, zullen uw gebruikers uiteindelijk vragen om logs, traces en metrics naar hun eigen observability stack te kunnen sturen. Dit kan zijn om te voldoen aan compliance-eisen, om kosten te beheren of om al hun observability-data op één centrale plek te verzamelen.

Het beperken van gebruikers tot uw ingebouwde dashboards of het beperken van exports tot bepaalde leveranciers creëert onnodige wrijving. In plaats daarvan is het ondersteunen van export naar elke OpenTelemetry (OTel)-compatibele backend een vendor-neutrale, toekomstbestendige praktijk die gebruikers de vrijheid geeft om hun eigen observability stack te kiezen.

Dit artikel beschrijft hoe u uw product kunt ontwerpen zodat gebruikers hun logs, traces en metrics naar een OTel-backend kunnen exporteren wanneer zij dat willen.

De vier observability-signalen

OpenTelemetry definieert vier soorten signalen, die allemaal worden verzonden via het standaard OpenTelemetry Protocol (OTLP):

• Logs: Gebeurtenisrecords, request/access logs en applicatielogs met tijdstempels en metadata.
• Traces: Gedistribueerde traces en spans, zodat gebruikers request-flows over services heen kunnen zien en deze kunnen correleren met logs.
• Metrics: Counters, gauges en histogrammen (bijv. request-snelheden, latentie, foutpercentages).
• Profiles: Samples die laten zien waar applicaties resources verbruiken tijdens de uitvoering.

Opmerking over Profiles: Profiles zijn op 26 maart 2026 in public alpha gegaan. Als signaal is het de bedoeling van OpenTelemetry dat profielen naast de huidige drie grote observability-signalen komen te staan, om gebruikers te helpen productie-incidenten op te lossen door resourcegebruik-patronen in hun codebase vast te leggen. Hoewel we ons in deze blog uitsluitend richten op logs, traces en metrics, zijn we benieuwd hoe profielen vorm krijgen en hoe de community ze in hun observability-systemen implementeert.

Het exportverhaal is voor alle drie de signalen (logs, traces en metrics) hetzelfde: laat gebruikers een OTLP-endpoint configureren en push de telemetrie daarnaartoe. Afhankelijk van wat uw product genereert, kunt u één, twee of alle drie de signalen ondersteunen. Veel platforms die OTel-export ondersteunen, bieden in ieder geval traces en logs aan, en een toenemend aantal voegt nu metrics-ondersteuning toe. Door vanaf het begin op alle drie te ontwerpen, voorkomt u dat u dit later moet retrofitten.

Hoe een "goed" telemetriesysteem eruitziet

Een solide exportstrategie heeft voor elk ondersteund signaal een aantal duidelijke eigenschappen:

• Vendor-neutraal: Gebruikers kunnen naar elk OTel-compatibel endpoint wijzen — een Collector-instantie of een van de vele backends die OTLP direct ondersteunen — zonder dat er custom integraties voor elke leverancier gebouwd hoeven te worden.
• Geen complexe custom ontwikkeling: Externe platforms (of de tooling van uw gebruikers) kunnen integreren via standaard OTel SDK's en het OTLP-protocol in plaats van propriëtaire API's.
• Rijke context behouden: Geëxporteerde data moet metadata, tijdstempels en trace/span-correlaties bevatten waar beschikbaar (bijv. log-records gekoppeld aan trace-ID's), zodat gebruikers data in hun eigen backend kunnen debuggen en analyseren zonder contextverlies.
• Ondersteuning voor Semantic Conventions: Navolging van de Semantic Conventions zorgt ervoor dat telemetrie-data gestandaardiseerd blijft en gemakkelijk interpreteerbaar is door elke compatibele backend. Dit vermindert ook de cognitieve last voor de eindgebruiker om te begrijpen hoe het softwaresysteem werkt, of het nu een first-party of third-party systeem is.

Twee contexten: waar draait uw product?

De manier waarop u OTel-export toevoegt, hangt af van wie het systeem beheert dat de telemetrie produceert.

Zelf-gehoste software

Uw product is een applicatie of systeem (bijv. een identity server, een service mesh, een database) dat klanten installeren en draaien in hun eigen omgeving (hun datacenter, hun cloud, hun Kubernetes-cluster).

Hier instrumenteert u uw product met OpenTelemetry. Wanneer de klant een endpoint configureert (bijv. via omgevingsvariabelen of een configuratiebestand), exporteert uw applicatie telemetrie vanuit het proces dat zij draaien. Omdat OpenTelemetry standaard configuratieopties biedt, kunnen gebruikers dezelfde ervaring verwachten als bij elk ander OTel-geinstrumenteerd systeem.

De export vindt plaats in de omgeving van de klant; zij beheersen het binary en de bestemming. Voorbeelden: Keycloak, Kuma.

Cloudplatforms

Uw product is een platform waar klanten hun eigen apps implementeren of uw managed services gebruiken (bijv. PaaS, serverless, API gateway). De workload draait op uw infrastructuur.

Hier voegt u een platformfunctie toe, zoals "Telemetry Drains" of "Observability Destinations", waarmee klanten kunnen configureren waar de telemetrie naartoe moet worden gestuurd. Uw platform verzamelt telemetrie van hun workload (en van uw eigen services, zoals routers) en stuurt deze door naar het OTLP-endpoint van de klant.

De export wordt uitgevoerd door uw infrastructuur, niet door een applicatie-binary die de klant draait. Voorbeelden: Heroku, Cloudflare.

Kortom: User-deployed software → focus op ingebouwde instrumentatie en endpoint-configuratie. Een platform dat u beheert → focus op configureerbare exportbestemmingen die uw infrastructuur gebruikt om data door te sturen.

Hoe anderen het doen

Hieronder staat hoe vier representatieve voorbeelden omgaan met de signalen.

Platform	Logs	Traces	Metrics	Implementatiemethode	Notities
Kuma	Ja	Ja	Ja	Software (user deployed)	Separate policies per signaal, allemaal OTel
Keycloak	Ja†	Ja	Ja	Software (user deployed)	†Logs in preview; hetzelfde endpoint voor alles
Cloudflare Workers	Ja	Ja	Nee*	Platform	*Metrics export nog niet ondersteund
Heroku	Ja	Ja	Ja	Platform	Gebruiker kiest signalen via --signals

De zelf-gehoste aanpak: Kuma en Keycloak

Als gebruikers uw software in hun eigen omgeving implementeren, is de best practice om de applicatie vooraf geïnstrumenteerd met OpenTelemetry te leveren en configuratie-flags voor hun OTLP-endpoints beschikbaar te stellen.

Kuma

Of klanten Kuma's control- en data-planes nu draaien op hun eigen Kubernetes-clusters of VM's, het is vooraf geconfigureerd om logs, traces en metrics naar een OTel-backend te sturen. Gebruikers configureren de export via mesh-policies:

• MeshAccessLog: Stuurt access logs naar een OTel Collector (endpoint + attributen zoals mesh-naam, starttijd).
• MeshTrace: Regelt gedistribueerde traces met configureerbare sampling en tagging.
• MeshMetric: Stelt control- en data-plane metrics beschikbaar. Integreert met OpenTelemetry en Prometheus.

Voorbeeld van het verzenden van traces naar een OTel-backend:

# MeshTrace policy
backends:
- type: OpenTelemetry
openTelemetry:
  endpoint: otel-collector:4317

Voorbeeld van het verzenden van access logs:

# MeshAccessLog policy
backends:
- type: OpenTelemetry
openTelemetry:
  endpoint: otel-collector:4317
  body:
    kvlistValue:
      values:
      - key: mesh
        value:
          stringValue: '%KUMA_MESH%'
      attributes:
      - key: start_time
        value:
          stringValue: '%START_TIME%'

Keycloak

Keycloak is een ander voorbeeld van zelf-gehoste software met uitgebreide telemetrie-export. In plaats van een aparte sidecar of platformfunctie, geven gebruikers simpelweg een startup-flag op die naar hun Collector-endpoint wijst. Het Keycloak-proces zelf regelt de export.

Er wordt één telemetrie-endpoint gebruikt, maar er zijn granulaire flags om specifieke signalen in of uit te schakelen:

• Traces: tracing-enabled=true (dekt HTTP-requests, DB, LDAP, outbound HTTP/IdP).
• Metrics: Gedetailleerde metrics via dezelfde OTel-integratie.
• Logs: Momenteel in preview en standaard uitgeschakeld (--features=opentelemetry-logs --telemetry-logs-enabled=true, met --telemetry-logs-level voor filteren).

Het definiëren van het endpoint, optionele headers en het voorkeursprotocol (gRPC of HTTP) ziet er als volgt uit:

bin/kc.sh start --telemetry-endpoint=http://my-otel-endpoint:4317 --telemetry-protocol=grpc

De platform-aanpak: Cloudflare en Heroku

Wanneer u de infrastructuur beheert, is de meest eenvoudige gebruikerservaring om de export op platformniveau af te handelen.

Cloudflare Workers

Omdat gebruikers hun code direct op de infrastructuur van Cloudflare draaien, wordt de export beheerd via de "Observability Destinations" platformfunctie. Gebruikers kunnen een OTLP-endpoint configureren in hun dashboard, waarna Cloudflare automatisch traces en logs van Workers naar die bestemming pusht. Hoewel metrics nog niet worden ondersteund, bieden de trace-data diepgaand inzicht in handler calls, bindings en outbound fetch calls. De sampling rate kan worden geconfigureerd in wrangler.toml.

Heroku

Heroku hanteert een zeer configureerbare aanpak met "Telemetry Drains". Gebruikers voegen een bestemming toe door het endpoint, transportprotocol en headers op te geven, en kiezen vervolgens expliciet welke signalen geëxporteerd moeten worden. Het platform verzamelt data van zowel de applicatie van de gebruiker (via de OTel SDK) als van first-party services (zoals hun Router).

Voorbeeld commando:

heroku telemetry:add <endpoint> --app <app-name> --signals traces,metrics,logs --transport http --headers '{"Authorization": "ingestion key"}'

Uw exportmodel ontwerpen

De fundamentele architecturale vraag is: moet de gebruiker via een API periodiek data ophalen (polling), of levert u de telemetrie direct aan een door de gebruiker gedefinieerd endpoint (push)?

De klassieke aanpak: custom polling API's

Traditioneel stelden platforms telemetrie beschikbaar via API's die gebruikers periodiek moesten pollen, waarbij ze paginering moesten afhandelen en de resultaten in hun eigen backends moesten laden.

Hoewel dit een logisch startpunt is als u al een mature API heeft, brengt het aanzienlijke kosten met zich mee:

1. Operationele last voor de gebruiker: Zij moeten schaalbare polling-systemen bouwen die intervallen beheren, paginering afhandelen, retries uitvoeren en ontbrekende data aanvullen.
2. Onderhoud: Gebruikers bouwen vaak custom oplossingen die niet schalen en veel onderhoud vereisen naarmate uw API-schema evolueert.
3. Latentie: Real-time levering wordt significant moeilijker, wat cruciaal is voor latency-gevoelige signalen zoals traces en metrics.

Een pull-gebaseerde implementatie voor logs ziet er vaak zo uit:

state: last_end_time
every poll_interval:
    start_time = last_end_time
    end_time   = now()
    next_token = null
    do:
        response = FilterLogEvents(log_groups, start_time, end_time, next_token)
        emit(response.events)
        next_token = response.nextToken
    while next_token != null

Voor nieuwe ontwerpen zou dit model niet de standaard moeten zijn.

De standaard-georiënteerde aanpak: OTLP

Voor real-time telemetrie gericht op ontwikkelaars is OTLP push het dominante patroon geworden. In plaats van te wachten op een vraag, exporteert uw service (of een OpenTelemetry Collector die u draait) logs, traces en metrics actief naar het geconfigureerde endpoint van de gebruiker.

• Eén protocol: U gebruikt één vendor-neutraal protocol voor alle telemetrie, waardoor u niet voor elk signaal aparte leveringslogica hoeft te bouwen.
• Contextbehoud: OTLP ondersteunt gestructureerde data en metadata uitstekend, waardoor cruciale context (zoals de koppeling tussen logs en trace-ID's) automatisch behouden blijft.
• Plug-and-play: Elke OTel-compatibele backend kan de data in near real-time innemen zonder custom polling-logica.

De exportervaring bouwen

Laat gebruikers een OTLP-endpoint configureren

Begin met het toestaan dat gebruikers hun eigen OTLP-endpoint en eventuele authenticatie-headers (zoals een ingestion key) opgeven. Laat gebruikers daarnaast expliciet toggelen welke signalen ze willen exporteren om datavolume en kosten te beheersen.

Standaardiseer de architectuur

U heeft twee hoofdopties:

1. Gebruik de OpenTelemetry SDK direct in uw services om data te emitteren.
2. Draai een interne OTel Collector die de telemetrie van uw systeem verzamelt en opnieuw exporteert naar het endpoint van de gebruiker.

Het aanhouden van standaard OpenTelemetry omgevingsvariabelen (zoals OTELEXPORTEROTLP_ENDPOINT) maakt de onderliggende infrastructuur betrouwbaar en eenvoudig te documenteren.

Houd semantiek consistent

Zorg voor consistente semantiek over alle signalen. De Semantic Conventions zijn uw referentie voor het consequent benoemen van attributen en schema's. Weaver (gebouwd op Semantic Conventions) helpt u om uw eigen attribuutnamen en schema's te definiëren en deze synchroon te houden met evoluerende code en infrastructuur.

Telemetrie routeren naar de gebruiker

U moet beslissen hoe granulair de routing moet zijn:

• Single endpoint: Voor de meeste gebruikers is één basis-URL ideaal. Uw exporter voegt intern de standaard OTLP-paden toe (v1/traces, v1/metrics, v1/logs).
• Per-signaal endpoints: Grote klanten willen signalen soms naar verschillende platforms sturen. OTLP ondersteunt dit native via signaal-specifieke variabelen zoals OTELEXPORTEROTLPLOGSENDPOINT.

Collectors draaien voor multi-tenancy

Wanneer u OTLP pusht, moet u beslissen hoe u Collectors inzet voor meerdere tenants.

Eén Collector per tenant

Als uw architectuur tenants al isoleert op infrastructuurniveau, kunt u een dedicated Collector-instantie per klant implementeren.

• Voordeel: Sterke logische isolatie. Problemen bij één klant beïnvloeden anderen niet.
• Nadeel: Resource-intensief bij honderden of duizenden instanties.
• Best fit: Enterprise SaaS-producten waar strikte isolatie een vereiste is.

Gedeelde Collector met statische pipelines per tenant

Alle telemetrie van uw platform stroomt naar één centrale Collector. Hierin definieert u separate pipelines per tenant. De routing connector is hier zeer geschikt om data naar het juiste externe endpoint te sturen op basis van resource-attributen zoals een tenant-ID.

• Voordeel: Eenvoudiger beheer bij beginnende of gemiddelde schaal.
• Nadeel: U moet een groeiend configuratiebestand beheren naarmate het klantenbestand groeit.

Eindoordeel: Custom polling API's vs OTLP

Voor moderne, op ontwikkelaars gerichte platforms is OTLP de juiste keuze. Gebruik custom polling API's alleen als standaardisatie geen optie is. Het unified protocol van OpenTelemetry behoudt rijke context, levert data in near real-time en is bewezen op schaal.

Samenvatting: Alles samenbrengen

Als u OTel-native export wilt implementeren, volg dan deze stappen:

1. Bepaal welke signalen u ondersteunt (bij voorkeur alle drie: logs, traces, metrics).
2. Gebruik OTLP voor de export via de OTel SDK of een Collector.
3. Stel een configuratie voor de bestemming beschikbaar, inclusief optionele auth-headers en eventueel per-signaal endpoints.
4. Geef gebruikers controle over welke signalen ze in- of uitschakelen.
5. Documenteer het contract: Geef het endpoint-formaat (gRPC/HTTP), vereiste headers en de semantiek per signaal aan.
6. Kies een Collector-topologie: Één per tenant (voor isolatie) of gedeeld (voor minder overhead).
7. Bied voorbeeldconfiguraties of snippets van omgevingsvariabelen aan voor een snelle start.

Door vanaf het begin te ontwerpen met open standaarden, vermindert u wrijving en engineering-overhead, en stelt u klanten in staat om op hun eigen voorwaarden het beste gebruik te maken van hun data.

***

Opmerking voor eindgebruikers: U hoeft niet te wachten tot uw SaaS-leverancier dit implementeert. Vraag direct om OTLP-export; het is een redelijk en steeds gebruikelijker verzoek.