ITRS Geneos Reviews

It's a monitoring tool. It's watching for all of our alerts, including high use of the server or running out of memory.

It's catching things that are going wrong before they become catastrophic, in most cases. It helps us avoid long periods of downtime and gives us a view into when things aren't quite working properly so that we can get in and fix them. We've seen those benefits from the day it was implemented.

One of the best aspects of Geneos is that it has a broad scope and can cover a lot of use cases. You can write your own scripts to monitor really specific things. And the rules that you can put in place can be quite complex for the alerts. Those two things are quite good.

The deployment method for upgrading is a bit tricky. It takes a little bit of manual effort. If that could be a bit more automated, it would help us a lot.

I'd also be interested in seeing some intelligent analysis of log files, along the lines of AI. It would be nice if it could start correlating events from all over the estate.

I have been using ITRS Geneos, in different companies, for about 15 years.

It's fairly reliable.

There are always glitches, but they seem to be fixed reasonably quickly. And, in general, it does what it says it's going to do.

Once you've automated it, it's very scalable.

For us, the hardware is in London and the solution is across multiple departments. We have about 30 to 40 users.

I expect our usage will remain steady. We are changing our platform, but it's the same size as the one we're on now.

The support is very good. It's quite immediate. I don't think I've ever had an issue that hasn't been resolved.

Positive

What we had, and still have, was more low-level than what I would have been involved with. It would have been more on the operating system level.

We added Geneos because we needed more visibility into the application. The other solution only looks at whether the machine is there and running or not.

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.

Our biggest ROI is that it has saved us downtime.

The pricing seems reasonable. We're happy enough with it.

There are a number of add-ons that come with extra costs. We use some of them. We have a license now in which most of the features are included, but there are some special extras that have to be added on.

Do a proof a concept and definitely look at how quickly other systems alert when there's a problem. With Geneos, it's pretty instant. With some of the other solutions, it's not that obvious, and can be a number of minutes before you get an alert.

I have implemented Geneos to improve business, management, engineering and support operations.

• We use Geneos to provide a business view of the IT infrastructure using its data to produce reports and dashboards that are ready for business management to view
• Management use Geneos to measure various stats on operations performance to ensure business and technical targets are being met.
• Engineering teams use Geneos for capacity and performance management
• The Ops teams use Geneos for process, log file, middleware, database, and custom application monitoring.

The Geneos monitoring solution is a mature industry standard monitoring solution, and is present in over 90% of the invest banks in the city. There are many reasons why it is the professional's tool of choice.

• The NetProbe carries over 100 samplers which are capable of monitoring hardware, OS, and the application layer.
• The NetProbe is a very light weight process typically uses around 0.3%CPU as it is written in C/C++ so no fear of it hogging your low latency machine resources.
• When it comes to custom monitoring the probe offers an easy to use open interface known as a toolkit sampler which is very simple to use or for more sophistication and control there is also an API.
• It is cross platform and will work on many different types of architecture such as Solaris, Linux, HPUX, AIX, and Windows.

I would like better access to the data that is being collected. ITRS are addressing this by using a KAFKA API interface to the gateway. Access to the data provides the ability to summarize, aggregate and correlate events and in many cases predict outages.

We had no issues with the performance.

It's been able to scale for our needs.

Customer Service:

10-10

Technical Support:

It's excellent, and by far the best third party support we get.

No

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

In house

Pricing and licensing is based on the requirements.

I have looked at other products but they fail right at the start – these other products use Java or Pearl and this is not what I want running on my machines. As this product was written in C/C++ it does need many files to run or a complex environment to setup.

Keep the implementation as simple as possible.

ITRS helps us to identify a lot of production issues proactively. E.g., ITRS alerts for a critical process memory that grows beyond the configured threshold limits. The limits are set to alert before the process crashes. This allows support teams to recover the process in a controlled manner (usually a planned restart before the process crashes).

A State of the World dashboard that we built gives a bird’s eye view of the entire production environment. These dashboards are displayed on big screens that are monitored by support teams in multiple locations. This helps us to monitor mission-critical components more effectively. FKM plugins can monitor huge logs in real-time for errors/exceptions and other keywords. Alerts are triggered immediately when an exception is logged.

As far as I know, ITRS does not have integration with any version control system. ITRS monitoring configuration is defined in a setup xml which gateway reads on start up (setup.xml). When you are working on a major monitoring set up, you will have to make a lot of changes in the xml. ITRS keeps only last 10 versions of the changes. If I want to restore an older version then it will not be possible unless you are taking regular backup of the set-up xml. Integration with a SVN will allow every major change in ITRS setup xml to be checked-in. If i want to restore any version of the xml (a month old), I can do that from the SVN.

I came across an incident when the setup xml was mysteriously wipe off from the disk. So we had to restore last working xml from a SVN that was manually maintained outside ITRS setup. If ITRS can include an optional SVN configuration (like DB logging), it will be very useful.

ITRS can define rules to alert when certain parameters that you monitor breach a threshold. Rules can be configured to fire recovery actions automatically to clear the alert. However, if the alert persists for an extended period, then it has the capability to fire multiple levels of escalation email or actions.

It also has powerful visualization features to develop dashboards to display in big screens and share it via Webslinger (a web server that allows dashboards to be accessed via web browsers). It can log metrics (values) into a reporting database and generate historical charts for trend analysis. The Toolkit plugin can run scripts for custom monitoring requirements that cannot be implemented using standard plugins. There are features to suppress alerts for time-period - Snooze, as ITRS call it - or change the value/severity of the parameter.

There are a number of things that you can do directly from ITRS active console without logging into the server. Processes can be restarted and you can open log files directly from active console. It also has a built-in scheduler that can run tasks (commands that you configure) on multiple targets. The active time feature enables you to apply different rules at different times. It also helps to disable alerts during non-business hours (eliminates noise).

ITRS has setup XML that holds the entire monitoring configuration. Only the last 10 versions of the setup XML is saved locally on the gateway server. These 10 versions get overwritten quite easily when you are working with a big configuration change. I would like to see ITRS integrate its setup editor with a SVN to check-in setup XML after major changes.

I have not observed any stability issues so far. ITRS has a transparent failover mechanism. If the primary gateway fails, the secondary gateway takes over. I have seen the active console freeze while it’s failing over, but everything recovers within a few minutes.

I have not observed any scalability issues in an environment with 60+ servers, 1000+ processes, 5000+ logs to monitor.

I am very satisfied with the level of technical support I get from ITRS. All the queries that I raised around monitoring setup and configuration issues were closed in a timely manner. We also have a ITRS technical support specialist visiting our office twice a week. This is very helpful to discuss some of the complicated monitoring solutions that we wanted to implement in person.

I have used Wily Introscope and Nagios, but they are not as comprehensive as ITRS.

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.

We have 20+ applications monitored in ITRS and the implementation was done in-house. ITRS has features to import template setup. This will save a lot of effort on the initial setup. If you are starting from scratch, create a setup template which can be re-used on the new gateways that you create. (E.g., default rules/samplers, etc. can be defined in a template and imported.)

I don’t have much visibility to the pricing, as this is negotiated at enterprise level. I heard that enterprise-level licensing is quite expensive.

I would definitely recommend this product for monitoring mission-critical applications.

ITRS is the best monitoring tool I have used so far. It comes loaded with a lot of built-in plugins to monitor almost all of the parameters that you want to monitor in a production environment – i.e., processes, memory, disk space, CPU, keywords in log files, daily feed file generation, web service monitoring, MQ, Database, FIX Sessions, etc.

ITRS ActiveConsole provides a powerful interface for monitoring the environment. The gateway setup editor makes it easy to work with the monitoring configuration.

The tool is highly customizable and can be tailored to your requirements. Dashboards can be created if needed and database logging can be enabled for analyzing trends and monitoring performance.

It has assisted the team to identify issues pro-actively, i.e. prior to a business user reporting them. This would ensure that the issue is identified and fixed in a timely manner. Also, the tools assists with stability as we are monitoring application infrastructure – application (all O/S), databases, middleware and much more.

It would be good if there were documentation on the ITRS website such as tutorials or plugins which are available to download.

I've used it for three years.

We've had no deployment issues.

There have been no issues with the stability.

We've had no issues with scaling it for our needs.

I have not spoken to the vendor directly.

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

In-house. Several tools were created by the Tech Services team to ensure the Geneos Netprobe installations and other key processes are simplified; easy to understand and use by all teams.

Ensure some of the samplers and types (for monitoring infrastructure i.e. disk space, hardware, memory etc ) can be used by multiple servers to prevent duplicating things. In the Gateway Setup Editor, follow the same generic folder structure and set up for all your applications (if you have more than one). This will make the Gateway easier to manage.

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.

The primary ability is to monitor systems in real-time. Many alternative monitoring systems use a polling system – so a short incident that occurs for a couple of seconds or less and resolves (such as a line outage or data gap). The small outage could have major consequences. Having to wait up to 60 seconds for the message can also mean valuable time is lost in resolving the issue.

The ITRS development team constantly works to make plug-ins and samplers, ensuring that when I implement new technologies – servers/black box solutions etc. minimal development has be done on my side. We can simply download the specifically written plug-in to the gateway and deploy the probe to the new technology. This ‘off the shelf’ approach beats onsite resources developing solutions that already exist.

Dashboards & auto execution – a few years ago the staff supporting our systems would have multiple windows open into various server applications. Not any longer. We have created powerful dashboards which on one screen shows every part of the system we need to see, going into the end applications is a rare occurrence and only for senior third line team members. Auto execution provides the ability to fix issues from the monitoring system. This allows us to have Geneos monitoring and incident management as our ‘core skillset’ – knowing how to support hundreds of applications via only needing to know one. Training is now far easier and staff can support more apps.

We support various versions of view the software at various institutions. The latest version is compatible with Linux/Solaris and SPARC. The probes (which deploy on end user systems) work on most OS including Windows. Consoles to the gateway to view status are Windows based and also various web based tools use modern versions of browsers such as IE, Chrome and Firefox.

We can only respond to issues once we confirm that the issue exists. An analogy we sometimes use is likening our role to that of Formula One pit mechanics – we work hard to ensure the engine is tuned and running, but we can’t stop unexpected issues ‘on the track’. Once an issue happens, we need to be working to resolve it instantly. Any solution that does not monitor in real-time is a non-solution for both CJC and our end clients. As we can see the moment an issue occurs reaction times are quicker. Events are logged and so trend analytics can be used for performance benchmarks; so month to month or even day to day we can review the system heath with a view to improving our performance and refine our monitoring.

CJC require an enhanced level of visual reporting for our clients, specifically due to the large datasets we need to analyse and the importance CJC place on capacity and upgrade management. CJC created a new visualisation tool utilising the existing ITRS Database. This was done with the full support and assistance of ITRS for our specific requirements. I have found that ITRS are aware of their client’s requirements and work towards platform improvements to benefit individual clients and the community as a whole.

I first used the solution in 2009 however CJC have been working with this product since 1999. CJC has to provide 99.999% availability on mission critical infrastructures and it would be incredibly difficult to do this without Geneos. Our clients have a similar requirement of ITRS and so require consultants trained in the product to support their systems. We have assisted in the support of real-time infrastructures at 15 tier one to tier two banks along with brokers and vendors.

From a software Installation point of view no, however all deployments come with their own challenges, especially when migrating away from an existing system as not one infrastructure is alike. CJC has historically upgraded a client from a legacy monitoring system on over 600 servers to ITRS, replicating thousands of bespoke rules and alerts. Migration has to be done with ITRS standing ‘shoulder to shoulder’ with the legacy system. ITRS during this time provide specialists and technical support to replicate rule sets.

Fortunately the system is very stable - we have never seen an application level incident with the monitoring system itself. The gateway has a redundancy mode which we enable so we have a live/live environment.

None, once the server gateways are setup it's simple to deploy the probes. We adhere to ITRS guidelines and monitor the servers themselves to ensure that we are not adding unnecessary load. The gateways run a fairly low footprint on entry level server specs.

The ITRS accounts team are passionate about the product and are client focused.

Generally we work direct with the developers as CJC staff are at an advanced knowledge level with the application. The development team quickly understand our requirements and work with us to achieve the goals we require.

We have historically supported many different monitoring systems, however one of the major reasons for switching was a previous system was not being developed further due to an end of live announcement. ITRS Geneos is commonplace on client sites and our teams had prior exposure or expertise. New staff can be trained on Geneos in a short amount of time and a solid user of Geneos can pull much more out of the system than previous alternatives.

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.

Generally we work through vendors however in most circumstances they provide CJC the freedom to setup the system how we require as ultimately we are doing the live support. We work with vendors/clients who have both a hands off and hands on approach to monitoring. However in both cases the understanding of why they would utilise ITRS Geneos shows their understanding of their own infrastructure needs.

It’s the primary tool to detect and start end to end incident management and system analytics so it’s a key part of our company offerings.

Our clients pay for Geneos directly from ITRS.

We found the best alternatives to be open source systems, however the development costs to get these to the standard of ITRS meant that open source was more expensive. Many clients have also done internal investigations and have come to the same conclusion. I would prefer not to name these systems simply due to the confidence that they do a fine job, however, I believe they are not best placed in our fast moving industry.

My logic is ask for a proposal – they cost nothing! If you don’t ask, you don’t get. It’s up to those looking for top level monitoring to go to the various providers and weigh them up both in terms of functionality in cost. I’m confident ITRS would be competitive for commoditised IT and non-mission critical environments.

As a user its UI is very easy to understand, nice to look at, organised easily, and also very quick at alerting. This makes it stand out above its competitors, which in my experience are slow and ugly.

As a company looking to onboard, its capacity to monitor just about anything from Unix log files and processes to database memory, and even run queries and provide results. It can be used as a one stop shop for all your monitoring needs if you understand how to utilise it to its fullest extent.

It has improved our efficiency in many ways. Management and user information are now on self-service as we can provide them dashboards which give them live updates on what they want to know when they want to know, rather than running a query every day and e-mailing it to them.

We can configure it to send us email alerts for errors, and set up pop-ups so we do not have to constantly monitor something. We now have control of what we monitor so there is no reliance on external teams to send us alerts.

Like any product there is always room for improvement, and although their documentation is good, I would say better documentation is always one to aim for though, and I believe they are doing this.

Technically, I believe the dashboard functionality can be more configurable as some shapes are very limited with what they can do.

I have worked with multitude of versions for a year and a half. All of the versions I have used are very similar, and it has very much added value to every team that has used it.

I was involved with the deployment of NetProbes onto the app servers to collect data. This was a simple process and easy to do.

We had no issues with the performance.

I was not involved with any of the other processes although I would say from my knowledge and experience it shouldn’t be that hard to deploy or scale up though I think depending on the size of scaling you would want to strategize how to handle the workload.

The Customer Service is one of my favourite parts. They are always helpful and point you in the right direction. They are also very quick to respond and have a forum for self-help. This is definitely one of their strong points.

We previously used a monitoring system that sent alerts to our phones or sent emails to us. We also have a team dedicated to monitoring and sending us mail. It was inefficient and a worse form of monitoring overall.

I was not involved in the initial setup.

Often I find that people who are not a fan of Geneos had a bad experience with a terribly configured gateway. It needs to be understood that being very configurable has its negatives as it needs to be managed properly to make effective use of the tool. Ground rules need to be set and changes need to be controlled, otherwise it can get messy very quickly and ruin user experience.

I am sure you have the ability to sit and consider options, both positive and negative, before choosing a product. I strongly suggest that if you do not have a visual and easily configurable monitoring tool then use this as a comparison for other tools. If you feel the other tool is better than Geneos then it really must be good or the sales man for the other product has done a great job

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.