OpenTelemetry voor hostingplatforms: traces veilig gebruiken

OpenTelemetry, signalen en backend duidelijk van elkaar scheiden

OpenTelemetry, vaak OTel genoemd, is geen monitoringportaal en slaat geen telemetrie permanent op. Het is een fabrikantonafhankelijke combinatie van specificaties, API’s, SDK’s, instrumentaties, het OpenTelemetry Protocol (OTLP) en de Collector. Applicaties genereren hiermee gegevens, verwerken en exporteren deze; het zoeken, bewaren, toekennen van rechten en alarmeren blijven taken van de gekozen backend.

De drie Signalen geven antwoord op verschillende operationele vragen. Traces ordenen de afzonderlijke stappen van een verzoek in chronologische en logische volgorde, metrics bundelen statussen tot meetreeksen en logs leggen afzonderlijke gebeurtenissen vast. Een robuuste observability-aanpak combineert deze elementen: een trace bakent een opvallend verzoek af, metrics tonen de frequentie ervan in de loop van de tijd, en bijbehorende logs leveren foutmeldingen of aanvullende details.

Voor hostingplatforms vloeit hieruit een duidelijke taakverdeling voort: OTel standaardiseert het genereren en doorgeven van telemetrie, maar vervangt geen doelsysteem. Vóór de implementatie moeten teams daarom vastleggen welke backend welke gegevens ontvangt, hoe lang deze nodig zijn en wie ze mag inzien. Pas door deze beslissingen kunnen de technische exporttrajecten en gegevensvolumes beheersbaar worden gemaakt.

Trace-context doorgeven over hostinggrenzen heen

Distributed Tracing koppelt de stappen van een logische transactie over proces- en netwerkgrenzen heen. Een Trace-context bevat onder andere een trace-ID voor het gehele proces en span-ID's voor afzonderlijke bewerkingen. Spans kunnen ouder-kindrelaties vormen; samen beschrijven ze een gerichte acyclische grafiek van het waargenomen werk.

Bij HTTP wordt deze context doorgaans doorgegeven aan W3C Trace Context, met name in de header traceparent. Een service neemt de inkomende context over en genereert voor zijn deel een bijbehorende span. Bij uitgaande aanroepen moet de service de context opnieuw doorgeven. Als dit niet gebeurt bij een controleerbare overgang, valt het verzoek in de backend uiteen in afzonderlijke traces.

Bij het afrekenen kan een reverse proxy het verzoek doorsturen naar de applicatie. Deze controleert bijvoorbeeld een cache, raadpleegt de database en roept een betalingsdienst en een e-mail-API aan. Als de overgangen worden gemonitord en de context wordt doorgegeven, kan de volgorde van deze stappen in een trace worden nagegaan. Voor wachtrij- of achtergrondtaken geldt hetzelfde principe, mits de context met het bericht wordt meegestuurd en bij de ontvanger wordt hersteld.

Een lange externe HTTP-span geeft echter alleen de waargenomen duur van deze geïnstrumenteerde bewerking weer. Het bewijst niet of DNS, het netwerk, herhalingspogingen, de tegenpartij of de belasting in het eigen systeem de oorzaak waren. Traces vormen daarom een uitgangspunt voor de diagnose; om de oorzaak vast te stellen zijn passende statistieken, logbestanden en een technische controle van de betrokken componenten nodig.

Hostingmodellen bepalen de speelruimte van OTel

Of OpenTelemetry haalbaar is, hangt in de eerste plaats af van het hostingmodel. Een minimale vereiste is controle over de configuratie van de applicatie of op zijn minst over omgevingsvariabelen. SDK’s kunnen, afhankelijk van de taalimplementatie, programmatisch en via de omgeving worden geconfigureerd; de daadwerkelijk ondersteunde omvang moet worden gecontroleerd voor de gebruikte taal en versie.

Op VPS’en, eigen servers en in containers kun je de Collector, netwerkpaden en procesomgeving meestal zelf instellen. In de officiële voorbeelden worden voor lokale OTLP-ontvangers de volgende poorten genoemd: 4317 voor gRPC en 4318 voor HTTP. Hieruit volgt geen algemene aanbeveling om dit toe te staan: de bereikbaarheid in de productieomgeving, firewallregels en authenticatie moeten zijn afgestemd op het betreffende platform.

Bij klassieke shared hosting ontbreken daarentegen vaak de rechten voor een continu draaiende collector of procesinjectie voor auto-instrumentatie. Er bestaan zero-code-oplossingen voor verschillende taalecosystemen, maar of je ze kunt gebruiken, hangt af van de looptijd, de implementatiemethode en de platformgoedkeuringen. Plan daarom niet uitgaande van de OTel-functie, maar van de toegestane configuratie- en exportmethode van de specifieke hostingomgeving.

Instrumentatie en dienstidentiteit doelgericht plannen

Het begint met een begrijpelijke Dienstidentiteit. Resources beschrijven de entiteit die telemetrie genereert, bijvoorbeeld een dienst of de uitvoeringsomgeving daarvan. Stel de hiervoor gebruikte resource-attributen op een gecontroleerde en consistente manier vast. Welke specifieke attributen automatisch beschikbaar zijn of aanvullend moeten worden geconfigureerd, hangt af van de taalimplementatie, de instrumentatie en de versie.

Controleer vervolgens de zero-code- of auto-instrumentatie van de daadwerkelijk gebruikte taalruntime en de bijbehorende versie. De OpenTelemetry-documentatie vermeldt onder andere benaderingen voor Java, JavaScript, .NET, PHP, Python en Go. Deze registreren vaak HTTP-, database- of clientbibliotheekgrenzen, maar de omvang, mate van uitwerking en ondersteunde bibliotheken verschillen per implementatie.

Automatisch gegenereerde sporen geven vooral technische overgangen weer. Voor specifieke stappen zoals „Bestelling vrijgegeven“ of „Factuur aangemaakt“ voeg je gerichte instrumentatie toe aan de code, voor zover deze stappen relevant zijn voor de diagnose. Zo wordt zichtbaar bij welke bewerking een proces mislukt, zonder elke functieaanroep te overbelasten met telemetrie.

Andere resource-attributen kunnen bijvoorbeeld informatie bevatten over de host, het proces, de container of de Kubernetes-omgeving. Welke attributen een taalimplementatie automatisch instelt en welke semantische conventies van toepassing zijn, moet afzonderlijk worden gecontroleerd voor de SDK, de instrumentatie en de versie. De waarden moeten afkomstig zijn uit gecontroleerde implementatiemetadata, zodat de identificatie van dezelfde uitvoeringsomgeving traceerbaar blijft.

Bij meerdere klantprojecten maakt naamgeving deel uit van het klant- en implementatieconcept. Telemetrie mag projecten niet per ongeluk samenvoegen of toegang via gemeenschappelijke attributen vergemakkelijken. Hoe applicatiearchitectuur, isolatie en schaalbaarheid met elkaar samenhangen, wordt ook uitgelegd in het artikel over SaaS-hosting voor meerdere klanten. Voor de telemetrie zelf geldt: verzamel klantgerelateerde identificatiegegevens alleen als dit functioneel noodzakelijk is en er is gecontroleerd of dit in overeenstemming is met de wetgeving inzake gegevensbescherming.

Collector-architecturen en veilige export

Bij directe export stuurt elke toepassing zijn OTLP-gegevens rechtstreeks naar de geselecteerde backend. Dit bespaart een extra component, maar verdeelt het doeladres, de inloggegevens en de exportconfiguratie over meerdere implementaties. Deze variant is eerder geschikt voor een kleine, duidelijk afgebakende installatie waarvan de backend veilig bereikbaar is en die geen centrale verwerking vóór de export nodig heeft.

Een lokale Collector Per host of pod ontvangt telemetrie gegevens dicht bij de applicatie. Applicaties exporteren gegevens naar een lokaal eindpunt; de collector bundelt de gegevens en kan herhalingspogingen, verwerking en doorsturing voor zijn rekening nemen. Voor Linux-hosts beschrijft de documentatie dit patroon als een mogelijkheid om applicaties aan localhost laten verzenden.

Een centrale gateway-collector bundelt daarentegen de backend-koppeling, de routing en uniforme verwerkingsrichtlijnen. Dit creëert echter een extra operationele afhankelijkheid, die moet worden beveiligd en op basis van de benodigde capaciteit moet worden gepland. In grotere omgevingen kan een lokale collector worden gecombineerd met een gateway, in plaats van alle applicaties rechtstreeks aan een centrale instantie te koppelen.

In een niet-productief voorbeeld ontvangt een receiver OTLP, verwerkt de geconfigureerde pijplijn de telemetrie en stuurt een exporter deze door naar de backend. Het OTel-overzicht beschrijft in principe ook het verrijken, transformeren en opschonen van persoonsgegevens als taken van de collector. Welke specifieke component een signaal ondersteunt en welke maturiteitsgraad deze heeft, moet echter afzonderlijk worden gecontroleerd voor de gekozen collector-distributie en versie.

De OTLP-poorten die vaak in lokale voorbeelden worden gebruikt 4317 voor gRPC en 4318 Voor HTTP geldt geen algemene goedkeuring voor gebruik in de productieve omgeving. Stel de toegankelijkheid vast via beveiligingszones, firewallregels en platformrichtlijnen. S14 beveelt veilige, geauthenticeerde verbindingen aan en een werking zonder root- of beheerdersrechten, tenzij een component aanvullende rechten nodig heeft. Aangezien S14 de mobiele ontwikkelingsvertakking main Zoals gedocumenteerd, moeten deze specificaties vóór het gebruik worden vergeleken met de documentatie van de daadwerkelijk gebruikte Collector-versie.

Sampling voor belasting en foutpatronen selecteren

Sampling bepaalt welke traces worden opgeslagen of verder verwerkt wanneer een volledige registratie te veel telemetrie oplevert. Begin met een klein, vooraf getest quotum en controleer of typische verzoeken, fouten en uitschieters in de latentie in de backend nog voldoende zichtbaar zijn. De juiste quota is geen universeel getal, maar hangt af van het verkeer, het diagnosedoel en de bewaartermijn.

Op Head Sampling De beslissing wordt aan het begin van een trace genomen. Een op ouders gebaseerde, verhoudingsgebaseerde strategie neemt daarbij de steekproefbeslissing van een bovenliggende span over en stelt een quotum vast voor nieuwe roots. Dit zorgt ervoor dat de selectie traceerbaar blijft, maar een fout die pas later wordt opgemerkt, kan niet achteraf worden opgenomen in een eerder afgewezen trace.

Tail Sampling analyseert de binnengekomen tracegegevens in de collector volgens de geconfigureerde richtlijnen. S12 toont uitsluitend de actieve ontwikkelingstak main en identificeert de processor daar als bèta voor traces en als statusgebonden. Deze status omvat verschillende beslissingsstrategieën en capaciteitsopties, waaronder limieten voor tracegroottes en interne shards. Dit zijn geen gegarandeerde eigenschappen van een bepaalde stabiele release. Voor productief gebruik moeten daarom eerst de Collector-Contrib-versie en de distributie worden vastgesteld en vervolgens moeten de versiespecifieke opties, standaardwaarden en benodigde resources worden gecontroleerd.

In het gedocumenteerde main-Alle spans van een trace moeten dezelfde collector-instantie bereiken, zodat een effectieve samplingbeslissing mogelijk is. De processor bewaart gegevens standaard in het geheugen; een daar beschreven tail_storage-De uitbreiding is experimenteel, wordt beveiligd door een feature gate en kan niet met elke sharding-configuratie worden gecombineerd. Deze gegevens dienen uitsluitend als richtlijnen voor controle. Zonder vastgestelde release kan hieruit noch een betrouwbaar routingconcept, noch een productiegoedkeuring worden afgeleid.

Gevoelige telemetrie beperken vóór de export

Telemetrie is alleen nuttig voor de bedrijfsvoering als de inhoud ervan beperkt blijft. Baggage kan vrij gekozen sleutel-waardeparen door verschillende diensten en processen heen verspreiden en beschikbaar maken voor traces, metrics of logs. Gevoelige Baggage-waarden kunnen daardoor ook onbedoeld achterliggende of externe bronnen bereiken. Controleer daarom de inhoud ervan vóór elke overdracht tussen diensten.

Op Bagage is dit bereik bijzonder belangrijk. Persoonsgegevens, sessie-ID’s, wachtwoorden of API-sleutels horen hier niet thuis. Een waarde die niet per se bij elke overgang nodig is voor de functionele toewijzing, mag niet als ‘baggage’ worden aangemaakt. De automatische doorgifte in netwerkverzoeken vergroot anders het aantal systemen dat de waarde kan verwerken.

Gegevensminimalisatie begint al bij de instrumentatie: leg alleen velden vast die nodig zijn voor een concrete diagnose. Controleer bovendien toepassings- en bibliotheekafhankelijke span-attributen, logvelden, URL's, headers en database-informatie met niet-productieve voorbeeldgegevens. Dit is een voorzichtige architectuurregel; welke van deze gegevens daadwerkelijk worden vastgelegd, hangt af van de SDK, de instrumentatie, de configuratie en de versie.

De Collector kan in principe telemetrie verwerken, aanvullen, transformeren en controleren op persoonsgegevens. Concrete filter-, attribuut- of transformatiecomponenten verschillen echter wat betreft distributie, signaalondersteuning en versierstatus. Bepaal daarom pas na controle van de beoogde release welke component welke velden moet bewerken, en beschouw een algemene beschrijving van de Collector niet als goedkeuring voor een bepaalde configuratie.

Wat betreft statistieken moet het team vooraf vaststellen welke attributen echt nodig zijn voor een specifieke operationele vraag. Individuele verzoek- of gebruikers-ID's en volledige URL's worden niet louter uit voorzorg als dimensies opgenomen. Controleer aan de hand van representatieve voorbeeldgegevens welke attribuutwaarden de instrumentatie daadwerkelijk genereert en sta alleen de route-, service- of foutklassen toe die bedoeld zijn voor gedefinieerde analyses.

Verwerkingsregels moeten van een versie worden voorzien en vóór de implementatie worden getest met representatieve, niet-productieve voorbeeldgegevens. Zo kan worden vastgesteld of diagnostisch noodzakelijke gegevens verloren gaan of dat gevoelige waarden nog steeds worden geëxporteerd. Bewaartermijnen, autorisatieconcepten, toegangslogboeken en verwijderingsconcepten maken bovendien deel uit van de architectuur van de gekozen backend en worden niet door OpenTelemetry zelf geregeld.

Collector stabiel laten draaien en fouten opsporen

Als er traces ontbreken of als een verwachte workflow in meerdere traces uiteenvalt, begin je met het opsporen van fouten bij de overgang tussen diensten. Controleer eerst of het uitgaande verzoek de context doorgeeft en of de volgende dienst deze leest. De W3C-trace-context met traceparent koppelt alleen de componenten die deze doorgifte daadwerkelijk ondersteunen en niet overschrijven.

Daarna volgt de pijplijn: ontvangt de geconfigureerde receiver gegevens, laat een processor de verwachte signalen door, en bereikt de exporter zijn bestemming? Afzonderlijke controles voorkomen dat een backend-probleem ten onrechte als een instrumentatiefout wordt beschouwd. Bedrijfsgegevens van de collector en duidelijk afgebakende testverzoeken helpen om verliezen aan een bepaalde fase toe te wijzen.

Exportfouten vereisen vervolgens een controle van DNS, bereikbaarheid, certificaten en authenticatie. S14 beveelt voor Collector-verbindingen beveiligde, geauthenticeerde kanalen aan en een werking zonder root- of beheerdersrechten, voor zover de gebruikte componenten geen extra rechten nodig hebben. De bron documenteert echter de mobiele ontwikkelingstak main; controleer deze veiligheidsinstructies daarom vóór het productieve gebruik aan de hand van de documentatie en de configuratie van de daadwerkelijk gebruikte Collector-versie.

Een andere bedrijfsindicator is Geheugendruk. Wachtrijen, herhalingspogingen en intensieve verwerking kunnen geheugen belasten wanneer een doelsysteem vertraagd reageert of uitvalt. Geheugenlimieten en beperkte wachtrijen moeten afgestemd zijn op de belasting en het gedrag bij uitval; hun effect wordt gecontroleerd voordat het systeem in productie wordt genomen. Ontbrekende limieten kunnen de collector zelf destabiliseren.

Voor de diagnose zijn daarom niet alleen applicatietraces van belang. Let ook op afgewezen of verwijderde gegevens, wachtrijen, exportfouten en de resources van de collector. Wijzigingen worden stapsgewijs doorgevoerd: eerst een pijplijn of een dienst, daarna de gevolgen voor de volledigheid en de opslagruimte controleren. Zo blijft duidelijk welke configuratiewijziging een foutpatroon heeft verbeterd of verslechterd.

Architectuurbeslissingen nemen voor platformteams

Voor een kleine, duidelijk afgebakende toepassing kan directe export naar de backend volstaan, mits de toegangsgegevens, het netwerkpad en de gegevensregels goed onder de knie zijn. Bij meerdere diensten is één lokale collector per host of een agent-gebaseerd patroon een mogelijke architectuur, maar geen algemene voorkeursregel. S10 beschrijft voor Linux een afzonderlijk draaiende collector op de host; pod-, agent- en gateway-varianten moeten worden afgewogen op basis van de implementatiepatronen en de respectieve platformvereisten.

Groeiende platforms profiteren vaak van een scheiding van taken. Lokale collectors kunnen gegevens ontvangen en bundelen; een centrale gateway-collector kan zorgen voor routing, uniforme filters en de koppeling met meerdere backends. Deze verdeling creëert echter een extra dienst, waarvan de beschikbaarheid, capaciteit en toegangsbeveiliging moeten worden gepland.

Bij veel klantprojecten is de scheiding van de telemetrie een architecturale keuze die bewust moet worden vastgelegd. Als projecten verschillende toegangsgebieden vereisen, moeten exportdoelen, backend-machtigingen en resource-labels dienovereenkomstig worden gepland en gecontroleerd. Vrij ingestelde attributen dienen daarbij ter beschrijving van telemetrie; dit artikel behandelt ze niet als vervanging voor een technisch afgedwongen toegangscontrole.

Gedistribueerde afhankelijkheden zoals cache, wachtrij en database vergroten de behoefte aan diagnose, maar vormen geen reden voor een algemene, volledige registratie. Juist bij een Redis-cluster kunnen afzonderlijke diensten en achtergrondprocessen verschillende delen van een proces zien. Het artikel over Redis Cluster-sharding voor grote hostingplatforms bepaalt de architectuur van een dergelijke cachelaag; voor telemetrie blijft het van cruciaal belang om contextgrenzen en gegevensvolume bewust te sturen.

Het besluit houdt daarom in dat Onafhankelijkheid van het backend met daadwerkelijke operationele kosten. Een collector vergemakkelijkt het wisselen tussen of de parallelle bevoorrading van doelen, maar vervangt noch de capaciteitsplanning, noch de foutafhandeling. Platformteams moeten vastleggen welke gegevens elk doel ontvangt, wie er toegang krijgt en welke storingen bij het exporteren de applicaties niet mogen beïnvloeden.

Een stapsgewijze uitrol begint met één dienst en een klein aantal diagnostisch belangrijke overgangen. Vervolgens worden contextcontinuïteit, filterregels, exportstabiliteit en opslaggedrag getest onder representatieve belasting. Pas wanneer aan deze criteria op aantoonbare wijze is voldaan, volgen andere talen, clients of backends. Dit beperkt het risico en voorkomt dat er een grote pijplijn ontstaat zonder duidelijke verantwoordelijkheid.