NetXMS Support Forum

Yes, then you will get more detailed picture. From my experience, I often configure only common System.IO.DiskQueue parameter on all servers, and then add per disk queue/time for those servers where I see need for more detailed information.

Best regards,
Victor

Должна. Похоже что у вас wxWidgets собраны под UNICODE, 0.2.19 это не поддерживал. 0.2.20 должен собираться нормально. Пока-что можно попробовать 0.2.20-rc1 или дождаться сегодня-завтра rc2.

Dolzen bit' bukval'no na dnjah. Menja so vseh storon osazdajut na temu novoj versii Ja planiruju v eti vihodnie plotno porabotat' i taki k ponedel'niku ee vidat'.

You should use $1 instead of $i. Do you use $1 in when trying short form? Also, you example has syntax error - there are missing ; after return statement.
It should be like this:


sub main()
{
   return ($1 / 2);
}


Best regards,
Victor

Btw, is there libeay32.dll in NetXMS\bin directory? It supposed to be installed with NetXMS.

Best regards,
Victor

Quote from: kghammond on February 13, 2008, 10:39:25 PM
I was just going to ask that question.  I assume then that process.io.xxx with a transformation will actually be more accurate.

They should be the same - in both cases you get average value for 60 second, the only difference is that for built-in counters you have calculation on server side (so using fewer cpu cycles on machine with agent) and that you can easily use them in templates without any changes in appropriate agent configs.

Quote from: kghammond on February 13, 2008, 10:39:25 PM
At the same time, my working set counter will be more accurate than process.wkset because it will be averaged over 60 seconds.  Is that correct?

Yes, that's correct.

Best regards,
Victor

Hello!

There are various errors. First, in many counters you miss leading backslash. Also, there should be a white space between % sign and "Disk Read Time" or "Disk Write Time". And finally, you should enclose description in double quotes if you are using colon. Correct section should looks like this:


*WinPerf
Counter = UserProcess.SQLServer.CPU:"\Process(sqlservr)\% Processor Time":60:A:INT:Average % CPU Time for sqlservr.exe over past minute
Counter = UserProcess.SQLServer.IO.ReadBytes:"\Process(sqlservr)\IO Read Bytes/sec":60:A:INT:Average I/O Read Bytes for sqlservr.exe over past minute
Counter = UserProcess.SQLServer.IO.WriteBytes:"\Process(sqlservr)\IO Write Bytes/sec":60:A:INT:Average I/O Write Bytes for sqlservr.exe over past minute
Counter = UserProcess.SQLServer.IO.OtherBytes:"\Process(sqlservr)\IO Other Bytes/sec":60:A:INT:Average I/O Other Bytes for sqlservr.exe over past minute
Counter = UserProcess.SQLServer.Memory:"\Process(sqlservr)\Working Set":60:A:INT:Average Memory usage for sqlservr.exe over past minute
Counter = System.IO.DiskReadTime:"\LogicalDisk(C:)\% Disk Read Time":60:A:INT:"Average Disk Read Time C:"
Counter = System.IO.DiskWriteTime:"\LogicalDisk(C:)\% Disk Write Time":60:A:INT:"Average Disk Write Time C:"
Counter = System.IO.DiskReadBytes:"\LogicalDisk(C:)\Disk Read Bytes/sec":60:A:INT:"Average Disk Read Bytes Per Sec C:"
Counter = System.IO.DiskWriteBytes:"\LogicalDisk(C:)\Disk Write Bytes/sec":60:A:INT:"Average Disk Write Bytes Per Sec C:"
Counter = System.IO.DiskReadTime:"\LogicalDisk(D:)\% Disk Read Time":60:A:INT:"Average Disk Read Time D:"
Counter = System.IO.DiskWriteTime:"\LogicalDisk(D:)\% Disk Write Time":60:A:INT:"Average Disk Write Time D:"
Counter = System.IO.DiskReadBytes:"\LogicalDisk(D:)\Disk Read Bytes/sec":60:A:INT:"Average Disk Read Bytes Per Sec D:"
Counter = System.IO.DiskWriteBytes:"\LogicalDisk(D:)\Disk Write Bytes/sec":60:A:INT:"Average Disk Write Bytes Per Sec D:"


Also, you may find useful built-in parameters Process.WkSet and Process.IO.xxx. You can find short description of built-in parameters here:
https://www.netxms.org/documentation/common_parameters.html

However there are difference between your custom parameters and built-in Process.IO.xxx - you define average value for last minute, while built-in parameters is a totals since process start - but you can calculate an average value using delta transformation for DCI on server side.

Best regards,
Victor

For process counters in question, if process does not exist, counter will return 0. But in general, if you try to add non-existing performance counter, it may fail on agent startup, or may return error to data collection requests - depending on what PDH returns to agent.

Best regards,
Victor

You mean just divide value to a constant number of processors? Currently you can do it on server side by using transformation script in DCI. If you have two processors, your transformation script can look like this:


$1 / 2


Drawback of this method is that you cannot create an universal template which can be used on machines with different number of CPUs, because CPU number is hard coded as a constant.

Best regards,
Victor

Hello!

CPU load is an average length of processor queue (number of processes ready for execution but waiting for free CPU time slot) for last minute. This measure is widely used in UNIX world, often called "load average".

Best regards,
Victor

Hello!

It's already implemented - in Object Browser select Object -> View -> Hide unmanaged leaf objects.

Best regards,
Victor

Process.UserTime and Proccess.KernerlTime is a total amount of time spent by process in appropriate mode. It's a always-increasing counters. You can collect perfmon counters via either PDH.CounterValue parameter or by defining new parameters via Counter in *WinPerf section of agent's configuration file.

Best regards,
Victor

P.S. Look at this message for some more information about creating agent parameters from PDH counters:
https://www.netxms.org/forum/index.php/topic,88.msg381.html#msg381

Hello!

If I understand your correctly, you need to calculate percentage of server's uptime (or normal operation) for a month. You can use two approaches:
1) scan collected data of System.Uptime parameter - while it's growing, it means that system is up. Gap in values means that system was down - so you need to calculate the amount of time passed between high and low value. For example, if System.Uptime history looks like this:

...
11:00:00 10000
11:01:00 10060
11:04:00 7
11:05:00 67
...

it means that server was down for about 3 minutes. So you sum all gap intervals, and then calculate uptime percentage using formula gap_interval_sum / total_seconds_in_month * 100 if you measure gap intervals in seconds.

2) Second approach is similar, but you scan event log for SYS_NODE_DOWN and SYS_NODE_UP events, and sum intervals between them. This method is less reliable then first one, because SYS_NODE_DOWN may be generated if, for example, NetXMS server loses connectivity with the server, while server still up and running. It's up to you to decide what should be considered uptime and what - downtime.

Best regards,
Victor

Про долгие проверки каждого интерфейса - это баг. А в лог они попадают в одно время с SYS_NODE_DOWN поскольку их придерживает механизм корреляции событий - чтобы можно было все SYS_IF_DOWN скоррелировать с SYS_NODE_DOWN и через event policy пропустить только SYS_NODE_DOWN.

Там чисто технические проблемы, но сделать надо. Кстати Windows агент такие процессы принудительно завершает.