NetXMS Support Forum

Rusificirovat' konsol' ne slozno. Daze bil nachat etot process. Sam process prostoj - beretsja message fail i v nem anglijskij tekst zamenjaetsja na russkij. Posle etogo mozno sdelat' rusificirovannuju sborku konsoli.

Try to replace file dbschema_sqlite.sql with attached one. May be file that you have is incorrect.

Best regards,
Victor

Hi!

SecondsToUptime should do the work. Don't forget that function names are case-sensitive, and don't forget to change DCI type to String. You transformation script may looks like following:


SecondsToUptime($1)


or


return SecondsToUptime($1);


Best regards,
Victor

Hi!

No, it should not loose autobind script on folder rename. It's just an attribute of the container and bound to object id of the container, as any other attribute.

Best regards,
Victor

Hi!

Did you have a chance to test 1.0.12?

Best regards,
Victor

Hi!

Under directory where you unpack console should be a directory called workspace\.metadata with file called ".log". Could you please send this file to [email protected]?

Best regards,
Victor

Hi!

Yes, you need to restart NetXMS Core.

For monitoring internal database writer queue, you should look at parameter with source "Internal" (not agent!) and name "Server.AverageDBWriterQueueSize". This parameter is only available for node object representing NetXMS server itself. DCI for this parameter should be created by default.

Best regards,
Victor

Hi!

What NetXMS version you are using?

Best regards,
Victor

1. No. You should create separate xml file for each parser.
2. You can pass as many parameters as you like. Attribute params contains number of parameters, so if you have 4 parameters for the event, you will have <event params="4">. Of course you have to have appropriate number of capturing groups in regular expression.

Best regards,
Victor

Hi!

This could be caused by database writer's queue growing to extremely large size - see my post here: https://www.netxms.org/forum/general-support/data-collection-delay/msg5745/?topicseen#msg5745.

Best regards,
Victor

Hi!

On "Last Values" page for node you see time stamp of last poll and last collected value, both cached in server's memory. When you are looking at DCI history (either as text or as graph), data shown taken from database. Inside NetXMS data collection going in two steps - at first step, data collected from agents and put into writer's queue. On second step, data is taken from writer's queue by separate background thread and written to database. Usually second step goes instantly after first one, and last value in database is last value collected, but some times there could be bottlenecks in writing data to database and some data may still wait in the writer's queue. In this case you will see that data in history is behind current time. You can check if this is the case by looking at database writer's queue size (either via DCI at monitoring server or via server's command line). If it is constantly large or even growing, then database writer is not able to write all data to database on time. In that case, you should first try to increase number of database writers (by increasing value of NumberOfDatabaseWriters configuration parameter) and, if this does not help, check your database engine for performance problems.

Best regards,
Victor

Hi all!

NetXMS version 1.0.12 is out. It is a bugfix release for 1.0.x branch. Changes from previous release:

- nxpush now supports node identification by DNS name or IP address
- Fixed memory leak in netxmsd
- Fixed crash in netxmsd
- Other minor bugfixes
- Fixed issues: #299

Best regards,
Victor

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