Solace Event Management Agent: Discovering What Runs on Your Brokers

The Solace Event Management Agent is an open-source tool that finds out what is actually running on your event brokers. It connects to Solace brokers and Kafka clusters, reads their queues, subscriptions, topics, consumer groups and schemas, and either sends the results to Solace Event Portal or writes them to JSON files. Solace publishes it on GitHub under the Apache 2.0 licence, where it is described as a tool that “discovers event streams flowing through a broker”. It replaced an earlier tool, the event discovery agent, which is now archived.

This page explains what the agent discovers, its two modes, how to deploy it and where to put it on a plant network, and what gets hard. It belongs to the Event Portal overview in the Solace cluster.

Why the Solace Event Management Agent exists

Most event estates are documented from memory. The architect who designed the topic tree left, three integrators added queues, and a Kafka cluster appeared for analytics. A catalogue built from interviews describes what people think is running. The agent describes what is.

That supports two jobs. Discover-first adoption, where an existing estate is imported into Event Portal rather than redrawn by hand, and ongoing audit, where the runtime is compared with the approved design so drift is caught. Solace’s product page frames the second as auditing “runtime environments to ensure deployed configurations remain aligned with design intent” (Solace).

Kafka estates benefit as much as Solace ones. A Kafka cluster that grew around analytics often has hundreds of topics with no record of who reads them. Because the agent reads consumer groups as well as topics, it can show which applications depend on which streams, which is the first question in any migration, retirement or Solace and Kafka integration design. The Apache Kafka documentation explains the consumer group model the agent reads.

What the Solace Event Management Agent discovers

As listed on the GitHub page in October 2026:

Source	What it finds	Tested versions
Solace event broker	Queues and their subscriptions, broker configuration	Not stated
Apache Kafka	Topics, consumer groups, configuration	3.9.1 and 4.1.0 (Docker-tested)
Confluent Platform	Topics, consumer groups	5.5.1 and 7.3.0
Confluent Schema Registry	Schemas	Versions bundled with the supported platforms
Amazon MSK	Kafka topics and consumer groups	Not stated

What is missing matters as much. The list does not include MQTT-only brokers such as those often used for a plant unified namespace, nor IBM MQ, RabbitMQ or cloud pub/sub services. If your plant data enters through another MQTT broker, the agent sees it only once it reaches a Solace or Kafka broker.

Connected and standalone modes

Connected mode. The agent links to Event Portal, scans are initiated from the portal, and the results are uploaded automatically. That populates the runtime model in Event Portal’s Runtime Event Manager, lets you import discovered objects into the design, and drives audits that flag where the runtime and the design disagree.

Standalone mode. The agent runs scans on its own and writes “separate JSON files for each scan type”, which can also be packaged as ZIP archives. Nothing goes to Solace’s cloud. This suits an air-gapped site, a one-off inventory, or a team that wants to inspect exactly what would be sent before connecting anything.

Deploying the agent and placing it on the network

The GitHub page documents four ways to run it: Docker containers (recommended for pushing configuration), a Java JAR with JRE 17 or later, Kubernetes with a ConfigMap, Secret and Deployment, and a plain process for development. The stated minimum is 1 CPU and 1 GB of RAM, so the hardware is not the constraint.

The network is. The agent needs to reach each broker’s management interface with credentials, and in connected mode it also needs a path to Event Portal in Solace Cloud. For a broker inside a plant, we would not open that broker’s management port to the internet. The usual answer is an agent in the plant’s DMZ or site services zone, reaching inward to the broker and outward to the cloud, each through a documented firewall rule. Our article on OT network segmentation in brownfield plants covers the zone model this has to fit.

What an audit finding looks like

Discovery is useful once. Audit is useful every month, because it turns “is production still what we designed?” into a list. The categories below are the kinds of drift a comparison between design and runtime is meant to surface; how Event Portal labels each one is best checked in a trial.

Finding	Typical cause	Why it matters on a plant
A queue exists on the broker but not in the design	Created by hand during an incident or a project	Nobody owns it; it can fill the spool when its consumer is retired
A subscription in the design is missing at runtime	A deployment step was skipped	A consumer, such as a quality system, silently receives nothing
A Kafka consumer group nobody recognises	A new analytics job or a forgotten test	Data is leaving through a path no one reviewed
A schema in the registry differs from the catalogue	A producer changed its payload without a new version	Downstream parsers break at the next deployment

An illustrative scenario: during a line changeover, a controls contractor adds a queue on the site broker to buffer events for a temporary dashboard. The project ends, the dashboard is switched off, and the queue keeps attracting messages. Three months later the site broker’s spool alarm fires on a Sunday. A monthly audit would have shown the queue as undesigned and unowned long before it filled. That is the plain case for running discovery continuously rather than once.

A discover-first sequence

For an estate that already runs, a sensible order is:

1. Inventory the brokers and confirm each is on the supported list.
2. Run standalone first on one broker, read the JSON and decide what metadata you are comfortable sending to the cloud.
3. Create service accounts with the minimum access the scans need, one per broker, and record them.
4. Connect one environment (test, not production) and import what it finds into Event Portal.
5. Clean up the model: name application domains, assign owners, and mark temporary or obsolete queues for removal.
6. Schedule audits in production and agree who acts on drift.

Discovery, import and audit are in Solace’s Accelerate package, not Foundation (pricing), so confirm the package before step 4.

Where it gets hard

• Credentials. The agent needs access to broker management interfaces. Least privilege, rotation and storage of those credentials are your problem.
• Noise. Temporary queues, test topics and abandoned consumer groups all appear. Expect the first import to need pruning.
• Coverage gaps. MQTT-only plant brokers are outside its supported list, so a UNS on another broker stays undocumented by this route.
• Roadmap items are not features. AsyncAPI export, a UI, a plugin framework and more broker types are listed as planned, not delivered.
• Topic-level detail on Solace. Direct-messaging topics that never touch a queue are harder to discover than queue subscriptions. Ask how they appear before you assume completeness.

---

Related: Solace Event Portal · Solace AsyncAPI and the event catalogue · Solace and Kafka integration · OT network assessment · Solace hub