Solace Geneos Agent Components and Operation

Solace Geneos Agent is a Java process that runs as service on the supported platform. The figure below provides a high level view of Solace Geneos Agent components and their responsibilities.

Solace Geneos Agent Components and Interactions

Illustration depicting the concepts described in the surrounding text.

  • Solace Geneos Agent Service—The entry point for running the application. It is responsible for loading configuration properties as well as initializing and starting event broker service, NetProbe services, and monitors.
  • NetProbe Service—Responsible for monitoring a NetProbe’s state and reporting data to the NetProbe using XML-RPC.
  • Monitors—Each monitor is in charge of collecting and updating one or more data views by interacting with the event broker through SEMP and NetProbe services. For example, AlarmsMonitor is used to populate AlarmsStats data view.
  • JMX Agent—All the components can optionally register configuration properties, statistics, and operations with a JMX (Java Management Extensions) agent. Registration allows administrators to monitor the Solace Geneos Agent's health, modify properties, and start/stop a monitor without restarting the agent through JConsole.

Solace Geneos Agent Operation

When the Solace Geneos Agent application runs, it does the following:

  1. It starts the Solace Geneos Agent daemon, which loads the agent’s configuration properties from the config directory listed above.
  2. The Solace Geneos Agent daemon, in turn, starts one or more of the agent’s NetProbe services as determined by the agent’s configuration properties.
  3. The Solace Geneos Agent daemon also creates three default threading contexts (each contains one thread):
    • DefaultCollectingContext—queues and executes data polling tasks, generally SEMP related operations
    • DefaultReportingContext—queues and executes data reporting tasks, generally NetProbe related operations
    • SelfMonitorCollectingContext—queues and executes the agent’s self-monitoring status and statistics. Using this collecting context avoids unnecessary waiting for SEMP request/reply operations.

    For the majority of use cases, it's recommended for monitor developers to use the above contexts.

  4. Based on specific global and monitor properties, the agent starts a Monitor Timer thread shared by all monitors, initializes and starts the default monitors that are bundled with the agent load, and then initializes and starts user developed monitors from the monitors directory listed above.