I was involved with the solution architecture and engineering team. We build the monitoring tools, collect the requirements from internal clients, set up the monitoring for their applications, design dashboards, etc.

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

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

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

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

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

It's a complex product, but we had some direct onsite support from two implementation guys for several weeks and they assisted. Once they'd shown me the ropes, it was fairly straightforward.

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

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

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

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

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

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

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

The initial setup was straightforward. 

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

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

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

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

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

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

The initial setup is complex. The documentation is not proper. You need to ensure that the configuration is well-documented so that it can be useful. The engineers are coming up with a new platform. They aim to include everything and integrate numerous data sources, making it a versatile platform. They are still in the development phase.

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

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. 

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

The initial deployment can be complex. It depends on how much you want to get into it. It's the sort of thing that grows organically. If you have a problem, you then add some more features to cover things so that you don't have the problem again. But when you first implement it, you will probably make it quite simple.

Including the provision of the hardware, it takes a couple of months to deploy. It's just a matter of installing the system and getting all the networking working.

The number of people required to deploy the solution depends on the size of the organization. For my current organization, it would take a couple of people to do it.

Maintenance involves upgrading it every now and then. License file replacement is another task.

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. 

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.

I have implemented Geneos for several banks and each implementation is different. The customers' requirements determine how the implementation is done.

Initial setup complexity depends what you want to implement (e.g., building a dashboard is complicated). You will need a basic training session to start working with the initial setup. Depending on what you want to achieve, the rules and actions can become a bit complicated.

It was straightforward, due to the automated tools created in-house to assist teams with the installation and set up.

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.

The product is straight forward to install and configure along with the deployment of probes to servers. From out of the box installation to a point of monitoring systems can be done in less than 24 hours. Installing new servers/applications into an established system can be done in minutes. ITRS Geneos is very well known in the financial services community as being the best platform to monitor real time data infrastructures and the application does what it says on the tin. Industry peers reflect this sentiment. ITRS are very good at adding plug-ins to various new software and technologies/black box solutions and also provide order flow monitoring.

However, it being both straightforward AND complex is the key. The system is easy to setup from a software perspective, but you need a system architect to design the system initially. Geneos is ultimately designed for mission critical servers supporting real time infrastructures, high frequency trading, low latency and order flow (and much more). Even with a fairly small footprint – setup not done properly could cause huge exposure. None of this can be reflected on the software, as deployment is always straightforward, however the day to day operation is where the platform form is judged.

The deployment took around one hour.

I was not involved in the initial setup.

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

I didn’t configure it myself during the initial setup. However, I did try it on my own in a virtual environment and I can say it was very simple to install.

The process in itself is simple to setup but getting it working through the corporate securities and restrictions can be a pain, but I guess that would be the case for any new tool setup.

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.

Initial installation was relatively easy even though - due to the nature of the task - numerous components had to be installed: netprobes on every monitored server, gateway servers, dashboard webserver, webmontage webserver. Directly after installation, however, basic real-time infrastructure monitoring worked out of the box, more advanced monitoring after appropriate configuration.

The deployment is easy and the configuration is fairly straight forward. The documentation for plug-in configuration is a little sparse, but the latest version of the user interface is very intuitive. It is important to note that Gateway configuration accepts XML files allowing easily transferable setups.

The initial setup was a bit complex. We use the product to monitor the Core trading infrastructures (OTC, CFD, Low Latency, etc.), which means many servers, many processes, many metrics. It was complex as in the beginning we were not completely aware of all the capabilities of the product and our infrastructure is close to 200 Servers and 150-200 unique process which are running multiple times. It was complex due to the very high complexity of our systems and the scale.

Straight forward, startup with basic metrics and progress toward bespoke use cases that's where the real value is. Be expected of a lot of a lot of customization and intuitive work around to extract metrics from your plant if it's not readily available.

The setup can be complex if the solution you are deploying is complex.

The server was already configured by the ITRS support team, but we configured our own gateway.

Performing the integration was slightly complex for us.

Out the box the product is not intuitive to set up, however there are a lot of resources online to mitigate this fact. However the users of the product have to be quite technical to get the best out of the product as they will have to understand the applications they are monitoring.

It was pretty straightforward. We just need to acquire a gateway which once done, is followed by probe deployment on hosts and you are done with it.

Initial setup itself is straightforward. There’s a single server (two in fault-tolerance) running the master “Gateway” process, and each monitored server runs a “Netprobe” process. Each tarball is extracted to a single folder, rather than strewn all over the file system. Upgrades are likewise easy.

To not run Netprobes as root, some network monitoring features necessitated writing in-house scripts to feed alongside into Geneos, but that’s also its flexibility in action.
Rather than a cookie cutter setup, you will likely find yourself continually tweaking features and adding new alerts to suit your needs.

It wasn't that complex to setup.

We were a little bit confused but once we found out what was needed, it was smooth.

It was very straightforward.

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

It's straightforward. You take it out of the box and it's simply plug and play, but it really depends on what you would like to use the product for. My advice before setting up would be to plan on what you want to achieve the product, what you would like to view without logging on to the server, what you need to know from the server, and what your customer would expect from you.

Every popular monitoring tool has a pretty straightforward installation workflow. Configuration might be more complex though.

It was simple as the set up is well documented and available across different operating systems.

A bit complex

Setup is bit complex, especially on Linux servers. You have to configure Netprobe on your system and then configure the path/workspace/profile and so on.

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

It was easy to setup as there were step by step installation instructions for every operating system.

It was straightforward.

The initial setup was very easy.