NetXMS Support Forum

Mozno, pri pomoschi scriptov v event policy. Naprimer, esli ja hochu chto-bi moe pravilo srabativalo tol'ko s 9 do 18, to ja mogu sdelat' takoj script:


sub main()
{
   hour = strftime("%H");
   if (hour >= 9 && hour < 18)
      return 1;
   return 0;
}


V versii 0.2.20 pojavilis' razlichnie uluchshenija v NXSL, i tam etot script mozet vigljadet' tak:


sub main()
{
   t = localtime(time());
   return (t->hour >=9 && t->hour < 18) ? 1 : 0;
}


Best regards,
Victor

Hello!

Could you please send screenshots with your database configuration, service configuration, and error message screens?

Best regards,
Victor

Hello!

This topic may be useful: https://www.netxms.org/forum/index.php/topic,28.0.html.

Best regards,
Victor

Quote from: StarryTripper on March 14, 2008, 09:45:03 PM
The need for an agent is certainly a turn off. Especially since it seems that many of the values the agent allows you to retreive are available through SNMP (CPU utilization, Network Utilization, Disk Space) while I understand others are not (service status).

Usage of NetXMS agents is not mandatory - you can use NetXMS in SNMP only environment as far as installed SNMP agents provides you with all required information. We create our own agents because it is usually easier to configure data collection from agent, and usage of an agent gives you some additional benefits:
- Strong encryption of connection between server and agents if needed (using AES-256, IDEA, Blowfish or 3DES);
- Proxy functionality - you cann access on host A via agent on host B, if host A not directly reacheable from NetXMS server (firewalled or NATed, etc.);
- SNMP proxy functionality - access remote SNMP devices not directly, but via NetXMS agent - can be useful if these SNMP devices not accesible directly or you wish to improve security;
- Execute commands on remote servers in reaction to events;
- You can extend agents easily;
- You can have centralized agent configs if you need.

Best regards,
Victor

Quote from: Alex on March 15, 2008, 08:03:56 PM
- В Network Map не показываются больше названия интерфейсов на карте, т.е. на какой порт кто подсоединен

Dejstvitel'no, est' takoe delo. Prosto komu-to bila nuzna karta bez podpisej, ja ih otkljuchil, peresobral konsol' i zabil pro eto. Sejchas ( v smisle v okonchatel'nom relize, ne v RC4) sdelal punkt menu Map -> Show connector names dlja perekljuchenija etih rezimov.

Quote from: Alex on March 15, 2008, 08:03:56 PM
- Изменились шрифты.
- Раньше названия железяк показывалось полностью, сейчас обрезается название до 12 символов.

Eto chto-to strannoe - ni shrifti, ni pokaz nazvanij ne trogal voobsche... U sebja sejchas otkril kartu - vrode vse normal'no. A kakimi stali shrifti?

Quote from: StarryTripper on March 14, 2008, 02:05:32 PM
I am currently evaluating network management solutions to implement. I have currently installed and configures HypericHQ, OpenNMS, (and the two aforementioned integrated with one another), Zabbix and ZenOSS. I actually on stumbled upon NetXMS while looking for how to do something in OpenNMS.

And what's your impression for now? What is good or bad?

It's not documented yet

Thank you for report, it's corrected now.

Best regards,
Victor

Hello!

Status DCI returns current status of a node. Meanings are following:

0 - Normal
1 - Warning
2 - Minor
3 - Major
4 - Critical
5 - Unknown
6 - Unmanaged

Node status is calculated based on status of child objects (usually interfaces) according to status calculation rules set for this node (default is "most critical"), and active alarms related to this node.

Best regards,
Victor

0.2.20-RC4 actually fix only one bug in console (random crash when changing object properties). No other bugs was reported so far, so I will build final 0.2.20 tonight.

Best regards,
Victor

Hello!

Brief description of common parameters provided by NetXMS agent can be found here: https://www.netxms.org/documentation/common_parameters.html. For Disk.FreePerc() parameter argument is a mount point. For example, on Windows in can be

Disk.FreePerc(C:)

and on UNIX

Disk.FreePerc(/usr)

(assuming that /usr is a mount point).

Unfortunatelly there are no step-by-step example for configuring SNMP DCI, but it should not differ much from configuring agent DCI - you just choose "SNMP Agent" as origin in DCI configuration dialog, and press Select button - you will see MIB browser instead of agent parameters list. Select required entry from MIB browser, and OID will be automatically put into Name field. All other configuration are completely the same as for agent DCI.

Best regards,
Victor

Hello!

%i is a unique identifier of the event's source object (usually node). If you plan to monitor only one service per node with these events, then using just %i is ok, but if you monitor more then one service running on same node and generate same events for diferent services, than you have to distinguish alarms nnot only by node id, but also by service. %3 and %5 is event-specific parameters, number 3 and 5 respectively. For events generated when threshold condition becomes true, parameters are following:

1) Parameter name
2) Item description
3) Threshold value
4) Actual value
5) Data collection item ID
6) Instance

For events generated when threshold condition returns to false, parameters are following:

1) Parameter name
2) Item description
3) Data collection item ID
4) Instance

So in my example I construct alarm key from node id and DCI id.

You can find list of parameters for any predefined event by opening Control Panel -> Events -> Edit appropriate event record and looking at the description field.
All possible macros for event processing policy can be found in NetXMS user manual or here: https://www.netxms.org/documentation/macros.shtml

Best regards,
Victor

I suggest the following scheme:

condition	event when true	event when false
equal 1	COP_SERVICE_STARTING	COP_SERVICE_OK
not equal 0	COP_SERVICE_DOWN	COP_SERVICE_OK

Uncheck "always process all thresholds". Threshold order is important.

Then you will get COP_SERVICE_STARTING if service is in starting state, COP_SERVICE_DOWN if service in state other than running or starting, and COP_SERVICE_OK when it returns to running state.

If you wish to create and terminate appropriate alarms accordingly, you can add the following rules to event processing policy:

Rule 1
Event: COP_SERVICE_STARTING, COP_SERVICE_DOWN
Alarm: Generate alarm, text: %m, key: SERVICE_PROBLEM_%i_%5

Rule 2
Event: COP_SERVICE_OK
Alarm: terminate alarm with key SERVICE_PROBLEM_%i_%3


Then you will have active alarm with appropriate text when service is not running, and it will be automatically terminated when service goes back online. If service will go from starting to, for example, stopped state, text of alarm generated by previous COP_SERVICE_STARTING event will be replaced by message text of COP_SERVICE_DOWN event, so you will have actual information in your alarm browser.

Hope this helps!

Best regards,
Victor

P.S. Also there is a description of threshold checking algorithm in NetXMS user manual, in section 5.2.3.3.

Hello!

If you wish to distinguish between different states, you can create multiple thresholds and events - for example, create separate event SERVICE_PAUSED and for service status DCI create additional threshold "when equal 1" and generate event SERVICE_PAUSED from it. It depends on your environment and requirements - there are no universal tips. From my experience, in most cases considering service as down if it's not running is ok, because it cannot process requests anyway, in whatever state it is, and it's the most important information - actual state is not so important.

Best regards,
Victor

Консоль версии RC3 иногда падала в core после изменения properties объекта.