Signal passend zur Frage wählen
OpenTelemetry unterscheidet unter anderem Metriken, Protokolle und Traces. Sie ergänzen sich, garantieren aber keine vollständige Sicht. Messzeitraum, Instrumentierung und Ausnahmen dokumentieren; Mittelwerte können langsame Anfragen verdecken.
| Frage | Hilfreiches Signal | Grenze |
|---|---|---|
| Wie viele Anfragen scheitern? | Aggregierte Metriken | Fehler, Umfang und Zeitraum definieren. |
| Wo vergeht die Zeit? | Trace und Schrittdauern | Stichproben und unbeobachtete Abhängigkeiten. |
| Was ist passiert? | Strukturiertes Protokoll | Keine Geheimnisse oder unnötigen Daten. |
| Funktioniert der Ablauf? | Funktionale Sonde | Ein Szenario deckt nicht alle Nutzungen ab. |
Diagnosen handlungsfähig machen
- Durchsatz, Fehler und Laufzeitverteilung je normalisiertem Vorgang messen. Nutzerkennungen und variable URLs nicht als Metriklabels verwenden.
- Ereignisse mit Korrelationskennung und Dienstversion verbinden. Kontextweitergabe und Stichprobenauswahl prüfen, bevor fehlende Traces untersucht werden.
- Jeder Warnung Auswirkung, Zuständigkeit und erste Maßnahme zuordnen. Sonden mit eigenen Konten betreiben und irreversible Aktionen vermeiden.
Daten schützen und Ergebnisse prüfen
Passwörter, Token und sensible Inhalte aus Protokollen fernhalten; Zugriffe und Aufbewahrung begrenzen. Ein erfolgreicher HTTP-Status kann ein fachlich falsches Ergebnis enthalten. Erwartete Regeln und Berechtigungen ebenfalls kontrolliert testen.
Primärquellen
Telemetriedaten mit Benutzeraufgaben verknüpfen
Metriken, Protokolle und Traces beantworten unterschiedliche Fragen. Hohe Verfügbarkeit kann einen fehlerhaften Checkout- oder Anmeldevorgang verschleiern. Definieren Sie das von Benutzern erwartete Ergebnis und instrumentieren Sie die entsprechenden Aufrufe.
- Wählen Sie einen Indikator für Erfolg, Latenz und für Benutzer sichtbare Fehler.
- Korrelationen zwischen Diensten verbreiten und gleichzeitig sensible Daten in Traces begrenzen.
- Einen Abhängigkeitsfehler simulieren, um zu prüfen, ob Warnmeldungen zu Maßnahmen und einem nachvollziehbaren eingeschränkten Modus führen.
Primärquelle: OpenTelemetry — Observability primer. Verwandte Methode: den praktischen Leitfaden lesen.
Erfassungsausfall: Logs und fehlende Ereignisse abgleichen
Erzeugte, empfangene und nutzbare Ereignisse trennen, statt Stille als Vorfallsfreiheit zu deuten.
- Erfasse Anwendung, Collector und Speicher mit Verantwortlichen. Bereite eine endliche fiktive Ereignisfolge mit stabilen IDs ohne Geheimnisse oder Kundendaten vor. Behalte Ereignis- und Beobachtungszeit: Verzögerung bedeutet nicht automatisch Verlust.
- Unterbrich im Test das Ziel und stelle es wieder her. Beobachte Warteschlange, Wiederholungen, Ablehnungen und Neustart. Persistente Queues können Verluste begrenzen, bleiben aber begrenzt und speicherabhängig; definiere Verhalten bei voller Queue. Prüfe, dass Erfassung den Dienst nicht still blockiert.
- Gleiche Referenz und tatsächlich lesbare Ereignisse am selben Stichtag ab. Zähle Wiederholungen, Verspätungen und Lücken getrennt; Netzbestätigung beweist keine endgültige Nutzbarkeit. Ohne verlässliche Referenz ist Abdeckung unbekannt statt null Verluste oder null Vorfälle.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"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"
}Erwartete Entscheidung
Fiktives Beispiel: Erwartet sind E1, E2 und E3, empfangen werden E1, E1 und E3. Drei Zeilen beweisen keine Vollständigkeit: E1 wiederholt sich, E2 fehlt am Stichtag.
Beweisen drei empfangene Zeilen drei gespeicherte Ereignisse?
Nein. Zwei Zeilen können dieselbe ID wiederholen und eine Lücke verdecken. Vergleiche IDs, Beobachtungsfenster und Kettenstufen.
Primärquelle: OpenTelemetry — Collector resiliency. Verwandte Methode: den praktischen Leitfaden lesen.
Verwaiste Subdomains: CNAME-Verweise kontrolliert entfernen
DNS-Namen mit kontrollierten Ressourcen verknüpfen und Abhängigkeiten vor der Freigabe auflösen.
- Erfasse Namen, CNAME-Kette, Anbieterressource und Verantwortliche. Gleiche DNS mit dem Inventar des berechtigten Kontos ab. HTTP-Fehler, NXDOMAIN oder fehlende Ressourcen verlangen Prüfung, beweisen aber keine Übernahmemöglichkeit. Schutzmechanismen unterscheiden sich je Anbieter.
- Entferne den Verweis oder leite ihn auf ein kontrolliertes Ziel, bevor die Ressource freigegeben wird. Berücksichtige frühere TTLs und Caches; prüfe autoritatives DNS und mehrere Resolver. Behalte noch erforderliche Eigentumsnachweise statt alle TXT-Einträge zu löschen.
- Prüfe Links, Weiterleitungen, OAuth-Rückrufe, Webhooks und Cookie-Domains. Ist die Ressource bereits freigegeben, korrigiere DNS und untersuche mögliche Exposition im Vorfallprozess. Gleiche nach jeder Löschung DNS und Ressourcen ab.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Erwartete Entscheidung
Fiktives Beispiel: portal.example verweist auf eine gelöschte Ressource. Entferne den CNAME oder wähle ein kontrolliertes Ziel; die fehlende Ressource allein beweist keine Übernahme durch Dritte.
Primärquelle: Microsoft — Prevent dangling DNS entries. Verwandte Methode: den praktischen Leitfaden lesen.
API-Wiederholungen: das gesamte Zeitbudget zählen
Aufrufdauer, Warten und gesamten Ablauf trennen.
Fiktiver Lehrfall: Die Zahlen beschreiben weder CIE noch Kunden.
Fiktives Modell: vier Aufrufe bis je 250 ms und Wartezeiten 100, 200, 400 ms. Jitter, Verbindung, Warteschlangen und lokale Prüfung fehlen.
- Versuche insgesamt
- 41 + 3
- Wartezeiten insgesamt (ms)
- 700100 + 200 + 400
- Modellbudget (ms)
- 17004 × 250 + 700
| Schritt | Maximaler Aufruf (ms) | Nächste Wartezeit (ms) |
|---|---|---|
| Versuch 1 | 250 | 100 |
| Versuch 2 | 250 | 200 |
| Versuch 3 | 250 | 400 |
| Versuch 4 | 250 | 0 |
| Gesamt | 1000 | 700 |
- Aufrufzeit1.000
- Gesamte Wartezeit700
- Gesamtfrist (ms)1.500
Prüfungen vor der Einordnung
- 1.000 + 700 = 1.700 ms überschreiten die Frist von 1.500 ms.
- Gesamtfrist weitergeben und doppelte Wirkung ausschließen; Timeout beweist keinen entfernten Abbruch.
Ein Wiederholungsbudget ausprobieren
n × T + W × (2^(n−1) − 1)
Verwandte Methode: den praktischen Leitfaden lesen.
Referenzen: Daten, Nutzung und Grenzen
Dokumentation geprüft am .
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
| Quelle und Zweck | Geprüfte Daten oder Richtwerte | Praktische Nutzung | Zu beachtende Grenze |
|---|---|---|---|
| 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-Abkündigung und Stilllegung
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
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