ITRS Geneos Reviews

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.

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.

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.

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.

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.

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.

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.

The solution is being used in the treasury management space, specifically to monitor the health of the technology estate. At this point, we have built out infrastructure monitoring as well as things like log monitoring and process monitoring; all those basics. The main use case is actually to build dashboards for our production support team to be able to have a high-, mid-, and low-level view of that technology estate.

The applications we monitor are financial services applications, treasury specifically.

With customizable dashboards, we've been able to build visibility across a very large portfolio of applications rapidly and consolidate the views. With ApDynamics, which is the other primary product here, we can't do anything like that at all. Building a dashboard like that is almost impossible. And even if we did build it, it wouldn't load. It would just be too heavy. With Geneos, it's very easy, especially in the web-based dashboard.