Operations Bridge 2019.02: What’s new in the release

by in IT Operations Management

Last week, we have announced Micro Focus Operations Bridge 2019.02, the release that brings new functionality as well as considerable improvements of existing features. With every new version, we continue to work on improving and innovating our solutions making them easier to use and manage. Our latest release brings improvements in stability and scale, increased performance and improved user experience.

This blog post will guide you through the most prominent updates in the new Operations Bridge release. For a full release overview, check out What's New in Operations Bridge on the Micro Focus Documentation Portal.

Operations Bridge 2019.02 brings new functionality in the following areas:

  • Container deployment enhancements:
    • Collect Once Store Once (COSO): Improved Virtualization Collector/Data Broker scalability, data maintenance configuration via REST APIs
    • Capabilities on top of COSO: New threshold configuration options for central thresholding and an improved algorithm for Automatic Event Analytics
    • Container Deployment Foundation (CDF): The ability to add/remove a capability via CLI, Fluentd logging enhancements, as well as the updated CDF 2019.02
  • Updated content with the new versions of:
    • OBM (Operations Bridge Manager) Management Pack for Amazon Web Services (AWS) offering fine-granular multi-account monitoring and RDS monitoring using role-based authentication
    • OBM Management Pack for Microsoft Azure enhanced with forwarding of Azure Monitor alerts into OBM
    • SiteScope solution template for Hadoop 2.x and 3.x and Cassandra 3.11.x
    • OBR JBoss Application Server Content
  • SiteScope enhancements that include SiteScope APIs to copy monitors between SiteScope servers as well as enhancements allowing to update monitor properties
  • Local client for APM now supporting all APM Admin UIs, LDAP and localization

The following capabilities have been released as part of Operations Bridge 2019.02:

For further details, check out latest Operations Bridge support matrices.

Let's first talk about the enhancements for the Operations Bridge container deployment.

COSO: Improved Virtualization Collector/Data Broker Scalability

Virtualization Collector collects the VMware topology, metrics and events and gives you visibility into the entire VMware Virtualization infrastructure (the virtualization data is streamed to COSO and can be visualized in BVD and PD dashboards).

The functionality was first introduced in Operations Bridge 2018.08 and was continuously improved since then, to ensure better scalability and optimal performance. Our latest release brings the new feature that enables you to horizontally scale Virtualization Collector components (Collection Manager and Data Broker) when monitoring multiple vCenter environments. This way, you can evenly distribute the vCenter load, which results in improved performance and scalability.

Let’s look at this feature in more detail. By default, the collection from one or more vCenter(s) is allocated to a single Data Broker pod. In Operations Bridge 2019.02, VMware collection solution enables you to create multiple Data Broker pods, making it possible to create separate channels for data collection and integration for each vCenter – thus increasing the scale and ensuring the efficient distribution of the vCenter load. The diagrams below illustrate the difference between the old and the new setups.

Figure 1 shows how the collection was done prior to Operations Bridge 2019.02, without Data Broker pod scaling:VC and DB no scaling.pngFigure 1

In this diagram, the Data Broker pod can be seen as a bottleneck as it receives the data from all vCenter collectors.

Figure 2 shows the horizontal Data Broker pod scaling supported with Operations Bridge 2019.02:

VC and DB scaling.png

Figure 2

In this setup, the collection of one vCenter is mapped to one Data Broker pod. Each Data Broker pod is registered as a different service and can process the incoming data. Another possible option is to map the collection from one or more vCenters to one Data Broker pod. What you cannot do, however, is to assign collection from one vCenter to multiple Data Broker pods – this is not supported.

Figure 3 provides some numbers representing optimized scalability as compared to previous releases:

Scale limits.pngFigure 3

In the current release, Data Broker pods can only be scaled manually using a shell script (the Collector pods are created automatically – one per vCenter instance). In the future, however, we plan to automate the scaling of Data Broker pods.

The procedure on how to create a Data Broker pod using a script is described here. (Note that only one new Data Broker pod is created when the script is executed – to create multiple Data Broker pods, the script needs to be executed multiple times.)

After creating a desired number of Data Broker pods, grant their certificate requests in OBM. Once Data Brokers are listed as monitored nodes in OBM, you can assign vCenter configuration aspects to different Data Brokers (for example, deploy vCenter Collection aspect to data broker 1 specifying vCenter1 as an instance parameter, then deploy vCenter Collection aspect to data broker 2 specifying vCenter2 as an instance parameter, and so on).

COSO: Data Retention Management Using REST APIs

This useful improvement helps you better maintain your data by deleting the aged records from the Vertica database based on the specified retention period (which can be configured using the REST APIs). The records in the store older than the configured retention period are periodically deleted. The deletes are hard deletes, which means that it is not possible to recover the records after they are deleted from the store.

You can set the default retention for dataset and entity dataset globally. Retention period can also be configured for a group of datasets identified by a particular tag associated to a dataset.

COSO: Central Thresholding Enhancements

Central Thresholding, introduced in Operations Bridge 2018.11, allows you to configure static thresholds for all data coming into SO. This feature is especially useful in situations where thresholding is not available at the data source or is not under control of the central monitoring team (for example, Virtualization Collector and Streaming Agent). The thresholds are evaluated on the data samples that are received in COSO. A threshold violation generates a corresponding event in OBM. Read this blog article for more information on Central Thresholding.

In the current release, this functionality has been further improved by implementing the following features:

  • Controlled reporting of threshold violations: unlike in the previous release, where notification were sent each time a threshold was violated, it is now possible to suppress ongoing violations of the same severity level (AlertOnSeverityChangeOnly). Also, it is possible to send a “reminder” notification after a given interval of time, even if the severity did not change (MaxTimeToNextAlertMins).

          A Graphical Representation of Threshold Alerts with SuppressionAlerts with supression.png         Figure 4

And this is how Figure 4 “translates” into the Configuration Policy with MaxTimeToNextAlertMins (30 minutes) and AlertOnSeverityChangeOnly (true) parameters:        Figure 4 - translation.png

  • Collective inference over a period of time (windowing): a violation can now be reported by inferring a threshold violation of a metric over a period of time. This feature helps in determining the continuity of the anomalies and hence allows to more deterministically report a violation and avoid false alerts.

    Example: You can configure to report a “Warning” threshold violation on a VM, if its CPU utilization is more than 80%, for more than 60% of the time, in the last 30 minutes.

  • Collective inference across multiple objects of same stream: Alert only when several objects had threshold violations. For example, you can configure to report a “Critical” threshold violation based on all VMs within the same cluster, if more than 80% of the data points (CPU usage of the all the VMs in the same cluster) are above 95% CPU usage, in the last 60 minutes.

    For detailed information on the metrics available for COSO (for each component), refer to this topic on the Micro Focus Documentation Portal.

COSO: Event Analytics Enhancements

Operations Bridge 2018.11 introduced the first analytic capability on top of COSO – analytics-driven event correlation based on machine learning algorithms. Event Analytics works by finding patterns in the event stream and using this information to group events together (the events with a high probability pertaining to the same problem). No additional configuration is required to enable this feature.

In Operations Bridge 2019.02, we have further improved this functionality by making the pattern detection more reliable. Earlier, the patterns always had to occur within a fixed 10-minute time window, therefore correlations could not be always detected. Now, a 10-minute sliding window is used, so the correlations can be detected more reliably.

In addition to this, Event Analytics now shows more accurate correlations. Before, if events had no Event Type Indicator (ETI), event types were sometimes incorrectly detected using attributes that were too generic and matched too many events. This resulted in the detection of too many patterns, so too many events were grouped together. Now the event type is based on a combination of fields if no ETI is set, which results in more accurate correlations.

Last but not least, the new COSO OBM event table has been introduced, which stores the data using the same types as used in UCMDB tables. This makes life easier for BYOBI (Bring Your Own BI) tool users who want to query the data from both tables.

Watch out for a separate article on Operations Bridge Event Analytics (to be available soon).

Container Deployment Foundation (CDF) Enhancements

  • Add or remove Operations Bridge capabilities via the Command-Line Interface (CLI)

You can now add or remove Operations Bridge capabilities (such as ITOM Intelligent Data Lake (IIDL), Business Value Dashboard (BVD), Operations Bridge Manager (OBM), End User Management (EUM), etc.) after the initial installation of Operations Bridge. (Earlier, to add or remove a capability, a complete re-installation was necessary.)

This feature works for any capability and is supported via the CLI. See Add or Remove Operations Bridge Capabilities on the Micro Focus Documentation Portal; from this section, you can navigate to detailed add/remove procedures for individual capabilities.

Consider the following points:

-   Capabilities required by other capabilities can be removed by mistake – keep in mind that we provide no automatic checking, so always remove capabilities with caution
-   Unchanged capabilities are not reconfigured and keep running (without downtime)
-   For certain capabilities, additional manual removal may be necessary (i.e., NFS folders)

  • Fluentd logging enhancements

    In Operations Bridge 2018.11, CDF changed the logging (to use Fluentd) to centralize logs from all master and worker systems to a single location (cdf-log share on NFS Server) and to simplify log forwarding of those logs to Operations Bridge Analytics and other targets (such as Elasticsearch). In 2019.02, CDF allows to configure the cdf-log share in the UI and for Operations Bridge, BVD container logs are now logging to that cdf-log share as well. (Please note that other Operations Bridge logs still can be found under the log volume or omi-0|1 volumes. Further alignment is planned for future releases.)

  • Updated CDF 2019.02

    Brings the latest releases of K8S (Kubernetes) and Docker, as well as numerous fixes to increase CDF robustness and resilience.

 Content Enhancements

The following enhancements are included in the latest versions of the Management Packs:

  • OBM Management Pack for Amazon Web Services (AWS):

    The new version of the OBM Management Pack for AWS brings the following updates:

    • Support for multi-account monitoring. With this enhancement, customers can monitor account-specific services for multiple accounts using a single AWS Management Pack monitoring node (previously, it was always a superset of all services (across all the accounts) if multiple accounts were being monitored). This brings the flexibility to choose for monitoring a specific service on the corresponding AWS account.

    • Support for monitoring a specific region: customers can now restrict the monitoring to a specific geographic region of interest (earlier Management Pack versions queried all the services across all regions; there was no flexibility to choose a specific region to be monitored).

      Choosing a Region to Be Monitored


      Figure 5

      Note: By default, all AWS regions are listed in the policy. To choose the region(s) to be monitored, use the '#' key to comment the regions that you do not want to monitor, then save the file.

    • New role-based authentication (RBA) aspects for AWS Relational Database Service (RDS) monitoring. (AWS RDS aspects enable you to discover and monitor RDS if you deployed the Management Pack on a cloud.) The following aspects are now available: AWS RDS Discovery RBA Aspect, AWS RDS Event log RBA Aspect and AWS RDS Health RBA Aspect. It is also worth mentioning that for your convenience, RBA aspects have been moved to a separate folder, to allow a better organization and easy differentiation of RBA aspects and aspects using other authentication methods. For more information on these aspects and the steps on how to deploy them, see this topic.

    • Alias name for Account ID. This enhancement allows you to specify an AWS Alias Name (used as the display label of the AWS Account CI). This way, you can enter meaningful names for your accounts thus improving the account analysis and readability (previously, only an Account ID was displayed, which made it difficult for customer to understand and analyze the account information). This option brings a better structured account display and improved readability.     

For more information on these enhancements, start with the Release notes in the Management Pack for  AWS 2019.02 documentation and then navigate through it as appropriate.

  • OBM Management Pack for Microsoft Azure:

    OBM Management Pack for Microsoft Azure has been enhanced to integrate with Azure Monitor and display Azure alerts in OBM. Azure Monitor provides tools for collecting and analyzing metrics that allow you to maximize the performance and availability of your cloud and on-premises resources and applications. As of recently, it also includes the Log Analytics tool.

    In Azure Monitor and Log Analytics, you can create rules with thresholds to get alerts on collected data. After meeting the necessary prerequisites and performing the required integration steps described here, you will be able to receive the alerts raised in the Azure Portal as events in the OBM Event Browser.

    In Azure, when an alert is generated, the alert's monitor condition (automatically set in place by the system) is set to Fired. When the underlying condition that triggered the alert clears, the monitor condition is set to Resolved. When an alert changes to Resolved in Azure, OBM receives a new event with Closed status, which closes the original Fired event.

    OBM Event Browser Showing Closed Azure Events


    Figure 6

    For more information on Azure Monitor Alerts Integration, start with the Release notes in the Management Pack for Azure 2019.02 documentation and then navigate through it as appropriate.

    SiteScope Monitor and Solution Template Updates:

    The following has been added in this release:

    • New Apache Cassandra Solution template to monitor Cassandra version 3.11.x
    • New Hadoop Solution template to monitor Hadoop 2.x and 3.x clusters
    • Hadoop monitor now also helps to dynamically monitor health and performance of Hadoop Distributed File System (HDFS), Hadoop YARN, and HBase master nodes of the Hadoop 2.x and 3.x cluster infrastructure using the standard JMX remoting technology

    For further details on supported products and product versions, refer to the Operations Bridge support matrices.

SiteScope Enhancements

The following new REST APIs are now available:

  • exportMonitorGroupConfig to securely export monitor group, monitor sub groups, associated monitors, associated remote servers with credential profiles, and monitor configurations from a SiteScope server
  • importMonitorGroupConfigto import monitor group configurations exported using the exportMonitorGroupConfig REST API into a SiteScope server
  • UpdateMonitorPropertiesConfig to update properties of a monitor in a SiteScope server
  • UpdateCredentialProfileUNIXRemoteServerto update UNIX remote server properties (you can also add or change the credential profiles associated with a UNIX remote server)
  • UpdateCredentialProfileWinRemoteServerto update Windows remote server properties (you can also add or change the credential profiles associated with a Windows remote server)
  • ExportSchedulePreferencesConfigto export Schedule Preferences (Absolute and Range) from a SiteScope server
  • ImportSchedulePreferencesConfigto import Schedule Preferences (Absolute and Range) into a SiteScope server

Another SiteScope enhancement to mention is the SiteScope-Store Once integration update: a new column CounterStatus was added to store the counter status data (good/warning/error/no data), which is sent from SiteScope to COSO. This makes it possible for you to view the counter status in reporting tools/BVD/PD.

SiteScope.pngFigure 7

APM (Application Performance Management) Enhancements

Last but not least, APM local client now supports all APM Admin UIs (previously, only EUM Admin UI was supported), LDAP and localization.

Note that Java-based APM Application UIs Top View and Topology Map can also be viewed in local client.

We encourage you to try out our new features and enhancements! For further information on our offerings, visit the Operations Bridge product page, explore our documentation resources and check out our videos and blogs.

If you have feedback or suggestions, don’t hesitate to comment on this article.

Explore full capabilities of Operations Bridge by taking a look at our Operations Bridge Manager, Operations Bridge Analytics, Operations Bridge Reporter, Operations Connector (OpsCx), Business Value Dashboard (BVD) and Operations Orchestration (OO) documentation!


To get more information on this release and how customers are using Operations Bridge, we are happy to announce the following events:

Read all our news at the Operations Bridge blog.


Explore all the capabilities of the Operations Bridge and technology integrations by visiting these sites:


Operations Bridge