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).
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.
- 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.
- Sensor for measuring the CPU load for Agents.
- Converts the raw CPU sensor measurements into Metrics
- 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
- Sensor for Measuring the message flow into and out of Agents (This Aspect is always loaded in the Base template)
- Sensor for measuring the size of messages
- Converts the raw message sensor measurements into Metrics
- 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
- Periodically polls the topology service and updates the internal Metric Service models to keep the Host-Node-Agent containment hierarchy up to date.
- 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.
- Sensor for measuring the Agent persistence size.
The gossip subsystem disseminates metrics between nodes. (See Using Metrics Servlets). The components are in qos.jar
- Piggybacks Metric requests and Metric Values on messages. Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component
- Limits which Metrics should be requested or value forwarded Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component
- Metrics Service Feed for updating metrics from remote Nodes. Load at the insertion point Node.AgentManager.Agent.MetricService.Component
- Collects gossip overhead statistics Load at the insertion point Node.AgentManager.Agent.MessageTransport.Component
- 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)
- Two Components should be loaded with the following parameters
"name=hosts","url=cougaarconfig:Metrics-Defaults.conf"The insertion point is Node.AgentManager.Agent.MetricsServices.Component
Acme rule scripts are available for loading the Metrics Service. The rules are in directory
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:
- 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.
- Loads the basic Metrics Service which includes some potentially high overhead components, such as the Agent-to-Agent traffic matrix and Gossip.
- 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.ruleOnly one serialization rule should be loaded.
- 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