< Quick start: monitor a small networkGetting startedSecurity considerations >
Recommended settings
The settings IPHost is installed with are typical and suit most use cases. However, as soon as monitoring setup grows beyond several monitors, certain settings will require adjustment. The below recommendations can save both time and other resources and provide more efficient monitoring system.
Split resources into groups, use inheritance to assign typical parameters: monitors of the same kind might require similar settings (that includes “State conditions” and “Alerting”). By default, inheritance is enabled system-wide.
IPHost uses hierarchy “All agents > Agent > Host group > Host > Monitor” to group monitors, and provides settings inheritance: for example, to adjust settings for entire hosts in host group, it is sufficient to change corresponding setting(s) for the host group. An example:
Please pay attention that nested host group (namely, “External” – located inside host group “Servers”) is used in the above example. That allows to bring finer control over inheritance.
Inheritance allows to do mass changes over multiple monitors. Avoid using individual monitor settings wherever possible. IPHost supports nested groups; placing hosts of similar purpose/role into the same group makes their further tuning simpler.
Reduce monitoring data retention time: in “Settings > Monitoring”, you can change period to keep monitoring and log data for. In most cases, setting “Store monitoring data” (as well as logs) can be set to 60 days or less. The more is that period, the bigger will become database, the more system resources will use IPHost components. If the only purpose of keeping monitoring data for long periods of time is accessing old performance data, we would recommend to export performance data from monitoring database and keep it as stylesheet (or in other formats). An example:
Adjust polling threads number: for busy monitoring setups, and/or for setups using resource-intensive monitors (such as Web Transaction Monitors, WMI and/or Script or Program – depends on script or program used), setting maximal amount of polling thread is recommended. On “Settings > Monitoring” section, under “System limits”, set “Start at most … polling threads” to the number of active monitors (set to upper limit of 1000, if you have 1000 or more active monitors). This way, you will reduce chances that monitors will have to wait for a chance to be polled. An example of “System limits” for a busy setup:
Relocate monitoring DB backup copies: on “Settings > DB Maintenance”, select a different location in “Backup to” field. When installed, IPHost has no information where to keep monitoring DB backup copies, and the folder where DB resides is chosen. An example:
Note that it is an extremely bad idea to keep both DB itself and its backup copies at the same place: if disk drive fails, there are chances you can lose both monitoring DB and all its backup copies.
Our advice is to either copy the DB backup copies elsewhere (create a scheduled task for that and/or use backup application, such as Duplicati, to transfer backup copies to a different storage. making more than one set of copies is even better.
Reduce polling time reasonably: the default settings, Ping monitors polled every 30 seconds and other monitors polled every minute, can do fine for initial setup, but for real-life cases those can be too frequent.
To begin with, there always are metrics that do not update often. For example, is you usually update an Internet shop once a day, it’s senseless to check for that update more than 2-3 times a day. If every call to Web server page can cause significant load (multiple background DB operations on remote host, for example) and a lightweight TCP monitor exists to check general Web server connectivity, it’s reasonable to poll TCP monitor (trying to connect to HTTP/HTTPS port) frequently – say, every minute – and more resource-consuming HTTP(S) or Web Transaction Monitor less frequently (say, once an hour). That way, you will use lightweight monitor to check for general health often, and resource-consuming one to perform actual, thorough checks, saving system resources on both local and remote hosts. An example:
Monitor IPHost installation health: if monitoring service itself goes down, the entire set of hosts it watched is left unattended. To be sure your monitoring setup is alive, it is recommended to watch the monitoring service status from another monitoring setup. The simplest approach would be to set up another IPHost installation (on different system) and set up monitoring IPHost monitoring service for each other.
Similarly, when remote network agents are used it is recommended to watch every agent’s service health from at least one another agent, to make sure agent’s shutdown will be reported.
Avoid using single notification media: if every notification is delivered via email services, you might have problems if that email service stops or otherwise becomes irresponsible. The entire monitoring setup can become useless if notifications can’t be delivered. An example of Alerting settings for primary mail server:
To handle possible mail primary alerting outage, utilize additional notification channels, for example:
- create notifications using alternate mail server; use it to notify of default mail server downtime or other failures
- use external message processing services (Amazon SNS etc.) and/or messengers (Slack, Jabber, Telegram etc.) to notify you of primary and/or alternate mail servers failure
- attach a GSM modem to computer running IPHost and use its SMS notifications to warn you of connectivity issues (if Internet connection inside the monitored network is broken, notifications are broken, as well)
- setup any external monitoring service (such as Pingdom or UptimeRobot) to watch Internet connectivity from outside
By implementing notification means similar to the steps above, one can significantly reduce chances of monitoring event going unnoticed.
Avoid placing IPHost monitoring on busy system: IPHost may require significant amount of resources when used for larger networks. Fast availability of system resources (CPU, network bandwidth, RAM) becomes crucial.
When resources become scarce and/or system load raises, the below can degrade monitoring setup efficiency:
- false alarms may start to happen (due to connection time raising or connections altogether failing)
- monitoring database working slowly (that can result in data loss)
- monitors polling might get skipped (thus, monitoring setup stops to reflect reality)
The above pieces of advice will help you to keep monitoring setup active, preventing its failure as much as possible. See “Getting started” page for more recommendations.
< Quick start: monitor a small networkGetting startedSecurity considerations >
