Zabbix 4.0.0 LTS
KVM/Qemu (qcow2) appliance from 2018-10-17

Client/target machines
CentOS Linux release 7.5.1804

cat /proc/cpuinfo (last "core"/thread).
-------------------------------------------------------------------------------------------
processor : 47
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
stepping : 2
microcode : 0x3d
cpu MHz : 2899.940
cache size : 30720 KB
physical id : 1
siblings : 24
core id : 13
cpu cores : 12
apicid : 59
initial apicid : 59
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
bogomips : 5004.49
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
-------------------------------------------------------------------------------------------
processor : 63
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz
stepping : 1
microcode : 0xb00002e
cpu MHz : 1200.265
cache size : 40960 KB
physical id : 1
siblings : 32
core id : 15
cpu cores : 16
apicid : 63
initial apicid : 63
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 4205.38
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

Duplicates ZBXNEXT-391?

It does not as far as I can see. But maybe somebody more knowledgeable could provide more certain answer.

Edit: on second look it could be connected somehow, but most certainly not the same, since the user load was somewhere between 30% and 50% which would, in the worst case, resulted in ~20% difference and the difference was around 50% and more or less at the level of real user load read from the server as seen on the screenshot.

Duplicates ZBXNEXT-391?

It seems that this could be it:
https://support.zabbix.com/browse/ZBX-10710

Just for the reccord. It seems that it is more related to kernel version than CPU cores/threads.

• 4.17 new behavior with system.cpu.util[,guest] and system.cpu.util[,guest_nice].
• 3.10 old behavior without it.

It seems that the graphs are missing guest, guest_nice times. It seems you are using virtualization, so that might account for the dips in cpu utilization graphs. Could you try adding them and check?

As I wrote earlier. It is exactly that. Thank you. You can probably close this issue if you do not wish to change templates to prevent this kind of misunderstanding.

Yes, the templates must be updated.

Fixed in:

• pre-4.0.2rc1 r87003
• pre-4.2.0alpha1 r87007

(1) [D] Documentation needs to be updated

• 4.0 Template changes
• 4.2 Template changes
• Zabbix Templates/Official Templates

vso we have talked to vzhuravlev and it was not clear how can it be added to official templates. It was suggested that we only change xml templates in svn for now so Zabbix Templates/Official Templates is Won't Fix

martins-v This subissue is resolved in (2). WON'T FIX.