NetXMS Support Forum

Could you please run from command line in C:\NetXMS\bin

netxmsd.exe -D 9

or

nxdbmgr.exe check

You should get additional information about reason.

Best regards,
Victor

64-bit PostgreSQL driver available at https://www.netxms.org/download/patches/008/pgsql.ddr. It is build against PostgreSQL client 9.0.4-1, which should be installed separately.

Best regards,
Victor

Creating an MSI package requires a lot of work, and I'm not sure when we will have resources for this. Existing agent installer has command line options for unattended install, so it can be wrapped into MSI. It will not allow full functionality provided by Windows INstaller, but at least will work as workaround for centralized agent deployment.

Best regards,
Victor

Hi!

Currently you can only monitor URL availability and correctness of returned data, not response time.

Best regards,
Victor

Hi!

Yes, it's possible. You can check this topic: https://www.netxms.org/forum/general-support/check-telnet-is-listening-on-host/ for configuration example.

Best regards,
Victor

hi!

currently named parameters are not supported in the log parser. If you pass multiple parameters, they will be numbered in order they appear in regexp. For example, if you have the following rule:

<match>Error (.*) at (.*)</match>
<event params="2">200000</match>

You will have two parameters - number 1 and number 2, and it will be possible to use them in macro expansion as %1 and %2. For log record

Error 4 at test

with this rule you will have
%1 == "4"
%2 == "test"

Best regards,
Victor

Hi!

I assume that you are installing NetXMS on Windows, right? Then please check that username you have entered in configuration wizard in DBA field, has sufficient rights for database creation.

Best regards,
Victor

Hi!

Unfortunately PostgreSQL driver is missing in x64 installer - it's a build bug. You should wait for 1.1.4 release, or I can put driver binary on web site if you need it now.

Best regards,
Victor

Hi!

To clarify - I'm not 100% sure that it will fix your problem, but recently I do the fix for problem with similar symptoms. So it is very likely that it's same problem. Actually, if you have mdmp files from the crash, you can send one to [email protected] so I can double check.

Best regards,
Victor

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