Agents Architecture

  This section describes the actual architecture based on a management agent system. Reasons for that choice are the following features, that are provided in an easy to use way (see also [#!ppc99!#]):

However, it is not assumed that agent systems have to be hosted on all machines. As explained in the following, the architecture contains means to cleanly embrace other sources for activity measurement via proprietary or standardized management protocols. Along with the architecture, supplementary information about the prototypical implementation developed in the project is presented. The agent platform chosen is the Mobile Agent Systems Architecture (MASA, [#!ghr99!#]) implemented and developed at our research group for general management purposes. The platform and agents are written in Java, making them independent of the underlying system to a great extent. The inter-agent communication is based on the Common Object Request Broker Architecture 2.0 (CORBA, [#!corba20!#]).

  

Abbildung: Architecture's hierarchy of probes and agents

Regarding the steps of the overall process, the architecture first becomes involved in step iii. The input at that step is a list of objects that play a role in the desired model and lists (for each object) of corresponding real managed objects and measurable activity values. With this information, one or more control agents (see figure ) start the required data collection and domain agents in the managed environment.

Means of collection are:

1.

management agents (in the sense used in management architectures like OSI or Internet management), already in place or to be installed,

2.

proprietary measurement tools (delivered with applications, etc),

3.

special probes, developed and deployed for the purpose of gathering information for this modeling,

4.

or agents of the agent architecture directly capable of measuring through interfaces of the agent system.

As representatives of the first type, the implementation supports access to SNMP agents, currently used to meter CPU activity of hosts and amount of network traffic on IP interfaces. Further implemented are probes of the third type, metering CPU utilization of applications by reading from the `proc filesystem' (as provided by SUN's Solaris, Linux and others). The means of collection should be installed close to the objects that have to be monitored, to avoid unnecessary traffic. On the other hand, not all endsystems are capable of hosting an agent system, or are not allowed to for security or other reasons. In these cases remote monitoring is the preferred choice.

There is no difference, whether (in step 4) the information is gathered to calculate a collective domain activity or directly for the later model generation. Figure shows the same flow of information for both cases. On the left hand side domain activity is calculated, while on the right hand side the information goes directly to the modeler agent.

  

Abbildung: Deployment of probes and agents

The collector agents help to concentrate the flows of data. In figure the collector agent in domain B (like all depicted by white squares without inner symbol, but marked with `*') uses queries to an SNMP management agent on the router and collects data from a probe on its own host. The agent on the other system in the domain directly accesses its host. Further tasks assigned to collector agents are the pre-selection of time intervals containing significant patterns of activity and the normalization of values. These tasks are combined in one agent to reduce the required communication bandwidth. In the example, both agents' data is then forwarded to the domain agent that calculates the resulting domain activity by joining the time intervals and summing up the values in case of overlaps. On the interface towards the modeler the agent behaves just like collector agents. Therefore, the whole domain appears as just one object in the model.

Modeler agents are responsible for the generation of the complete resulting models. The task to decide for each pair whether a dependency exists (in the way it is explained in section ) is performed by one or more neural agents containing the pre-trained neural network. An example model for the scenario is included in figure . All systems except the one hosting the modeler agent and one router are part of the model, however, the systems in domain B are only represented indirectly by one single element. In cases where both modeler and domain agent are present in the same domain (to generate a detailed model and calculate the overall activity for other models), the data collection still must take place only once. The modeler simply queries all information from the domain agent which does not only aggregate the data, but also caches the individual activity time series.