I'm using two monitoring tools simultaneously: Dynatrace and Geneos. I provide cloud support, which requires various business monitoring tools for different domains and lines. Geneos and Dynatrace are my primary tools, but I also use Prometheus and other cloud component monitoring tools for Docker and Kubernetes. Geneos is missing container monitoring. 

I've been monitoring the same area for the past 17 to 18 years and have used a variety of products, such as AppDynamics, Dynatrace, and BMC. ITRS Geneos is the only tool that covers all layers of monitoring, from the hardware to the business layer. No other tool can match its coverage. AppDynamics is the best monitoring tool for latency monitoring. BMC is the best tool for infrastructure monitoring. ITRS Geneos is a tool that offers end-to-end application performance monitoring, from the hardware to the application.

In 2008, we used an open-source monitoring tool and a custom monitoring tool we built in-house. This script worked well for us, and I didn't want to move away from it. Even now, I think about how we don't need to pay a bunch of money to a vendor for a tool that already works well for us but the number of systems kept increasing, and the scope kept increasing. I couldn't hire more and more people to handcraft more and more script support and maintain X, Y, and Z. We had to do the R&D, we had to develop the script, and we needed to maintain the resources. There were pros and cons to this. ITRS Geneos came into the picture, and we also evaluated other enterprise monitoring vendors. We found ITRS to be the best tool to go forward with. We purchased a small number of licenses and conducted a trial first for six months and a year, and the tool worked well. Then we slowly moved on, one department became two, three, and four, and now the entire bank uses ITRS Geneos.

I work in a trading production support role. Eight years ago, we made the switch from using HP OpenView for monitoring purposes to using ITRS Geneos. This was because there was no GUI available with HP OpenView.

We have never considered any lower-cost or open-source alternatives because the team is comfortable with the current system. The L1 monitoring team is the team that checks the dashboards and provides alerts. They are so familiar with the system that we have never thought of getting away from it.

Prior to Geneos, we had enterprise-level tools like SCOM, and CA's APM, which is a performance monitoring tool, and there were elements of Tivoli and other big-company monitoring solutions, but they were never very customizable. We would never have been able to monitor the completely custom-built application that we provide.

You can't just go and buy a tool that will monitor a custom application, so a lot of our monitoring prior to Geneos was via bespoke scripts that were running and sending emails. You can imagine how nightmarish that was. We had a large volume of emails, no persistence, and no idea of who was looking at an alert.

Geneos was able to execute a lot of our custom scripts along with a lot of its core plugins. And because it has a console, with a means of tracking alert volumes and for designing the rules, it was very easy to tailor our rules to avoid false alerts.

A manager of mine came in from a previous place of employment where they used Geneos and he was singing its praises. It replaced our completely custom-built, email-based solution.

It was before my time, but to my knowledge, we didn't have a proper solution prior to this. There was probably SCOM, but that was at a very base level and only for hardware monitoring. It was not to the level that we have now. There was also no other integration with regard to getting callouts or other notifications about issues. So, we didn't have a proper solution prior to this. 

We previously used Dynatrace and are still using Prometheus and Grafana. We switched from Dynatrace to ITRS, but are still using open-source monitoring solutions for the observability portion which ITRS falls behind on. Dynatrace had a delay in the alerting system because it sampled data every 50 percent which meant the tool had to wait a certain amount of time before sending an alert. However, ITRS was real-time which helped the app support team take necessary actions. With Dynatrace, alerts took around seven minutes and with ITRS Geneos, the alerts take two seconds to come in.

The main problem with our previous solutions was that the monitoring itself was not working at all. The other solutions didn't trigger the alerts. We didn't face this issue with ITRS Geneos. The installation of the monitoring tool itself failed or after being installed it didn't work. The product or the monitoring tool died for a few days and we had no monitoring which went unnoticed. We used different in-house tools based on whatever infrastructure was provided such as IBM or CompuCom. These solutions had a lack of application-related monitoring.

Before Geneos, we didn't really have an effective way of managing alerts.

When I joined in market data, it was being used within market data. Then, I moved into investment banking. Since it was not being used in investment banking, so I took the product into the investment banking area.

We did not have a previous solution.

I've used AppDynamics, Dynatrace, and many others before that, but those are the two most recent.

In terms of the time taken to get an alert, it's somewhat configurable, but the data lag in AppDynamics has always been about two to three minutes, and that's after fine-tuning. That's as good as we could get. With Dynatrace, it was more like four to five minutes.

The pros of Dynatrace and AppDynamics are that they get deeper into the code, and deeper into the transactions automatically, out-of-the-box. Those are very good features. That's not something Geneos does; it doesn't try to do that and that's fine. But the other two are both very good at that. 

The cons are that they are difficult to customize — maybe impossible to customize. The idea of being able to write a script and execute an action on a monitored server is not a realistic proposition in either of AppDynamics or Dynatrace. And that's huge for us. We use that all the time. That's one of the very best features of Geneos that the competition does not have.

Geneos was ordered by our manager because he had experience with it and found our monitoring portfolio to be inadequate, which we agreed with. We have other monitoring tools, but they replaced Dynatrace with AppDynamics and AppDynamics, frankly, just doesn't do everything that we needed to do.

We had a manual, custom-built script, and then we used Foglight monitoring. We also used the BMC monitoring tool. Now, we have transitioned from all these tools to ITRS.

For the initial four to five years, we were doing manual monitoring where we built a custom script and deployed it to the production servers to monitor, but the number of scripts kept on increasing. They required a developer and constant maintenance and enhancement. We had to keep going. It was never-ending. At one point in time, we ended up having a few hundred scripts in our production environment. It was very hard to manage and maintain them. It was a cumbersome process, so we thought of getting rid of them.

We then moved to BMC monitoring, but the problem with BMC monitoring was that only the admin was able to set up the configuration. It also did not provide a real-time view, which was a big drawback. When we configured something in production with BMC, we couldn't even validate whether the settings were correct and whether it was working as expected. It also didn't provide real-time data. It tells you only when something has happened. It sends you an alert when something is broken. We didn't want a monitoring tool only to know when something is broken. So, we started to look at other tools available in the market, and we found ITRS Geneos to be the best tool. Its usage expanded pretty quickly. We started with a few applications, and very quickly, our organization understood its benefit against the investment. We started migrating applications to it, and now, half of our organization is using ITRS Geneos. It took one to two years for us to identify and understand the benefits of this tool.

What we had, and still have, was more low-level than what I would have been involved with. It would have been more on the operating system level.

We added Geneos because we needed more visibility into the application. The other solution only looks at whether the machine is there and running or not.

Prior to Geneos we used a few solutions, but they were very restrictive in what we could do. We could only do process up/down and log file monitoring, whereas Geneos has a huge range of other things that we can monitor.

When I started, they had one of the original versions of ITRS Gateway. Now, everything is Gateway 2, but this was the original Gateway. As time went on, we were bought out and another company came in and they were using Nagios. I converted all of their monitoring from Nagios to ITRS. Our current company was using Check_MK, and I took all the servers that they had in Check_MK and brought them into ITRS as well. We wanted our NOC to have a single pane of glass to look at the entire environment. Having them look at an ITRS console, a Nagios console, and a Check_MK console was just too much. So I consolidated everything into one.

Through the migrations, I've learned how to use those other solutions. I even did a proof of concept with Nagios, because when one of the companies saw how expensive ITRS was, they asked me if we could do everything in Nagios that we're doing in ITRS. I attempted to do it, but one of the big problems was our extensive log file monitoring. Right now we have six ITRS Gateway servers, although it's really only three because the other three are just the backups. To create that same solution with Nagios, I would have needed over 20 servers. It wasn't feasible.

I also eventually looked at Check_MK, but the problem was that it's really just for system-level monitoring. It doesn't really get too extensive with application monitoring, and with the amount of application monitoring that we have deployed, I don't think it would have been possible to do with Check_MK.

ITRS is expensive but their service is second to none. And if you have any problems, they usually resolve them within a day or two. 

There is no comparison when it comes to the visual presentation, between ITRS and Nagios. The Nagios front-end is horrible. It's very difficult to figure out what's alerting and what's broken. With the ITRS console, it's immediate. If you have your filters set correctly you can see exactly which servers and which managed entities are having an issue. 

The time it takes to get an alert is about the same in ITRS and Nagios. It really depends on how things are configured. We have checks in ITRS that are configured for every 20 seconds. Some of them are every five seconds. You can do the same in Nagios. But the actual viewing of the events is much easier in the ITRS console than it is in the Nagios console.

The ITRS gateway is also easier to deploy than Nagios.

Nagios and Check_MK are both cheaper solutions but you get what you pay for. The amount of money that you can save with those solutions would be needed for someone in the background, doing a lot of development work to replicate what we're doing in ITRS. You could get cost savings upfront, but you're going to pay for it in the end with the development work.

In those days we only used home-baked solutions, but nothing commercial. Someone else made the choice to go with Geneos. It was prior to my involvement. We thought, "That looks okay."

No

I have used Wily Introscope and Nagios, but they are not as comprehensive as ITRS.

Previously we had an HPE service for monitoring and before that we had Nagios. The flaw in them was that we only received emails. One dedicated person had to continuously monitor the mail to get action taken when there were alerts. What helped us with ITRS was the real-time monitoring, where the alerts are coming in on the GUI itself. This has resulted in faster action when there are alerts. Events are immediately captured in the ITRS dashboard.

We checked various other tools and the monitoring techniques on the market, as well as the techniques used by ITRS. We found that the ITRS monitoring techniques, whether by polling or reading the files, was capturing the data more effectively and showing it on a dashboard which is more intuitive. Here, everything is done based on the trading system that is on the one gateway server. The monitoring techniques that the internal ITRS dashboard is using are more effective than the other monitoring techniques. That's why we opted for ITRS.

We have historically supported many different monitoring systems, however one of the major reasons for switching was a previous system was not being developed further due to an end of live announcement. ITRS Geneos is commonplace on client sites and our teams had prior exposure or expertise. New staff can be trained on Geneos in a short amount of time and a solid user of Geneos can pull much more out of the system than previous alternatives.

I worked with other monitoring tools like Nagios and I found Nagios is a bit hard to enter in the agents and to understand the services. But Geneos is very easy and it's very interesting to understand and to work with it.

I work with Geneos now because I switched companies. 

We previously used a monitoring system that sent alerts to our phones or sent emails to us. We also have a team dedicated to monitoring and sending us mail. It was inefficient and a worse form of monitoring overall.

Not at the customer where I’m working at the moment.

The reason for choosing ITRS Geneos was the availability of its wide range of out of the box plugins and its visualization layer that simplifies and represents the application components well.

This was the first product I used, so I do not have a comparison.

We used Icinga (a Nagios-Clone) before and currently still do in various areas. Geneos has been introduced due to the need for real-time monitoring and notification and for the excellent possibilities to publish monitoring results via web servers.

Yes we did. Geneos is a highly configurable monitoring system with many built-in plug-ins and offers great functionality. All of this aside, the breach predictor was one of the selling points. The old product was missing many of the expected out of the box functionalities.

Our previous product had poor functionally and of poor quality.

We previously used IBM Tivoli for our monitoring needs.

There were custom in house solutions that we are replacing with vendor products.

Various iterations of TIB Hawk, Traverse, and in-house written apps had sufficed, but never truly provided centralized, customizable, easy to use, and market data specific monitoring available via ITRS Geneos.

We switched because this covers everything we need to monitor in one place.

This is the first time we are using a product that has the capability to monitor everything in one place.

No previous solution used.

Tivoli was used prior to my start. I personally used PRTG and ITRS is significantly better.

We used Sentinel which was awesome but it did not provide metric views.

No

No previous solution was used.

I did not previously use a different solution; it's recommended in the project and cheap.

We previously used Nagios, but switched to Geneos as it has better monitoring for applications. Also, it has more features and better configuration possibilities.

We didn't use anything previously.

Yes and we switched due to company preference.