The two main structures in gossips are histories and states. What this monitor really does is to inform you about your system changing its state. Whereas the coder of the serveral Tests defined what a state is. A State has its own meaning in gossips. Through analyzing histories within the scope of a client, a state of a 'measured' system or service is identified. During the runtime of the different tests, gossips measures a system or service. Measuring means the test desides in which state the system or service is. All these measurements are stored in histories and from these histories the state of a client generated. The advantage of the design is that gossips its self never is in a certain state. Many problems that arise when you work with a software that switches into different states do not occur.

Gossips has a distributed intelligence. The monitor software runs on all the hosts join system which is monitored. Each host has its own configuration. As system manager of gossips you classify hosts in groups (e.g. computerroom, subnet, domain,...). In a second configuration file you provide configurations for the previously defined groups. The server builts for all client intern configuration structure and when the clients connect to the server for the first time they maintain they private configuration. As described in last paragraph the clients detect state changes during the system measuring. These variances of state are send to the server where a knowledge base comes into operation.

With the help of a knowledge base you are able to handle the messages that gossips transfers to you via email. The knowledge base is formed through error files. These files build the fundament of the centralized server intelligence. As system manager you are able to describe an occuring error and add a solution to it. When gossips detects a already known error it forwards not just the error to you but also your description and solution. This feature helps you to fix certain problems faster in the future and eases your work.

One easy example it to test wheather a machine is alive or not. To do a test like that you write a probe which 'measures' pings on the particular host. These measurements are registered to the history-object of the probe. This history has a constant length and the oldest measures are popped away. Furthermore you have to write a test which uses the ping_probe to define a state of the host. A test is able to read the history object of the linked probes. The test has a look at the history of the probe and decides if the system has changed its state. In gossips the system has a state but not the gossips itself.

The scheduler object is a queue. The elements in the queue are the probe-objects. The scheduler looks that the probes are executed at the right time. Once a probe is executed the scheduler reinserts and sorts the probe by the time of its next execution. The monitor sleeps after firing a probe until the next has to be fired. When a probe hangs during its execution, the probe is stopped after a timeout and the failure of the probe is reported in its history. The Tests are inserted by the probes into the scheduler. After their execution they are not reinserted by the scheduler.

The example above shows the principle of how gossips work and introduces the main objects in the design: probe, test and scheduler. Each of these objects has its own history where it registers its measurements or calculations. The scheduler has a special history called message_pool. Its special because in this history you can find all the changes of the monitored part of the host. These changes get there through different filter instances. First there is the probe which gathers information and puts it to its history. The test reads these results and evaluates them. If it detects a state change of the system it drops a message in the message_pool.

There are Tests (message plugs) that evaluate the message pool and when they find a new entry in the message pool or a correlation between the messages of the tests, they send a message to the gossips server. The client connects via a tcp socket to the server and first proves it's identity by giving the right response to a given challange of the server (challenge/response module by Luis E. Munoz).