Template categories
An application template is a ready-made bundle of monitors that you can create together in one step. When you apply a template, it becomes an “application” in IPNetwork Monitor, shown as its own node in the main tree. These application monitors run a coordinated set of checks for a particular host or application class—such as Windows Servers, Microsoft Exchange, Apache or IIS web servers, Oracle database servers, and more. Using templates helps you build and maintain a consistent monitoring setup with less manual work.
Templates are also used during discovery. In the Discovery Wizard, you can choose which application templates should be considered when scanning a network. Each template includes criteria that determine how discovery handles a host. When a host matches those criteria, the corresponding template is applied.
IPNetwork Monitor ships with several predefined template classifications, and you can easily create new ones when needed.
List of Template Classifications
Description of Template Classifications
These template classifications are predefined:
Server Health Checks templates include the common monitor types used to evaluate overall server health. After tuning thresholds to match your environment, any failure in the recommended set should be treated as urgent and investigated immediately.
Domain Controllers templates help validate Windows domain deployments by checking core roles and services. Domain infrastructure supports authentication, directory functions, and internal service communication; trouble in any of these areas can impact the entire local network.
Mail Servers templates confirm availability and key security mechanisms for mail systems—typically SMTP/POP3/IMAP4 services, including MS Exchange.
Web Servers templates track health and key indicators for common web servers (for example, connection counts and resource usage). Use the most specific template available; fall back to generic templates only when a server type isn’t explicitly covered in this category.
Database Servers templates cover a range of database engines (MySQL, MS SQL, etc.), checking operational metrics along with connectivity and overall service health.
Virtual Machines templates validate the status and integrity of both hypervisor hosts and guest systems. Note: guest checks here don’t rely on “standard VM access”; the guest is treated as an application running on the hypervisor host.
Other Applications And Services templates include services that don’t fit into the categories above, such as SharePoint or Memcached.
Monitoring Usage Scenarios
- Templates provide a standard baseline of monitors. A built-in template’s name typically indicates the intended use—choose the closest match whenever possible, and use a generic template only when no specific template applies.
- If none of the existing templates fits your needs, create a new template with the exact monitors you want. Give it a clear, descriptive name so its purpose is obvious later.
Monitoring Best Practices
- If your alerting email relies on domain authentication, you can lose notifications when domain authentication fails. To reduce this risk, consider installing a secondary, local mail server on the IPNetwork monitoring computer. For the same reason, avoid using intranet email as the only notification path; prefer an external email service.
- Use two independent outgoing mail servers (MTAs) so delivery can continue if one becomes unavailable or unreachable. A locally installed MTA can serve as a fallback and keep copies of monitoring messages.
- Monitors that test secure transmission using SSL v2/v3 should be used only for legacy devices that still require outdated protocols. Otherwise, favor the strongest ciphers your environment supports. See the Mozilla SSL Configuration Generator (or a comparable tool) for guidance.
- When tracking resource usage for web or database services, avoid aggressive polling—especially in production. If you run database consistency checks, keep queries lightweight and run them at a conservative interval.
- Reduce monitoring overhead by checking an easy-to-read resource rather than repeatedly probing a heavy service endpoint. One approach is to update a simple status file at regular intervals and have monitors read that file. For example, command-line MySQL tools can run basic checks and write results to a local text file, making subsequent verification faster and less intrusive.
- If IPNetwork Monitor runs inside a virtual machine, deploy a second IPNetwork Monitor instance on separate hardware to monitor the VM’s health. That way you can still receive alerts if the VM—or its host—fails.