ITRS Geneos Reviews

It is for application monitoring. So, we are using it for basic infrastructure, process up/down and log file monitoring to create metrics, and alerts. Then, we extended the use to cover creating more of a system management console, so we could stop and start a process from the console without having to go into the box to do the change. 

Across the bank, every team needs to provide a Ready For Business status, which is shown in a centralised web page for ease of viewing. As the bank is very large, it is down to the application teams as to what tool they choose to use, and in this instance individuals would manually update the webpage status for their area. We used Geneos to start automating that process, which helps provide a holistic health across all applications, and due to the nature of Geneos, also enables downstream applications to understand the health of their upstream providers. 

Geneos is an agent that runs on the host. The agent collects the information, then provides it through to a console. The analysts can then see all the information coming through on the console.

We started linking applications together. As a large company with a lot of individual support teams, most teams will support their own application. However, if you think of it from a business flow point of view, the business requires those applications to work together for the business to actually work. We have been able to link the applications together and can see the health of applications, which are two to more steps removed from where we are. During an incident, people will first start looking at their own application, then realize there is nothing wrong with the application. So, they go and ask the upstream app team. Now, they can see if the app three steps before them has a problem, which is probably the reason why my app is not working as expected.

The solution is used across the entire investment banking division, covering environments such as electronic trading, algo-trading, fixed income, FX, etc. It monitors that environment and enables a bank to significantly reduce down time. Although hard to measure, since implementation, we have probably seen some increased stability because of it and we have definitely seen teams a lot more aware of their environment. Consequently, we can be more proactive in challenging and improving previously undetected weaknesses. For example, we recently started to use it for managing certificates when we were having issues with certificate expiry to validate that certificates were not due to expire, or had been correctly refreshed and as a result significantly reduced the certificate failures in this space by about 70 percent over a period of 12 months. This improvement was predominantly down to the visibility Geneos provided. Due to the certain standard configs leveraged with Geneos this enabled us to be very quick and nimble as we could just create the required scripts and push them out to all the Geneos instances to be deployed easily. So, all the different teams could leverage this capability with a high level of reuse.

In my previous role, I used to use Geneos for market data. It plugs into the Thomson Reuters platform and was very good on the market data. Geneos provides lightweight data collection that sits on the host, which we run on time-critical servers and it doesn't have any performance impacts when doing electronic trading.

If a server CPU is at 90 percent, you can get that alert within seconds with any monitoring system. Therefore, what is more relevant is: 

• How do you manage those alerts? 
• How you consolidated those alerts so you are getting relevant information. 

With Geneos, you can alert on certain thresholds, so there can be warnings, or if you have an action on it, then it can then bump it up to the top. 

We are using it to set thresholds, so we can see what is occurring and intervene beforehand.

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

The flexibility of the console is probably the biggest value. It is the ease in which you can pull the data together onto a screen. You can pivot the screen to however you choose to look at it. So, you can take a simple approach, and it can show business flow. Then, you can give it to a manager or business user who can see their flow and it quickly helps with the flow. Therefore, you create more of a technical view and look at more of the environment through a construction or routine lens.

The second biggest value is the ease of being able to configure and modify alerts to better manage them.

The third biggest value is that you can automate responses, so you can get it to run scripts. You can invoke a script automatically based on an event or can trigger manually if you want to carefully manage the situation. We also integrated it into ServiceNow, so if there is an event on the console, then we automatically generate a ticket, so there is an audit trail. The added benefit of ServiceNow integration is that you can leverage the on-call functionality to provide responses out of hours.

Mobile phone integration is probably not as rich as it could be.

Another area where I would like to see some improvement is around visualising the environment. At the moment, drawing the estate within Geneos is a very manual process, so it would be better if there was a reusable database behind it that can link the environment to the configuration. For example, read a CMDB to provide the view of how it works together. Or, if not feasible to read the CMDB, put the effort into creating your diagram and generating a CMDB from it. This would be very valuable because App teams have to pull stuff together, to show where host A is in relationship to host B, and at the moment this is a lot of manual effort with very little reusability.

I have been using Geneos pretty much since I have been at the bank. I have been at the bank for eight years and used it in two roles. When I joined the bank, I headed up market data and the bank was already using Geneos. So, it was already in place when I joined. Then, I changed roles and moved into applications support for the front office, where I introduced Geneos and helped create an enterprise deal enabling it to be rolled out across all areas of the front office.

It is stable.

There is very little maintenance for Geneos itself. Sometimes, you have to upgrade it. Effort is more about building standards and improving the capability of the solution.

It scales relatively well.

About 8,000 hosts are covered by it.

User roles are predominantly application support.

The technical support is good. I haven't encountered them directly, but I know some guys who have and they have been relatively responsive.

I normally deal with the account team. I have had a number of sessions with them, which have been quite good. Where there have been gaps in the product, they have taken that feedback onboard, then tried to enhance the product.

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

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

There are different ways of doing it. I think installing Geneos itself is relatively straightforward. When you use Geneos to scale, then you can do it one of two ways: 

1. You can give each team Geneos, and they can do it themselves. That is not ideal because they end up setting it up in slightly different ways. 
2. You can try to have a central team engineer it, which is better, but obviously it takes longer to do that. 

If you said, "I have a small estate that I want to get monitored," then getting in and instrumenting your estate from zero to having it done can be done in a relatively short period of time.

When I rolled this out to my area, I just gave it to individual teams, as I felt we were behind where we needed to be from a monitoring perspective. I just said, "Look, get the product out there. Start using it. Let's get some value out of it. Then, at some point in the future, we will work out how we converge onto some standards." Which is what we did.

Another team, who came a little bit later, saw what we had done and the benefits we were getting, but had the benefit of having some central engineering team, took the time to engineer it and have a standard, then they pushed that standard across. Although this took longer to deploy, there are benefits because they can now do things quicker with that standard. My area then started converging onto that standard, but we had to kind of do almost a double build. 

All things considered, if I went through the same thing again, I would still probably do it the way I did it because we started getting value out of the product straight away, which was critical for me due to the immaturity of our monitoring, rather than waiting to build a consistent approach, then pushing out.

For each team in each area, it probably took about two months to start getting them from zero to having it deployed, then getting value back on it. Some of them were quicker than that, if they had previous experience with it. For the teams that had zero experience, it probably took about two months. More sophisticated monitoring and automation takes a bit longer and if you are looking to instrument your whole environment, especially if you're doing it without any incremental / dedicated resources, then you are probably looking at a couple of years. 

We didn't have any incremental bodies to go and do this. The existing production support team did it themselves. There was no additional funding to go and build this capability out. It was just the existing guys during their day job. I was like, "This will help you. Get this done, and start using it."

We have seen ROI because the environment is far better managed.

When I first came in, their pricing was very high. ITRS had a high expectation of what their price should be based on perceived value. I think they have been realizing, more recently, that there are other competitors, so their pricing is a lot better. Licensing for on-premise is okay, however I feel there is quite some work to be done for cloud and  containers. We're still working with them to try and work out what that pricing should look like.

In terms of value, you have to negotiate with them to get a good deal for the product, but that is no different to any other vendor. I think if you don't negotiate, then you will end up paying a relatively higher price for it. If you negotiate, you can get a lot better deal.

We have a tiered pricing model with an ELA. Every other year, we agree on what the pricing is. We work out how many licenses we are using. It is all predefined, because when we started the contract, we agreed the rate card and made sure that price increases were RPI type price increases.  I feel that is a good model, as previously we didn't have an ELA, we had loads of individual contracts and everyone was paying a different price. The pricing wasn't that competitive nor that great, but we spent some time putting all those contracts together to get a global pricing.

There are some optional add-ons, if you want them.

We looked at some other tools, predominantly AppDynamics. It comes in a slightly different perspective. It is aimed more at performance monitoring. It was a lot harder to derive the value out of it, than what we have done from Geneos. Geneos was an easier tool for the teams to get used to, on-board, and immediately get value out of it. AppDynamics was one of those things where you have to spend an awful lot of time before you can get value out of it. It is also more suited for certain applications than others, where Geneos is a bit more generic and can probably work in most spaces.

We were also evaluating some home grown solutions, which were lower cost solutions. In my opinion, Geneos wins against homegrown solutions, as it has been around for a number of years and a lot of people have fed into the ideas. So, it has evolved due to feedback from various clients, because there is a dedicated team behind Geneos product. Whereas, if you think about home grown solutions, they are limited by your experience and rarely mature as funding ultimately becomes an issue, so end up not as function-rich as Geneos.

If you look at some competitors, such AppDynamics, they probably have a better way of discovering dependencies as well as connectivity to them. That aspect is probably another area for Geneos to improve on.

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.

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 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 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.

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 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 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.