v2.34.1 — CPU-Metrik gegen Selbstkontamination des Workers

Behoben

• Spurious 100-%-CPU-Meldungen auf eigentlich idle Servern. Die Windows-CPU-Messung las % Processor Time mit nur 100 ms Fenster und einer Einzelmessung. Da MetricsCollector in Task.WhenAll parallel zu 10+ Checkern (EventLog-PowerShell, SQL-Probes, AppPool-PerfCounter, HTTP-Probes) läuft und der Worker beim Start zusätzlich JIT/DI-Last erzeugt, landete das Sample fast immer in einem Burst — der Worker mass sich selbst. Die Fehldiagnose erklärt, warum "auf dem Server selbst" niemals 100 % zu sehen waren.

Neu

• Mehrfachabtastung mit Median: Default 3 Samples über 900 ms Fenster statt eines 100-ms-Snapshots. Eine einzelne Burst-Spitze gewinnt nicht mehr.
• Eigenanteil subtrahieren: Process.TotalProcessorTime vor/nach dem Fenster → 100 × self_ms / wall_ms / coreCount wird vom System-Median abgezogen. Clamp [0, 100].
• Prozess-Priorität BelowNormal: SimpleAdminWorkerHost.RunAsync setzt den Worker-Prozess beim Start auf ProcessPriorityClass.BelowNormal. Der Worker darf die echten Workloads nicht verdrängen.
• Konfigurierbar über appsettings.json: Metrics:Cpu:WindowMs (Default 900, Range 200..10 000), Metrics:Cpu:Samples (Default 3, Range 2..20), Metrics:Cpu:SubtractSelf (Default true).
• Debug-Log CPU usage: X% (system median Y%, self Z% over N ms, samples [...]) macht die Herkunft des Endwerts nachvollziehbar.

Intern

• 16 neue Unit-Tests für Median, Clamp, Self-Subtract und Konfigurationsbindung.
• Linux (/proc/stat) und macOS hatten den sauberen Delta-Pfad schon vorher, bleiben unverändert.
• Alle sechs Pakete im Lockstep auf 2.34.1.

Empfehlung

Falls weiterhin auffällig hohe CPU-Werte auftauchen, lassen sich die Defaults ohne Neu-Build nachjustieren — ein Fenster von 1 500 ms mit 5 Samples glättet Server mit sehr vielen gleichzeitigen Checkern noch stärker:

{
  "Metrics": {
    "Cpu": { "WindowMs": 1500, "Samples": 5, "SubtractSelf": true }
  }
}

🤖 Generated with Claude Code