Additional use cases for new switch „svm_in_name“

The switch ‑‑svm_in_name for the usage check was first introduced in version 3.9.1. We would like to take a look at an intersting use case for this new switch. ‑‑exclude|‑X and ‑‑include|‑I can be used to filter the list of instances by name. If the instance name starts with the name of the Vserver separated by a dot, one can easily select a group of instances that belong to one or more Vservers. Previously, this could be done using the switch  ‑‑vserver|‑s, but only for one particular Vserver. Only a specific Vserver could be selected but not two of them or more interestingly a whole group based on a naming-pattern of the Vserver name. All of these use cases are now possible. Let ’s look at a few examples:``` ./check_netapp_pro.pl ‑H filer ‑o volume ‑‑svm_in_name ‑I ^vserver1\.

This check monitors all volumes on vserver1. Previously, this was also possible with this command: ./check_netapp_pro.pl ‑H filer ‑o volume ‑s vserver1

Since -I can be used multiple times (whereas -s can only be used once), checks such as this are now possible: ./check_netapp_pro.pl ‑H filer -o volume ‑‑svm_in_name ‑I ^vserver1\. ‑I ^vserver2\.

This command enables all volumes on vserver1 and vserver2 to be monitored.  Alternatively, one could write a more compact command such as: ./check_netapp_pro.pl ‑H filer ‑o volume ‑‑svm_in_name ‑I ^vserver[1|2]\.

Using pattern matching with `‑‑include|‑I` and `‑‑exclude|‑X` one could create this check: ./check_netapp_pro.pl ‑H filer ‑o volume ‑‑svm_in_name ‑X ^sales-


### Outlook

Including the Vserver name in the instance name has proven itself to be more useful than expected and other checks might also benefit from this practice. We are also thinking of adopting this setting as the default configuration and thus making ‑‑svm\_in\_name obsolete. As always we appreciate any feedback you might have on this subject.

Service Processor Check
Information about model and version in the head check

Comments