22
edits
Difference between revisions of "User talk:Pavels Gurskis"
Jump to navigation
Jump to search
User talk:Pavels Gurskis (view source)
Revision as of 15:35, 23 December 2014
, 15:35, 23 December 2014no edit summary
m (Welcome!) |
|||
| (15 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
You will probably want to read the [[Help:Contents|help pages]]. | You will probably want to read the [[Help:Contents|help pages]]. | ||
Again, welcome and have fun! [[User:AlexKirhenshtein|AlexKirhenshtein]] ([[User talk:AlexKirhenshtein|talk]]) 22:12, 24 April 2014 (EEST) | Again, welcome and have fun! [[User:AlexKirhenshtein|AlexKirhenshtein]] ([[User talk:AlexKirhenshtein|talk]]) 22:12, 24 April 2014 (EEST) | ||
== DCI Parameters == | |||
Notes on using particular DCIs | |||
=== ChildStatus === | |||
ChildStatus can be used to check status of child items of the nodes, particularly: | |||
# Network Service | |||
# Interface | |||
While using ChildStatus to check status of the interface, keep in mind, that depending on the device/vendor object ID of the interface might change between the [[configuration polls]]. | |||
For Cisco switches there's way to preserve ifIndex for the interfaces using '''snmp-server ifindex persist''' command (read more about that on [http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/28420-ifIndex-Persistence.html Interface Index (ifIndex) Persistence]) | |||
PS: This might require entering command in interface (rather than global) context. | |||
PPS: Not sure if works everywhere... '''write mib-data''' might be needed as well | |||
=== SNMP Instance Discovery === | |||
Let's say we want to collect status of all interfaces on a node. | |||
Put OID of interest in "Parameter" field on "General" tab with {instance} suffix (.1.3.6.1.2.1.2.2.1.8.{instance}). | |||
Put something meaningful in "Description" filed on "General" tab, use {instance-name} macro to make this human-readable ("Interface status ({instance-name})"). | |||
Go to "Instance Discovery" tab. | |||
Pick "SNMP Walk - Values" as discovery method. | |||
Pick proper base OID as described in [[Creating SNMP table DCI]] (.1.3.6.1.2.1.2.2.1.1). | |||
Add instance discovery filter script: | |||
snmp = CreateSNMPTransport($node); | |||
ifName = SNMPGetValue(snmp,".1.3.6.1.2.1.2.2.1.2." . $1); | |||
ifType = SNMPGetValue(snmp,".1.3.6.1.2.1.2.2.1.3." . $1); | |||
return %((ifType==6), $1, ifName); | |||
{instance-name} in "Description" filed will be replaced with 3rd parameter returned from the filter script (ifName in that case). | |||
== Node interface == | |||
Notes on working with node interfaces | |||
=== Parameters === | |||
==== Required poll count ==== | |||
NetXMS will consider interface down only after given number of unsuccessful polls. | |||
== Event Processing Policy == | |||
=== SYS_* Events === | |||
Please note, that as part of internal event correlation, '''no SYS_* events processed''' from the node after receiving SYS_NODE_DOWN event, until SYS_NODE_NORMAL received from that node. However, custom events processed just fine even after SYS_NODE_DOWN event. | |||
=== Macros for Event Processing === | |||
Note, that different set of macros available for Activation and De-activation of alarms. For example, if you use unique DCI ID for alarm generation ('''%5'''), you should use different macro to de-activate this alarm ('''%3''') | |||
== NXSL scripting == | |||
==== Referring scripts from Script Library ==== | |||
Calling scripts from Script Library: | |||
myVariable=Name::In::Script::Library/functionName | |||
==== Event Processing Policy ==== | |||
Calling Script Library scripts from Action in Event Processing Policy: | |||
%[Name::In::Script::Library/functionName] | |||
NB: you can not pass any parameters when calling scripts from EPP Actions, however you have access to $event and $node object | |||