I'm having some problems with several netXMS parameters, Using the 2.20 agent, console and server.
Parameters
system.memory.physical.free Works perfectly
System.uptime Unsigned integer 60Sec interval Not supported status
System.cpu.loadavg Float 60sec interval 0.000000
Disk.Free(C:) Unsigned int64 60Sec interval Is inaccurate, reads 800MB, to 5GB too much
Just a few parameters I tried.
What operating system agent is running on?
Sorry, forgot to mention.
The agent is running on a windows XP pro 32Bit machine with SP2 installed.
Do you have English version of Windows or in some other language?
I'm using the dutch version of windows on all machines.
It's the reason for System.Uptime. I'll fix it soon. Load average can be OK, I don't know you actual load. About DiskFree - what is the value returned by agent and what is real value?
Best regards,
Victor
Allright, great :)
The value returned by agent on hdd space:
System #1: Free:62.7GB NetXMS reads out: 67G
System #2: Free:8.64GB NetXMS reads out: 9284M
CPU load is at a constant 0.000000 value, which can't be right, the systems aren't idle.
:)
Quote from: xenth on April 10, 2008, 05:42:21 PM
The value returned by agent on hdd space:
System #1: Free:62.7GB NetXMS reads out: 67G
System #2: Free:8.64GB NetXMS reads out: 9284M
It's a console display problem, not an agent bug. Actual DCI value for free disk space is in bytes. When you use multipliers in console to view current DCI values, console uses them in common sense, i.e. K = 1000, M = 1000000, and so on, because console has no knowledge about units of DCI - is it bytes or something else. If you multiply 62.7 to 1024 * 1024 * 1024 and then divide by 1000000000 and take whole part, you'll get 67. You can also turn off multipliers and see correct number of bytes.
Thre are no straight-forward solution for this. Probably we should add additional DCI property - units, to give console a hint how to work with the values.
Best regards,
Victor
Could you please check attached WINPERF subagent - it should fix System.Uptime and System.ThreadCount on non-english systems.
Best regards,
Victor
Thank you victor, will test this in a minute. :)
Also, I am still having the System.CPU.Loadavg read out at 0.000000, is there a solution for this as well?
Thanks again.
Quote from: Victor Kirhenshtein on April 11, 2008, 10:11:22 AM
Could you please check attached WINPERF subagent - it should fix System.Uptime and System.ThreadCount on non-english systems.
Best regards,
Victor
Sorry for the delay, this subagent doesnt fix the problem unfortunately :(
system.uptime remains red
Is there any messages in agent's log (or system event log) when agent starts?
Best regards,
Victor
I cannot seem to find it in the event log, odd.
When I run nxagentd -c , it says the configuration file is OK.
Everything seems to be OK but I cant read out the system.uptime (red) and the system.cpu.loadavg doesnt give back a proper reading.
Also, when I turn of the "use multipliers" context item I still get the wrong readouts, from 2.00000 to 6.000000 it was mostly on 2.000000 during 100% load.
Sorry that I keep hammering on this but it's very important that I get the processor average load readout.
Just to make sure that we are understanding each other correctly: processor load and processor utilization are different parameters - processor utilization, or usage (represented by System.CPU.Usage) is a percentage of time spent by processor outside idle loop, and processor load (represented by System.CPU.LoadAvg) is an average length of process run queue (or average number of processes ready to run but waiting for execution because CPU is busy running other process). So, when CPU utilization goes to 100%, CPU load can be 2 - it just mean that in average, 2 processes are waiting for execution - which is normal.
CPU utilization is mostly used in Windows world, and CPU load average - in UNIX world. We support both of them on all platforms.
Best regards,
Victor
Grr, now I feel dumb :D
Thanks once again for solving the problem!