ITRS Geneos Reviews

We are using Geneos for basic monitoring, like process, logs, database monitoring, etc.

In terms of the applications we monitor with Geneos, they are the basics, like load processes for getting the data, parsing it, and loading into the database. We have a processor running 12 to 14 hours a day and we have to monitor the data we are getting, the FIX (financial information exchange) messages. We are parsing to see whether everything went fine or not. Then, if we are loading it into a database, we are checking the counts to confirm that whatever is in the FIX messages is getting loaded.

The solution’s web-based UI is a really helpful tool because sometimes what happens is that we are not on our machines but we can utilize those links over our mobile phones. We can access things from pretty much anywhere. If we are traveling, we can check the status of my application through the web-based UI and see if something is failing.

Previously, we did not have much in the way of monitoring. Geneos offers various kinds of samplers and it keeps adding integrations as well. For example, we are using Control-M scheduler for our batch. We integrated ITRS with Control-M and now we are getting all the alerts from there into our ITRS monitoring, and we can publish that in the dashboard. In one view we can see how our hardware is, how our logs and processes are, and how our batch is. And we are using Symphony and there is integration from ITRS for that. That's also something that we are utilizing here.

In addition, the fact that I check anything from anywhere, is a time saver for us. I would say that, overall, the solution is saving between two to three hours per day, compared to having to do everything manually.

For my application, Geneos is detecting and helping us avoid outages at least once a day. It's proactive monitoring so we get an alert and can take action before there is a major impact.

One thing we're utilizing in Geneos is the Gateway-SQL. That's really helpful for us. Using Gateway-SQL, we are able to merge two different views into one. Suppose we have to check something in the log and that we have to check something in the database and do a comparison before publishing a result. We can achieve that using Gateway-SQL.

Another valuable feature in Geneos is the FIX Analyser, because in our automation we are dealing with a lot of FIX messages.

On top of that we use the dashboards which are very good for presenting everything in one place, and we can send it to our higher management. We have different kinds of dashboards. For our application team, we have a full-view dashboard where we have set up the status of the processes, the hardware, and everything. Then we have a management dashboard for looking at applications. It tells us if the whole of application XYZ is green or not. We can design different kinds of dashboard per our needs.

Alerting happens in real time, and we can set up the sampling interval. If we want something to be checked every five seconds, we can do that in Geneos. We have different intervals set up. Some things are not really important and have been set up with sampling every one minute. We also have things we sample every 20 second and things we sample every five seconds.

We explored the database logging feature of Geneos ITRS and we are not using that much as of now. We are using it for a reporting type of function. We collect the trends — how many alerts we are getting — and we probably review it once in a month. But I would really like to see something from the Geneos side to set up automated reporting from ITRS. We have to send reporting to management every day. To do that we have to check the dashboard and then we have to report whether everything is fine or not. In the future, I want something, some reporting kind of feature in ITRS, where it can collect all the data and mention what is green, what is amber, and what is red in a report. That is the most important thing that I would like to see.

The other area where something could be done is the scheduling part. Instead of relying on any other scheduler, it would be good if we could use an ITRS tool for scheduling our batches.

I started using ITRS Geneos in 2012, so it has been almost nine years.

The stability has improved, as we purchased an upgrade. Now it's pretty stable.

We have all the processes defined, but if we are deploying a new process on our side, we can simply tell the ITRS team that we have here, "Okay, we are deploying a new code base and these are our requirements," and they can set up monitoring quickly. It doesn't take more than five to 10 minutes from their side.

Technical support is really helpful. Whenever we have a use case, we can simply send out one email and we get a response the same day, often within an hour. That's really helpful and pretty impressive. And the guys know what they are doing. They're always responsive and knowledgeable.

We did not have a previous solution.

The initial setup was pretty much straightforward. We had two Geneos people come to our place. They sat with us and set up the process; how to define everything and we then had all the XMLs identified. If there is anything new to set up, we can simply follow the guidelines provided. It's an easy setup. We can do it in five to 10 minutes.

The implementation strategy was a form that we had to fill out where we indicated, "You have to monitor this process. This is the log part," etc. ITRS then took care of everything else.

The initial deployment process took about a year. In addition to the Geneos people, there was one person from each of the application teams involved from our side. We have a team of three people who are dedicated to ITRS itself. They deploy the probes, set up the monitoring, and manage the gateway. They work full-time on ITRS. Altogether, across our organization, about 500 people are using ITRS.

We have definitely seen return on investment, although I can't share specifics.

We have an enterprise license so it's easier to scale up. The other license option is per-user, in terms of how many servers you're monitoring.

We haven't evaluated anything else so far, although that would be a higher-management discussion. But I think everyone is happy, as we have been using the same thing for many years.

We are not the team that's monitoring the real-time data. We have a different team that set up the Geneos for that.

We are really relying on Geneos for everyday tasks. All the monitoring is in Geneos and we are going to continue using it. We are pretty happy with Geneos and I would rate it at the higher end, a nine out of 10.

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

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

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

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

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

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

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

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

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

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

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

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

I rate the overall tool an eight out of ten.

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.

The customizability and the speed, those are the two best things about it. You really just can't customize and fine tune many monitoring tools to get the degree of specificity that you want from the metrics. That's one area where Geneos has excelled. And it's just really fast. 

Also, the Netprobe is so lightweight compared to the agents that most monitoring tools use. It's really superior to the competition. The agent that is used by almost every competitive tool takes a lot more system resources. It's slower and it requires a greater effort and more compromises in terms of security to install on the monitored servers. With Geneos, because it lives outside the code, it is far easier and far less taxing on the monitored systems.

It is better than any monitoring product I've ever used in terms of providing real-time metric data. Everything else I've ever used has a lag that is significant enough to make a difference to our customers. This solution is nearly instant.

The web dashboards are very good, also lightweight. They're responsive and pretty easy to set up.

Some aspects of dashboarding are very proprietary and it makes it difficult, at times, to replicate your work easily. That is one area where it could really be improved.

Other suggestions we have made to ITRS include:

• Breadcrumb navigation within web dashboards
• The addition of a nickname feature: Allow us to easily nickname any metric and then use that nickname anywhere that metric appears
• Add a ticker control: Define a region of the dashboard which scrolls or flashes between a designer-determined list of metrics
• Carousel and index navigation options for web dashboards
• Geneos dashboard frame: We would like to see capability to add a frame of Geneos dashboard content to a web page-based dash. This would allow construction of “mixed-source” dashboards
• Non-Geneos dashboard frame: We would like the capability to add a frame to a Geneos web dashboard that gets fed from a different source.

I've been using ITRS Geneos for about 18 months. We're using version 4.9.2 and we're just waiting for version 5 to be packaged for deployment. It's already gone through the approval process, but we have to wait until corporate center sends it to us. 

The stability has been very good so far. There are times when we overload gateways, but that could be something we're doing wrong or things that we haven't learned yet.

One thing that could be improved in terms of rapid scaling would be more ability to clone aspects of an implementation. It seems like there are opportunities in this area, where we have repetitive tasks to do when it comes to implementing things on new servers or on new gateways. It would be great if there was an easy way to clone something that had already been done.

Within my area, there are about 240 users who just look in the Active Console or at a dashboard to determine what might be alerting in their world, and then respond to it. We're still at the beginning of our implementation. I expect it to be used more. Most of these users use it minimally. If they have a production issue, they'll pop in there and take a look. It's not like they're staring at it full-time.

And there's a small team, four of us, who are helping to build the implementation. We do all kinds of things, mostly around onboarding servers, interfacing with the support team, and interfacing with the teams that own the applications to make sure that we implement correctly. Most of us are e-business systems consultants, but those titles will be changing over to engineering titles because of a reorganization here. In terms of "power users" who are in there every day doing a lot of things, there are maybe 20 people.

I have not used their technical support.

I've used AppDynamics, Dynatrace, and many others before that, but those are the two most recent.

In terms of the time taken to get an alert, it's somewhat configurable, but the data lag in AppDynamics has always been about two to three minutes, and that's after fine-tuning. That's as good as we could get. With Dynatrace, it was more like four to five minutes.

The pros of Dynatrace and AppDynamics are that they get deeper into the code, and deeper into the transactions automatically, out-of-the-box. Those are very good features. That's not something Geneos does; it doesn't try to do that and that's fine. But the other two are both very good at that. 

The cons are that they are difficult to customize — maybe impossible to customize. The idea of being able to write a script and execute an action on a monitored server is not a realistic proposition in either of AppDynamics or Dynatrace. And that's huge for us. We use that all the time. That's one of the very best features of Geneos that the competition does not have.

Geneos was ordered by our manager because he had experience with it and found our monitoring portfolio to be inadequate, which we agreed with. We have other monitoring tools, but they replaced Dynatrace with AppDynamics and AppDynamics, frankly, just doesn't do everything that we needed to do.

We are reliant on another group within our business to do the setup and that makes it complex, especially since they have expertise in this and we don't. We had no experience whatsoever with it, coming into it. So for us, it was complex, but that's because we didn't own it. It would have been fine for a team that does this all the time. I don't think it would be a problem.

We're still doing our deployment in some ways. We're 18 months in, so we're not a very mature implementation, but that's not all because of the product. It's partly because we're doing some 112 applications and we've actually already done two tech refreshes on almost all of those in an 18-month period. It's almost like we've onboarded all of that three times in a year-and-a-half. So it's been difficult. And we've made some missteps and some mistakes due to inexperience on our part, and maybe due to a little bit of lack of guidance from the experts on our affiliated team too. I don't blame the product. I blame us.

Our implementation strategy is the other area where I can blame us. It was driven by an executive who wanted this tool here, while we had never heard of it. His direction to us was simply to move as fast as possible, rather than taking the time to plan anything out. That's why implementation has been most difficult. We're used to doing careful analysis and planning in advance, and then execution takes less time with fewer problems. But instead, we did it backwards because he insisted. We just started implementing before we knew what we were doing. And of course that just means that we have to redo a lot of work, based on the mistakes we made. That's nothing to do with the product.

We have seen return on our investment with ITRS, but not as much as we're going to see. We're still in the early stages and we're not mature yet. But we've already seen some return on that investment and we believe the return will be significant, eventually.

The purpose of adding this tool is, of course, to reduce two things: the number/frequency of incidents, and reduce the amount of time to resolve incidents. Already, in 18 months of immature implementation, we have had approximately a 10 percent reduction in incident frequency and something like a 17 percent reduction in the duration of incidents. It's clearly helping our support team to identify the source of a problem and the solution for the problem.

In terms of how many issues we have detected and outages avoided as a result of using Geneos, we're not to a point where we have done those types of metrics to scale. It's mostly anecdotal at this point, but I have started to collect that information. Part of the reason for the lack of those metrics is that we don't have a mature process around the support teams feeding that information back to us at a central collection point.

The licensing cost may seem expensive upfront. However, the service is outstanding, the tool does things that no other tools can do, and the customizability more than makes up for the cost of licensing.

One of the really distinguishing and good things about ITRS is that it is a small company and they are extremely helpful. They have been extraordinary to work with in every respect: true customer service and a genuine care about the customer, which is not what I normally find from monitoring-tool vendors.

It's a tremendous tool and the company is so easy to work with that even if you just want to try it out or see what it can do for you, they make it very easy to do that in a no-risk situation.

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

We use it for application monitoring, monitoring of our business applications to provide our support teams with alerts around the problems and events that may be occurring within the apps.

We're a financial company and we monitor applications for trade entry, trade management, risk, and order flow. It's used for any application that's being used in the tradeflow stack.

Because we're a large organization, we've built some really great management dashboards that show the end-to-end flow of how our applications are fitting together and any alerts that are occurring on those applications at the moment. It provides a management-level view of the underlying data.

While we don't use it in a predictive mode—we are reactive—our reaction time is greatly improved using Geneos. We've gone from hours down to minutes.

It's hard to say how many issues we have detected and outages avoided using Geneos, but I definitely know that prior to Geneos we had hundreds of events a month that we were slow to react to. We may still get those events, but we are much faster at reacting to them, and that has really improved our interaction with our users. The confidence of our users has greatly improved because of our ability to react much faster.

The biggest benefit of Geneos is the fact that we can clearly see, if we have an alert, where that alert has come from. We can see the data around that alert and anything that might be relevant is also shown. We can very easily right-click and see why we've received that alert. That's the best part about it, that you've got all the data there with the alerting. It's the usability that it provides. It's not really the real-time data, you can get that everywhere, but rather the fact that it pulls all of those other pieces together.

Also, the Netprobe that is deployed on each of the application servers is very lightweight. That is another of the great benefits of Geneos.

One area where there is room for improvement is the log file. I would like to be able to do a pre-run on the log files. When you are testing log files for regular expressions, it would be good to be able to do a quick check up front on that side of things before you release that into production.

And more generally, there is room for improvement with the Netprobe agent performance and understanding when you need to deploy a second Netprobe versus a single Netprobe.

I've been using ITRS Geneos for two and a half years. We're on version 4.12 but we're moving up to 5.3.

The stability is very good. Very rarely do we have an outage with Geneos. We do sometimes have outages with the agents, the Netprobes, usually due to the loads that we are trying to get them to do.

Scalability is probably a weak spot. We find that once we get up to about 120 Netprobes we have to then run another gateway, but we can have multiple gateways running on the same server. So even though we can monitor, and we are monitoring, thousands of servers, we have thousands of gateways. One of the difficulties is tying all of that data together if you want to create some sort of summary reporting across all of that.

Our environment runs into the hundreds of applications, which is then multiple thousands of Netprobes, on the order of about 8,000 servers.

Technical support for Geneos is awesome. Absolutely awesome. They are top-rank. They have an immediate chat facility off of their website. There's always someone there; really helpful, great guys.

Prior to Geneos we used a few solutions, but they were very restrictive in what we could do. We could only do process up/down and log file monitoring, whereas Geneos has a huge range of other things that we can monitor.

We're very thankful for that, in terms of the deployment process, we got some advice to get some understanding about how we would like to configure Geneos. You have to do some background work and upfront work before you start your deployment. Once you've done that, you can create some standard configurations. Then we deployed to all of our applications, created a standard package for how to deploy the Netprobes internally, and then we deployed the gateways onto virtual servers. 

We've gone for a federated model where we have a group of individuals that are monitoring the monitor. They're monitoring Geneos and doing all the server-side configuration that is required. We then have the application support teams that have slightly less Geneos knowledge, but they set up the configuration for their individual applications.

We deployed it to over 120 applications. The initial deployment took us about six months, and then we spent another six months to a year refining that. It's a constant process thereafter of continual improving of the monitoring. Whenever we find something new, we will add in a new configuration.

The core team involved in the deployment included four people, and the extended team ran to 20 to 25 people because it's such a large deployment. When it comes to users of Geneos, front-end, it would be around 350. 

It's very difficult to put a number on it, but I'm sure that the product has paid for itself.

It is expensive. They have to look at the model around when we move to cloud and how that's going to work. The licensing cost does pay off because of the improvements in support to our business.

Our previous solutions and this one take roughly the same amount of time to alert. Both do so within a couple of minutes.

We had a few choices to evaluate, including using an OpenStack or open source solutions, but when we evaluated those we felt that, given the time and effort to stitch them together, it was more beneficial for us to use Geneos. The time and effort needed to get those open source systems up and running and combined—you have to use multiple open source products to get the same functionality—and the fact that there's no support and nobody to help, led us to conclude that it's much easier to use the ITRS solution.

The configuration can be very flexible, which is great when you're trying to do something, but it means that if you're just starting out, there is more than one way to do something. Take professional advice, use the ITRS website, understand how everything fits together first, and then proceed. Try to get a consistent configuration design across all of your applications.

A lesson learned from using Geneos would be to get buy-in from the people who are the users of Geneos. Get them onboard nice and early. Get them familiar with the tool. It does take time to understand how the tool works, so invest in training.

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.

It's used mainly for application monitoring. We monitor the process log files, web URLs, JVM, SQL Database, etc. There are several things. There are over a hundred plugins available with ITRS, and we use the plugins based on our license agreement.

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

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

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

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

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

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

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

I've been using this solution for 13 years.

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

It's scalable.

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

Positive

We had a manual, custom-built script, and then we used Foglight monitoring. We also used the BMC monitoring tool. Now, we have transitioned from all these tools to ITRS.

For the initial four to five years, we were doing manual monitoring where we built a custom script and deployed it to the production servers to monitor, but the number of scripts kept on increasing. They required a developer and constant maintenance and enhancement. We had to keep going. It was never-ending. At one point in time, we ended up having a few hundred scripts in our production environment. It was very hard to manage and maintain them. It was a cumbersome process, so we thought of getting rid of them.

We then moved to BMC monitoring, but the problem with BMC monitoring was that only the admin was able to set up the configuration. It also did not provide a real-time view, which was a big drawback. When we configured something in production with BMC, we couldn't even validate whether the settings were correct and whether it was working as expected. It also didn't provide real-time data. It tells you only when something has happened. It sends you an alert when something is broken. We didn't want a monitoring tool only to know when something is broken. So, we started to look at other tools available in the market, and we found ITRS Geneos to be the best tool. Its usage expanded pretty quickly. We started with a few applications, and very quickly, our organization understood its benefit against the investment. We started migrating applications to it, and now, half of our organization is using ITRS Geneos. It took one to two years for us to identify and understand the benefits of this tool.

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

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

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

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

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

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

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

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

It's very powerful. They just need to improve the cloud and API offerings. I've been working in the finance industry for 18 years. It's a top-tier tool, and it's being used by more than 200 organizations in the world.

I'd recommend ITRS Geneos, but it also depends on the use case. To people working in the finance industry, I'd recommend it. However, it might not be suitable for non-finance industries because they might be looking for a cheap monitoring solution, and ITRS Geneos won't suit them.

Overall, I'd rate ITRS Geneos an eight out of ten.

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