The History Monitor maintains a historical database of performance and system usage metrics. Its primary purposes are to:
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 properties in this class are general performance metrics like global references and routine calls.
These properties are all counter types and the interval data is collected as deltas, which represent the change in the counter over the last interval. When this data is summarized into hourly and daily values, the data is normalized to per-second rates
— The properties in this class describe the performance of write daemon cycles. The system automatically keeps track of the last 20 write daemon cycles, and the History Monitor stores the data for the cycles that occurred in each interval. Typically, there are multiple cycles within each interval.
The system usage metrics are defined in:
— The properties in this class track how busy the system is but do not tend to change as quickly or dramatically as the performance data; things like the number of processes in InterSystems IRIS and license information.
— This class tracks the database growth, file size and free space, for each local database.
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.
The counter properties of the SYS.History.Performance
class are normalized to per second rates for these calculations (except Total).
After creating the summaries, Application Monitor automatically purges the interval and hourly databases. The default is seven (7) days for interval data and 60 days for hourly data, but these may be changed using the SetPurge()
method in SYS.History.PerfData
classes. The SYS.History.Daily
data is not automatically purged, but can be done manually using the SYS.History.Daily:Purge()
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.
The are also several Export()
methods provided for each persistent class so that the individual tables can be exported to files in CSV format, suitable for use with a spreadsheet such as Microsoft Excel. In particular, the SYS.History.PerfData:Export()
method creates a file that is very similar in format to that created by the ^mgstat
utility (for more information, see the Monitoring Performance Using ^mgstat
chapter of this guide).
You can add user-defined metrics to the History Monitor (SYS.History
Create a class, or multiple classes, that inherit from SYS.History.Adaptor
and add %Numeric
properties to define the metrics.
User-written classes must be in the %SYS namespace, and should begin with Z or z to prevent naming conflicts with system classes and problems during upgrades.
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:
Selecting UserPerf or UserSys lets you collect data at the same interval and with the same timestamp as SYS.History.PerfData
, which makes it easier to correlate your data with the system data. User gives you a choice of a third (unrelated) time interval.
There are several parameters in the SYS.History.Adaptor
class that provide options for how properties are collected and summarized; for more information, see the SYS.History.Adaptor
class reference documentation.
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.
However, because of the schema evolution
feature, you can safely add new objects and properties. See Schema Evolution
in the Defining Persistent Classes chapter of Defining and Using Classes
Content Date/Time: 2019-08-22 06:48:58