The InterSystems IRIS™ History Monitor maintains a historical database of performance and system usage metrics. Its primary purposes are to:
Provide a performance baseline and help with analysis of performance issues.
Help analyze system usage over time for capacity planning.
This database is defined in the SYS.History
class package and kept in the %SYS
namespace. All of the details of the database structure are published there and the data is accessible through SQL or the normal persistent object access. The class documentation in SYS.History
also contains descriptions of all the individual properties, methods and queries that are available.
The data is generally organized into performance (see SYS.History.Performance
) and system usage (see SYS.History.SystemUsage
) data. The performance metrics are intended to be sampled at short intervals (by default, 30 seconds), and the system usage data at longer intervals (by default, 5 minutes). At the beginning of each day, the individual interval samples are summarized into hourly and daily tables as averages, maximums, minimums, standard deviation, medians and totals. You can select which, if any, of the summary functions are kept for each metric class. The interval and hourly data may be purged automatically after a defined number of days (by default, seven (7) days and 60 days, respectively); the daily summary is intended for long-term analysis and can be purged manually.
This chapter contains the following sections:
All of the collected metrics are defined in four %SerialObject classes in SYS.History
. These same classes are used as the basis for the Interval, Hourly, and Daily databases, so all of the properties are defined as %Numeric
types to allow for decimal values in the summaries.
The performance related metrics are defined in:
The system usage metrics are defined in:
To begin collecting data, you must do the following:
The detailed interval collection of data is defined in two persistent classes:
The corresponding %Monitor
classes must be activated in Application Monitor in order to collect data and build the history data:
System Monitor, including Application Monitor, starts by default in the %SYS
namespace when the InterSystems IRIS instance starts. You can configured other startup namespaces, however. The %Monitor
classes are provided by default only in %SYS
, but can be added to other configured startup namespaces using ^%SYSMONMGR
For each metric property, the system may calculate the average, maximum (high-water mark), standard deviation, minimum, median, or total for each hour and for the whole day. The summary functions are selectable (or may be disabled) for each base class (SYS.History.Performance
, or SYS.History.Database
) and for each summary period class, using the SetSummary()
method of each of the base classes. By default, the History Monitor calculates average, maximum and standard deviation for each class for both hourly and daily summaries.
Since the database is defined as persistent classes, the data is available using standard SQL or persistent object access. Using the SQL browser in the Management Portal is a quick and easy way to see the various SQL schemas/tables that are created, including the individual property values.
You can add user-defined metrics to the History Monitor (SYS.History
Code the Sample()
method to instantiate the class and provide periodic values for each property. This method is called when the interval data is collected.
When you compile your class, it is added as an embedded object to an interval persistent class in SYS.History
. You can choose where and when it is collected using the INTERVAL
parameter provided in SYS.History.Adaptor
class. This selects which interval class it is added to and which %Monitor
class does the collection, as shown in the following table:
User-defined classes are also added as embedded objects to the SYS.History.UserHourly
summary classes. The user-defined metrics are summarized and automatically purged just like the system metrics.
User-defined metric classes become embedded objects in persistent data. You should not change definitions after data collection has started: deleting objects can result in orphaned data; re-defining existing classes or properties can cause already stored data to be misinterpreted.
Content Date/Time: 2019-02-16 01:08:12