What advice do you have for others considering ITRS Geneos?

Overall, I rate the solution a five out of ten.

To those planning to use the solution, I would say that it is an easy-to-use monitoring tool. Amongst the available monitoring tools, it is a really good option. I rate the overall tool an eight out of ten.

It's very powerful. They just need to improve the cloud and API offerings. I've been working in the finance industry for 18 years. It's a top-tier tool, and it's being used by more than 200 organizations in the world. I'd recommend ITRS Geneos, but it also depends on the use case. To people working in the finance industry, I'd recommend it. However, it might not be suitable for non-finance industries because they might be looking for a cheap monitoring solution, and ITRS Geneos won't suit them. Overall, I'd rate ITRS Geneos an eight out of ten.

I give the tool an eight out of ten. Over the years, the latency between the monitoring tools on the market has closed. A decade ago, BMC took over five minutes to provide an alert. Currently, AppDynamics and BMC claim that their alerts are within 20 seconds. ITRS Geneos provides real-time alerts. In my honest opinion, ITRS Geneos has great potential and can be leveraged to any level. It is hard to predict how many outages we have avoided using ITRS Geneos because, in the monitoring industry, we define the key monitoring standards that are required to build, deploy, monitor, and fix a problem. Each time there is a situation we define new monitoring practices and deploy them across the organization. We don't want any business impact. The number of alerts is being produced by ITRS Geneos, which means so many issues are being detected. It's not an exact tally, but it gives us a sense of how many issues are being caused and how fast the PSS team is fixing them. The maintenance is based on the number of binary changes each year, for example, there are graphical GUIs, a gateway, and the network. When we deploy the binary, we set up some customization, and the tool starts working. The business is going to keep on asking for new enhancements, which is going to be one part of the maintenance. The ITRS Geneos tool is continuously improving, fixing, or adding new features. They release a new binary every quarter. At a minimum, we need to upgrade the binary every year. In order to upgrade the binary, we need to have the correct amount of people. It depends on the situation. For example, at my previous bank, I had almost 40,000 pieces of production hardware. I had almost 11 people for maintenance and support. In my current department, I have two to three people because the number of servers is very large, which is nearly 2,000 file servers.

I give the solution a nine out of ten. We had only two people doing the setup, the manager and one other person. I was mostly a tester, testing the applications and making sure everything was in order for the solution. There were four of us in total during the deployment process. There are currently five to six people on a separate tooling team that handles ITRS Geneos. I am no longer part of the ITRS team. Previously, ITRS Geneos was only implemented in trading operations from 2014 to 2015. In 2016, we started to use it in other departments as well. By 2017, all the departments were using the ITRS Geneos. There are five to six departments where the solution is used. In fact, we have created an exchange one view as well as a dashboard where we can look at six to seven departments as a single view. In case any specific department has any issues, the warning critical alert will come from that view. The solution requires maintenance. There is a separate tooling team that takes care of ITRS Geneos. There are five people who are looking into all the maintenance, patching, and all areas of the gateway servers for the solution. Additionally, there are two more activities. The first activity is with respect to the uptime availability part related to gateway servers. The second activity is with respect to releases. If there are any application changes, whether the change has been done in the solution or not, they will also be taken care of. We are also evaluating new dashboards and features, such as our use of ICT and forecasting. There is a separate team who looks into all of this maintenance and development. Plus there is an onsite team in Manila. For any mission-critical projects, I recommend ITRS Geneos because time is crucial. Everything needs to be resolved within five minutes, and the SLA is strict. To resolve incidents within a five-minute window, we need to monitor and escalate within 30 seconds. The team should focus on monitoring and recovery within the first 30 seconds.

I rate Geneos seven out of 10. If you are primarily doing application monitoring, I would recommend AppDynamics or Dynatrace instead of Geneos. Go with Geneos If you want infrastructure and market data monitoring.

I give the solution a nine out of ten. ITRS Geneos has many plugins that are specific to monitoring, such as file transfer monitoring and log file monitoring. As a result, it has become very versatile and can be used for every application in a bank. We use the solution for critical business applications where even a single second can make a difference, such as trading. The trading-related critical applications we use are the bank's three platinum applications. They have plugins to monitor other products as well, so we monitored everything using ITRS Geneos. The solution needs a minimum amount of maintenance, as new versions will be deployed and works will be fixed. Therefore, it is necessary to have one or two resources who can manage the maintenance. Over time, if a new version is released, it needs to be deployed. This is why it is important to have a team who monitors whether an upgraded solution from ITRS is delivered and whether we are using an older version. We need to keep in check and work with the vendor to ensure that we are up to date. This requires some level of maintenance, mostly to upgrade to the latest version with new features and bug fixes. Our deployment model is: one server, with 16 CPUs and 64 gigabytes of RAM, can monitor 300 physical servers or 300 servers. This way, the number of servers required for monitoring is based on the number of servers and applications in the organization. For example, if an organization has 1,200 servers, it will need four primary gateways and four backup gateways, for a total of eight servers. This is a manageable number, as it can monitor 1,200 servers without using too many resources. If we are looking for a single solution that can meet the needs of our entire organization, Geneos is a good tool. However, if we are happy to deploy multiple solutions for different monitoring needs, applications, and businesses, those solutions are available. It may be that we can choose different solutions, but the other solutions are only good in some specific areas. If bank strategy or organization strategy dictates that we have one tool across the organization, then ITRS Geneos is best in that case because it is one that is very customizable and very much configurable based on different needs.

I give the solution seven out of ten. We usually don't update our software often, but we do it every quarter to keep our customers happy. My advice would be that new users to the solution need to determine the use case and the number of systems they want to monitor. ITRS provides a great monitoring solution for physical servers and virtual machines, but if they're planning to focus on the observability of applications, there are two drawbacks they need to consider.

Based on what we've learned over the years, start with the end goal or plan with the end goal in mind. It'll save you a lot of time. If you start with what you want, with that vision, you could build around that instead of just trying to build and doing the basics. It's going to save you a lot of time. You can immediately see its benefit after the deployment, but the more you work with it, on it, and expand it, you start seeing additional benefits. It comes back to the customizable part of things. The more you play with other types of add-ons, you tend to realize where you can use them and which other places you would benefit from them. I would rate it a 9 out of 10. If there was a mobile app, I would've given it a 10.

Definitely do a PoC, but beyond that my advice would depend on where you're coming from. It's a very technical tool, but we are doing very technical monitoring. We're not doing website monitoring, for example, although it does do that. It is helpful that you understand what you're trying to monitor first. You need to have a really clear idea what is an actual alert in your system before you do anything else. That's critical. Overall, the tool is superb.

Determine the scale you need. If you do want to go enterprise-wide, it probably is worthwhile standardizing on the design. However, if you're already a small shop and bleeding (have no effective monitoring in place), then just get out of there as quickly as possible and think about standardizing afterwards. Think about what you want from the product. The product is very capable, so you can just use it for monitoring, but you can get a lot more value out of it by sharing with a business to demonstrate business flows and picture it in that dimension. Definitely consider the automation or scripting capabilities of the product, which are very powerful. This avoids you having to jump onto boxes and run commands yourself. You can script them, which means you avoid people making mistakes or human errors. The solution’s web-based UI is functional. It is not as rich and as powerful as a console, but it gives managers in business a high-level view of the environment. An analyst or support person is probably better off with a console rather than a web-based view. We haven't really played with the application performance monitoring too much. I believe the stuff they have come out with will help us start seeing trends over time and be better improved in them. However, I haven't really tested that part out. We are not using it for predictive analysis. I would rate this solution as an eight out of 10.

The configuration can be very flexible, which is great when you're trying to do something, but it means that if you're just starting out, there is more than one way to do something. Take professional advice, use the ITRS website, understand how everything fits together first, and then proceed. Try to get a consistent configuration design across all of your applications. A lesson learned from using Geneos would be to get buy-in from the people who are the users of Geneos. Get them onboard nice and early. Get them familiar with the tool. It does take time to understand how the tool works, so invest in training.

If you want a critical, secure, and regulated environment and to do powerful and flexible rules, you should choose Geneos. I would rate Geneos an eight and a half out of ten. Not a ten because when the Gateway was very overloaded it was very hard to monitor the alerts, especially for the product services. The situation would be very critical. Otherwise, it's a very good, excellent tool.

We are not the team that's monitoring the real-time data. We have a different team that set up the Geneos for that. We are really relying on Geneos for everyday tasks. All the monitoring is in Geneos and we are going to continue using it. We are pretty happy with Geneos and I would rate it at the higher end, a nine out of 10.

Follow the standards that ITRS provides. Their support is second to none and they will always guide you in the right direction. At any given time we have at least 20 users connected to all the gateways, and that's not everybody because we're a global company. It's when the offices are open that people connect to it. They are the NOC users. They're all in Manila and they watch the screens and make sure if anything is alarming that a ticket is opened for the correct group. We have some of our system engineers who are looking at it for server-level errors. We also have production engineers who are responsible for the trading applications. They are also looking at the consoles to see if anything's alerting.

One of the really distinguishing and good things about ITRS is that it is a small company and they are extremely helpful. They have been extraordinary to work with in every respect: true customer service and a genuine care about the customer, which is not what I normally find from monitoring-tool vendors. It's a tremendous tool and the company is so easy to work with that even if you just want to try it out or see what it can do for you, they make it very easy to do that in a no-risk situation.

It's a very good tool to use and everybody is very happy with it. We are looking forward to more features. Not all the data that is being captured is currently being stored completely in the right ITRS dashboards. There is a project in progress for collecting the data and storing it for capacity and numbers purposes. We have seen a demo related to data collection for capacity planning and it looks very useful, as do the capacity reports. But that project is still in the roll-out phase and will take a couple of months. The next feature we are looking at rolling out is the integration with the ticketing tool. That is planned for the next four to five months. We are now looking at integrating small things into ITRS. If any incident or issue comes up, the first thing we ask is, "Why isn't it part of ITRS? How can this be integrated into ITRS?" Any small activities, challenges, or issues which we foresee in our day-to-day operations, we look at how we can implement them in ITRS. This is a more proactive kind of approach. So it's not only for current alerts but we can also implement things for the future in ITRS. I would rate ITRS at nine out of ten. Everything is being monitored by ITRS. The reason it's not a ten is that, because it's an integral part of all our operations, if anything fails in ITRS, we're not sure where we would go. We are almost over-dependent on ITRS.

It would be sensible to use experienced staff. Although I say you can get up and running with little or zero experience, and then go on the journey yourself, if you want to get up and running quicker, then use experienced staff. It's not essential, you don't have to, but if you have a choice... I don't necessarily mean experienced in terms of the product itself, Geneos. Use staff that has higher experience in production support and in seeing problems first-hand. They're the ones who will know what to set up and monitor. Use someone who has real-world experience in seeing what those problems are, and maybe even supporting it themselves. They need to be at the call face or inside of the call face, and the daily problems. Don't use a developer in the back room who just gets a problem ticket every so often, but someone who is involved in the firefighting so they can see the real problems that you're trying to solve. Those real problems include having issues being picked up in a timely manner, and what's needed to quickly focus on where the problem is. Someone in a back room who receives a problem ticket isn't going to understand all the processes that have been followed to raise that problem ticket. You need someone at the call face who sees all the arguments between the different teams, each one saying, "It's not my problem." They need to see people scratching their heads and thinking, "I don't know where this comes from." All those real-world problems. To sum it up, use someone who has real-world experience in dealing with production support first-hand, or in direct sight of first-hand. I feel that quite strongly. In our organization, the solution is extensively used, and we're happy with that coverage. It's used across seven business divisions. We have a complex licensing arrangement. The number of users is in the hundreds. We don't have plans to increase nor demise. It's stable, it's serving a purpose, and we're happy with it. It's always dangerous to give a solution a ten out of ten, because it can strive. And a seven is pretty neutral. It's got an area where it could improve, in the IT analytics, so I'm going to give it an eight because there are two steps for improvement to get that IT analytics done.