Ungewöhnlicher Traffic in AppService sichtbar in Metric über Data In (oder DataOut) Aggregation "Sum" im exakten Abstand von 20min

Die AppServiceHTTPLogs erfassen nur eingehende HTTP-Anfragen, aber die Bandbreitenmetrik umfasst den gesamten Netzwerkverkehr, einschließlich:

• Plattform > App-Kommunikation
• App > externe Abhängigkeiten
• Telemetrieexport (Application Insights)
• Interner Infrastrukturverkehr

Diese Diskrepanz ist normal, da Metriken auf Infrastrukturebene und nicht nur auf der HTTP-Ebene gesammelt werden.

App Insights als Hauptursache validieren: KQL ausführen (Log Analytics)

union requests, dependencies, traces
| summarize TotalData = sum(itemCount) by bin(timestamp, 20m)
Show more lines
Then compare timeline with spikes

Outbound-Traffic-Quellen überprüfen** **Aktivieren:

App Service > Diagnose & Lösen > Netzwerk / SNAT / Ausgehende Verbindungen

Vergleichen Sie funktionierende und nicht funktionierende Apps** **Überprüfen Sie Unterschiede in:

• App Insights-Konfiguration
• Diagnostikeinstellungen
• Hintergrundaufgaben / Planer
• Externe API-Aufrufe

Kostenanalyse Drilldown** **In Kostenmanagement:

• Filter:
  • Zähler = Bandbreite
  • Gruppieren nach:
    • Ressource
    • Region

Bestätigen Sie, ob der Traffic mit diesen App-Diensten übereinstimmt

Hallo,
Danke für deine Rückmeldung.

Das ist mir bewusst, dass der HTTP Traffic != Metric Traffic ist.

Hier der Vergleich zwischen den Metric Peaks und Log Analytics, für mich stimmt das nicht überein, dass das Application Insights die Peaks verursacht

• App Insights-Konfiguration
  • Sind alle AppServices (funktionierende und nicht funktionierende) sind gleich
• Diagnostikeinstellungen
  • Sind die selben, ein Eintrag "W3C", welche in ein "Log Analytics Arbeitsbereich" die HTTP Logs schreibt.
    
• Hintergrundaufgaben / Planer
  • Wir haben die selben Peaks auf den App Services, welche KEINE WebJobs, Backups sind die standart 1h Backups bei allen App Services.
• Externe API-Aufrufe
  • Haben wir im Code (Google JS API) wird jedoch nur funktional von Benutzer verwendet und Clientseitig.

DIe Kosten für "Bandbreite" decken sich etwa mit dem im Metric angezeigten Traffic Volumen (1.8 TB) - April 2026:

Die Frage bleibt für uns leider immer noch offen, wie wir auf 1.8 TB Traffic kommen, denn ohne diese unerklärlichen Peaks wäre der Traffic nicht so hoch!

Danke für die weitere Hilfe,

Gruss Patrick

Hallo,

Gibt es schon nähere Erkenntnisse oder eine Erklärung dazu, welche mich weiterbringt?
Es ist leider extrem frustierend, Kosten durch Traffic zu haben, welcher aus meiner Sicht nicht erklärbar ist.

Danke für die Hilfe,

Patrick

Vielen Dank für deine Geduld und die detaillierten Rückmeldungen. Ich verstehe deine Frustration – 1,8 TB Traffic, der weder in den HTTP-Logs noch in Application Insights auftaucht, aber echte Kosten verursacht, muss unbedingt aufgeklärt werden.

Da wir folgende Ursachen bereits ausgeschlossen haben:

• Application Insights (Timeline passt nicht zu den Peaks)
• WebJobs (gleiche Peaks auf App Services ohne WebJobs)
• Backups (Standard 1h, identisch auf allen App Services)
• Externe API-Aufrufe (clientseitig)

Hier sind gezielte nächste Schritte, um die tatsächliche Quelle des Traffics zu identifizieren:

1. Diagnostic Settings vorübergehend deaktivieren (Test)

Du hast eine Diagnostic Setting (W3C → Log Analytics Workspace) aktiv. Der Export von Logs an Log Analytics erzeugt ausgehenden Netzwerkverkehr, der in den DataOut-Metriken erfasst wird, aber nicht in den HTTP-Logs erscheint.

Test: Deaktiviere die Diagnostic Setting auf einem App Service für 2–4 Stunden und vergleiche die DataIn/DataOut-Metriken vorher/nachher. Falls die Peaks verschwinden, ist der Log-Export die Ursache.

2. Netzwerk-Trace über App Service Diagnostics (AppLens)

Dies ist der definitivste Weg, um die Traffic-Quelle zu identifizieren:

• Gehe zu App Service → Diagnose and solve problems
• Suche nach"Network Trace" oder"Collect Network Trace"
• Starte einen Trace, der einen Peak-Zeitpunkt (z. B. :19, :39, :59) abdeckt
• Analysiere die PCAP-Datei, um die Remote-Endpunkte und Datenmengen zu sehen

3. Ausgehende Verbindungen prüfen (Kudu Console)

Öffne die Kudu-Konsole (https://<app-name>.scm.azurewebsites.net) und führe während eines Peaks folgenden Befehl aus:

netstat -ano

Oder in der PowerShell-Konsole:

Get-NetTCPConnection | Where-Object {$_.State -eq 'Established'} |
 Select-Object LocalPort, RemoteAddress, RemotePort, OwningProcess |
 Sort-Object RemoteAddress

Dies zeigt dir die aktiven Verbindungen zum Peak-Zeitpunkt und gibt Aufschluss darüber, wohin der Traffic fließt.

4. AppServicePlatformLogs prüfen

Falls noch nicht aktiviert, aktiviere AppServicePlatformLogs in den Diagnostic Settings. Diese erfassen plattformseitige Aktivitäten, die nicht in den HTTP-Logs erscheinen:

AppServicePlatformLogs
| where TimeGenerated >= ago(4h)
| summarize Count=count(), TotalSize=sum(estimate_data_size(*)) by bin(TimeGenerated, 20m), Level, ContainerName
| order by TimeGenerated desc

5. Application Insights Telemetrie-Volumen genauer prüfen

Auch wenn die AI-Timeline nicht perfekt mit den Peaks übereinstimmt, prüfe bitte das tatsächliche Telemetrie-Exportvolumen im Log Analytics Workspace:

union withsource=TableName *
| where _ResourceId contains "<app-service-name>"
| where TimeGenerated >= ago(24h)
| summarize DataVolumeMB = round(sum(estimate_data_size(*)) / 1024.0 / 1024.0, 2) by bin(TimeGenerated, 20m), TableName
| order by TimeGenerated desc
| render timechart

Wenn die Peaks in dieser Abfrage mit den Metric-Peaks übereinstimmen, hast du den Verursacher gefunden.

6. „Always On" und Health Check Konfiguration prüfen

• Always On sendet alle 5 Minuten einen GET-Request an die App-Root – das erzeugt zwar Traffic, aber in der Regel nur wenige KB.
• Health Check: Falls konfiguriert, sendet der Load Balancer periodische Anfragen an den Health-Check-Pfad. Prüfe unter Configuration → Health check, ob dies aktiv ist.

7. Azure Support-Ticket erstellen (Empfehlung)

Da die bisherigen Schritte die Ursache nicht identifiziert haben und es sich um reale Kosten (1,8 TB/Monat) handelt, empfehle ich, ein Azure Support-Ticket zu erstellen:

• Service: App Service (Web Apps)
• Problem type: Performance and Availability → Unexpected Traffic or Bandwidth Usage
• Das Product-Team kann serverseitig (auf Plattformebene) Netzwerk-Traces und Traffic-Analysen durchführen, die von der Kundenseite nicht zugänglich sind.