NetXMS Support Forum

Smena tipa DCI zdes' ne pomozet - schetchik na samom ustrojstve 32bitnij. Server budet eto 32bitnoe znachenie u sebja hranit' kak 64bitnoe, no sbros schetchika proishodit na samom ustrojstve. Esli ustrojstvo podderzivaet extended interface MIB (vetka .1.3.6.1.2.1.31.1.1.1), to mozno ispol'zovat' ifHCInOctets (.1.3.6.1.2.1.31.1.1.1.6) i ifHCOutOctets (.1.3.6.1.2.1.31.1.1.1.10) - eto 64 bit schetchiki.

Problema v tom, chto traffik na interfejse predstavlen kak postojanno uvelichivajusheesja 32 bit znachenie - kol-vo baitov. Pri dostizenii znachenija 2 ^ 32 schetchik sbrasivaetsja na 0. Esli poschitat' vremja do sbrosa schetchika pri traffike 500 mbit/sec, poluchim:

500 mbit/sec = 524288000 bit/sec = 65536000 bytes/sec

T.e. schetchik v srednem uvelichivaetsja na 65536000 kazduju sekundu. Poskol'ku max. znachenie eto 2 ^32 = 4294967296, to schetchik budet sbrasivatsja primerno kazdie 65 secund. T.e. mezdu znachenijami, vzjatimi s intervalom v 300 sekund, proizojdet neskol'ko sbrosov schetchika, i raznica mezdu nimi ne imeet nikakogo smisla.

Na vihodnih ja vilozu versiju 1.0.12. Tam est' neskol'ko vaznih ispravlenij, skoree vsego eta problema toze ischeznet.

Most likely it is fixed already in 1.1.3. I'll do a backport to 1.0.x branch and roll out 1.0.12 this weekend.

Best regards,
Victor

I have added support for named parameters in events. This functionality will be available in 1.1.4 release. Currently only threashold reached/rearmed events have named parameters. Named parameters can be accessed using %<name> macro and using GetEventParameter function in NXSL scripts. The following parameter names available for threshold violation/rearm events: dciName, dciDescription, dciId, instance, thresholdValue, currentValue, isRepeatedEvent (latter only for threshold violation events).

Best regards,
Victor

I agree that making SYS_THRESHOLD_REARMED to have less parameters than threshold violation event was a bad decision. The best option probably could be changing it to have same parameters in same order as SYS_THRESHOLD_REACHED, but this will broke compatibility with existing setups. Compatibility will be retained if we add missing parameters at the end, but as same data will be at different places for reach and rearm events, this may cause additional configuration errors. I'll do something with it in 1.1.4, but I don't decide exact solution yet.

Best regards,
Victor

Hi!

Sorry, I don't fully understand what you mean by "to be through w.r.t. terminal settings".
Adding support for SIP instant messaging is a good idea, I'l ltake a look how hard it could be to implement it.

Best regards,
Victor

Hi!

usually you use containers in object tree to group your servers. Then you can easily create rules in event processing policy for these groups - just by specifying required container as source. For example, to send e-mail to different people for group A and group B, you should create two rules:

1. Source = Container_A, Action = send_email_to_admin_1
2. Source = Container_B, Action = send_email_to_admin_2

Best regards,
Victor

Eto oznachaet kakoj-to bug v servere, iz-za kotorogo zavisajut vnutrennie processi. A kakaja versija servera u vas stoit?

And just in case - I made changes Java console. Do you use new Java console (nxmc.exe) or legacy one (nxcon.exe)?

Best regards,
Victor

Console uses port 4701 to connect to server, so on client side you should allow remote port 4701 for nxcon.exe (and Java console), and on server side you should allow local port 4701 for process netxmsd.exe.

Best regards,
Victor

Hi!

You should use full path name to parser xml file in agent's configuration. Otherwise agent will look for it in current directory, which is usually root of disk C: or directory where nxagentd.exe is located.

Best regards,
Victor

It's not possible to do that by configuration, only by changing console code. I have added these 3 new presets, next version of the console will have them.

Best regards,
Victor

Zamenite
DBDriver = /usr/local/lib/libnxddr_oracle.so
v netxmsd.conf na
DBDriver = oracle.ddr

Pomenjalas' shema imenovanija DB driverov v 1.1.3 (stala takoj-ze, kak v Windows). Dolzni bili sozdatsja symlinki, no ne sozdajutsja.

Hi!

I don't think that transformation script is a right place for SNMP trap generation. Normally you should create threshold, and generate traps, send emails, etc. from event processing policy via actions. Currently you don't have built-in option for SNMP trap sending, but you can use any command line tool capable of sending SNMP traps and call it via "execute command" action. I agree that having built-in SNMP trap sending action is a good feature, but until it is not implemented, there is workaround.

As for multiple actions for event - you already can do that - in one rule in event processing policy you can specify multiple actions.

Best regards,
Victor