Source types for the Splunk Add-on for NetApp Data ONTAP

The Splunk Add-on for NetApp Data ONTAP collects API data from NetApp storage controllers running Data ONTAP in 7-mode or cluster mode. It collects performance data about specific inventory objects and data about the configuration of your NetApp storage infrastructure. We collect logs on NetApp filers that contain basic information about their operation. This gives you the visibility you need into the health and state of your storage infrastructure enabling you to better manage it.

API data collection is managed by the Hydra scheduler working with the data collection nodes. The exception to this is the collection of syslog data from the filers.

The data we collect

The following NetApp data types are collected by the app:

Data source	Data type	Description
API	Inventory data	This data is collected from the Net App filers in 7-mode and Cluster mode and contain information about specific object instances. These objects are volume, disk, LUN, aggregate, vFiler, QTree, and Quota.
API	Performance data	Performance data is collected from the following NetApp filer objects in 7-mode and Cluster mode: volume, disk, LUN, aggregate, vFiler, QTree, and Quota. Performance counters collect data for performance objects.
API	Options data	This add-on collects 7-mode options data and Cluster cifs-options data.
API	EMS data	The app collects details of critical activities from the NetApp filer Event Management System (EMS).
Syslog	NetApp filer logs	These are log files generated by the NetApp filer in 7-mode and cluster mode. This data is collected by configuring the NetApp filers to send the logs to a syslog server (over the network).

Sourcetype	Eventtype	Tags
ontap:perf	Performance	performance, storage
ontap:system	Storage	storage
ontap:volume	Storage	storage
ontap:disk	Storage	storage
ontap:aggr	Storage	storage
ontap:lun	Storage	storage
ontap:vserver	Storage	storage
ontap:qtree	Storage	storage
ontap:quota	Storage	storage
ontap:cifsoptions	Storage	storage
ontap:options	Storage	storage
ontap:ems	Storage	storage
ontap:nfsexports	Storage	storage
ontap:cluster	Storage	storage

Common Information Model compliance

The Splunk Add-on for NetApp Data ONTAP supports the following event categories in the CIM:

• Inventory
• Performance

Note: The Splunk Add-on for NetApp Data ONTAP does not extract CIM data for storage and cpu objects of the performance data model.

The Common Information Model is available as an Add-on that implements the CIM tables as data models. You can download the Splunk Common Information Model Add-on (Splunk_SA_CIM) from Splunk Apps. For more information on the Splunk Common Information Model Add-on, see the "Common Information Model Add-on" topic in the Splunk Enterprise documentation. See also the Splunk documentation on how to "Understand and use the Common Information Model" in the Knowledge Manager Manual.

You can use the data models available in the Splunk Common Information Model Add-on in two ways:

• You can use them to test whether your fields and tags have been normalized correctly.
• After you've verified that your data is normalized you can use the models to generate reports and dashboard panels via Pivot.

The CIM enables you to identify common events across different technologies and, using the CIM, you can build a variety of specialized searches across the datasets that have been mapped to event categories relevant to the underlying technologies. Splunk_SA_CIM is a repository of data models that can be used with Splunk apps and Splunk 6.0 or later. The CIM identifies the fields that must be present in the data for the dashboards to work, and the tags that need to be assigned to the data for the process to work correctly.

For information about the fields in these event categories, read "Standard fields and event category tags" in the Splunk Knowledge Manager manual.

When you add sourcetypes for your data to the Splunk Add-on for NetApp Data ONTAP, refer to the Splunk Enterprise CIM documentation to ensure that you follow the requirements for data processing to CIM standards.

Key performance counters

You can collect data for each performance object in your storage system. We monitor the performance of your storage systems by collecting the key performance counters for your storage devices so that you can be proactive in configuring your system to meet your storage demands and troubleshooting your performance issues. This enables you to identify and diagnose problems early.

Example using performance counters for the Volume object

We use performance counters in some of the searches that power the dashboards in the Content Pack for NetApp Data ONTAP Dashboards and Reports. For example, in the Volume Detail - NetApp Data ONTAP dashboard, we use the latency values (average, other, read, and write) to chart the latency values over time for reads on the volume, writes to the volume, average latency for all operations on the volume, and the average time for other operations on the volume. All operations are reported in milliseconds. See the Selected Volume Latency (ms) panel in the Volume Detail - NetApp Data ONTAP dashboard to see the results of the search.

sourcetype=ontap:perf source=VolumePerfHandler host="host_name" objname="volume_name" | timechart first(eval(avg_latency_average/1000)) as avg_latency_average first(eval(other_latency_average/1000)) as other_latency_averagefirst(eval(write_latency_average/1000)) as write_latency_average first(eval(read_latency_average/1000)) as read_latency_average by objname

You can also create your own custom searches using the storage performance counters. Run your search in the Search bar in Splunk. For example, you can use the performance counter "Average Volume Latency" in a search to collect the average latency of all of the operations on the volume and then display the last received value by host and volume name.

An example of a search that can do this is:

index=ontap sourcetype=ontap:perf source=VolumePerfHandler avg_latency_average=* | rename objname as volume_name | stats last(avg_latency_average) by host,volume_name

The result is a table that displayed the host names, the volume name on the host, and the last latency values.