Configuration

The Metrics Service is made of many components all of which are optional. If no components are added the Metrics Service will act as a black-hole with MetricsUpdates writing, but no call-backs or queries returned from the MetricsService (reader). The following types of components can be configured. The specific components are listed in the following sections along with their function, insertion point and module (jarfile).

Metrics Servlets

The following components allow viewing of Metrics through servlets. (See Using Metrics Servlets). The components are in core.jar and should be loaded into the NodeAgent.

org.cougaar.core.qos.metrics.MetricsServletPlugin

Loads the Metric Service Servlets, which are: AgentLoadServlet, RemoteAgentServlet, NodeResourcesServlet, MetricQueryServlet, MetricsWriterServlet,

CPU Load Components

The following components collect metrics about the CPU consumption of Agents. The components are in core.jar and should be loaded into the NodeAgent.

org.cougaar.core.thread.AgentLoadSensorPlugin

Sensor for measuring the CPU load for Agents.

org.cougaar.core.thread.AgentLoadRatePlugin

Converts the raw CPU sensor measurements into Metrics

org.cougaar.core.thread.TopPlugin

servlet for viewing running threads (TopServlet). Also loads the RogueThreadDetector.

Message Load Components

The following component collect metrics about the message traffic into and out of Agents. The components are in the mtsstd.jar and should be load at the insertion point Node.AgentManager.Agent.MessageTransport.Component

org.cougaar.core.qos.metrics.AgentStatusAspect

Sensor for Measuring the message flow into and out of Agents (This Aspect is always loaded in the Base template)

org.cougaar.mts.std.StatisticsAspect

Sensor for measuring the size of messages

org.cougaar.core.qos.metrics.AgentStatusRatePlugin

Converts the raw message sensor measurements into Metrics

org.cougaar.mts.std.StatisticsPlugin

Servlet for viewing raw message sensor counters, which include: StatisticsServlet, AgentRemoteStatusServlet, AgentLocalStatusServlet

Agent Mobility and QuO Components

The following Components pull the topology service to detect when Nodes and Agents move. Also, they offer a service for QuO Sysconds to subscribe to Metrics. They should be loaded in the insertion point Node.AgentManager.Agent.MetricsServices.Component

org.cougaar.core.qos.rss.AgentHostUpdaterComponent

Periodically polls the topology service and updates the internal Metric Service models to keep the Host-Node-Agent containment hierarchy up to date.

org.cougaar.lib.mquo.SyscondFactory

Factory for creating QuO Sysconds which track Metrics.

Persistence Size Components

The follow component measure the memory consumption of Agents. These components are in the core.jar and need to be loaded into every Agent.

org.cougaar.core.qos.metrics.PersistenceAdapterPlugin

Sensor for measuring the Agent persistence size.

Gossip Components

The gossip subsystem disseminates metrics between nodes. (See Using Metrics Servlets). The components are in qos.jar

org.cougaar.core.qos.gossip.GossipAspect

Piggybacks Metric requests and Metric Values on messages. Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component

org.cougaar.core.qos.gossip.SimpleGossipQualifierComponent

Limits which Metrics should be requested or value forwarded Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component

org.cougaar.core.qos.gossip.GossipFeedComponent

Metrics Service Feed for updating metrics from remote Nodes. Load at the insertion point Node.AgentManager.Agent.MetricService.Component

org.cougaar.core.qos.gossip.GossipStatisticsServiceAspect

Collects gossip overhead statistics Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component

org.cougaar.core.qos.gossip.GossipStatisticsPlugin

Load Servlet for viewing Gossip overhead statistics. Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component

RSS-Resource Status Service

The Metric Service need access to configuration files to define the expected network and host capacity. The Metrics-Sites.conf file is required and the Metrics-Defaults.conf file is optional. Example files are in the overlay at …/configs/rss or source in in qos/configs/rss. Also, the data feed with the name “sites” has the special purpose of defining the sites themselves (i.e.subnet masks), so other Metrics Keys should not be put in this conf file.

The cougaarconfig: url scheme means the files are on the cougaar config path. Otherwise, the url is normal and will just down load the conf files. Putting the configuration files on a web server is useful for a cougaar applications which run at a site with a complicated topology. Also, Network and Host management systems can update the files with real data. (Note the conf files are down-loaded only once at startup)

org.cougaar.core.qos.rss.ConfigFinderDataFeedComponent

Two Components should be loaded with the following parameters
"name=sites","url=cougaarconfig:Metrics-Sites.conf"
"name=hosts","url=cougaarconfig:Metrics-Defaults.conf" The insertion point is Node.AgentManager.Agent.MetricsServices.Component

Acme Scripts

Acme rule scripts are available for loading the Metrics Service. The rules are in directory qos/csmart/config/rules/metrics. The rule.txtlist the recommended rules to load the standard Metrics Service. Addition rules must be added in order to measure the length of messages (serialization) and setup the network/host configuration files (rss). The rule directories have the following purpose:

sensors

Adds servlets that look at the raw sensors. These rules do not load any of the Metrics Service runtime, so they should not impact performance. These rules are useful for debugging and we recommended that they should alway be loaded.

basic

Loads the basic Metrics Service which includes some potentially high overhead components, such as the Agent-to-Agent traffic matrix and Gossip.

serialization

The basic MTS serialization rule for measures message length. This rule conflicts with other serialization rules, such as bandwidth measurement, security, and compression. These other aspects must be loaded in a specific order which is explained in the metrics-only-serialization.rule Only one serialization rule should be loaded.

rss

Supplying network and host configuration data to the RSS is very network specific. Each test site has its own rules which tap into the local sources of system information. If you are running at the TIC, you should load the rules in rss/tic