Advanced OMEGAMON Data Broker configuration examples

Advanced OMEGAMON® Data Broker configurations consist of combinations of single or multiple stores, sinks, and forwarders.

The examples presented here show archetypal configuration patterns in separate instances of OMEGAMON Data Broker. Actual configurations can be more complex than these examples, combining multiple basic and advanced configuration patterns in a single instance of OMEGAMON Data Broker.

These examples use the term multiple to mean two or more. For example, where an example shows two instances of a store, sink, or forwarder, you can specify more. The examples show only two instances for conciseness.

For store, sink, and forwarder IDs, use a naming convention of your choice. These examples use STOREn, SINKn, and FWDn. You can either use this generic naming convention or your own naming convention that is specific to your environment.

For consistency, modularity, and ease of maintenance, consider using reusable sink parameters rather than forwarder-scope sink parameters for all sinks, even if none of the forwarders use the same sink.

Example: Forwarding the same data to multiple instances of OMEGAMON Data Connect

Figure 1. OMEGAMON Data Broker advanced configuration: one store, two forwarders, two sinks
Multiple forwarders can use the same store. Each forwarder can send to a different sink.

There are various reasons why you might want to forward the same data to multiple instances of OMEGAMON Data Connect. For example:

  • Different teams in your organization might want to independently manage their own instances of OMEGAMON Data Connect without affecting, or being affected by, other teams. Each team can change the configuration of OMEGAMON Data Connect according to their own requirements and restart OMEGAMON Data Connect according to their own schedule.
  • If your organization uses OMEGAMON Data Provider to make data available to multiple destination analytics platforms, then, instead of configuring a single instance of OMEGAMON Data Connect that sends data to all destinations, you might decide to use a separate instance of OMEGAMON Data Connect for each destination. Similar to the previous point about a team-based approach, this destination-based approach enables your organization to change the configuration of OMEGAMON Data Connect and restart OMEGAMON Data Connect according to the requirements of each analytics platform, without affecting others.

The following example configures OMEGAMON Data Broker to send data to two instances of OMEGAMON Data Connect, both running on the same z/OS® instance as OMEGAMON Data Broker (localhost), but listening on different ports:

ZWES.PLUGIN.KAY.ZISDYNAMIC=KAYSISDL
ZWES.PLUGIN.KAY.CIDB=KAYB0001

* Store
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON

* Sinks
KAY.CIDB.SINK.SINK1.HOST=localhost
KAY.CIDB.SINK.SINK1.PORT=15351

KAY.CIDB.SINK.SINK2.HOST=localhost
KAY.CIDB.SINK.SINK2.PORT=15352

* Forwarders
KAY.CIDB.FWD=ON

KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1

KAY.CIDB.FWD.FWD2.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD2.SINK=SINK2

Example: Forwarding data from multiple stores to the same instance of OMEGAMON Data Connect

Figure 2. OMEGAMON Data Broker advanced configuration: two stores, two forwarders, one sink
Multiple forwarders can use the same sink.

Different data sources can write to different stores. You can choose to forward data from each store to separate instances of OMEGAMON Data Connect or to the same instance of OMEGAMON Data Connect.

If you want to analyze data from multiple sources in the same destination analytics platform, then you might choose to forward data from multiple stores to the same instance of OMEGAMON Data Connect, which then makes all the data available to that analytics platform.

ZWES.PLUGIN.KAY.ZISDYNAMIC=KAYSISDL
ZWES.PLUGIN.KAY.CIDB=KAYB0001

* Stores
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON
KAY.CIDB.STORE.STORE2.NAME=SOURCEB

* Sink
KAY.CIDB.SINK.SINK1.HOST=analytics1.example.com
KAY.CIDB.SINK.SINK1.PORT=15351

* Forwarders
KAY.CIDB.FWD=ON

KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1

KAY.CIDB.FWD.FWD2.SOURCE_STORE=SOURCEB
KAY.CIDB.FWD.FWD2.SINK=SINK1

The following example shows a similar configuration that uses TLS for the connection to OMEGAMON Data Connect. This example demonstrates the usefulness of reusable sink parameters for forwarders that use the same sink: you only have to specify the sink SSL parameters once.

ZWES.PLUGIN.KAY.ZISDYNAMIC=KAYSISDL
ZWES.PLUGIN.KAY.CIDB=KAYB0001

* Stores
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON
KAY.CIDB.STORE.STORE2.NAME=SOURCEB

* Sink
KAY.CIDB.SINK.SINK1.HOST=analytics1.example.com
KAY.CIDB.SINK.SINK1.PORT=15351
KAY.CIDB.SINK.SINK1.FWD1.SECURITY=TLSv1.2
KAY.CIDB.SINK.SINK1.FIPS=ON
KAY.CIDB.SINK.SINK1.KEYRING=KAYSIS01/KAYring

* Forwarders
KAY.CIDB.FWD=ON

KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1

KAY.CIDB.FWD.FWD2.SOURCE_STORE=SOURCEB
KAY.CIDB.FWD.FWD2.SINK=SINK1

Example: Forwarding data from each store to a separate instance of OMEGAMON Data Connect

Figure 3. OMEGAMON Data Broker advanced configuration: two stores, two forwarders, two sinks
A separate forwarder and sink for each store.

Different data sources can write to different stores. You can choose to forward data from each store to separate instances of OMEGAMON Data Connect or to the same instance of OMEGAMON Data Connect.

If you want to analyze data from different sources in different destination analytics platforms, then you might choose to forward data from each store to a separate instance of OMEGAMON Data Connect, which then makes the data available to the appropriate analytics platform.

ZWES.PLUGIN.KAY.ZISDYNAMIC=KAYSISDL
ZWES.PLUGIN.KAY.CIDB=KAYB0001

* Stores
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON
KAY.CIDB.STORE.STORE2.NAME=SOURCEB

* Sinks
KAY.CIDB.SINK.SINK1.HOST=analytics1.example.com
KAY.CIDB.SINK.SINK1.PORT=15351

KAY.CIDB.SINK.SINK2.HOST=analytics2.example.com
KAY.CIDB.SINK.SINK2.PORT=15351

* Forwarders
KAY.CIDB.FWD=ON

KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1

KAY.CIDB.FWD.FWD2.SOURCE_STORE=SOURCEB
KAY.CIDB.FWD.FWD2.SINK=SINK2

Example: Completing or overriding reusable sink parameters with forwarder-scope sink parameters

If you use a common subset of parameters for different sinks, you can define the common subset as reusable sink parameters, and then use forwarder-scope sink parameters to complete or override those reusable parameters.

For example, suppose you use the same port number and SSL parameters to forward data to OMEGAMON Data Connect on different hosts. You can define reusable sink parameters that include the port number and SSL parameters, but exclude the hostname, and then use forwarder-scope sink parameters to complete the sink parameters by supplying a hostname:

ZWES.PLUGIN.KAY.ZISDYNAMIC=KAYSISDL
ZWES.PLUGIN.KAY.CIDB=KAYB0001

* Store
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON

* Sink (incomplete: no HOST)
KAY.CIDB.SINK.SINK1.PORT=15351
KAY.CIDB.SINK.SINK1.FWD1.SECURITY=TLSv1.2
KAY.CIDB.SINK.SINK1.FIPS=ON
KAY.CIDB.SINK.SINK1.KEYRING=KAYSIS01/KAYring

* Forwarders
KAY.CIDB.FWD=ON

KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1
KAY.CIDB.FWD.FWD1.SINK_HOST=analytics1.example.com

KAY.CIDB.FWD.FWD2.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD2.SINK=SINK1
KAY.CIDB.FWD.FWD2.SINK_HOST=analytics2.example.com

You can also use forwarder-scope sink parameters to override individual reusable sink parameters. In the following example, forwarder 1 uses the hostname specified by the reusable sink parameters, while forwarder 2 overrides that hostname:

ZWES.PLUGIN.KAY.ZISDYNAMIC=KAYSISDL
ZWES.PLUGIN.KAY.CIDB=KAYB0001

* Store
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON

* Sink
KAY.CIDB.SINK.SINK1.HOST=analytics1.example.com
KAY.CIDB.SINK.SINK1.PORT=15351
KAY.CIDB.SINK.SINK1.FWD1.SECURITY=TLSv1.2
KAY.CIDB.SINK.SINK1.FIPS=ON
KAY.CIDB.SINK.SINK1.KEYRING=KAYSIS01/KAYring

* Forwarders
KAY.CIDB.FWD=ON

* Uses the hostname specified by the reusable sink parameteters
KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1

* Overrides the hostname specified by the reusable sink parameters
KAY.CIDB.FWD.FWD2.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD2.SINK=SINK1
KAY.CIDB.FWD.FWD2.SINK_HOST=analytics2.example.com

Bad example: Multiple forwarders using the same store and the same sink

Do not use this configuration pattern. The sink receives duplicate data.

Figure 4. OMEGAMON Data Broker advanced configuration: two forwarders, same store, same sink: do not do this!
Bad configuration pattern: multiple forwarders using the same store and the same sink.

Be careful that you do not inadvertently define this bad configuration pattern:

* Store
KAY.CIDB.STORE.STORE1.NAME=OMEGAMON

* Sink
KAY.CIDB.SINK.SINK1.HOST=analytics1.example.com
KAY.CIDB.SINK.SINK1.PORT=15351

* Forwarders with same store and sink: do not do this!
KAY.CIDB.FWD=ON

KAY.CIDB.FWD.FWD1.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD1.SINK=SINK1

KAY.CIDB.FWD.FWD2.SOURCE_STORE=OMEGAMON
KAY.CIDB.FWD.FWD2.SINK=SINK1