Use intermediate hosts to process multi-source or complex data
Imagine you need a monitor to react to a value derived from several performance values. For example, you may want to trigger an alert only if CPU load and free memory have both crossed certain thresholds.
If those monitors are related to the same host, you can always use generic monitor type, such as Script or Program, Python script etc., and do whatever math is required. One practical detail to keep in mind is that such scripts run under the Monitoring Service account by default, so if they need access to network shares, external tools or a helper environment, corresponding credentials may need to be configured explicitly. What should you do if the performance values can only be taken from different hosts?
There are several solutions.
Get the values directly from monitoring database
The first approach is straightforward. Create corresponding IPNetwork monitors; use a script to extract whatever data they have, process the data and use the result as new performance value.
The advantage of this approach is no additional source, service or host is required to do the processing.
The disadvantages:
- you keep extra (source) monitors; if you are using any license different from Enterprise, that reduces the amount of monitors you can have
- concurrent access to monitoring database can be tricky; if the monitoring setup is rather busy, there can be considerable delays in getting data; also, data may be out of sync with one another
Use third-party services
There are multiple possible services providing a way to aggregate and preprocess data: SaaS (such as Datadog, New Relic etc.) and self-hosted ones (for example, time-series databases). The source data can first be channeled to that service and later extracted by IPNetwork Monitor using a custom script or HTTP(S) monitor type. A newer variation of the same idea is to query IPNetwork Monitor through its built-in MCP API by using a read-only token for status checks and reporting, instead of reading the monitoring database directly.
Advantage: you do not need to spend computing resources to get all the processing.
Disadvantages:
- you keep extra source monitors; on licenses with active monitor limits, that can consume part of your active monitor quota even if the aggregation logic itself is simple
- concurrent access to monitoring database can be tricky; if the monitoring setup is rather busy, there can be considerable delays in getting data; also, data may be out of sync with one another
Offload the processing to virtual machine
This approach resembles, to some extent, the previous one. However, you do “quick and dirty” processing, using virtual machines (VMs) or Windows Subsystem for Linux to do the work.
Advantage is relatively low resources amount required to do such processing: most simple performance values can be obtained from Linux-type environment, using a variety of existing pre-installed tools.
Disadvantages include:
- you still need to install and configure the VM or WSL instance
- you would need to write the “wrapper” scripts that get the required data and process them as required
One of the advantages of WSL is the ability to exchange data directly with its Windows host (i.e. the system where IPNetwork Monitor is running). This can save time and resources of IPNetwork Monitor by offering already processed, easy-to-read performance data. At the same time, if such helper scripts are launched directly from the monitoring service, it is worth remembering that default SYSTEM-based execution may not be suitable for every WSL scenario, and SSH into WSL can be a better option in some environments.
Final comments
What is your preferred way to proxy the performance data when you need to do complex processing and/or aggregating them?
If you need assistance implementing any of the proxying approach mentioned above, or if you have any idea to offer, feel free to contact us.