Logging & Telemetrie

Wie die DataBridge Logs erzeugt, welche Telemetrie sie sendet und wie Sampling die Kosten steuert.

Die DataBridge steuert ihr Telemetrie-Volumen über zwei voneinander unabhängige Mechanismen:

Gepuffertes Logging — Log-Einträge werden pro Funktionsausführung gesammelt und erst am Ende des Laufs, abhängig vom Ergebnis, selektiv gesendet.
Sampling von Abhängigkeiten — ausgehende Aufrufe an Quell- und Zielsysteme werden nur anteilig gesendet, sofern sie erfolgreich und schnell waren.

Der zweite Mechanismus ist der eigentliche Kostenhebel: In einer Volumenanalyse über 90 Tage entfielen rund 78 % des gesamten Datenvolumens auf Abhängigkeiten und nur ein Bruchteil auf Log-Einträge.

Seite	Inhalt
Metriken	Custom Metrics — die einzige nicht gesampelte Mengenangabe
Performance & Laufzeiten	KQL-Abfragen für Laufzeiten, Fehler, Abhängigkeiten und Datenvolumen

Gepuffertes Logging — drei Lauf-Ergebnisse

Ergebnis	Kriterium	Gesendete Log-Level
Normaler Lauf	Keine Fehler, keine Warnungen	Nur Warning + Error + ~20 % der Information-Einträge (konfigurierbar)
Lauf mit Warnungen	Mindestens eine Warning, kein Fehler	Alle Information + Warning + Error
Fehlerlauf	Mindestens ein unbehandelter Fehler	Alle Debug + Information + Warning + Error

Der Anteil der Information-Einträge im Normalbetrieb wird über TELEMETRY_INFO_SAMPLE_RATE gesteuert (Standard: 20 = 20 %). Die Stichprobe wird pro Eintrag gezogen — es entstehen also vereinzelte Traces aus allen Läufen, keine vollständigen Ketten. Lückenlose Ketten gibt es nur bei Warning- und Fehler-Läufen.

Trace-Level erreicht Application Insights nie

`LogTrace` ist ausschließlich live sichtbar

Log-Einträge auf Level Trace werden niemals an Application Insights gesendet — auch nicht bei Fehler-Läufen. Der Telemetriepfad ist auf Debug und höher begrenzt.

Sichtbar sind sie nur live: lokal in der Konsole bzw. im Container-Log, in Azure im Log Stream der Function App (oder per az webapp log tail).

Sampling von Abhängigkeiten

Ausgehende Aufrufe an Quell- und Zielsysteme (D365 OData, SQL, Table Storage, Service Bus) werden von Application Insights automatisch als Dependencies erfasst. Ohne Filterung verursachen sie bei kurzem Polling-Intervall ein Vielfaches aller Log-Einträge zusammen.

Aufruf	Wird gesendet
Fehlgeschlagen	Immer vollständig
Langsam (≥ `TELEMETRY_DEPENDENCY_SLOW_MS`)	Immer vollständig
Erfolgreich und schnell	Nur zum Anteil `TELEMETRY_DEPENDENCY_SAMPLE_RATE` (Standard 10 %)

Die Entscheidung fällt pro Aufruf

Anders als beim Logging wird hier pro Aufruf entschieden, und zwar in dem Moment, in dem der Aufruf endet — also bevor bekannt ist, ob die Funktionsausführung insgesamt erfolgreich war.

Praktische Folge: Ein fehlgeschlagener Lauf enthält garantiert den fehlgeschlagenen Aufruf, aber nicht zwangsläufig die erfolgreichen Aufrufe davor. Wird der vollständige Verlauf für eine Analyse gebraucht, ist vorübergehend TELEMETRY_CONTROL=TRACE_ALL zu setzen.

Steuerung über `TELEMETRY_CONTROL`

Die Einstellung wirkt auf beide Mechanismen — Traces und Abhängigkeiten:

Wert	Wirkung
`TRACE_SAMPLE` (Standard)	Selektives Sampling wie oben beschrieben
`TRACE_ALL`	Sendet alles, deaktiviert jedes Sampling (für aktive Fehlersuche)
`TRACE_NONE`	Unterdrückt Traces und Abhängigkeiten vollständig

Eine leere Variable entspricht TRACE_SAMPLE. Details zu allen Telemetrie-Einstellungen stehen unter Umgebungsvariablen.

`TRACE_ALL` nicht dauerhaft setzen

TRACE_ALL deaktiviert sämtliches Sampling und kann das Datenvolumen um ein Vielfaches erhöhen — bis hin zum Erreichen der Tagesobergrenze (Daily Cap), ab der gar keine Telemetrie mehr ankommt. Nur gezielt für die Dauer einer Analyse aktivieren.

Auswirkung auf bestehende Auswertungen

Bestehende Alerts und Dashboards prüfen

Verworfene Abhängigkeiten werden vollständig entfernt und nicht über einen Hochrechnungsfaktor (itemCount) kompensiert.

Auswertungen über dependencies / AppDependencies, die auf absoluten Zählungen oder Durchschnittslaufzeiten beruhen, liefern zu niedrige Werte.

Besonders kritisch sind Fehlerquoten der Form countif(success == false) / count(): Da fehlgeschlagene Aufrufe vollständig erhalten bleiben, erfolgreiche aber gesampelt werden, ist das Ergebnis deutlich überhöht. Solche Abfragen und darauf basierende Alerts sind zu entfernen oder auf die Tabelle requests umzustellen, die keinem Sampling unterliegt.

Nicht betroffen sind:

Fehleranzahlen und Fehlerursachen — fehlgeschlagene Aufrufe werden nie verworfen
Auswertungen langsamer Aufrufe — ab dem Schwellwert immer vollständig
Requests, Exceptions, Traces und Custom Metrics — unverändert

Wichtige Log-Felder in Application Insights

Feld	Beschreibung
`operation_Id`	Korrelations-ID — verknüpft alle Einträge einer einzigen Funktionsausführung
`operation_ParentId`	Span-ID des Requests — sorgt für die korrekte Einordnung in der End-to-End-Transaktionsansicht
`operation_Name`	Name der ausgeführten Function (z. B. `GetChanges`, `ProcessStandardQueueItems`)
`timestamp`	Zeitpunkt des ursprünglichen Log-Aufrufs, nicht des Sendens am Ende der Ausführung
`message`	Log-Text
`severityLevel`	0 = Verbose, 1 = Information, 2 = Warning, 3 = Error, 4 = Critical
`customDimensions.Category`	.NET-Logger-Kategorie
`customDimensions.Exception`	Vollständiger Stack Trace (nur bei Exceptions)

Automatisch erfasste Telemetrie

Neben den eigenen Log-Einträgen erfasst Application Insights selbstständig:

Requests — je Funktionsausführung, mit Laufzeit und Erfolgskennzeichen
Exceptions — jede aufgetretene Ausnahme mit Stack Trace
Dependencies — jeder ausgehende Aufruf (unterliegt dem Sampling, siehe oben)

Auswertung im Azure Portal

Schnelle Übersicht — Performance Blade

Application Insights → Untersuchen → Leistung

Zeigt alle Funktionsausführungen mit Durchschnittslaufzeit und P50/P95/P99-Perzentilen. Ein hoher P95-Wert deutet auf gelegentliche Verzögerungen hin (langsames Zielsystem, Queue-Stau).

Fehlerdiagnose — Failures Blade

Application Insights → Untersuchen → Fehler

Fehlgeschlagene Aufrufe, gruppiert nach Fehlertyp, mit direktem Zugriff auf Stack Traces.

Einzelne Ausführung verfolgen — Transaction Search

Application Insights → Untersuchen → Transaktionssuche

Filter nach operation_Id, um alle Einträge einer einzigen Ausführung zu sehen.

Tipps für die Fehlersuche

operation_Id finden: Im Failures Blade auf einen fehlgeschlagenen Request klicken → End-to-End Transaction Details → operation_Id ist in der URL bzw. in den Details sichtbar.
Komplette Traces aktivieren: TELEMETRY_CONTROL = TRACE_ALL setzen, den problematischen Job über ExecuteJob manuell auslösen, anschließend zurücksetzen.
Zwischen Funktionen korrelieren: Schlägt eine der Process…QueueItems-Funktionen fehl, ist die operation_Id der ursprünglichen GetChanges-Ausführung in der Nachricht gespeichert — so lässt sich der vollständige Pfad eines Datensatzes nachvollziehen. Beachten Sie dabei die Einschränkung beim Dependency-Sampling (siehe oben).

Metriken

Custom Metrics der DataBridge — vorab aggregiert und ohne Sampling.

Performance & Laufzeiten

KQL-Abfragen für Laufzeiten, Fehlerquoten, Abhängigkeiten und Datenvolumen.