ITRS Geneos Reviews

We use it to monitor all our production servers, our UAT servers, as well as all the trading applications that are running on them. Additionally, we use some of the other features to monitor some of the network equipment via SNMP. Our NOC is watching the screens I created for them using the Geneos dashboards and the Event Ticker. They open cases for specific teams, depending on where the alert is coming from. It gets routed to the correct group and they resolve the issue.

For the most part, our applications are fixed protocol trading applications. We have a host of products and they're all unique. They range from process monitoring to log file monitoring to API. For example, the trading application has an API which sends data into the ITRS gateway and that displays information. We have rules written around that.

We use the Web Dashboard and it's great. You have to take the time to create the dashboards. I'm the only person administering ITRS at this point, and with over 500 servers and a lot of applications I don't have a lot of time to create dashboards.

When I first started, they were having outages daily. A lot of times it was the customer that was calling saying, "Hey, we're having a problem. Can you please look into this?" The alerts weren't even there. Our company didn't have an ITRS administrator. Someone from the New York ITRS office would come out once a week and do whatever he could, but he wasn't full-time. Once I became full-time, I was able to clean everything up, make sure only the required alerts were being generated, and that allowed the production team to actually see, "Oh, okay, this is broken right now," and enabled them to fix it. 

It has allowed us to be less reactive and more proactive when it comes to issues. The consolidation of all the other monitoring applications into one allows the NOC to see everything more clearly as well. It definitely improved the overall functionality of the trading applications because we are able to see stuff alerting much more easily.

In terms of the number of issues we have detected and outages avoided, I wouldn't even know where to begin with that. It's a large environment, so we have issues every day. I don't know that I can quantify them.

The log file monitoring is probably what we use most extensively, especially the FKM sampler. That would be the one we utilize the most for scraping log files and looking for our messages.

In terms of the solution's real-time data, it's great. I can't say enough about it. I've evaluated many other products, including Nagios, because everyone wants to use stuff that's cheap — ITRS is very expensive — as well as Check_MK and some stuff from HPE, and nothing provides a solution like ITRS does. It's definitely the best solution that I've used, as far as real-time monitoring goes. You immediately get a pop up if something is broken. It's easy to see what's broken and what's not. 

The filtering in the Active Console is exceptional. Depending on the user base, some people don't want to see server-level errors, so we have filters set up in the Managed Entities view, which allow us to filter out things that certain groups don't want to see, while allowing them to see other things. It's a great real-time monitoring solution. And you can draw graphs immediately, right from the Active Console, whether they're current graphs or historical graphs.

It also provides lightweight data collection. We have numerous metrics being logged to the database. As an example, in Europe we have the MiFID requirements where time-tracking on all the servers has to be logged to a database. At any point, regulators can come in and say that they want to see that data. We use ITRS for tracking that. We do the same in the US for a FINRA requirement where we're tracking NTP. We log all the NTP data, the offset drift to say, "Okay, you're off from this stratum." That gets dumped into the database. We then have a weekly report that runs and which is put into long-term storage for seven years. It definitely is good for doing that.

They have the Webslinger solution where you can see when something is alerting. It's a little bit cumbersome.

I've been using Geneos for over 12 years.

It's absolutely stable. I've never had a problem with the actual ITRS gateway software.

I definitely found bugs early on and they would correct them pretty quickly. But in the last five years I haven't found any bugs, and if we ever have an outage it's because of either the network or the server that the gateway is running on. But the software is absolutely stable. It's probably the most stable software that I'm responsible for at this point.

It's absolutely scalable. 

The only place that we have a problem with scalability is with what is called the UL Bridge dashboard. That is an API stream that goes to the net probe. We're just sending so much data that sometimes the net probe suspends, so we're not seeing the data. That's the only place where we really have an issue. But I don't think it's the ITRS functionality that is responsible. I think it's our software just sending too much data.

In terms of the possibility of increasing usage, everything is pretty stable. The servers that we have them on are all Linux servers with more than enough CPU and memory. I've never really run into a utilization problem on any of the servers where ITRS is running.

I don't only administer this application, I'm also responsible for other applications. As an example, I have another application that has been broken for over a month now and I've had to open three separate cases with the company and the issue still isn't resolved. They keep telling me, "Well, it's a different issue. You have to open up another case." But with ITRS support, I can go off on a tangent: "No, I found this and this and this and this," and it all goes under one case and it all gets solved within a day or two.

I've been working with ITRS support for 12 years and I have a very good relationship with the New York office. There have been plenty of things that I've recommended that came out within one or two releases of the next versions of the software.

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

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

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

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

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

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

The ITRS gateway is also easier to deploy than Nagios.

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

We have absolutely seen return on our investment with ITRS. The stability of the trading applications with Geneos means it pays for itself.

Pricing is the touchy subject, even here. Upper management always wants us to find a cheaper solution. But we have so much integrated with ITRS. For example, in one of our environments we have extensive client notifications, so if a client session goes down, they immediately get an email. It's automated. We don't have to do anything. That's a feature that our clients really like. It's expensive, but it does its job very well. And you set it and go.

Follow the standards that ITRS provides. Their support is second to none and they will always guide you in the right direction.

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

We are monitoring uptime, availability, and performance of the trading systems through the ITRS dashboards. We have five segments and we have created all the applications and dashboards for these segments. 

We are monitoring online and have created a separate, integrated monitoring room where we have installed all the Geneos dashboard screens and we have a separate group of people monitoring these tools. In case of any alerts, there are mechanisms for escalation.

Currently, we have not only provided dashboards to IT operations, but we have provided them to other departments as well. For example, the hardware team has its own dashboard, and the network team has its own dashboards. The business team also recently started using dashboards.

The types of applications we monitor start with trading applications. We have a cash market, futures and options, and through the ITRS dashboards we monitor all the back-end servers. The only thing that is not covered by the dashboards is the front-end, which is used by the members. But all the in-house application servers are covered, as are all the networks switches, all the hardware details, and the software applications for the trading servers. Apart from that, there is a separate interface team that is also monitoring its own dashboards.

Essentially, we are trying to include all the business parameters in the monitoring, those which are used most by the business users. Those parameters are being tracked in the ITRS dashboards. We have divided our dashboards into application processes, logs, hardware, and network. All these dashboards are combined and are visible in an Exchange one-view dashboard which is visible at the executive level.

On a yearly basis, we identify around 50 to 60 incidents through ITRS. Typically, we don't have outages to our critical systems. We haven't had any in the last three to four years. So while ITRS has not been involved in avoiding outages, there have been one or two critical issues which it detects each year. Those have not resulted in outages, but there would have been major business impact from them. We detected them due to ITRS.

It enables us to monitor application processes, to do log-monitoring on a 24/7 basis, to do server-level monitoring - all the hardware parameters - as well as monitor connectivity across applications to the interfaces.

The ITRS dashboards monitor real-time data. There are two processes. One is that it reads from files via netprobes that are installed on all the servers. They read the respective online files which are updated every two seconds and then display the online data. The second process is that the dashboards are updated through scripts. ITRS servers run scripts and collect all the data. That is how real-time monitoring is done.

It also provides integration with ticketing tools. Whenever there is an alert, ITRS can directly open a ticket in a particular ticketing tool.

We can also view the logs from the time of an alert and back, or at ten minutes before the alerts, or two hours or one day before the alert.

We are also able to shift all the rules from one server to another.

And recently, we have started using automated actions when there are critical alerts.

We have introduced many of the monitoring processes in the past five to six months, for the trading dashboards and the business team. We have segmented gateway servers doing the monitoring. Sometimes, if there is a lot of data coming onto the servers, we have observed a little bit of slowness on the gateway servers which are doing the ITRS dashboard monitoring.

I believe the plan is that the tooling team will divide the gateway servers into two, with half of the application trading servers monitored by one gateway server and the other half monitored by another gateway server.

In our organization, every department is very much dependent on ITRS. For me, the basic concern is the contingency planning for ITRS. For example, if a dashboard server stops working tomorrow there is a concern. Contingency is a concern; something needs to be planned. We have not observed any failures in the ITRS dashboards. But because of the dependency of every department on the ITRS dashboards, this is a major concern. The trading server availability is dependent upon the server availability of the dashboards.

Up until now, there has been no failure in ITRS. Currently, it's stable. Because the number of servers, the monitoring alerts, rules, and categories is increasing, we have to increase the number of data servers. But it's currently stable. There is no problem with the stability of ITRS.

Because we have an enterprise license there is no issue with scalability.

If the number of servers increases, we have enough licenses to cover that. As far as the dashboards are concerned, the number being used by the various departments is fixed.

We have received very good support from technical support. All our tickets, all the changes, have been done in the specified time. We received a good amount of support from them during the initial deployment. Although it was a complex architecture, the deployment went very smoothly. 

And currently, the changes which happen very frequently here, the changes in the dashboards, are done very smoothly. We have not had any issues with support.

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

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

The setup was not straightforward because our system is quite complex. There are multiple servers and segments and departments and, at that time, we had various OS versions. We had some challenges.

We deployed in segments. Our first deployment took around eight months. The next segment of deployment took around three to four months. The third segment took another three to four months. Everything together, all the dashboard deployments completed and all the segments, took between one-and-a-half and two years.

We also had some migrations planned for the trading department at that time, so we integrated the deployment of the dashboards with those migrations. The servers that had already been migrated, where the major architectural changes had already happened, they were where we deployed ITRS first. If we had deployed on the old servers, we would have had to re-do the deployment efforts of ITRS.

The second point in our strategy was that the critical servers were the trading servers. We did the ITRS dashboards on them first, and then, finally, on the hardware and network. And we have targeted the interface servers for later.

We also integrated this with a latency tool, Corvil.

We had a number of people involved in the deployment. There was a manager as well as someone who looked into the basic ingredients of the ITRS dashboards, the coding, etc. Another person was responsible for the user look and feel, how the GUIs would look, as well as the use-cases. There were three people at that time. Now, managed services has started to use the ITRS dashboards, and that is being handled by our separate tooling team. 

When there are any releases or changes made to the trading systems, we inform our tooling team. We create a request for them to make all the changes to the dashboards and they make the changes.

We're now into more of a maintenance process.

Overall, we have about 150 to 200 people using the solution in our organization.

Things like the capacity planning have a separate cost.

We looked at three other monitoring tools, but that was four or five years ago. BMC was one of them and there was an HPE solution as well. We looked at them based on top industry reviews.

We considered HPE open-source, but the GUI features and how fast it displays alerts on the GUI, as well as polling and integration with other third-party tools - they were lagging. We found ITRS more useful.

It's a very good tool to use and everybody is very happy with it. We are looking forward to more features.

Not all the data that is being captured is currently being stored completely in the right ITRS dashboards. There is a project in progress for collecting the data and storing it for capacity and numbers purposes. We have seen a demo related to data collection for capacity planning and it looks very useful, as do the capacity reports. But that project is still in the roll-out phase and will take a couple of months.

The next feature we are looking at rolling out is the integration with the ticketing tool. That is planned for the next four to five months.

We are now looking at integrating small things into ITRS. If any incident or issue comes up, the first thing we ask is, "Why isn't it part of ITRS? How can this be integrated into ITRS?" Any small activities, challenges, or issues which we foresee in our day-to-day operations, we look at how we can implement them in ITRS. This is a more proactive kind of approach. So it's not only for current alerts but we can also implement things for the future in ITRS.

I would rate ITRS at nine out of ten. Everything is being monitored by ITRS. The reason it's not a ten is that, because it's an integral part of all our operations, if anything fails in ITRS, we're not sure where we would go. We are almost over-dependent on ITRS.

We use it for application monitoring.

The people who monitor the applications, the operations staff, are not typically developers. The operations staff can, by themselves, configure that monitoring to react to an issue they've seen. They get a very short and tight feedback loop where they see an issue and they can incrementally improve the monitoring themselves.

The operations staff have a good understanding of the behavior of the application in real life, so they are best placed to update some of that monitoring and they are able to do that when it doesn't require development skills. You'd normally put highly paid, experienced developers on the call face to monitor it in the middle of the night.

One of the most valuable features is that it can be configured by non-developers. It doesn't require development expertise to configure it. 

The ITA, the post-incident analytics, could be improved. They know that. I'm sure they're working on it. That encompasses a whole facet, a whole dimension, of the product.

The stability is quite good. It's what I expect. It's commensurate with a product of that flexibility and price point.

We've used horizontal scaling effectively. Horizontal scaling, by having more of it, more systems, and more processes, works quite well. That horizontal scaling allows us to delegate the administration as well. We've not hit scaling problems ourselves, but if people wanted a big, humongous instance, and they used vertical scaling, I imagine they would.

We've not had problems, but I could imagine some people, if they go the vertical direction, would have problems. That's not uncommon with software technology. I was watching a Google presentation last night and they were saying, "If you go vertical, you will almost certainly hit problems, whereas horizontally, you can just keep scaling forever.

Technical support is excellent, very good. They're very accessible, with them being specifically London-based. Unlike if you went for one of the big providers - which, if you did, you would have to be a very big customer, in a top-tier bank such as ourselves, to have regular meetings with them - we can talk with the product managers, we can get our points across. They're accessible. It's good, we're happy.

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

The initial setup was straightforward. Just put your head down and do it. We got it knocked off in a day. It's fine. It was a long time ago, but it was fine. Straightforward.

My implementation strategy at the time was roll my sleeves up and get stuck in. With it being a practical product, one that you can improve and make changes to, there's not a long ramp to get value out of it. You can get value very quickly out of it. Then you can incrementally build off that. 

You don't need months and years of training to get anything out of it. You can get something out of it, literally, on day one. Then you can increment and improve, as you understand your own requirements, and as you understand the product, and as you mature as an organization.

On all aspects, as you understand more of everything, you can improve your monitoring. So the good thing is you get something out of it day one, you don't need years of training, and then you can build on that.

The deployment was done by just me. 

Once deployed and configured, we distributed maintenance, in that people maintain their own areas. It's not that it requires a certain number of people to maintain it, rather, a lot of different people have input into the rule-setting. Currently, it is just me who maintains it. A very small team would suffice for maintenance.

We've seen increasing stability. Given the problems and issues that software invariably has, we've had the ability to quickly react and identify where those faults lie because we've had monitoring. The return has really been our ability to have confidence that things are good and, when things are bad, our ability to work out quickly and focus on where they are bad.

I believe they went back probably another decade. It went back to the very early market-data days. There wasn't much choice at the time, if any. There was open-source software, such as Nagios that we had looked at. There was some open-source software, but nothing really in the sensible commercial space.

It would be sensible to use experienced staff. Although I say you can get up and running with little or zero experience, and then go on the journey yourself, if you want to get up and running quicker, then use experienced staff. It's not essential, you don't have to, but if you have a choice... I don't necessarily mean experienced in terms of the product itself, Geneos.

Use staff that has higher experience in production support and in seeing problems first-hand. They're the ones who will know what to set up and monitor. Use someone who has real-world experience in seeing what those problems are, and maybe even supporting it themselves. They need to be at the call face or inside of the call face, and the daily problems.

Don't use a developer in the back room who just gets a problem ticket every so often, but someone who is involved in the firefighting so they can see the real problems that you're trying to solve. Those real problems include having issues being picked up in a timely manner, and what's needed to quickly focus on where the problem is. Someone in a back room who receives a problem ticket isn't going to understand all the processes that have been followed to raise that problem ticket. You need someone at the call face who sees all the arguments between the different teams, each one saying, "It's not my problem." They need to see people scratching their heads and thinking, "I don't know where this comes from." All those real-world problems.

To sum it up, use someone who has real-world experience in dealing with production support first-hand, or in direct sight of first-hand. I feel that quite strongly.

In our organization, the solution is extensively used, and we're happy with that coverage. It's used across seven business divisions. We have a complex licensing arrangement. The number of users is in the hundreds. We don't have plans to increase nor demise. It's stable, it's serving a purpose, and we're happy with it.

It's always dangerous to give a solution a ten out of ten, because it can strive. And a seven is pretty neutral. It's got an area where it could improve, in the IT analytics, so I'm going to give it an eight because there are two steps for improvement to get that IT analytics done.

Event Management: Manages alerts from infrastructure, applications, and batch jobs. Performs 24/7 monitoring across our Global Markets platform.

This solution has helped provide relief to existing Level 2 teams, allowing them to focus efforts on in-depth problem analysis.

• Dashboards
• Processes
• FKM
• Disk

These alerts proactively help manage the enterprise operational risk.

A lightweight version which could host more than 100 gateways, as we can see slowness while loading all our gateways. We do support a horizontal platform and having this feature will have an impact in the MTTR.

We have started a project green movement and it is running successfully. The motive is to make sure nothing is red (faulted) and make sure it is immediately monitored and resolved or delegated. This has kept our systems and operations healthy.

This tool allows one to analyse, integrate and customize as per the systems and allows you to set your own rules.

I am hoping to get some good features on the IBM MQ messaging tool, as this is most frequently used in our team.

I would rate technical support 7/10. It's self-explaining and the support is limited.

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

Initial setup is easy. The support team internal to our organization takes care of all the installations.

An in-house team implemented the solution.

It's a very effective and productive tool, and avoids any major incidents.

With ITRS, we are able to monitor in real time our infrastructure, whether it is hard disk failures, number of or failure of processes, and switch port packets being dropped.

ITRS uses SNMP to communicate with our devices as well as SNMP net probes installed on our servers. ITRS’s use of SNMP provides a lot of valuable information from the device without affecting performance.

I would like to see a user community established to assist with implementing and supporting the product.

I would also like to see suggested guidelines to accomplish a monitoring task. The issue is that ITRS is so flexible that there is more than one way to complete a task, each with benefits and disadvantages.

Technical support is 9.5/10.

The Technical Support Specialists know the product very well but not the client environment. I would recommend that a copy of the ITRS configuration for each client reside within a Technical Support Library to assist them in diagnosing and solving each client’s issues. I have no issues with utilizing SFTP to transfer my configuration to an ITRS secure server when I make a change; of course, a Save Online button would help.

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

As stated, the issue is that ITRS is so flexible that there is more than one way to complete a task.

An in-house team implemented it with assistance from ITRS.

This product saves us a lot of time in development.

Plan and implement the initial framework for the enterprise size as reworking for growth would be a challenge.

We have automated some manual system checking processes.

We have monitoring tools that allow us to view individual systems health and issues on its own.

Geneos gives us visibility on all of our systems at once and we can build dashboard views to monitor transactions moving from one system to another. This has greatly assisted with troubleshooting and helped us understand how the system behaves when issues are imminent leading to proactive prevention.

• Custom script toolkits
• Data aggregation
• Alerting rules to emails
• System APIs

Backward compatibility with deprecated features and in system documentation on what configuration areas are needed to be updated: There is a bit of this in place already, but it can be improved.

I've been trying to update to version 3.5 but the gateway will not start up because my configuration contains deprecated features. The error logs are not very helpful and I've been using a tedious trial-and-error process to find out which part of my configuration is disagreeing with the new version.

I could start with a lower version and then work my way up but that would mean upgrading over 50 servers multiple times which is something I'm trying to avoid.

Technical support is great. They have an online ticketing system for support. I find them quite responsive any time of the day.

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

The initial setup was done by the ITRS consultants. They designed a fully customized solution for our system. The basic out-of-the-box monitoring is quite straightforward. The custom solution involved uniquely written scripts to read our application log files.

We started with the vendor team, and then they handed over to me and I became the in-house team. A tip would be to have a dedicated team and give them time to play around with the program. Try all of the features and settings and ask a lot of questions. Geneos has a lot of features and it grows very quickly. Geneos is very flexible. Be sure your Geneos team has a balanced skillset; creative skills as well as technical.

I don't have the figures unfortunately. But the ROI has been growing slowly. We do have a number of other tools and our systems are quite big and complex. I've also met some resistance in the adoption of another monitoring tool from the users. Expect a slow start on ROI with Geneos. In my case, it is finally gaining popularity after catching a number of critical issues that their other monitor tools missed.

It's a lot of work to get started but worth it.

Most enterprises have multiple sites with deployed, disparate resources, and varying data requirements. Geneos gives a real time global view of both resource usage, coupled with headroom availability is powerful information for both right sizing budgets and identifying projected choke points. Recent improvements of the Gateway publishing feature strengthen its position as a top as an enterprise monitoring solution.

The ability to logically normalize data gathered from multiple types of sources via pre-built plugins is extremely powerful. This functionality, coupled with the ability to import custom data via the Toolkit plugin allows Geneos to be leveraged to monitor every system in the enterprise. The use of Attributes within the enterprise facilitates very flexible grouping and viewing of this information. Enterprise scalability is also an important feature of Geneos. This is very important as gathering enterprise data metrics is only the first piece of managing the system.

Software is continually updated with enhancements - normally client requests - every couple of months. Due to the maturity of the product, this means the software is feature rich and targeted at the modern environment.

The strengths of the product is data capture and ease of configuration. However, data visualization – real time and historical – is a weakness. This is being addressed with VALO and ITRSInsights but this is not production ready yet.

We had no issues with the performance.

Scalability is built in to the product

Customer Service:

Excellent and very reactive

Technical Support:

Knowlegable with their own product but also with how it interacts with client software

I think that the configuration is fairly straightforward and much simpler than other management systems.

I rated this product a 9 due to how much I used it and how useful it was to us. It has allowed us to provide immediate support where needed, reducing business impact.