NetXMS Support Forum

That's very interesting, because at least on my system iostat's result are consistent with value given by NetXMS agent. Can you point me to exact place in iostat source code?

Best regards,
Victor

Hi!

/proc/diskstats has the following fields (numbering started after device name):

Field 1 — # of reads issued
Field 2 — # of reads merged
Field 3 — # of sectors read
Field 4 — # of milliseconds spent reading
Field 5 — # of writes completed
Field 6 — # of writes merged
Field 7 — # of sectors written
Field 8 — # of milliseconds spent writing
Field 9 — # of I/Os currently in progress
Field 10 — # of milliseconds spent doing I/Os
Field 11 — weighted # of milliseconds spent doing I/Os

NetXMS agent gets field #9 (# of I/Os currently in progress) to calculate average disk queue size. And "disk queue" means "number of disk I/O requests that are either in service or waiting for service". In iostat, it's a parameter called avgqu-sz (shown if running with -x command line option). On my NetXMS server it looks like this:


root@netxms:~# iostat -x 1
Linux 2.6.32-5-686 (netxms)     03/24/2012      _i686_  (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.26    0.00    2.39    3.24    0.00   86.11

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
cciss/c0d0        0.02    39.01    3.07   26.43   265.29   523.52    26.74     0.17    5.64   3.27   9.66

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.50    0.00    1.50    2.00    0.00   96.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
cciss/c0d0        0.00    13.00    0.00   13.00     0.00   208.00    16.00     0.05    4.00   4.00   5.20

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.45    0.00    1.48    0.49    0.00   94.58

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
cciss/c0d0        0.00     8.00    0.00    3.00     0.00    88.00    29.33     0.02    6.67   4.00   1.20

^C
root@netxms:~# nxget 127.0.0.1 "System.IO.DiskQueue(cciss/c0d0)"
0.033333
root@netxms:~#


Best regards,
Victor

No, it's not possible, because each counter requires background processing, so agent have to know instance from the beginning, not only at DCI value request time. What I could think of simplifying counter configuration is to add option to WinPerf to collect all instances of a given counter. I'll add this as feature request.

Best regards,
Victor

Hi!

I hope that it will be before end of March, but I have planned quite a lot for this release, so maybe it will be delayed till first half of April, depending on how fast I'll be able to do development.

Best regards,
Victor

I would create a script which will get the file, parse it, and push values to NetXMS server using nxpush command. Then you can work with the values as usual - set thresholds, show history, etc.

Best regards,
Victor

You don't need two events, just two different rules for same event.

Also, if you want to put this logic into your script, it is also possible. You can just pass additional parameter to your script, giving current status of internet connection. In action definition, you can use macro %[script_name], and in the script return different values depending on internet connection state.

Best regards,
Victor

No, for your configuration you just have to add threshold for last value = 10000. ICMP.PacketLoss will work only for preconfigured targets (added by Target = ip_addr parameters in nxagentd.conf).

Best regards,
Victor

Hi!

I have some ideas why this can happen. I do some fixes already, next release will contain them. Hopefully it will help.

Best regards,
Victor

Hi!

I doubt that there are any possibility to access UPS from NetXMS agent in parallel with other software. The only good solution I could think of is to add additional functionality to UPS subagent, so it can shutdown server if UPS battery is running out. If this could be interesting, I will add it as feature request.

Best regards,
Victor

Sorry for not returning to this issue for too long. Looking through the code didn't give me any ideas. Is it possible to do either: 1) run system for some time with high debug level (at least 5, 6 is better) and send me debug log after nodes disappear; or 2) give me remote access to the system so I can look around and possibly get additional information?

Best regards,
Victor

Hi!

Yes, this is possible. You have to create two rules: one for sending SMS and second for executing your notification script. In first rule you have to add filtering script, which will return TRUE if there are no internet connection. For second rule you can use the same script, but with reversed return values: FALSE if there are no internet connection and TRUE if internet connection is available. Depending on your policy, you may also add "stop processing" flag to first rule (for SMS sending), and do not use filtering script in second rule at all.

Best regards,
Victor

Hi!

There are few possible ways, assuming you have preconfigured targets on agent:

1. You can collect Icmp.PacketLoss parameter for target, and generate event when last value reaches 100 (or any other unacceptable packet loss value).

2. You can collect Icmp.AvgPingTime or Icmp.LastPingTime, and set threshold for value 10000 - ping subagent returns 10000 as response time value to indicate unreachable target.

If you use Icmp.Ping parameter (so no preconfigured target), the only possible way is to set threshold for value 10000.

Hope this helps!

Best regards,
Victor

Hi!

Can you confirm that IP address 172.16.4.41 presented on one of the interfaces of the node?

Best regards,
Victor

Все счетчики - это беззнаковые целые, и при достижении максимума переходят через 0. Например, если у меня 8-ми битовый счетчик, то при значении 254 прибавив 3 я получу 1. Обычно для счетчиков абсолютные значения не важны, и собирают обычно дельту. В истории должно хранится уже значение после вычисления дельты и обработки transformation скриптом. Что касается быстрых интерфейсов, то переполнение счетчиков происходит очень быстро, и чтобы получить осмысленные значения, надо собирать данные часто, каждые 5-10 секунд, иначе между двумя опросами может произойти несколько переполнений и переходов через 0, и тогда дельта, вычисленная сервером, даст неправильный результат. Можно также использовать 64-битные счетчики из ifXTable (.1.3.6.1.2.1.31.1.1.1.6 и другие), если устройство их поддерживает.

Eto pohoze primer iz etogo obsuzdenija: https://www.netxms.org/forum/oe-oo/oo-oto-teeo-snmp-traps/