You can use the service when developing applications to make sure that there are sufficient resources to maintain your application over time. The information obtained by the service can in some cases be translated to histories for tracking over time and can cause the generation of alarms on monitor specific error conditions or limits.

Using the System Monitor Service is not recommended in every production environment since it consumes resources (in the form of histories and heap memory) . Instead, it is best used on a single device in a population as a sample. It can be useful for confirming memory leaks on a platform where you suspect one might exist, or if you wish to determine high water marks for the NRE Configuration.

Figure 103.   System Monitor Service properties

This service and the monitors it provides are mostly implemented in Java and can be used on both Supervisor and JACEs, both Niagara products and Niagara Portability Software Development Kit (NPSDK) products. However, the Socket State Monitor is used specifically with Tridium JACE devices, and the RAM Disk Monitor, which is only for embedded devices that uses a RAM disk for alarm and history records. The Socket State Monitor is further specific to the Tridium JACE since it is tied to the netstat, an application that is only available through the Tridium spy.

While these monitors are valid for Supervisors, they are probably of lesser value in those environments since resources on Supervisor tier platforms are expected to exist in abundance. IFor example, it might be of little value to monitor something like the System Memory on a Supervisor platform because it may have multiple gigabytes of space. However, you can elect to monitor this if you choose.

The System Monitor Service may be of particular value in any embedded controller, including third-party controllers, that elect to use the NRE Configuration View, to control the size of various memory pools.

Figure 104.   Platform Administration tool, the NRE Configuration View

When dealing with the pools defined here, space not actually used is space wasted. If you can use the associated monitor (i.e., Heap Memory Monitor, Meta Space Memory Monitor, Code Cache Memory Monitor, RAM Disk Monitor) to determine that you are not actually utilizing the amount of space you’ve reserved, then you can confidently lower that pool’s size as a means of providing memory for some other pool. For instance, if the Meta Space Memory Monitor shows the allotted memory is only half utilized in a long running station, then you can safely reduce the size of that pool to free up memory for the Heap Space or System Reserve.

For more details, see documentation that is in the NPSDK.

Usage notes

When added to station Services, the System Monitor Service is enabled by default. For any of the monitors provided by the service, there is no “Enabled” state. The monitors are either present and collecting, or absent. If you do not wish to monitor a particular pool, delete the corresponding monitor from the service.

In general, configurable properties for any monitor are context specific to the monitor and self-explanatory. Exceptions are the Generate Alarm and Log Memory to History properties which are described in the following sections.

Generate alarm

For any monitor that supports limit properties like Minimum System Memory Limit (System Memory Monitor) or Minimum Heap Memory Limit (Heap Memory Monitor), the Generate Alarm boolean will indicate that an alarm should generate when this limit is crossed. For example, if Free Heap Memory were to drop below 512K ( or other specified number) when polled, an alarm should be generated to indicate the event occurred.

The generated alarm uses the relevant alarm information (Alarm Source Info, etc.) associated with any particular monitor.

The Generate Alarm action for the different monitors works as follows:

Log Memory to History

The history for any particular monitor follows the rules as defined in the monitor’s History Config, allowing you to configure retention policies, capacity, tags, etc., as with any history extension. The intervals of these configs should be kept at the default so that the history is always generated as a consequence of the Check System action.

The Log Memory to History action for the different monitors works as follows: