SolGeneos Agent Components and Operation

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

SolGeneos Agent Components and Interactions

  • SolGeneos Agent Service—The entry point for running the application. It is responsible for loading configuration properties as well as initializing and starting router 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 Solace router 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 SolGeneos Agent's health, modify properties, and start/stop a monitor without restarting the agent through JConsole.

SolGeneos Agent Operation

When the SolGeneos Agent application runs, it does the following:

  1. It starts SolGeneos Agent daemon, which loads agent’s configuration properties from config directory listed above.
  2. SolGeneos Agent daemon, in turn, starts one or more agent’s NetProbe services as determined by the agent’s configuration properties.
  3. The SolGeneos 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
    • SelfMontiorCollectingContext—queues and executes the agent’s self-monitoring status and statistics. Using this collecting context avoids unnecessary waiting for SEMP request/reply operations.

    Note:  For the majority of the use cases, it is 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.