Problems with agent parameters

Started by xenth, April 10, 2008, 11:39:13 AM

Previous topic - Next topic

xenth

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.

Victor Kirhenshtein

What operating system agent is running on?

xenth

Sorry, forgot to mention.

The agent is running on a windows XP pro 32Bit machine with SP2 installed.

Victor Kirhenshtein

Do you have English version of Windows or in some other language?

xenth

I'm using the dutch version of windows on all machines.

Victor Kirhenshtein

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

xenth

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.

:)

Victor Kirhenshtein

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

Victor Kirhenshtein

Could you please check attached WINPERF subagent - it should fix System.Uptime and System.ThreadCount on non-english systems.

Best regards,
Victor

xenth

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.

xenth

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

Victor Kirhenshtein

Is there any messages in agent's log (or system event log) when agent starts?

Best regards,
Victor

xenth

#12
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.

Victor Kirhenshtein

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

xenth

Grr, now I feel dumb  :D

Thanks once again for solving the problem!