- About LogicMonitor
- Cloud Monitoring
- Dashboards and Widgets
- Getting Started
- LM Service Insight
- About LogicModules
- Creating & Managing DataSources
- Active Discovery
- Data Collection Methods
- Groovy Support
- PowerShell Support
- Setting Up JobMonitors
- Help & Troubleshooting
- User-Defined AppliesTo Functions
- SNMP sysOID Maps
- Rest API Developers Guide
- RPC API Developers Guide - Deprecated
- Servicenow CMDB Integration
- Terminology and Syntax
NetApp Active Discovery is used to discover instances by means of the NetApp OnTAP API. There are two distinct methods of NetApp Active Discovery:
- Performance Object – a simpler method suitable for discovering instances where the returned results do not include duplicate Name values, and includes some pre-defined instance grouping methods
- XML – a more flexible discovery method, in that it can key off different field names, and supports flexible grouping and description fields
Regardless of the selected method, there are three sections to the NetApp Active Discovery:
- Parameters – this section will vary depending on whether you select type Performance Object or type XML
- Filters (optional) – this section enables you to filter the discovered instances. You can filter against the ##WILDALIAS## token to filter based on discovered instance name, or you can filter based on any attribute (as specified in the NetApp API) of discovered object when you are using Performance Object Discovery. See the examples in the sections below.
- Group Method – this section enables you to decide whether you’d like to manually group discovered instances, or whether you’d like to automatically group discovered instances. Note that the NetApp grouping method will automatically place volumes and disks in their parent aggregates when applied to objects of type volume or disk, but have no effect otherwise.
Performance Object NetApp Discovery
Performance Object Active Discovery will return the name field of all the returned objects, as both the instance name and wildcard value. Note that this makes the discovery method not suited for cases where the object cannot be retrieved by name, or where duplicate names can exist. (For example, a cluster controller will return all the managed systems as having the same “name” field (they will all be named “system”) – but they must be queried by the system UUID. For this reason the system performance datasources are not discovered using Performance Object discovery.) An exception to this is that the Performance Object discovery method has special processing to support volume discovery in cluster mode, so it can deal with possibly duplicative volume names, and return the UUID field as the identifier.
To use Performance Object NetApp Discovery, set the Type parameter to ‘Performance Object’. Once you set type to Performance Object you’ll need to specify the NetApp Object (as referred to by the NetApp API) to discover – this is typically an object like a volume, disk, lun, etc.
The filter in the image below filters against ##WILDALIAS## to only discover volumes with the string “vol0” in their name:
The filter in the image below discovers only volumes on a specific aggregate, using ‘VOLUME-ID-ATTRIBUTES.CONTAINING-AGGREGATE-NAME’ as the filter attribute:
The image below shows the Active Discovery section for the NetApp volume performance datasource, modified to only apply to volumes with beta in their name:
XML NetApp Discovery
XML based NetApp instance discovery is a more powerful (but more complicated) method. It works by specifying an XML request to send to the NetApp, using one of the NetApp SDK API calls, and then specifying how to interpret the results.
To use XML NetApp Discovery, set the Type parameter to XML. Once you’ve set the type to XML, you’ll need to specify:
- XML Request: The API request to send to the NetApp in XML format
- Instance Locator: The name of the XML element that contains the instance result set array
- Instance Value: The XML path of the instance value, relative to the array located within the instance locator (not the instance locator itself.) Supports an optional regular expression to filter instances in the XML object value, which may have a capture group. See below for an example.
- Instance Name: Optional XML path of the instance alias, or human readable name. If not given, defaults to the Instance Value.
- Instance Group: Optional XML path of the instance group – note that this will override the default NetApp Group Method parameter ‘aggregate’
- Instance Description: Optional XML path of the instance description.
The XML response that a NetApp will reply to the call may look like this:
<results status='passed'> <attributes-list> <instance-info> <name>system</name> <uuid>scenariolab-01:kernel:system</uuid> </instance-info> <instance-info> <name>system</name> <uuid>scenariolab-04:kernel:system</uuid> </instance-info> </attributes-list> <num-records>2</num-records> </results>
The Instance Locator field identifies that the instances are within the array contained within the <attributes-list> XML path. (In this case, that is the array of <instance-info> elements, but these are selected automatically.) The unique identifier, the Instance Value, is set to uuid – so this will return the contents of that element.
Instance Name is set to uuid:(.*?):.* – so this will also return the contents of the UUID field, but only the part that matches the regular expression capture group (the parenthesis.) The regular expression captures the contents of the uuid field before the first colon. So for the UUID field scenariolab-01:kernel:system it will return scenariolab-01.
The Instance Description is set to the contents of the Name field. Thus for the above XML result, the returned instances will be:
|Instance Name||Instance Value||Description|
In this Article: