Concepts

IxoraRMS is a performance and resource monitoring tool, designed to present heterogeneous data, collected from various sources, in a graphical way. In IxoraRMS data is collected by Agents and passed to the Console to be displayed or to be recorded for later playback.

There are two main modes of monitoring using IxoraRMS and choosing one over the other depends whether Host Manager can or needs to be installed on the target machine.

Agent based monitoring

Agent based monitoring means that the Host Manager component is running on the monitored host and agents are deployed in 'Remote' mode. Use this method only if necessary as it usually consumes more resources on the monitored system.

Agent-less monitoring

This is the preferred way to monitor a system as it usually is more efficient. Depending on the platform and the type of application being sampled, some application-specific client tools may be required; an example would be DB2 and Websphere. Others will only require configuring permissions to allow remote access, as is the case when retrieving Windows information through the Remote Registry service. Process-based providers may also be created to execute command line tools through the rexec utility or via telnet or ssh2 sessions.

Monitoring Agents (or simply Agents)

Agents have the responsibility of collecting data from various sources and making it available to the Console. Depending on the type of application or system being monitored, an agent can perform its data-collecting duties in two modes:

  • Local: the agent itself is run locally and collects data through the network from the monitored system.
  • Remote: Host Manager must have been installed on the monitored system. The agent will run on the remote host and will use Host Monitor to send data to the Console.

Agents are shown in the Console as nodes under the host node that corresponds to the host being monitored.

Monitoring Entities (or simply Entities)

A monitoring entity is a provider of monitoring data in the form of monitoring counters. Entities are usually organized in hierarchies and are shown in the Console under agent nodes.

Monitoring Counters (or simply Counters)

A counter represents a single value that characterizes an entity. The type of the value can be string, a double, a long, a date or a generic object. Counters are shown in the Console as properties of selected entity nodes.

In the figure above you can see entities of the Windows agent, as well as the counters for the selected entity (Processor).

An agent will return data only for the counters which are enabled. To enable counters, click the checkbox next to them, then click "Apply". Enabling counters is also required for recording a session log: only data for enabled counters will be recorded. Note that when enabling a view or a dashboard all required counters are automatically enabled. This is also true for views which use regular expressions.

Counters can also be enabled by right-clicking any entity of an agent and selecting "Enable All Counters" or '"Enable All Counters Recursively". The recursive option will also enable all counters of all child entities. Dynamic counters (created during a monitoring session) will be created enabled if their parent entity was enabled in this way.

Providers

Providers are extensions or building blocks for custom monitoring. Their role is to collect small pieces of data in a very simple form and send it to the Console where it will be parsed and inserted into a hierarchical structure.

There are three types of providers that can be built:

  • Process: the monitoring data is extracted using external processes.
  • SQL: the monitoring data is extracted using a database connection and SQL statements.
  • Java: the monitoring data is extracted using custom Java code.
  • JMX JSR 160: the monitoring data is extracted using JMX from clients implementing the JSR 160 specification.

For more information on providers see "Custom Monitoring".

Host Manager

A Host Manager provides an environment for agents to run in, and acts as a gateway to the Console.

Install the Host Manger on a monitored machine only if you cannot run the agent in 'Local' mode(this usually happens when client side libraries are required but not available on the Console but note that some agents like the Log File Monitor will always require a Host Manger to be running on a remote host).

Even without any agent enabled a Host Manager will provide a few information elements about the host it runs on. This information (operating system version, architecture and time difference between the host and Console) can be seen by selecting the host node in the session tree.

When started, Host Manager will detect all available network interfaces and will prompt you to select the one to use.

Console

All control and display functions of IxoraRMS are available from the Console. Data from all hosts and all agents is presented in a hierarchical layout and can be displayed on screen, or can be recorded in a log file.

Individual performance counters from each agent can be plotted on charts, tables, properties or dedicated viewers. More complex queries can also be defined, grouping multiple counters from different agents or different hosts on the same chart or table. A powerful syntax is provided for specifying counters to be plotted, described in more detail under "Defining Custom Views".

As described under "Custom Monitoring", user-defined agents and providers can also be created from the Console, and can be used along with the built-in agents.

For ways to create rules that trigger alerts and various reactions see "Reactions and Alerts".

Monitoring Session

In IxoraRMS all information related to a monitoring sesion (hosts, activated agents, counters plotted and so on) can be saved together as a session file (*.rmss).

When restoring a session IxoraRMS will attempt to connect to the same hosts and enable the same agents, while restoring the screen layout with all charts visible at the time when the session was saved.

Saving sessions is a convenient way to manage all your lists of hosts and configuration (such as database connection parameters etc) for each one.

Monitoring Session Tree

Monitoring data is represented in the console in a hierarchical format, using a tree widget. This is referred to as the Monitoring Session Tree.

Sampling Interval

Data is collected regularly from agents, with a frequency controlled by the Sampling Interval parameter.

The Sampling Interval is typically adjusted at Monitoring Session level by changing the value on the application toolbar. This value is propagated and used by all agents, unless overridden at agent or entity level.

This setting can be overridden at an agent level by unselecting the "Default" interval checkbox. More complex agents also allow adjusting the sampling interval per entity.

You can also configure an entity to update its children periodically. Right click on the entity and from the context menu choose "Refresh Schedule". Note that this action might not be available on every entity. In the dialog box enter a value which will represent the number of sampling intervals between entity update operations.

Once a refresh schedule was set for an entity a refresh icon will upear next to it like in the following example:

Note that certain entities are not able to refresh their children and in such circumstances the schedule is set on the first ancestor entity or agent able to refresh its descendants. In this case a refresh icon will be shown for both the original entity and its ancestor.

Monitoring Level

For certain agents (only WebSphere so far) the monitoring level can be specified at agent or entity level. The monitoring level controls the amount and type of data that will be collected by the agent. By lowering the monitoring level you can reduce the impact of monitoring on the monitored system. This allows the user to control the volume of information displayed, with higher levels resulting in more entities and counters present in agent's tree. If this is supported, markers will be displayed next to each entity to show the current level. Options are provided to control monitoring level per each entity, per subtree or per entire agent.

Identifiers

It is important to note that names of entities and counters as displayed on screen are human-readable, localized names. These names don't always match the real identifier used underneath by the application. This untranslated name must be used when defining custom views. To reveal these identifiers select "Toggle Identifiers" on the "View" menu or press Ctrl + I.

Resources

A resource in IxoraRMS's terminology is any artifact that belongs to a node in the monitoring session tree. Examples of resources are: entities, counters, views, dashboards,...The user needs to be able to reference on a regular basis entities and counters in order to build data views.

Resource selector (rid)

The concept of a resource selector is used to specify a way of selecting one or more resources. Rid is the short name for resource selector and it might be used occasionally throughout documentation.

A resource selector uses a simple syntax that contains up to four parts separated by the slash ('/') character:

<host>/<agent>/<entity_path> - to reference an entity

<host>/<agent>/<entity_path>/[<counter>] - to reference a counter

where:

<host> - is the name of the host

<agent> - is the identifier of the agent

<entity_path> - is the entity path which in turn has a similar syntax to the resource:

<entity_path_element_1>/<entity_path_element_2>/.../<entity_path_element_N> where entity path can contain any combination of characters

In an entity path, the first element (<entity_path_element_1>) must always be root.

[<counter>] - is the counter name. The counter part of the resource must be enclosed in square brackets.

The following is an example of a resource selector that identifies the 'Disk Writes/sec' counter of the 'LogicalDisk/C:' entity of the 'Windows' agent on machine 'localhost'. See the image to the right to see the actual entity identified in the monitoring session tree.

localhost/agents.windows/root/LogicalDisk/C:/[Disk Writes/sec]

Relative resource selector

Relative resource paths can also be used and they are ubiquitous throughout IxoraRMS.

Artifacts can be created at different levels (host, agent or entity level) in the monitoring session tree. All artifacts are aware of their location, and if host or agent names are not specified, the current values will be used. Rewriting the example above:

-/-/root/LogicalDisk/C:/[Disk Writes/sec]

Assuming this resource selector was used in the definition of an artifact (usually a view or a dashboard) under an entity of the Windows agent, when the artifact is plotted it dynamically completes the path with the real names of the host and agent it was plotted from. This allows the same query to be reused on different hosts, or on different agent instances.

Regular expressions based resource selector

Resource selectors are used to select not only one resource but a group of resources that match a set of regular expressions. To achieve this, all components in the resource selector definition (<host>, <agent>, <entity_path>, [<counter>]) can contain regular expressions. The syntax requires that any component that must be treated as a regular expression has to be surrounded in round brackets ("()"). The same syntax rules apply for the entity path elements. Note that you can not specify a regular expression that encompasses more than one entity path element.

Examples:

1. This example is from a view defined for the WebSphere agent that selects all avgUseTime for all connection pool modules in all application servers. The view is defined at the agent level.

-/-/root/(.*)/(.*)/connectionPoolModule/(.*)/(.*)/[connectionPoolModule.avgUseTime]

2. This example is from a view defined for the Windows agent that selects the "% Registry Quota In Use" from the System entity. The view is defined at the System entity level.

-/-/-/[% Registry Quota In Use]

3. This example is from a view defined for the Windows agent that selects the "% Processor Time" for all processes in the system (excluding the Idle process). 

-/-/root/Process/((?!Idle).*)/[% Processor Time]

Resource XML syntax

This is the XML syntax for specifying a resource (the highlighted section contains optional elements):

<resource id="" rid="" name="" description="" iname="" code="" format="" type="" min="" max="" style=""/>

where:

  • id - mandatory. It is a short unique id to be used as reference for the resource.
  • rid - mandatory. The resource selector as described above.
  • name - optional. The text to be displayed as the name of this resource.
  • description - optional. The descriptive text for this resource.
  • iname - optional. The instance name, designed to have different values for each entity matched by a regular expression based selector. It uniquely identifies one resource that matched the regular expression based selector.
  • type - optional. It can be one of 'string', 'number' or 'date'. Used to determine data type for the value returned and to choose the appropriate rendering. It is used in general to override the native type of the counter(for instance to display a long value as a date).
  • format - optional. The format specifier used when displaying values provided by this resource (see "Formatting Syntax").
  • code - optional. Java code (body of a Java function) to be executed with this resource as an input parameter. This is a shorthand for creating a function in-place when the only parameter of the function is the value of the counter selected by this resource.
  • style - the style this resource inherits.
  • min - the minimum value expected.
  • max - the maximum value expected.

Resource style

All the optional elements in the XML syntax of a resource are referred to as the style of the resource. There values affect the way the resource is represented in different controls.

The most important style attributes are name and iname. The name attribute represents the name of the resource, it has to make sense for all matches provided by the resource selector. The iname represents the instance name if that particular match for the resource selector.

When defining name and iname attributes in a resource, the following tags can be used, and will be replaced at execution time with the appropriate values:

  • $host - the name of the host where this value comes from
  • $agent - the name of the agent which generates this value
  • $entity - full path of the entity
  • $entity[n] - element n in the entity path (0-based)
  • $counter - the name of the counter
  • $1,...,$n - can be used as placeholders for regular expression groups

Example of values for the name and iname style attributes:

1. In this example, the resource gets the same name as the counter ('% Processor Time') and all individual matches selected by the regular expression selector rid will be named '<host_name>/Process/<process_name>/% Processor Time'.

<resource id="proctime" iname="$host/$entity[1]/$entity[2]/$counter" name="$counter" rid="-/-/root/Process/((?!Idle).*)/[% Processor Time]"/>

2. In this example, the resource is named 'Processes' and the instance name is just <process_name>. This resource can be used as the category for a table view or the domain values for a bar chart.

<resource id="id0" iname="$entity[2]" name="Processes" rid="-/-/root/Processes/(.*)"/>

Functions

Functions in IxoraRMS are operations that are applied to one or more counters in order to create a virtual resource that can be used in data views and reactions. For a list of all available functions in IxoraRMs see Functions.

Queries

Queries are used to select counters from the monitoring data stream. The Query object is the part of the View definition that specifies what data needs to be collected and processed before being displayed. Resources, functions and reactions are defined together inside a Query. There is a very important constraint when writing queries: all the resources in the query definition that use regular expression based selectors must have identical selection criteria (i.e. identical regular expressions).

Syntax:

    <query>
        <resource id="" rid=""/>
        ...
        <function op="" id="">
            <param id=""/>
        </function>
        ...
        <reaction params=""...>
        ...
        </reaction>
    </query>


Multiple <resource>, <function> and <reaction> tags can be specified.

In the example below a query is shown in the definition of a view using a query without regular expression based selectors.

In the second example below the query uses regular expression based selector (Notice that the selection criteria constraint mentioned above is satisfied)

Data Views (or simply Views)

A very powerful feature of IxoraRMS is the ability to group related counters, together with graphic display hints, into a single View object, easy to plot with one click. A view can group counters from the same agent entity (eg: Disk Reads, Disk Writes for a PhysicalDisk entity), different entities as well as counters across multiple hosts (eg: Disk Reads for all monitored hosts). A view is defined mainly by a query that selects the monitoring data and information about how to present this data to the user.

Controls (or Widgets)

A control is the GUI widget associated with a data view. This name is used sometimes throughout the application and this documentation when referring to a data view in a GUI context.

Dashboards

Along with Views there are Dashboards, which are groups of views and individual counters that can be plotted together, making it easy to display all relevant performance metrics for an entire system

Both views and dashboards can be found at any level in the monitoring session tree.

Views and dashboards can also be customized or created from scratch, see "Defining Custom Views".

In the example below the definition of a dashboard is shown as XML.

Data View Boards (or simply Boards)

A board is a widget that groups together data views of the same type (charts, tables, properties...). A board contains a maximum, configurable, number of data views; when this number is reached a data view is plotted on a new board. All data view boards are grouped together in data view screens (see below).

Data View Screens (or simply Screens)

To control the volume of information shown at a time on the screen, data view boards can be group under a Data View Screen and shown or hidden together. IxoraRMS creates an initial screen; more screens can be created later by using the tool bar controls.

Monitoring Agent Version

The monitoring agents can have different versions, depending on the version of the targeted monitored system. The meaning of the version when referring to an agent is, at all times throughout IxoraRMS, the version of the targeted monitored system. As an example, the DB2 agent has versions 8.1, 8.2, 9.*, corresponding to the versions of the supported monitored DB2 system.

Monitoring Session Artifacts

Monitoring artifacts are pieces of data that are attached to nodes in the monitoring session tree (session, host, agents and entities).

Types of monitoring artifacts:

  • Data view
  • Dashboard
  • Provider

The artifacts attached to agents or entities can be assigned to one or more agent versions.

Reactions and Alerts

In IxoraRMS it is possible to define complex rules for triggering reactions such as visual alerts, emails, jobs and advices. For more information see "Reactions and Alerts" and "Jobs".

HTML Generation

In IxoraRMS it is also possible to generate a HTML page with all the data available in the current monitoring session; the HTML generator can be set to refresh the generated data periodically. For more information see "HTML Generation".

Non-Interactive Monitoring Session

You can also start a monitoring session in a non-interactive manner using

batchStart.bat(sh) [sessionName] [logFile]


where the two parameters are the monitoring session name and the log file where monitoring data will be stored. To stop a session started with batchStart you must run batchStop.bat(sh).