NetXMS Support Forum

Depends on how do you monitor service status. If it is done via set of DCIs, then you can create additional DCI and in transformation script, read values of all service checking DCIs, count number of services in "down" state, and return that value. Then you will be able to set threshold on this DCI as usual.

Best regards,
Victor

Quote from: lindeamon on August 17, 2011, 09:28:23 AM
another thing regarding this solution:
i have configured a dci to find uptime through snmp and in the autoapply it told it to apply it on node that have snmp and do not have an agent.what i want to know is,once a node was applyed with this dci and i install an agent on it,will the template be automatically unbind ? if not,what is the right way do unbind it automatically ?

It all depends on your auto apply script. Template is applied when script returns true, and removed when script return false. So, if you wish template to be applied only on nodes with SNMP, but without NetXMS agent, and remoed from SNMP-only node when NetXMS agent installed on it, your auto apply script should looks like following:


return $node->isSNMP && !$node->isAgent;


Best regards,
Victor

Hi!

In 1.1.x versions, you should use Java console for working with network maps. In Java console, there are separate tree (Maps) where you can create map objects.

Best regards,
Victor

K sozaleniju bez izmenenija konsoli, tol'ko konfiguraciej - nel'zja. Ideja horoshaja, mozno budet realizovat'.

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