I haven't investigated details, but I assume both priority and instability issues - both, removing the synth. 100% load (Prime95) on all 4 cores / 8 threads ( stable), within seconds ZBX reports an http 500 - and extending timeouts/delays past 3s does not help (local GB LAN). Unfortunatelly I stumble into two issues - the first being the biggest caveat: 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! 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.
That is how I came about to experiment w/ Ganesh's Remote Sensor Monitor. 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). 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. 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' -) 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.
My monitoring server, where I wish to 'trap' measurement values is a Zabbix 4 LTS (on deb stretch). I'm running a fully watercooled rig w/ W10 Pro (1903) & the latest HWiNFO (incl. To state the stats of where I am, what I experience and where I want to go: 1st of all - nice work(!!!), Martin, for HWiNFO and nice work, Ganesh, for the JSON server!
0 kommentar(er)
