Reuse and inherit
If you happen to monitor a small network, your task may be rather simple. A few monitors can be generated via network discovery or added manually, and a small set of alerts is usually manageable as well.
However, when you either need to create many monitors, or adjust settings for multiple monitors, the task might seem significantly less attractive. Changing the same setting for multiple monitors may become a nightmare, if you have hundreds of them. Fortunately, IPNetwork has been designed to reuse same settings – by inheriting them and by using templates. A few guidelines follow.
Inheritance
All the objects in IPNetwork monitoring setup are located within the same hierarchy: root (“All Agents”), agent, host group (may be nested), host, application template (optional; see also below) and, finally, monitor. Most common parameters (such as credentials, polling time, dependency monitor etc) are, by default, inherited from the parent element of the hierarchy. Every single parameter of every element of the hierarchy can be defined separately; along with inheritance, that allows quickly assign specific settings for given object – and equally quickly to re-establish inheritance (up to every child object – i.e., monitor).
You can learn about inheritance in more detail in our online help. By using nested host groups, one can assign similar settings very flexibly to monitors belonging to the same logical group. For example, you can create a host group for systems in the same data center and use inheritance so alerts for that group notify only the relevant contacts. This also makes later changes easier: once a shared parent setting is adjusted, all child objects that still inherit it immediately use the new value.
Variables
If you open a default “Send mail” simple action in its editor (see “Settings > Alerts > Simple actions” in IPNetwork Monitor GUI client), you will notice quite a lot of so called template variables; they contain settings data for context, and are replaced with their actual values before the setting is actually used.
For example, the $AdminMail string is replaced with actual administrator (primary) email address, used both in default alert, and to notify of any important events (such as database problem, license expiration, planned reports etc).
One can find full list of available variables in IPNetwork online help. Note that they can be used in rather unusual way: if, for example, monitor name contains user part of email address, and the “Send mail” simple action for that monitor’s alert contains address like “$MonitorName@example.com”, then every such monitor will send notifications to its specific email address.
Application templates
Finally, we have a case when same set of monitors should be assigned to many a monitor. When there are few monitors, they can be copied using “Copy” item of the context menu. Multiple monitors can be copied that way to multiple hosts.
However, we might need more control and flexibility. For example, certain monitors should only be enabled if target host possess certain function; for example, we might wish to add mail server specific monitors only if the host is running a mail server.
To address such issues, application templates are used in IPNetwork Monitor. Templates can be created from existing monitors, grouped by category, and selected in the New Monitor Wizard together with single monitors. They can also be filtered by keyword, protocol, or resource type, which makes them much easier to find in larger environments. It is also worth remembering that some template monitors may require manual parameters before they are ready to start, so reviewing the template after applying it is still a good practice.
Conclusion
Use the above mentioned means to create and modify monitoring setups quickly and easily. Wherever possible, use inheritance; build host groups hierarchy to group logically close hosts; use application templates to create and copy multiple monitors across same type hosts.
Questions? Comments? Feel free to leave us comments by contacting us directly.