OpenText Operations Bridge Reviews

We use this solution primarily to monitor servers, to do some log file monitoring, events correlation, and events duplication as well as dashboarding.

We have a bunch of critical servers and applications. We are able to monitor using this product to create a dashboard and have automatic alerts to notify the responsible team.

The event correlation is the most valuable aspect of the solution. 

The UI could be better. The ease of use, deployment, upgrades, and licensing could be better. The license, not only the model, rather, the way you manage your users and things like that need to be worked on.

The initial setup is a little bit complex. 

Technical support could be better.

The solution can be more stable.

It's not easy to scale. 

The solution needs network monitoring, and support for more cloud providers.

Anomaly collection could be better. They need better reporting. 

I've been dealing with the solution for ten years. 

While it is a lot better in the current version, it is not as reliable. You need people constantly checking everything, to keep it running. It's a complex product so some components, internally, can cause some unexpected behaviors.

While it can scale, more or less, it's not a straightforward process. 

We have between 50 and 100 people using the solution right now. There are level one, two, and three operators and a few system admins. 

We do not have plans to increase usage. 

We aren't very satisfied with technical support.

Neutral

I did not previously use a different solution. I use something similar in parallel, however, it's not a replacement. 

The initial setup is a bit more complex than straightforward. I'd rate it a three out of five in terms of ease of setup.

I was not here for the latest deployment. However, based on my experience, usually, it takes at least one month to more to plan, prepare, deploy, and configure.

We have five people who can handle deployment and maintenance. 

The deployment was handled in-house with some professional services helping as well. 

While we don't precisely calculate the ROI, we have seen it.

It's quite an expensive solution. I rate it five out of five in terms of the high cost.

I did not previously evaluate other solutions. 

We're using a mix of versions 2020.11 and 2022.05.

I'd advise new users to be prepared to face issues and have problems with the support.

I would rate the product seven out of ten. 

We primarily use the solution for monitoring Linux and application workloads. 

The integration capabilities are very helpful. 

It is stable and reliable. 

I'm not aware of areas that need improvement. 

I've used the solution for quite a while. I've used it for ten years at least. It's been about a decade. 

The product is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. 

I'm not sure how many people are using the solution in our company at the moment. 

I've never used technical support. I've never needed any assistance. 

I was not part of the original installment. 

I haven't validated all of the monitoring tools on the market. 

We're a customer and end-user. 

I'm likely using the latest version of the solution. 

The solution is a good monitoring tool. People should try it. 

I'd rate the product eight out of ten overall. 

With our HPOM installation, we monitor the European (and part of the global) infrastructure of our financial services, consisting of around 800 servers in various regions.

It has greatly reduced the number and duration of outages as support teams are notified immediately when something goes wrong or even before something breaks. The integration with the ticketing tool makes sure that there is a record for every issue.

The various types of monitors are very useful. We use them all:

• Threshold monitors
• Log file monitors
• Open message templates
• SNMP trap monitors
• Process monitors
• Database and infrastructure SPIs.

Additionally, the Performance Manager provides great insight into our systems' performance.

Installing and upgrading the HPOM and Operations Agent software is not always easy and the process can be quite fragile. Once it is running, it is very quick and stable, but an upgrade can quite easily break something or terminate unexpectedly.

For additional features, we are looking forward (and implementing) OMi 10.6x.

• To monitor the complete IT infrastructure. 
• To consolidate various products into one and various screen NOC were using to monitor the environments into one single screen, so they can act quickly on the issues and resolve the issue faster. 
• Correlate the events from servers, network switches, routers, and present single or few events with the help of correlation techniques stream-based event correlation and topology based event correlations to reduce number of events, so NOC can find root cause more quickly and help with the ROI. 
• Migration from Operations Manager of Linux to Operation Bridge products. 

Single pane of glass. NOC has to view only a single screen to monitor the entire infrastructure. All events can be seen on single screen and they integrate well with other products. 

Well integrated OMi with Network Node Manager (NNM), Operations Bridge Reporter (OBR), Operations Manager for Linux (OML), and Operations Connector and Universal Discovery to correlate events using SBEC event correlation. Event correlation helps to consolidate and reduce event counts, so operators can act quickly and resolve the issue in a timely manner. 

It has the capability to display overall health of the infrastructure and is very useful for executive reports on the health of the infrastructure.

It helps to integrate and consolidate various products, such as Operation Manager, Operations Bridge, OMi, Operations Bridge Reporter, Operations Connector, Network Node Manager, Universal Discovery, ServiceNow, and NOC, which use one single screen to monitor the entire infrastructure. SBEC (Stream-Based Event Correlation) event correlation has helped consolidate events into one event helping to reduce events visible to operators letting them act and find root causes more quickly. It has helped to handle message storm situations. Earlier NOC were using different screens to monitor different environments. Now, they have to look at single screen as other products are well-integrated with OMi. 

Topology base event correlation. Topology-based event correlation does not work well with NNM events. NNM does not understand well and collect information needed to correlate the events. Separate active and history tables from one single table and improve performance. It should be improved to view more than 100K events from closed browsers without impacting performance. QA of the products should be thorough before it is released and documentation lacks the information needed to implement the products, upgrade the products from one version to next version, and there is integration with other products. If events goes beyond 100,000, performance is degraded and sometimes the browser freezes.

No.

No.

Technical support is good, but it could be improved. 

No, we are migrating from OML to OMi. 

Initial setup was straightforward and integration was easy. 

In-house. 

Not applicable.

It is competitive. 

No.

The product is great, but it could be improved. 

The ability to integrate directly with the RIPM on top of DSM. We're looking to use the event feed into OMI, the metrics feed, and using things like SHA. There might be opportunities later to try for a faster root cause analysis.

At the moment, we're still building the system, so I can't say.

When installing against IIS, you need to expect a fully locked-down IIS, rather than expecting a fully out-of-the-box. It is sold to enterprise customers and I can't believe any enterprise customers would be happy to leave IIS out-of-the-box. I would think that everybody would have locked it down. You add what you want to include in a white list, rather than blacklist out what you want to exclude. So, the IIS configuration definitely needs to be improved.

The installation instructions need to be improved, as well.

We had a designated person with FlexCare. He was fair enough with the installation in general. I think we worked out what the problems were with the filters ourselves, because we've seen that on other HPE products. We were kind of expecting it.

We are combining it with other monitoring tools. They did a huge proof of concept to determine what the right fit was. I wasn’t involved in that. It was all vendor engagement, and so on. It wasn't just HPE, we had other vendors as well, such as IBM and Compuware.

The installation instructions are a mess to the point where the advice given to us by other HPE people has been to not follow the instructions, but to follow the VMEs instead.

The installation for an enterprise IIS solution, rather than just an out-of-the-box one, doesn't work very well. We ended up needing to troubleshoot the installation to get it to work. Installing the IIS filters was a big headache. We installed them, but we couldn’t do anything until we went in and adjusted them. When I left, there was still a problem creating users. We couldn't do any of that, so I don't know if they fixed that yet.

For people doing this for the first time, if you have support from HPE, use it. Milk it. Use your FlexCare points and grab somebody. You might sail straight through. If it works, and you do not have any problems with that, then maybe you're fine.

It is mostly used for event management. We use it to consolidate events from different data collectors.

The correlation feature is the most used feature. It allows you to correlate events from different sources and have more meaningful events.

The deployment of agents on new CI should be improved. There should be some kind of automation to directly deploy them from the console.

It can maybe have some more AI functions because most of the other tools are going in that direction.

I have been using this solution for around two years.

It is stable. It has got high availability.

I haven't done that yet, but its scalability must be good. It must be easy to add new servers.

In terms of usage, mostly the operations teams work on these events. We have a team of around ten members.

Their support is good. The community is also helpful.

It was pretty straightforward.

It was actually management's call, so I didn't get a chance to look at other tools.

I would rate Operations Bridge an eight out of ten. It is a very good solution for event management and agent-based monitoring.

This is a mature product. There is good support from HPE and it involves constant updates. There is a path to move on to the next product.

It's our monitor of managers. It's our monitoring tool and it looks after all our servers.

At the moment, I don't know what the roadmap is for this solution. There's a product that's been out for two or three years now, called Operations Bridge. There is a migration path to that, but it's not an obvious one. HPE has not made that obvious to us, so I'm trying to find out how we move on.

The product and the UI need updating. Everything about the user experience needs updating. I work at the other end, which is the more technical end, and I like what it does. But when a user sees a GUI that looks like it was written in the 1970s, it doesn't fill them with any confidence. It needs more dashboards, more graphs, and more everything that management wants to see.

We've had this solution for 12-13 years.

It's fairly complex deployment, even though it's supposed to work out-of-the-box. It's a product that can be tailored. It probably will work straightaway, but if you want to get the best out of it, you've got to change it to suit your environments.

It's a mature product and has good stability.

The product has good scalability. We've gone from 100 to 700 servers without any hiccups. It's a very scalable product.

I have used technical support. They are good; perfect. We don't raise many cases, but when we do raise cases, it's good. They are the same as any other company. It's just support at the end of the day.

There is an issue at the moment with HPE, in that their support for this product has moved over to Sofia, Bulgaria. That can pose its own problems, but it's like anything that's off-shored. It's going to take a little bit longer, and you have to accept a few more difficulties when you're trying to explain problems or reject solutions.

I've looked at Moogsoft and Nagios as alternative products. There are lots and lots of other ones out there. I’m not sure if we will stay with HPE.

We've got a very mature product that would be awful to try and replace. However, if we don't get what we want out of it, and we can't go forward with it, then the new kid on the block will just come in and slot straight in.

When selecting a vendor, I look for attention to the customer and the support you're going to get when you're going through this. If we do move, it will be a fairly fraught experience. We want to be confident that either HPE or another vendor will be behind us and helping us down that path.

I've been working with it for 15 years, and I know how powerful it is. If you spoke to some of our end-users, they probably wouldn't even mark it, because they don't even use it. They don't use the interface, because they don't like it. There are so many other things on the market now.

I think it's a practical solution for taking a lot of different inputs from our operations and transforming them into sort of unified, actionable events that you can automate and make sense of automatically. We get a lot of different inputs in a lot of different formats which usually, once a person looks at it, it comes down to something very simple, like an event type.

Operations Bridge works with the idea that these events are mapped, sometimes manually, sometimes from pre-existing templates, into event-type indicators and then you can build automation logic on those indicators. That's valuable because it means we can do automation on events that come from different sources without going through each source every time to do the same automation, over and over again.

Actually, we're going to see measurable results maybe next year. We haven't had it in wide production use for that long yet, so I can't mention percentages, really. But so far, the experience has been that it enables automation from sources that usually don't support automation.

Also, it's just a very nice place to do some basic correlation and things like that. We've been using fairly old technology user interface-wise before this, so it's a nice upgrade for operators to operate in.

I'd like more integration between the separate systems that make up the Ops Bridge part of the thing. There's a separate reporting component, which is very separate at the moment. There's the operations analytics, which is also a separate product and has a very different stack from OMi and the other Ops Bridge core components. Mainly, I just want more harmony between those things.

That is a huge thing. There are a lot of different components you need to understand before you can get proficient at the product.

Also, the less Flash we can get in the UI, the better. That would be great.

We haven't put that much load on it, so it's difficult to know from that point of view. It's OK. The UI is web-based, but it requires both Java and Flash and these days, that's not really the cutting edge by any means.

We haven't had that many issues with it, but Java replaces native operating system and web components with Java components. Sometimes the functionality or the stability isn't what a native component would be, so we've had some issues there, but it's never been really that serious. It's just like, some scrolling thing doesn't work or you have to refresh the page; that kind of thing.

There are pretty heavy limits on what the system can do. It hasn't been an issue for us, really, but the philosophy of the system is not a big data product. You can't just push thousands and thousands of events to it per second. It's not meant for that.
The idea is that you filter events below Ops Bridge and then just the ones that the element managers think might be actionable are thrown forward. For that, it's fine, but there is the risk that you lose a lot of visibility into events that you don't beforehand know that you should be pushing forward to Ops Bridge.

We’ve used technical support for a few small things. It's been fine so far. We've gotten some pretty good patches and things for specific issues, so it’s been mostly positive so far.

We switched because it was beginning to be mainly in-house built software. We didn't want to take on the burden of developing it much further. It lacks these features and it was just essentially scripts running other scripts. We wanted something that had actual enterprise-level support, had a concrete development plan, and that integrated well in the systems that we already have.

We did the initial implementation of the environments together with HPE; we built the production environment, they built the test and development environments as references. It was OK. In hindsight, there were more things that we should have taken into account before we started building, some of which we understood, some of which we didn't. All in all, there are a lot of components.

I think the changes they're proposing now to the product in the next year or two, those might help. We'll see. Or, at least we'll have new problems. But there are a lot of components to install on a lot of virtual machines, if that's your architecture.

We did a few proofs of concept with CA. We did proof of concept installations and went through some of the licenses that we already have elsewhere in the company, with both CA and HPE. We ended up with HPE because there we saw how we would develop this level automation that we're heading for, without the amount of work getting just ridiculous. I think CA might even had better monitoring components, but the event management wasn't as strong, at least for our use case.

If you're researching this solution or something very close to it, before you begin implementation and the careful planning, look into your CMDB and data structures. Figure out what CIs and what information in your configuration management database you actually need to orchestrate monitoring and to orchestrate the views from the events that you get. Having too much information makes it impossible to test the solution, and not having enough doesn't give you the functionality you need.