Reuse and inherit

if you happen to monitor a small network, your task may be rather simple. A few monitors can be either generated via network discovery, or added manually. Same is true about setting up alerts. A few of them can’t be too difficult to setup.

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, IPHost has been designed to reuse same settings – by inheriting them and by using templates. A few guidelines follow.

Inheritance

All the objects in IPHost 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 details in our online help. By using nested host group, one can establish very flexible assigning similar settings to the monitors of the same logical group. For example, one can create a specific host group to unite hosts related to the same data center, and use inheritance to use alerts sending notifications to specific contacts only for the hosts of that group. That will also allow redefining inherited settings: as soon as they are changed, all the entity inheriting it begin to use the new setting value.

Variables

If you open a default “Send mail” simple action in its editor (see “Settings > Alerts > Simple actions” in IPHost 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 IPHost 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 have been introduced in IPHost. The topic itself is rather vast; templates can be created manually from arbitrary amount of existing monitors. To facilitate sharing the templates, we have set up its own community site (it can also be directly accessed – templates read and posted – directly from IPHost GUI client).

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, using the forms below, or by contacting us directly.