What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
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.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
I have not used their technical support.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
What other advice do I have?
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.