Het juiste signaal kiezen
OpenTelemetry onderscheidt onder meer metriek, logs en traces. Deze vullen elkaar aan zonder volledige dekking te garanderen. Leg meetperiode, instrumentatie en uitsluitingen vast; een gemiddelde kan trage verzoeken verbergen.
| Vraag | Bruikbaar signaal | Beperking |
|---|---|---|
| Hoeveel verzoeken mislukken? | Geaggregeerde metriek | Definieer fouten, bereik en periode. |
| Waar gaat tijd verloren? | Trace en stapduren | Steekproeven en niet-gemeten afhankelijkheden. |
| Wat gebeurde er? | Gestructureerd log | Geen geheimen of overmatige gegevens. |
| Werkt het traject? | Functionele probe | Eén scenario dekt niet elk gebruik. |
Diagnose bruikbaar maken
- Meet verkeer, fouten en duurverdelingen per genormaliseerde handeling. Vermijd gebruikersidentificaties en variabele URL’s als metrieklabels.
- Koppel gebeurtenissen aan correlatiecode en serviceversie. Controleer contextoverdracht en steekproevenbeleid voordat u ontbrekende traces onderzoekt.
- Geef elke melding een impact, eigenaar en eerste actie. Gebruik aparte testaccounts en vermijd onomkeerbare handelingen in probes.
Gegevens en uitkomsten controleren
Houd wachtwoorden, tokens en gevoelige inhoud uit logs; beperk toegang en bewaartermijn. Een geslaagd HTTP-antwoord kan een fout bedrijfsresultaat bevatten. Test ook verwachte regels en rechten in een beheerste omgeving.
Primaire bronnen
Telemetrie koppelen aan een gebruikerstaak
Metingen, logboeken en traceringen beantwoorden verschillende vragen. Een hoge uptime kan een mislukte checkout- of aanmeldingsprocedure maskeren. Definieer het resultaat dat gebruikers verwachten en instrumenteer vervolgens de aanroepen die dit resultaat leveren.
- Kies een indicator voor succes, latentie en zichtbare fouten in de gebruikersprocedure.
- Propretiseer correlatie tussen services en beperk tegelijkertijd gevoelige gegevens in traceringen.
- Oefen een afhankelijkheidsfout om te zien of waarschuwingen leiden tot actie en een begrijpelijke, verslechterde modus.
Primaire bron: OpenTelemetry — Observability primer. Verwante methode: lees de praktische gids.
Verzamelstoring: logs en ontbrekende events reconciliëren
Scheid geproduceerde, ontvangen en bruikbare events; stilte bewijst geen afwezigheid van incidenten.
- Breng applicatie, collector en opslag met eigenaars in kaart. Maak een eindige fictieve eventreeks met stabiele identifiers zonder geheimen of klantdata. Bewaar event- en observatietijd: vertraging betekent niet automatisch verlies.
- Onderbreek in een test de bestemming en herstel die. Observeer wachtrij, pogingen, afwijzingen en herstart. Een persistente wachtrij kan verliezen beperken, maar is begrensd en opslagafhankelijk; bepaal gedrag bij een volle wachtrij. Controleer dat verzameling de dienst niet stil blokkeert.
- Reconcileer referentie en werkelijk leesbare events bij dezelfde peiltijd. Tel herhaling, vertraging en ontbreken apart; netwerkbevestiging bewijst geen uiteindelijke bruikbaarheid. Zonder betrouwbare referentie is dekking onbekend, geen nul verloren events of incidenten.
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}Verwachte beslissing
Fictief voorbeeld: E1, E2 en E3 worden verwacht, maar E1, E1 en E3 ontvangen. Drie rijen bewijzen geen volledigheid: E1 herhaalt en E2 ontbreekt op de peiltijd.
Bewijzen drie ontvangen rijen drie bewaarde events?
Nee. Twee rijen kunnen één identifier herhalen en een ontbrekend event verbergen. Vergelijk identifiers, observatievenster en ketenstappen.
Primaire bron: OpenTelemetry — Collector resiliency. Verwante methode: lees de praktische gids.
Verlaten subdomeinen: een CNAME gecontroleerd verwijderen
Koppel DNS-namen aan beheerde middelen en sluit afhankelijkheden voordat een dienst wordt vrijgegeven.
- Leg naam, CNAME-keten, leveranciersmiddel en eigenaar vast. Vergelijk DNS met de inventaris van het bevoegde account. Een HTTP-fout, NXDOMAIN of ontbrekend middel vraagt onderzoek en bewijst geen overnamemogelijkheid; bescherming verschilt per leverancier.
- Verwijder de verwijzing of gebruik een beheerd doel voordat het middel wordt vrijgegeven. Houd rekening met eerdere TTL-waarden en caches; controleer autoritatieve DNS en meerdere resolvers. Bewaar noodzakelijke eigendomsvalidaties in plaats van alle TXT-records te wissen.
- Controleer links, redirects, OAuth-callbacks, webhooks en cookiedomeinen. Is het middel al vrijgegeven, corrigeer DNS en onderzoek blootstelling via het incidentproces. Vergelijk DNS en middelen na elke verwijdering.
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Verwachte beslissing
Fictief voorbeeld: portal.example verwijst naar een verwijderd middel. Verwijder de CNAME of kies een beheerd doel; afwezigheid bewijst geen overname door derden.
Primaire bron: Microsoft — Prevent dangling DNS entries. Verwante methode: lees de praktische gids.
API-herhalingen: het hele tijdbudget tellen
Scheid oproepen, wachten en het hele gebruikerspad.
Fictief leervoorbeeld: de cijfers beschrijven CIE noch klanten.
Fictief model: vier oproepen tot 250 ms met wachttijden 100, 200 en 400 ms. Jitter, verbinding, wachtrijen en lokale controle ontbreken.
- Pogingen totaal
- 41 + 3
- Wachttijden samen (ms)
- 700100 + 200 + 400
- Modelbudget (ms)
- 17004 × 250 + 700
| Stap | Maximale oproep (ms) | Volgende wachttijd (ms) |
|---|---|---|
| Poging 1 | 250 | 100 |
| Poging 2 | 250 | 200 |
| Poging 3 | 250 | 400 |
| Poging 4 | 250 | 0 |
| Totaal | 1000 | 700 |
- Oproeptijd1.000
- Opgetelde wachttijd700
- Globale deadline (ms)1.500
Controles vóór een conclusie
- 1.000 + 700 = 1.700 ms overschrijdt de deadline van 1.500 ms.
- Geef de globale deadline door en voorkom dubbele effecten; timeout bewijst geen externe annulering.
Een herhalingsbudget proberen
n × T + W × (2^(n−1) − 1)
Verwante methode: lees de praktische gids.
Referenties: gegevens, gebruik en grenzen
Documentatie geraadpleegd op .
De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.
| Bron en doel | Gecontroleerde gegevens of maatstaf | Praktisch gebruik | Te behouden beperking |
|---|---|---|---|
| NIST · SP 800-61 Rev. 3 Prepare incident response within cybersecurity risk management. |
Revision 3 was published in April 2025 and supersedes Revision 2. It is a CSF 2.0 Community Profile. | Rehearse containment decisions, evidence preservation, communication and recovery. Compare planned actions with evidence produced during the exercise. | Reading the guide does not validate a local plan. Contacts, emergency access and dependencies need local testing. |
| Google · Core Web Vitals Distinguish loading, responsiveness and visual stability. |
Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. | Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes. | These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience. |
API: uitfasering en beëindiging
De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.
Announced retirement and continuity to verify
A Sunset field signals intent; it establishes neither actual shutdown nor guaranteed continuity until then. Prepare dependencies, data and access to move.
- Identify the announcement’s exact scope and owner.
- Keep dates and updates with receipt evidence.
- Test exit, in-flight operations and removal of obsolete access.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23