Basic setup: use simple monitors
There are instructions to get started with IPNetwork Monitor, covering most typical situations. However, relying on all default discovery options when looking for hosts and/or monitors can produce a broader initial setup than necessary. In most cases, it is simpler to create lightweight “draft” monitors first, just to make sure the service exists and accepts connections, and then add protocol-specific checks as required. We provide sample instructions below: follow them to create and start your monitoring setup.
The initial monitor set can be added manually or by running a network discovery; after that, typical monitor sets can be copied over multiple hosts or applied through templates. If needed, discovered monitors can also be reviewed before activation instead of being enabled immediately.
Use PING and TCP monitors only
The basic connectivity monitors include PING, TCP and UDP monitors. Unless a response is expected from the target service, using UDP usually does not make much sense, since it will not reliably confirm service availability on its own.
PING monitor reports general device presence; keep in mind that some environments restrict ICMP (including PING) by firewall policy, so TCP may remain the only practical connectivity check. This is especially common in cloud environments unless ICMP is explicitly allowed. Note that under normal circumstances inside a controlled private network, ICMP should not be blocked without a reason.
TCP is a fundamental protocol standard that provides reliable connections. A TCP monitor checks only whether a connection can be established; if more detailed validation is required, other monitor types should be used. This type of monitor can also be used as a dependency monitor: if a certain TCP port must be open under normal circumstances, its state can be used to stop dependent checks and avoid cascading alarms when the service is unreachable.
The above two monitor types are suitable for creating a quick monitoring setup; add detailed checks afterwards as needed. This approach also matches how IPNetwork Monitor templates are often used: start with a small enabled set, then expand the monitor list where deeper visibility is required.
Network discovery
To speed up creating simple connectivity monitors, network discovery can be used both for one-time lookup and for periodic (scheduled) host list updating. IPNetwork Monitor discovery can detect hosts and services across multiple protocols, while still allowing you to begin with a lightweight connectivity baseline.
To look for several possible ports, at “Select monitor types” step of network discovery wizard, click “Ports” field for TCP monitor and enter comma-separated list of ports to scan for.
To map TCP/UDP ports to corresponding well-known services, you can use IANA reference. There’s also a short reference in so called “services” file, located in “/etc” in Unix-like and macOS operating systems, and in “C:\Windows\System32\drivers\etc” in Windows.
Cloning hosts and monitors
Another strategy is this: when several hosts use a typical set of monitors, it may be quicker to create the required set for a single host, and then either
- copy the whole host (along with all its monitors) or selected monitors, as explained in Tree view manual, or
- create an application template and assign it to other hosts, thus applying only the required monitors in a more consistent way
Note: creating a template may be a more flexible approach, since you can replace the template afterwards whenever required. Templates can also create or reuse a PING monitor on the host and use it as a dependency for application monitors.
Conclusion
We recommend starting with a simple monitor set to create monitoring setups more quickly and with less load on the system running IPNetwork Monitor. If you need advice on this, feel free to contact us.