ITRS Geneos Reviews

I was using ITRS Geneos at HSBC. I have been using this product for more than two years. I have 20 years of experience working in IT with software in general. I am working with an on-premises deployment model. The platform's data visualization capabilities have been really good for finding anomalies and addressing issues, and my experience with the product has been really good.

I utilize ITRS Geneos's real-time monitoring. The critical banking applications running at HSBC need more reactive monitoring than a proactive approach. In that way, the product has been providing appropriate insights before an issue arises. The teams are using predictive analytics features of this product.

The automated alerting system really reduces the mean time to respond for an incident failure. The respective on-call engineers and support teams are getting notified before an incident happens.

The advantages and strong points of ITRS Geneos for me personally are seamless integration with existing systems as well as upcoming modern systems. The user interface is really good. From a management point of view, these are the key aspects with respect to the user interface and seamless integration. We get very good community support for this product.

ITRS Geneos has impacted my organization positively, and I would rate it 4.5 out of 5.

I do not see much room for improvement. Support for data cloud platforms could be great. Modern cloud platforms and data cloud platforms require more attention from the product.

I have been using ITRS Geneos at HSBC for more than two years.

The product is really capable of handling large volume data. I do not see many issues with the ability to handle high-frequency data.

I would rate 9 out of 10 with respect to ITRS Geneos's support, support metrics, and their support delivery.

I have worked with multiple products including ServiceNow, Splunk, AppDynamics, and PagerDuty.

I have not deployed the product myself. The product was already running at HSBC when I joined. However, the operational experience has been really good because I was the observability architect for HSBC. I received very good feedback from the HSBC end-users as well as the application owners and service owners.

I was not part of the deployment team. I cannot comment on the deployment timeframe because organizations at the scale of HSBC require a minimum timeframe for deployment.

ITRS Geneos helps improve decision-making and analysis. With respect to post-mortems during incidents, it really helps during root cause analysis.

I do not have the pricing information because it lies with the finance team.

We are using ITRS Geneos for availability and performance monitoring. With respect to availability, there have been no observations of any business functionalities being impacted. All capacity parameters are okay. We are also using the solution for the performance part, where all the latency, the number of messages, the rates, and the number of external client logins are monitored. Lastly, we use the solution to monitor all the hardware capacity parameters such as CPU, disk, and memory usage for all applications. 

We use the application logs, as well as OEM logs. We monitor the processing rates, the number of messages processed, and the number of external login clients. We also monitor whether any exception handling or code has been created. Because our application does not involve a database, we are not monitoring database activity. We monitor inside the applications, to see whether the server is on primary mode or has gone to secondary mode, whether the failure has happened or not, as well as the configuration part that all the application configs are intact, there are no changes in the application configs, that we monitor. We also monitor the applications to make sure the connectivity across the various modules and various servers are there, which are interconnected either through PCP or our protocol. We are also monitoring the downstream systems and upstream systems. 

Our previous solution alerted us through an SMS or email. The alert would go to one person whose job is to monitor and if they were busy with another activity we would be delayed in responding to the situation. With ITRS Geneos, we can see everything on the dashboard. We can see the relationship between the two email alerts. We can also see the whole picture of where the issue is, allowing us to take action quickly. We can detect the actual connections between the two alerts. Suppose my alert comes from one server, and another alert comes from the client, we know there is a potential issue between the two servers and client connectivity. An email or SMS alert will never give us the full picture. So, at that time, I had to go into the system and focus on what the issue actually was. That was quite difficult. But now, with the new system, it's more proactive. We have started to monitor the system more closely because many of the alerts that we didn't have before are now enabled. For example, we have thresholds that warn us when we need to reduce space.

We first started to use ITRS Geneos in our department in 2014. After that, the solution was implemented in other departments, and the downstream systems inherited the monitoring. Trading is just one part of the organization where monitoring is now taking place; other systems, such as risk surveillance and collateral management, have also been upgraded. As an organization, we need to have a holistic view. This means that if I am a HOD, I need to have a holistic view of not only trading but also downstream systems. Previously, the senior manager did not have any view of what the issue was, where it was, and what the impact was. This is because there are many downstream systems that can be impacted. Now, with the holistic view in place, the senior manager is able to see where the issue is and where the impact is.

The solution provides lightweight data collection. We have recently had a business dashboard as well. Along with order messages and client logins, we are also monitoring capacity reports, view logs, and business reports. We have captured all of this information and put it in our database. We can see a historical view of user logins, latency, and whether or not it has improved.

With the help of the solution, we can predict and prevent failures. Many times, one incident can lead to another event. For example, if we have three modules and there is a buildup in module C, and there are observations and issues, ITRS Geneos can help monitor the buildup. If one of our people is trying to resolve the issues in module C, the monitoring person can also monitor the back pressure going to module A, then I will start checking the impact for modules A and C. Since we have the complete end-to-end connectivity part, with ITRS Geneos, I can make sure that the issue on the one server or the one module can be prevented on the other modules as well. We have prevented multiple P1, and P2 issues using ITRS Geneos.

We monitor the number of incidents proactively every month. This number is based on the number of incidents that we receive from ITRS Geneos. Roughly, 20 to 30 percent of all incidents are proactively detected and avoided using the solution. Whenever any incident comes up, the first question we ask is why wasn't it caught in the monitoring. In the last eight years, we have actually progressed so much with the solution, we configured multiple rules and multiple samplers, using ITRS Geneos because of each and every incident we learn from.

One of the most valuable features of ITRS Geneos is the active time feature that helps with the trading applications that I support. The HP OpenView solution we previously used worked on a 24-hour seven days week cycle but the market hours are 9:00 AM to 3:30 PM. 

ITRS Geneos has good GUIs that provide us with a single view of all the various applications. We have around 500 servers, and monitoring 500 servers on individual devices is a bit challenging. Putting the various applications in a single GUI is very difficult. In ITRS Geneos, all the GUI and user-friendly dashboards are there. All the information is available at a glance, we have five segments in case any one segment, or any one problem occurs, we can highlight it, and we follow the steps. We then access the active console which is a step-by-step detailed view to resolve the issue.

Currently, the most valuable thing for an individual is a mobile device. Since that is where people are currently tracking everything, we have multiple applications or apps that are for various products. I would like ITRS Geneos to develop an app, where instead of going to specific login terminals or logging into laptops or desktops to check alerts, we can have visibility in the app itself. Using the ITRS Geneos app, we could see the error message during our travels or wherever we are. 

I would like to see the capacity of messages for forecasting increased. Since the NSE is the number one derivative stock exchange in the work for three consecutive years, the number of messages is important. We use the capacity planner in ITRS to forecast our data needs for the next two months. The planner is important because the volume of data we produce is becoming more and more volatile compared to when we first started using ITRS Geneos in 2014.

I have been using the solution for eight years.

ITRS Geneos is a stable product and we have not had any downtime in the past eight years. The stability portion is good, but we do need to configure new applications correctly for the solution to stay stable.

The solution is scalable. We are the number one derivative stock exchange, and our number of servers has increased significantly in recent years. In 2014, the number of servers was 50, but now it is 500, ten times as many. Our gateway servers were also limited to around five, but now there are 15. This increase in scalability has allowed our maintenance team to deploy more gateway servers and improve our monitoring gateways. We are also looking into redundancy and unused data to further improve performance.

We currently have 120 people using the solution in our department and around 400 from all of the departments, including vendors.

The technical support for ITRS is currently very good. The person who developed or implemented the ITRS dashboard previously provided technical support for us, so he has a good understanding of the system. Additionally, many of the deadlines for ITRS are set by top management. ITRS is seen as a high priority, so there is good response time from the ITRS-managed service currently.

Positive

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.

There were a few team members involved with the deployment. I was there with respect to providing any details to ITRS Geneos or the signup portion of the solution, the testing of the ITRS, such as whether alerts are showing properly or not. At that time, I was involved in all these areas of deployment because we have various segments in our module. We started with only a specific segment. Initially, we focused on the GUI design, how it should look and what rules should be configured, and where it should come from. All those nitty-gritty details of importance are required for the ITRS dashboard. I was not responsible for the creation of the samplers, the installation of Netprobes, or the entering of rules. There was a separate team responsible for those tasks.

Developers faced a challenge when there was no database, but they soon found ways to overcome this obstacle. They had to monitor the application, logs, and other aspects of the system. After four to six months, they started to figure out how to monitor specific aspects of the system if there were multiple items that needed to be monitored. We need to consider three things: the first is whether ITRS will have a file or tooling mechanism; the second is whether there will be any impact on production; and the third is whether ITRS will have a built-in script. We have considered these three aspects of ITRS in order to go deeper into the application so Netprobes can act as the agents on the production machine to eliminate any impact. After all the items were gathered, the most important step was putting everything into one active console. This is where I accessed the files and did all of the reading. The fifth month was when we had all the GUIs created and the sixth month was when we started the testing part, making sure all the alerts are configured and displaying correctly. We did all the testing at the end of the day because it was in the production environment. There was some hard work that was put in, and the initial two months were difficult because we didn't know how to do it, or what needed to be planned. We completed deployment for all five segments we support within one year. In the first six months, we completed deployment for only one segment. Subsequently, for the next four months, we deployed with another two segments, and subsequently, in the last two months the entire deployment was complete.

The implementation was completed in-house.

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.

This is a global monitoring tool designed for self-configuration administration and flexibility. This makes it popular among banking industries and top-tier companies. I work for a bank and I'm in the financial market domain. My market domain applications are the FX market, equities, the stock market, and settlement, which are all monitored through ITRS Geneos.

ITRS Geneos provides lightweight data collection. The tool is outside the application. Most other monitoring tools are deployed within the application. When we deploy a monitoring tool, it may have a side impact on the application. This can be due to the tool using a lot of CPU and memory, which can degrade the performance of the main application. We need to be very careful when choosing a monitoring tool so that it doesn't have a negative impact on our applications. ITRS Geneos is a great tool for data collection. It sits outside the application, which provides flexibility in defining what data is needed and what level of CPU or memory is allowed for collection. Additionally, the tool can be preset to collect a certain type of data, such as one to ten data points. Next time, it also collects one to ten data points but it sees only the changes in the sixth row. The tool sends only the sixth row to reduce the latency between the application servers and the gateway. That's where the data collection is well-optimized in ITRS Geneos.

ITRS Geneos is a great tool that is being used by all top-tier banks. The tool can prevent and predict failure depending on how we use the tool. I headed up the support teams at two banks using the tool. Another advantage of the tool is that it never restricts us. The new trading application has a lot of flexibility. For example, we can connect the monitoring tool to see alerts, we can use the standard monitoring checks that are available, or we can build our own monitoring tool to plug into ITRS Geneos. We can also build the trading system or our own system that we want to see down into the system. This flexibility allows us to prevent or predict problems, depending on our implementation.

Real-time data is one of the unique features that ITRS Geneos offers. For example, if there is an impact on a particular server and a particular application, I want to see what the impact is or what the CPU or hardware usage information is, as well as the service in the same application. I can see the real-time data and the impact by accessing ITRS Geneos and looking at the tree.

I don't want a tool that tells me when something is broken. I want the tool to tell me when something is going to break. That is the difference between ITRS Geneos and other tools. I want proactive monitoring, not reactive. I don't need to be notified after the fact that something has broken. If something is broken, I get a notification by email, and some of my customers are going to call me. ITRS Geneos provides proactive monitoring.

The great advantage of this tool is real-time monitoring. ITRS Geneos not only alerts us but also gives us a real-time view of the data. This is the tool's first great advantage. It is also lightweight and flexible and can adapt to monitor even low-latency systems, which is the tool's second advantage. Another great feature of this tool is its good presentation layer, which allows us to build custom dashboards to present to business stakeholders. This gives them a high-level status of what is being monitored. If we compare ITRS Geneos to other tools, we will find that each one specializes in a specific area, but the ITRS Geneos tool is more comprehensive. This is its great advantage.

ITRS Geneos cloud monitoring is very weak and can use improvement. I have been exploring other monitoring tools for the cloud space," but ITRS needs to look into it because the way it is being implemented or it is available at this moment is too complex to use. I'm able to manage my stakeholder expectations until the cloud introduction. After the cloud introduction, I see there is a gap that ITRS cannot fit into, and I'm looking for some custom stories. ITRS needs to focus on the cloud space.

I have been using the tool for 14 years.

ITRS Geneos is a very stable tool.

ITRS Geneos is a tool that can be scaled without limitations. 

We currently have between 3,000 and 4,000 people using ITRS Geneos.

I have worked with ITRS technical support for many years. A lot of the support staff I have met in person. When I need assistance I provide them with clear details including the binary, operating system, and what plug-in is being used. This way, I receive a straightforward response back from the technical support team. I believe two to three email exchanges are necessary in order to collect the initial response between the customer and the ITRS vendor. To avoid this, I think the vendor could improve their input template. By ensuring all the information is keyed in after one search, the user will be forced to give all the information before initiating the email conversation. This will help to improve the response time.

I always give feedback, but it seems they don't want to let me create videos and publish them. People find it difficult to read through pages of documentation, and they may not want to do that. Making videos would make it easier for them. These are two areas that I think need improvement when it comes to the support team.

Positive

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.

Initially, I found the tool to be frustrating and disliked it. I was worried that I would be kicked out for not being able to use the tool. However, I found that it is a great tool once I got used to the initial setup, which may be a bit complex for some people. It can take someone two to three weeks to become an expert in using this monitoring tool. Overall, it is a great tool.

We always hire consultants for six months or one year to help set up our monitoring tools. Once they're set up, we have experts who learn from them and then take over.

Monitoring is not an easy task. It's difficult to estimate the return on investment for monitoring investments. It's difficult to say for sure. Based on my experience, I've gone through multiple products, but I have not found a suitable tool to replace ITRS yet.

The people who work for me right now are working in multiple monitoring industrial spaces such as oil companies or middleware companies, production companies, and the banking, finance, and insurance industries. I have people right now working in different domains. The price for ITRS is okay for the banking industry. ITRS Geneos is not a cheap tool. It's a moderate price for the banking industry. The reason we are not able to add the ITRS monitoring tool for the non-banking industries, and non-finance industries, is that the pricing is too high.

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.

We use Geneos for infrastructure and application monitoring. I have used this solution for three or four companies. The use cases were slightly different for each, but it primarily monitored infrastructure and applications. You can also use it for market data monitoring. 

We monitor applications in the financial industry, including cash management and trading departments, as well as corporate, private, and retail banking. All these teams use Geneos, and some of my previous clients use it for data center monitoring. 

Geneos is deployed on public and private clouds and on-premises data centers. We use Geneos in all three environments. My clients use various public cloud providers, including AWS and Azure. 

Geneos provides near-real-time data if the underlying infrastructure is sufficient. The time to get a response depends on the kind of alert you set. All monitoring tools have multiple alert methods. 

You can receive an alert within the tool where it flags the issue on the dashboards. You get real-time alerts in Geneos. You can also receive alerts via email. That is quick unless your email system has some delay latency. Geneos sends alerts within 20 to 30 seconds. It will throw the alert to your inbox and 13 chatbots. You can configure Geneos with chatbots also in real-time.

The primary benefit to our company is the dashboard. We have a management dashboard that highlights business-critical alerts to management. We have a high-level dashboard for management and a technical dashboard for L2 and L3 engineers. The help desk and other L1 departments have their own dashboard. 

The dashboard has improved our business significantly because it provides visibility into the entire operation from one screen. It offers a traffic-light mechanism. When there is an issue in North America or South America, Geneos immediately alerts you and the management that there is something we need to look into. 

Geneos can predict and resolve problems through automation. Geneos will automatically restore the service several times when a service goes down based on our configuration. It prevents a couple of outages each month where the services do not come back online following a server restart.

The remarkable feature of Geneos is the dashboard. Geneos' flexible dashboard sets it apart from other monitoring tools. Other solutions have limitations in their dashboard design and can't be customized as much. The Geneos dashboard allows unlimited creativity.  

Geneos' application monitoring could be improved a lot. Products like AppDynamics and Dynatrace provide the process of thread-level monitoring, but Geneos lacks these capabilities. I rate Geneos six out of 10 for data collection because it isn't lightweight compared to AppDynamics and Dynatrace.

The solution's specialty is its dashboards, and I feel like it hasn't developed this functionality much over the past nine years. The dashboard is robust and excellent, but the capabilities could be updated. 

I've used Geneos for nearly nine years.

I rate Geneos eight out of 10 for stability. There is some lag and a few bugs, but the vendor addresses issues quickly when we complain. They will note the bug and attempt to resolve the problem in the next release. 

The scalability is poor. You will experience some performance issues when you add more clients. The dashboard is their best feature, but it's complex and lacks auto-scaling capabilities. If you're monitoring thousands of machines, you need separate gateways to monitor them. If you have a thousand servers, you need to split that into five gateways with 200 servers each. Otherwise, performance will be sluggish. 

I rate Geneos support three out of 10. I seldom contact Geneos, but I haven't been happy with their support. Their response time is slow, and there are communication gaps because their help desk is only available from Manilla. There are also some language issues. I'm not saying they are incompetent, but their support is sub-par in terms of communication. 

Negative

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 was involved with the solution architecture and engineering team. We build the monitoring tools, collect the requirements from internal clients, set up the monitoring for their applications, design dashboards, etc.

Deploying Geneos is straightforward. The Geneos agent can be quickly installed on Linux and Windows. The Windows agent is relatively time-consuming compared to Linux because Windows has some limitations. The installation and configuration are straightforward, and their documentation is excellent. Anyone with moderate knowledge of infrastructure can follow the documentation.

After deployment, Geneos requires some maintenance. For example, the agent sometimes crashes, so we must manually restart it. 

Geneos is a little costly, but it's worth the money.

Based on feedback from colleagues and friends working in the financial sector, Geneos is relatively costly. Many companies have been switching from Geneos to Dynatrace, Sysdig, or other monitoring tools in the past two years because of the price. 

We evaluated SolarWinds and Dynatrace. Dynatrace is more focused on application monitoring, but we use Geneos for dashboards in spite of its other limitations. Geneos is our dashboard and front-end monitoring application.

Geneos enables us to identify all the issues happening within a given period. Though it lacks some advanced monitoring capabilities that other tools have, it's the best dashboard for our purposes. We tried Prometheus and one of the open-source tools. We also evaluated Nagios. None of those solutions had the same dashboard capability.

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.

It is one solution for all monitoring needs. For one of the banks, we were using different products because each product had specific features. Then we came across ITRS Geneos, which provides comprehensive monitoring from the application level, and is very configurable and customizable. At the second bank, I was part of the team that onboarded the support from one customer or vendor to another. The third bank was evaluating multiple products and decided to use ITRS Geneos across the bank, replacing multiple solutions.

Using the solution we can set the sampling of the data every two seconds. This will ensure that the monitoring is done every two seconds, and the data will be refreshed and displayed on the dashboard or active console in real-time. The solution's default is two seconds but can be reduced further if needed. 

We aimed to detect any issues or outages before clients reported them by using Geneos or the monitoring tool. Our goal was to be 100% successful, and we rarely heard about customers raising issues of instability or slowness where our tool was not able to find it first.

The application team in the banks always wants stability in the environment. They never want a product that assists in monitoring to make the system unstable or overloaded. I always appreciate Geneos' stability and ease of use. For example, during a disaster recovery situation, Geneos' configuration is so good that it will automatically handle most of the items a user would not need to do, such as exporting extra resources or configuring the monitoring tool. This is very convenient because if they feel like they need to do something extra during a disaster recovery drill or any other problem, they can focus on that without having to worry about the monitoring tool.

The company started producing its product in 1998. As a mature product, ITRS Geneos has had time to evolve and change along with its customers. 
No product is designed perfectly or works well for all scenarios. Customers request features and the product evolves over time. The solution has a Custom Toolkit plugin to configure and customize our needs if nothing else can be monitored through the inbox.

ITRS Geneos is configurable based on the architecture and therefore provides lightweight data collection. There is one agent running on the machine which needs to be monitored, and the data the particular agent will collect is completely configurable. It can start from very basic monitoring, checking CP utilization and memory, and go to a much deeper analysis of the data by installing more plugins, like messaging queues, IBM MQ monitoring, and so on. One of the best features is that the solution is very configurable because it is an evolved product of over 20 years, and it can still run on machines that are not really good with system resources. These machines have less CPU and memory, and the solution can run on those machines also without taking much capacity and without slowing down the application itself.

A lot of solutions now use AI to predict and prevent failure. ITRS Geneos needs to evolve its prediction and prevention capabilities, as AI-based monitoring is becoming more important. Earlier, it was just alert-based. Most organizations look towards artificial intelligence-based monitoring solutions. Products such as Dynatrace rely more on artificial intelligence using algorithms to predict future failures, which is a plus point compared to ITRS Geneos. If the solution can use AI to monitor trends and provide analysis without having to wait for the threshold to be reached it would be very helpful.

Recently, the infrastructure has been moving from bare metal or a physical server to more cloud-based infrastructure. Being an older solution, the architecture is still perfect for physical machine monitoring. However, ITRS Geneos is improving and evolving in cloud-based monitoring. But there are some specific tools that are better than ITRS Geneos in cloud-based monitoring, which are strictly cloud-based. For the solution to stay relevant in the cloud-based monitoring environment Geneos needs more plug-ins with more features. Instead of offering clients workarounds, the solution should have a cloud-based out-of-the-box version.

I have been using the solution for seven years.

One of the aspects I really liked about Geneos is that it is stable. It keeps the application stable where it is running and doesn't disturb the environment it is monitoring. This is a big plus point because the noise of monitoring can start to bother us and make our environment unstable. Geneos has an edge in that it is fairly stable and doesn't disturb the environment.

The solution is scalable but only if it is done manually. It is not smart enough to scale itself based on need. The scalability must be handled manually, so the maintenance manager or support team will have to go and set up additional servers and gateways. ITRS Geneos doesn't have the intelligence to scale itself.

The technical support is good. Customers can log in, create tickets, and follow up on them. They can also escalate tickets if necessary. There are escalation points in the system, and people to whom customers can raise tickets. The ticketing system is effective and efficient. Geneos does have experienced support people who can provide good answers. However, I have heard that they didn't get the proper response from them on some occasions. The key is that if a client can escalate the issue and request dedicated support to the particular client based on how the contract agreement is set up, Geneos has put more experienced clients on dedicated support.

Positive

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.

After deployment, there is some work that needs to be done by individual application teams who want to use ITRS Geneos. For example, if there are 100 applications and 10 teams supporting them, then each team will need to evaluate how best to use the solution. ITRS Geneos provides professional services when it is deployed at an organization. Organizations often look for professional services during deployment because these professionals can provide the best configuration for the organization. Usually, an organization will take a professional services contract for six months, one year, or two years, depending on how fast they want to deploy their new application. Geneos provides these professional services, which makes the deployment much easier and quicker. If they didn't provide these services, it would be very challenging for the application teams to implement themselves.

On average, deployment can take anywhere from three to six months for multiple teams to fully switch over to ITRS Geneos and stop using their previous solutions.

The gateways are the core components of the Geneos architecture. They act as the nervous system of the software, collecting data from various sources and sending it to the other components for processing. The gateways are deployed on-premises and are designed for ITRS Geneos. The gateways are deployed across the regions to increase residency. The deployments are implemented one time and then the upgrades are pushed through orchestration tools. The UI part of the thin client is pushed as any application software on our desktops from the server. Any new upgrades are pushed either through the Orchestrator tool at the server level or the Windows-based tool for updates or patching.

Usually, when a bank starts accepting or starts migrating from other tools to Geneos, there is a team of five to seven people who work on deployment, which is the engineering team or the people who are actually working on the ground; maybe a couple of project managers in the different regions working along with other projects, pushing this project as well. However, after the deployment is done and the user community gets knowledge and awareness of this solution, we slowly see banks dismantle this team. This team is no longer required since application teams are autonomous and can get help directly from the support. Depending on the organization's size, our bank had a team of seven people set up with project managers and professional services colleagues in Europe, Asia, and America. The deployments usually have a centralized team to support all of the regional teams. The user teams or application teams became more hands-on over time and could manage the tool themselves. The team of seven people was usually dismantled and only one or two people who were subject-matter experts were left to support when required.

The implementation was completed in-house with the help of ITRS' professional services team.

We were definitely successful in reducing the number of severe incidents. Our targets were to reduce the number of high-severity incidents, which occur when there is a delay in noticing or finding out about an incident, and then the customer raises it to us. By detecting and at least providing a workaround or fix before the customer notices, we improve our KPIs by reducing the number of high-severity incidents. That is what we see as a return on investment because we avoid the penalty by addressing the incidents quickly.

The pricing is based on a deal that is evaluated based on future utilization and other components. The organization is not just purchasing a license for the product, but also managing services and professional services from ITRS. Another factor is if the implementation is going to be in production, non-production, or both.

I work with other products like Dynatrace and they are lacking in that they have a minimum interval and are still evolving to increase their real-time monitoring. However, they are working on specific features to improve that. Currently, they don't have the real-time monitoring that ITRS Geneos has.

When we were evaluating or comparing other products, we found that some products for installation and data collection require another Java virtual machine. The base was set up as a Java virtual machine on the client machine and then extracted the data collection. ITRS Geneos directly uses operating system calls to fetch data, so it doesn't need another layer or another software installed. With other solutions, it becomes difficult sometimes because a Java virtual machine itself requires some resources, CPU, and memory. This can cause delays or affect the actual application running.

There was a comparison going on between BMC tools and ITRS Geneos. The bank's strategy was not to rely on one tool but to use ITRS Geneos for critical applications that require timely messages, instead of relying on the in-house monitoring tools. Banks don't mind paying the license fees for the solution instead of using the infrastructure-provided monitoring tool or custom in-house builder monitoring tools.

Open-source tools have become more popular in the last 5 to 10 years. Linux, for example, comes with Prometheus, a monitoring tool. However, these open-source tools are not suitable for global monitoring and cannot be used across the bank. We cannot create a dashboard out of it where it links multiple applications hosted on different environments and different kinds of applications. We needed some sort of proprietary tool or a license-based tool that can be used as a global tool for the whole department, or for the whole BU, not just specific to the product or applications.

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.

We are a bank that caters to the FX business which is a high-revenue application. The solution provides us with a shorter turnaround time, in the event that something goes wrong. We evaluated a few other tools, and then considered the applications that we are using. ITRS has been providing the required solutions for our use cases.

ITRS provides proactive monitoring so that we are aware of any outages in advance. Because we are also in the FX business, we have custom monitoring enabled. This allows us to see any spikes in rates ahead of time and take corrective action based on that information. We've received a lot of feedback from traders that they appreciate this proactive approach and have been able to take action based on market volatility.

It provides us with lightweight data collection.

I have been using this solution for a while now and I can say each week we can detect and avoid on average between three to five outages. This helps at the beginning of the week when there are usually more problems. Once we avoid those issues, the rest of the week runs smoother.

The flexibility to have our custom scripts cater to the application monitoring needs is one of the most important features that I value in the ITRS Geneos tool. Though ITRS provides us with certain plugins, there are a few use cases wherein the application team wants to have their own monitoring, such as doing our tracing on FX deals by leveraging the custom modules. We can easily plug the custom scripts into ITRS either in Java or by using a Python program and having the monitoring in place.

The solution's log monitoring and alerting mechanisms are very user-friendly and easy to plug and play.

In relation to real-time data, the Geneos tool from ITRS is a great tool for monitoring physical servers and virtual machines. However, it falls a bit short when it comes to monitoring containerized platforms running on OpenShift. That said, the real-time monitoring capabilities are still very effective for monitoring servers and VMs.

I give the solution a seven out of ten in its ability to predict and prevent failure.

There is one drawback to using lightweight data collection: we lack the feature of observability based on time series, such as historical model data. This makes it difficult to view data in ITRS. ITRS needs to improve this feature.

The dashboarding needs a lot of improvement. It takes a lot of manual work to get it up and running. The dashboarding also doesn't render automatically according to the screen size. For example, if we create a dashboard on a 14-inch screen and want to put it on a 55-inch TV, the dashboard doesn't automatically render. There is some misalignment. 

Another major feature ITRS lacks is that they don't provide a mobile app to monitor the dashboard. We have to always log in to the laptop to check the necessary details. If these two features improve, I would give the solution a ten out of ten for its ability to prevent failure.

Currently, the ITRS tool is available as a binary. We do not have this particular tool as a containerized module, such as a Docker image. This makes it difficult to set up on the Kubernetes platform. 

I would like to have a feature for tracing on the application side added to the solution. The end user requests data from the application and we need to identify where any delays occur in order to improve application performance. Visualizing the tracing information is helpful in identifying the source of any delays.

I have been using the solution for six years.

The stability is good.

While scalability is easy to achieve, the process can be labor-intensive. Automating the process would make it much more efficient.

Our data center is located in Singapore, we do not have a presence globally. We have around 60 users currently.

The technical support team is excellent. They are able to understand our needs and provide us with the appropriate answers.

Positive

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 initial setup was straightforward. 

It took almost two or three days to have the complete setup running, and following the production process, it took another week.

We implemented ITRS with 50 servers being monitored. We decided on the number of gateways and also looked for the high availability of the monitoring system. We onboarded the servers and had agents installed separately on them. We had a team of three people who were able to bring everything into production within one week.

The implementation was completed in-house.

We have seen a return on investment because we saved money by managing our alerts proactively. This avoided any downtime, which made the traders happy. 
We were able to keep our application running almost 99.9% of the time.

The market tools are on par with this solution, but if the solution included more features, then it would be well within the range for the cost.

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.

We use it for monitoring and visibility of all our production environments from a foreign exchange perspective. 

At the current stage, we are probably 80% on-prem and 20% on AWS cloud.

We use it for all types of hardware. Most of the apps are built in-house, and the majority are Java or Java-hosted apps. We also monitor IBM MQ and Apache instances, and we've also started monitoring some AWS components and Tomcat components. We also extensively monitor FIX Trading or FIX Protocol.

One of the benefits is to have 24/7 automated monitoring of our most critical services.

In general, it has drastically increased the visibility of our estate. It has definitely improved our response times to issues. We can proactively detect issues and prevent outages as well.

It's very good in terms of real-time data. I've got no objections or concerns about it. It's so customizable. You can decide if you want your data in a real-time view, or you can have a bit of a delay on things. There are a few components that we almost monitor in real-time, and it works perfectly for us.

It provides lightweight data collection. Our servers or other things are not taking any strain since day one with it. We are quite comfortable with the load. Almost none is placed on our servers at the moment by this tool. So, it's cool.

It is very good for predicting and preventing failures. It comes back to the customization of the product. Depending on your business case and use case, you can customize it to prevent anything you don't want to end up with. It's very good. It's difficult to know the number of outages detected or avoided by using the solution. It is probably more than 80%. If we don't detect something, we would normally just go back and say, "Okay, why didn't we pick up this particular issue?" We will look at what options are there to prevent it next time round. So, this percentage obviously increases.

The flexibility of the product is most valuable. It is highly customizable. If you put your mind to it and think of something you could do, there's a good possibility you can get it integrated within the console, if it's not readily available. The simplicity or ease of customization has been valuable.

For the last year or two, I've been asking the vendor about the mobile app. This is something that probably everyone asks when they see the tool and they see how powerful it is. If there is any mobile app for this or if there is any way this tool can be more easily accessible other than having a big client installed, it would be great. I know you can build dashboards, et cetera, but there is no quick and easy way. I should be able to download an app, log in, and see my status. That will put this product above everything else out there. I believe it's on their roadmap.

Other than that, we are not looking for any features. Initially, when we started, they were just, for example, Windows compatible from a front-end console perspective, but that has evolved over time. Now, they can run on Linux, Mac, etc. So, that's great. There was a bit of pushback initially, but after that has been sorted, the next question everyone is asking is obviously being mobile. What can I do remotely? Do I have to physically log in? Do I have to open up my laptop? That's the next big thing everywhere. People sometimes just want to glance at something or have the mobile opportunity to do things.

We've probably been using it for the last seven to eight years.

Its stability is very impressive. It's very solid. We haven't had any flaky stuff going on in the last couple of years. We obviously follow the recommendations and baseline regarding setup, et cetera. In that regard, we haven't had any serious issues.

It is definitely scalable. Five or six different departments within our organization are using this monitoring solution. We've got AWS, and geographically, we have systems in South Africa, and we've also got a few in the UK. Overall, there are about 20 to 30 users of this solution.

We have plans to increase its usage. It's currently the only monitoring solution on our slate. With the thoughts of going to AWS, et cetera, this is always part of our journey. It depends on what comes up in the near future, but if anything develops in our world, the first question that comes up is what's going to monitor it? Is Geneos coming along? Can it be done? Et cetera.

They're very good. We've been working with it for quite a few years now. So, it is quite soothing to know that there is someone who knows more than you if you really get stuck. It does help. We haven't come across a scenario where they couldn't help us.

Positive

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. 

I basically inherited it. I don't know who did it before me, but it was a bit of a mess when I started. I was thrown into the deep end, but I wasn't personally involved initially. I just took it over.

There is no maintenance in terms of struggling to keep it going, but there's always this constant drive for improvement. There is a constant drive to improve the monitoring and add new scenarios that we haven't thought about or didn't cover. So, there is an ongoing drive to enhance, but that's not maintenance per se.

We have indeed seen an ROI. In the industry that we're working in, if the systems that are being monitored by this solution are all down, we could potentially look at losing a million SA rands an hour. That's the potential loss we are working with. That in itself speaks volumes versus the licensing cost we need to pay for this a year. That just gives an idea. If we don't have this monitoring in place and we lose the systems per se, we could lose what we pay now for licensing probably in about an hour. So, there is definitely value.

The pricing is fairly market-related. They have been very lenient because we have been working with them for so long. An example is that we're currently migrating some of our services to AWS, and they've given us a grace period for some of the things to help with the migration and not to grow additional costs while we are migrating, but it's still on par with the market.

I believe they did consider open-source or lower-cost alternatives. The topic also has come up when licenses would be renewed, et cetera. We know what we are paying for, and we're getting value for the money as well.

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.

We use it for one purpose since we are in the banking sector, so we have the infrastructure, log monitoring, and all. We are doing all of these with ITRS Geneos.

ITRS Geneos has different plug-ins, or, like, we have log monitoring plug-ins like file monitoring. Also, ITRS Geneos' dashboard feature is good.

Speaking about room for improvement, ITRS Geneos is not on the cloud at a time when everyone is moving to the cloud. I definitely know that they have some monitoring extensions or plug-ins for the cloud, but it needs to be explored more, especially for the different features and whatever we have in different cloud areas. So we need more things available for the cloud as well.

Cloud already has features that make it stable. So, if they make the solution available on the cloud, then it will be stable.

I have experience with ITRS Geneos. I am a customer of the solution who is using it at my current workplace, which is a bank.

Stability-wise, I rate the solution an eight out of ten.

Scalability and stability are both parallel things. Hence, I rate it an eight out of ten for both.

More than 5,000 people in my organization use the solution.

Whenever we have new issues that we are facing, we contact ITRS Geneos. So we just need to get them, and they support us. I had a good experience with the support.

Regarding the initial setup's ease and difficulty, I would say it was moderate.

I can say it's not that cheap because the licensing is a little bit costly. So, definitely, we had to pay a certain amount to use it.

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 used mainly for application monitoring. We monitor the process log files, web URLs, JVM, SQL Database, etc. There are several things. There are over a hundred plugins available with ITRS, and we use the plugins based on our license agreement.

ITRS Geneos gives real-time data. For example, we have an incident in the production environment related to a particular server that might be impacting applications' connectivity. With Geneos monitoring, with a high-level view, at a glance, we can see all the applications that are impacted. It gives a real-time view. We don't even need to log in to the server to verify the status one by one.

ITRS Geneos provides lightweight data collection. I've been working with this solution for a long time, and I know that they take only the changes when they collect data. They don't take the whole dump of data every five seconds. For example, if I want to monitor a process every thirty seconds in an application server, it would check the process every thirty seconds. Only if there is a status change, it gets reported into the gateway and notified by the user. It doesn't send duplicate data. It reduces data transfer within the network. It's lightweight.

ITRS Geneos can predict and prevent failure. Generally, people go and set up the basic configuration and just monitor the infrastructure, processes, and other basic things. It also can identify that something is going to break. For example, if my CPU usage is 70%, I can predict that it's going to break in three or six months. There is a way to use historical data to predict when it's going to break. However, it's hard to measure the issues detected and outages avoided by using this solution. When you prevent something from breaking, it's hard to estimate the loss that you have prevented. Generally, in our organization, we have P1, P2, and P3 incidents, and our target is to reduce them by 15% to 30% and increase the availability of the systems for the users.

It's a very powerful application monitoring tool across the industry. Many free, open-source tools are available. There are also paid tools, but ITRS Geneos is a real-time application monitoring tool where the user can monitor, self-configure, and manage alerts through their console. We don't even need to log into the server to fix a problem.

Their cloud monitoring solution needs to be improved. I have already given them the feedback that it's not capable of meeting the latest technology needs.

It's built like proprietary software. I can't expose the data to ITRS, and similarly, ITRS can't expose the data to the outside world. They have created a boundary. It's a bit binding solution. In the modern world, people like to be able to expose the data to do whatever they want. They can query the data, send it, or pull it. ITRS needs to provide more in terms of the API offering.

They have documentation, but they can improve the documentation and provide videos to show how to do monitoring configuration or deployment.

I've been using this solution for 13 years.

In the early days, around 2009 or 2010, there were performance issues, which have been addressed. Over the last five to six years, we haven't faced any kind of challenges related to stability. As long as your deployment is correct and you implement it in the right way following the recommendations, it's a very stable product.

It's scalable.

Their support is good. I'd rate them an eight out of ten.

Positive

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.

We haven't deployed it on the cloud because it isn't good in the cloud even though they claim that it supports the cloud. We have deployed it on-premises on a physical server.

Its deployment is okay. It's not too complex, and it's also not too easy. It can be installed easily by using documentation.

The implementation duration depends on the scale of the environment. For example, deploying it for two thousand servers may take more than a year. For 50 to 100 servers, it can take two months. Organizations have their processes for deployment, release approval, and change process. There are so many things to follow, but on average, a small-scale implementation with 50 to 100 servers can be done within one quarter.

Its setup varies based on the organization. I can have the central monitoring in one location, which can be connected to all servers running in the US, UK, Japan, etc. A single setup like this is feasible on a small scale with 100 or 200 servers. If you have 4,000 or 5,000 servers, you may need a regional setup, and then you have to integrate the regional setup with the global one.

I have worked for three to four organizations, and the very first time, I took the help of a consultant to do the deployment. After that, in other companies, I did it on my own. You don't need many resources for deployment.

In terms of maintenance, I've been doing it for quite a long time. It's easy for me, but other people may find it a bit difficult. I find it quite straightforward.

Based on my experience, to build such a solution in-house, you require eight to ten developers. You have to follow the release process, maintain the code, and do check-ins and check-outs. You have to take care of many things, and you have to pay for human resources. You have to pay for the hardware and maintain the code. You need to retain the knowledge, and continuously maintain the resource within the team or organization. All this can be easily eliminated with ITRS. Initially, I wasn't very comfortable with it, but later on, I realized that it can remove all those expenses. It's also extensive, whereas you can't just go and expansively build your own monitoring solution.

Its price is reasonable. It isn't too expensive, and it isn't too cheap, but it also depends on a company's volume and negotiation. 

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.

We have multiple teams in multiple locations using it to monitor multiple environments, including UAT, production, and dev.

The solution has been instrumental in reducing our incidents that were related to monitoring issues that we had spotted, but because in our previous system those issues were sent by email and none of them got action. It has helped us avoid many Sev 1 or “system down” issues, as well as Sev 2 issues, because the monitoring is so effective.

It has also detected issues before any other of our corporate monitoring tools have identified them. For getting out in front of a problem before it happens, it's absolutely superb. Obviously, that's down to the design of the actual alerting that we put in place, but Geneos allows us to do that. Alerts are quite visible, very obvious on the console in the tree structure. It’s helping us do what we're trying to do, which is avoid instances for our clients before they notice them. It has been instrumental in doing that.

I'm a massive fan of Geneos and I’m not even sure where to start when it comes to valuable features. I live and die in it and that has been the case for the last four or five years.

The ability to completely tailor and customize what it's monitoring is one of its strongest points. A lot of other monitoring tools are good at certain things, but one of my colleagues described it as the “Swiss Army Knife” of monitoring tools. It can do anything you want. And if something you need is not built-in to the product, you can quite easily build it yourself. As a developer/support engineer, that's perfect. The capacity to completely customize it in any way — incoming stuff, outgoing integrations with the tools — is quite powerful.

The tree structure that you can create in the monitoring tool itself is also very useful.

We've also bought Datadog at an enterprise level. That solution looks really pretty. Personally, I don't like that but a lot of senior management, the non-technical guys, do like that. ITRS have started to make some major changes that we haven't taken on board yet, in the creation of dashboards and more visibility of the metrics that we collect. At the moment, that's something that's lacking, but I know they have addressed it. Still, it’s not that easy to create stuff to help with visibility and dashboarding in Geneos.

I have been using ITRS Geneos for about five years.

The stability is better now. We had some issues early on, about three years ago. I'm not saying that they were the product's fault, they may have been mine. But now, it's very stable and doesn't require a lot of coaxing to keep running.

It’s scalable. We've gone from one product and about five servers up to eight products that we supply, and there are over 300 servers that we're monitoring now. And I envision that doubling, at least, in the next couple of years.

We have it in three data centers across the globe. Although I work for one particular part of our company, with one particular product, which is where we started, I have also rolled it out to other teams and trained them. We use it in a federated model where we provide the platform, train up someone on those teams, and they then administer their own alerts.

We have about 400 users who have access to the console itself.

Their technical support is superb. Absolutely amazing. If our support team for our own products was as good as theirs, we would be brilliant. They are really good. There are a couple of guys there who are absolutely excellent.

Positive

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's a complex product, but we had some direct onsite support from two implementation guys for several weeks and they assisted. Once they'd shown me the ropes, it was fairly straightforward.

In its out-of-the-box form, it takes a few hours to deploy. But it then takes a long while to build up that monitoring catalog.

From a technical point of view, we started seeing results instantly, because it resolved the issue of our having to maintain all of our custom-created scripts. But it truly came into its own only about a year after deployment. It took us six months to a year to fully implement it. But Geneos knows how many alerts it has created for a certain “client environment,” and we could then look at those alerts and tune them a lot more easily than we could have with an email system.

Our implementation strategy involved starting out with fairly vanilla, cross-environment samples that we created in Geneos, while running the old monitoring tools, our script/email calls, in parallel. That allowed us to gain confidence in Geneos. We ran them in parallel for a few weeks and analyzed the results. As we gained confidence, we slowly moved more and more of the functions of our old monitoring tools into Geneos.

I was the main person on our side involved and I had a little help from the rest of the support team.

For us, it doesn't require any maintenance, but it all depends on how you automate things. For example, because we are a multi-country organization, each country has different daylight savings changes. Because we've automated that, it's hands-off. But, out-of-the-box, you don't need to do any maintenance at all.

I don't generally get involved with ROI at a metrics level, but Geneos has definitely helped when it comes to getting ahead of a potential client issue before it occurs. That doesn’t affect ROI directly but, in some cases, it would save us because we have SLAs with our clients. There would definitely be reputational as well as some cost savings, because we've detected problems before or as they're happening and before the client notices. Quantifying that is very difficult. How do you quantify the reputation of how good your service is?

Given our spend and the amount of service we have in it, the pricing is quite reasonable.

We have not bought Geneos at an enterprise level. If we did pursue that, it would be a lot cheaper. But there haven’t been any complaints about the licensing model. And we actually don't pay for UAT, which is quite unique in the industry at the moment. We only pay for production licenses.

Of course, it has to run on a server, so there was a cost for that. There is also a database server behind it with a small cost for that. Other than that, there are no additional costs, and they provided training for free.

We played with Micro Focus SiteScope, Splunk, and various other tools. They're all very good in their own right for certain elements, but Datadog didn’t exist then. Geneos seemed to do everything we wanted in one place, to create that single-pane-of-glass view that we didn't have.

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.