1st of all - nice work(!!!), Martin, for HWiNFO and nice work, Ganesh, for the JSON server!
To state the stats of where I am, what I experience and where I want to go:
I'm running a fully watercooled rig w/ W10 Pro (1903) & the latest HWiNFO (incl. Rainmeter/RTSS) - all fine/stable.
My monitoring server, where I wish to 'trap' measurement values is a Zabbix 4 LTS (on deb stretch).
This is all pers./private fun - I also deal w/ a Zabbix SRV on a medium 4c RHEL w/ a generous Maria DB piggy backed (conc. comm > 400/s) in an enterprise environment, handling nearly 13k items and avg 160 processes/s - I know a tiny bit about ZBX - but that's another 'business' ;-)
Noticing that the generic ZBX template for Win monitoring (agentd/poller) is not precise about the CPU load vs the number of cores, but HWiNFO delivering clean and consistent details AND looking into eliminating the poller aspect (the ZBX agentd runs a high queue trying to reach a client host that is naturally turned off when not in use), I was/am looking into creating the measurement values at the point of origin and e.g. using the zabbix_sender.exe to push them into a ZBX Trapper on the server (zabbix_sender also uses JSON internally and is capable of bulk/blob btw).
That is how I came about to experiment w/ Ganesh's Remote Sensor Monitor...
Got it fired up (port def opt is a bit missleading but easily figured out ;-) ) and had JSON data available on the local net via HTTP.
On ZBX I the created a (parent) item using http_agent to grab the JSON as a string and take it from there w/ a child item - starting w/ the CPU load - SWEET, I got a precise graph going in ZBX!
Unfortunatelly I stumble into two issues - the first being the biggest caveat:
- When I apply a synth. 100% load (Prime95) on all 4 cores / 8 threads ([email protected] stable), within seconds ZBX reports an http 500 - and extending timeouts/delays past 3s does not help (local GB LAN).
I haven't investigated details, but I assume both priority and instability issues - both, removing the synth. load as well as waiting a period of time, don't help - the JSON SRV needs a restart :-(
- Possibly I don't know a damn thing about JSON/ZBX, but I find it hard to have ZBX 'look into' the JSON data provided by the Rem Serv Mon...
Manually cutting down the origin tree to just one value (using Rem Serv Mon Conf) made it easy to figure out the makings of a child item in ZBX - but 'normalising' the complete tree is s/t I hadn't figured out yet (or ZBX 4 LTS can't do it)...
?
Example of the tree as it is and what I presume to be more helpful:
[
{
"SensorApp": "HWiNFO",
"SensorClass": "System",
"SensorName": "Virtual Memory Commited",
"SensorValue": "10431",
"SensorUnit": "MB",
"SensorUpdateTime": 1574756119
},
...
[
"SensorApp": "HWiNFO"
{
"SensorClass": "System"
{
"SensorName": "Virtual Memory Commited",
"SensorValue": "10431",
"SensorUnit": "MB",
"SensorUpdateTime": 1574756119
},
...
}
...
Ganesh/ALL - w/ all do respect - am I thinking in the wrong direction?
My other thought (primary actually) goes into the direction of using the native onboard zabbix_sender.exe - but cherry-picking the few needed 5, 6, 7 values - thus further reducing the overwhelming amount of values available (266 items of
"SensorApp": "HWiNFO" !) and therefore furthurly reducing process time/load...
...but how to access individual values from HWiNFO (shared mem access I presume - Martin, I had recently written you an email ;-) ) and scripting a simple BAT or PS1 to address the zabbix_sender.exe or to to have the zabbix_sender.exe run through a list of objects?
However I get it running, I'll be glad to share it!
THX for your ideas, thoughts & insights!