The scalability is poor. You will experience some performance issues when you add more clients. The dashboard is their best feature, but it's complex and lacks auto-scaling capabilities. If you're monitoring thousands of machines, you need separate gateways to monitor them. If you have a thousand servers, you need to split that into five gateways with 200 servers each. Otherwise, performance will be sluggish. 

ITRS Geneos is a tool that can be scaled without limitations. 

We currently have between 3,000 and 4,000 people using ITRS Geneos.

The solution is scalable. We are the number one derivative stock exchange, and our number of servers has increased significantly in recent years. In 2014, the number of servers was 50, but now it is 500, ten times as many. Our gateway servers were also limited to around five, but now there are 15. This increase in scalability has allowed our maintenance team to deploy more gateway servers and improve our monitoring gateways. We are also looking into redundancy and unused data to further improve performance.

We currently have 120 people using the solution in our department and around 400 from all of the departments, including vendors.

It’s scalable. We've gone from one product and about five servers up to eight products that we supply, and there are over 300 servers that we're monitoring now. And I envision that doubling, at least, in the next couple of years.

We have it in three data centers across the globe. Although I work for one particular part of our company, with one particular product, which is where we started, I have also rolled it out to other teams and trained them. We use it in a federated model where we provide the platform, train up someone on those teams, and they then administer their own alerts.

We have about 400 users who have access to the console itself.

It is definitely scalable. Five or six different departments within our organization are using this monitoring solution. We've got AWS, and geographically, we have systems in South Africa, and we've also got a few in the UK. Overall, there are about 20 to 30 users of this solution.

We have plans to increase its usage. It's currently the only monitoring solution on our slate. With the thoughts of going to AWS, et cetera, this is always part of our journey. It depends on what comes up in the near future, but if anything develops in our world, the first question that comes up is what's going to monitor it? Is Geneos coming along? Can it be done? Et cetera.

While scalability is easy to achieve, the process can be labor-intensive. Automating the process would make it much more efficient.

Our data center is located in Singapore, we do not have a presence globally. We have around 60 users currently.

The solution is scalable but only if it is done manually. It is not smart enough to scale itself based on need. The scalability must be handled manually, so the maintenance manager or support team will have to go and set up additional servers and gateways. ITRS Geneos doesn't have the intelligence to scale itself.

More than five users are using this solution, including admin and users.

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.

It scales relatively well.

About 8,000 hosts are covered by it.

User roles are predominantly application support.

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.

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.

It's scalable.

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.

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.

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.

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.

It's been able to scale for our needs.

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

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

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.

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.

We have around 100 devices that we are monitoring. There are three administrators who administer it. 

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.

Scalability is built in to the product

It's been able to scale for our needs.

We have had no issues scaling it for our needs.

No issues. If a gateway has a high load it easy to set up additional gateways to get headroom on each gateway again. If a netprobe has too many servers one can parallelize by running several netprobes per monitored server. Resource footprint of Geneos is generally very small.

It's been able to scale for our needs.

We've been able to scale it for our needs.

No. Planning the implementation of the product on the infrastructure keeps scalability issues away. The product is easily scalable.

There were no issues scaling it for our needs.

Performance can be a problem with complex or greedy rules and samplers.

It's been able to scale for our needs.

It's been able to scale for our needs.

It can be difficult to gather data on large Geneos estates.

It's been able to scale for our needs.

There have been no issues scaling it for our needs.

No issues encountered.

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

No issues encountered.

I had issues scaling it and ended up having to distribute the load over seven gateways.

Adding new monitoring nodes is quite straightforward.

It's been able to scale for our needs.

No

It's been able to scale for our needs.

No issues encountered.

No we didn't.

Yes, we encountered some problems due to the fact that Gateway is 32bit (4gb memory limit) - maybe we should split it into a few, or maybe open access cluster would be a solution but we did not try it yet.