CPU usage percentage Check über den Agent zeigt falsche Werte

[ppabst]

Moin, seit dem (ungefähr) letztem release von dem Agent, habe ich auf vielen Server Windows/Linux das phänomen das ich angeblich 100% CPU hätte, hab ich aber nicht.
Auf dem Dashboard steht Server CPU usage percentage 100%.
Wenn ich dann auf den Check klicke sehe ich ja den graphen und dort ist seit Stunden nicht mehr als 2 - 3 % und dann einen starken Ausschlag, auf dem System selber ist aber nichts zu sehen.

Kernel Version 4.15.0-177-generic

[nook24]

Leider kann ich das Problem nicht nachstellen, weder in einer VM noch auf Hardware. Hier mal ein Beispiel von einem Linux Server.

Die CPU Auslastung wird unter Windows und Linux auch völlig unterschiedlich abgefragt. Deswegen macht mich die Fehlerbeschreibung etwas stutzig.

Unter Windows wird die Klasse Win32_PerfFormattedData_PerfOS_Processor genutzt: https://docs.microsoft.com/de-de/windows/win32/wmisdk/wmi-tasks--performance-monitoring

Unter Linux werden die Werte aus /proc/stat ausgelesen. Die Berechnung des Prozentwertes ist von htop abgekupfert.

• Handelt es sich bei den Systemen um VMs auf dem gleichen Hypervisor?
• Tritt der Fehler wirklich unter Linux und Windows auf?

[exa-mk]

Ich kann das Phänomen auf mind. 1 Host (Proxmox Qemu-VM; Rocky Linux 9.1, Kernel 5.14.0-162.6.1.el9_1.0.1.x86_64) auch nachvollziehen.

• 10min iostat (2s interval): CPU quasi komplett idle:
  cpu_usage.txt
• openITC meldet dagegen quasi dauerhaft >80% Auslastung:
  

[kbilev]

Hi,
wir haben ein änliches Problem auf manchen Systemen. Es tritt gefühlt nur auf System auf welche eine load average von < 0,1 haben.
Wenn ich folgendes Script ausführe "https://rosettacode.org/wiki/Linux_CPU_utilization#Go" habe ich folgenden Output:

go run cpu.go
CPU usage % at 1 second intervals:

1 :  0.000
2 :  0.000
3 :  0.000
4 :  0.990
5 :  0.000
6 :  0.000
7 : 14.000
8 : 33.663
9 :  0.000
10 :  1.000
11 : 35.000
12 :  5.051
13 :  0.990
14 :  1.000
15 : 42.574
16 :  0.000
17 :  4.000
18 :  1.000
19 :  0.000
20 :  0.000
21 :  0.000
22 :  0.000
23 :  0.000
24 : 39.394
25 :  0.000
26 :  0.000
27 :  0.000
28 :  0.000
29 :  1.980
30 :  5.000
31 : 40.404
32 :  1.000
33 :  0.000
34 : 40.000
35 :  0.000
36 :  0.000
37 : 15.842
38 : 27.273
39 :  0.000
40 :  0.000
41 :  0.000
42 :  0.000
43 :  0.000
44 :  0.000
45 : 40.000
46 :  0.000
47 :  6.000
48 :  0.000
49 :  0.000

Der Service Graph in openITC zeigt jedoch konstant 40% load an.
Ich habe keinen Lösungsvorschlag, aber vieleicht hilft es, das Problem näher einzugrenzen
System: Ubuntu 20.04.4 LTS 5.4.0-121-generic
Beste Grüße

[kbilev]

Das "Problem" hat sich bei uns gelöst.
Ein unglücklicher Zufall. Wenn ein rechenintensiver Check auf schwacher VM zur gleichen Zeit ausgeführt wird wie das "Check CPU Usage", zeigt der Agent einen hohen Wert an. Normal, da zu dieser Zeit die VM höher beansprucht ist.
Dieser Wert ist aber nur eine Momentaufnahme und kann sich dann ich Graphen falsch wiederspiegeln da der Wert nur zb alle 5 Minuten abgefragt wird.
1 Sekunde 100%, 4 Minuten 59 0%, der Graph zeigt jedoch ständig 100% an.
Einfache Lösung: Den/die Custom Checks mit ungeradem Intervall ausführen, damit dieser sich nicht mit dem Check CPU Usage überschneidet
Beste Grüße

[nook24]

Danke für die Info, sehr schöne Analyse. In der Tat vergleicht der Agent zwei unterschiedliche Messungen, welche in einem Abstand von einer Sekunde getätigt werden.

https://github.com/it-novum/openitcockpit-agent-go/blob/728a89e6f0890b5c3b26d24f1ee63eab5003bbe3/checks/cpu_posix.go#L55C2-L67

[nook24]

Ich konnte das Problem auf einem System nachvollziehen. Das Problem wird dadurch verursacht, das der Agent alle Checks mehr oder weniger gleichzeitig ausführt und damit auch seine eigene CPU Auslastung misst und darstellt.

In meinem Fall sah der Graph für die CPU Auslastung wie folgt aus:

Der Graph zeigt immer Werte von 60 - 100%, obwohl die CPU auf dem System eigentlich nicht ausgelastet ist.
In diesem Fall kam die Auslastung daher, das der Agent die CPU-Auslastung gleichzeitig mit den Docker Checks ausgeführt hat.

Um dies zu vermeiden, habe ich als Workaround in den CPU Check eine Verzögerung eingebaut, somit ermittelt der Agent plausible Werte von 8 - 10% CPU Auslastung. (ganz rechts im Graph schon leicht zu sehen.)

openitcockpit-agent-go/checks/cpu_posix.go

Lines 57 to 67 in 5b7a505

	if c.checkInterval > 5 {
	// The Agent executes all checks in parallel, so we need to sleep here to avoid high CPU usage / wrong measurements
	// This is a workaround until we have a better solution
	log.Debugln("CPU check will sleep for 3 seconds to avoid high CPU usage")
	c.SleepWithContext(ctx, 3*time.Second)
	log.Debugln("CPU check is awake now")
	} else {
	log.Infoln("checkinterval is less than 5 seconds, which could lead to high CPU usage values.")
	}

Die Lösung ist nicht Optimal, mal schauen wie man das noch optimieren kann.