Application and Server monitoring is an incredibly diverse space. Freeware, Opensource, and some silo tools that cost hundreds of thousands of pounds, well-known brands run by some of the largest software houses in the world and niche players known by a select few.
This for the uninitiated makes for some tough choices, lots of time spent in research and a steep learning curve. I have been in this space for more than 30 years, and here’s my guide to the marketplace today. Hopefully, this will give you some ideas about what to do next.
Agile Scrum is when developers make chunks of code in defined steps towards a known goal. These guys are experts, they live and die the space they are in. They have made the mistakes, know all the pros and cons. This is all they do, and over many many years, they create a product worthy of its cost.
Application and server monitoring is as we will see, a place where many choices have to be made, making them will dictate the quality of your monitoring. Opensource means that you have to go on this journey and devote your life to making the code work well.
Decent sticking plaster solutions do happen, but even they make come with the ongoing effort of keeping the code up to date and making changes and improving the code. Typically, the hidden cost and overheads of opensource far exceed the cost of paid-for software and achieve far less impressive results.
There is a place for “silo” tools, ones that do a defined piece of your monitoring. They might look after a specific database or mail client; some are interested in say the transactions flowing across your network. These tools work well for departments. I always think they are complementary to unified tools, they delve deep once you know about the problem but are typically very bad at alerting and lack context. Is the problem they see the cause or the symptom?
They are often very expensive because the vendor has to recoup the development cost in a small(ish) market. The choices here are;
My experience is that they work well as complementary tools but rarely as part of understanding service levels.
I see many tools that started off as say Windows, or Unix or IBM i tools. Then they purchase a tool for one of the other operating systems and plug this in. I have never seen one of these work to a high standard.
Often well-marketed they can make lots of claims and some have become quite well used. They typically have a shelf life of 2-4 years as the drawbacks slowly overcome the pain of realizing a wrong decision has been made. If your vendor suddenly adds Windows on to an IBM i tool or vice-versa. The question to ask yourself – did they make this or buy in a new company and plug it in? How different are these solutions now and can I get the same levels of monitoring across the board? Which one is the weak partner? If one of the operating systems are cheaper in the vendor’s portfolio then alarm bells should ring.
SNMP, WMI, Java, Soap Calls, Shell Scripts, Syslog etc. These can all be put to many uses; this means a tool designed to use all the network monitoring protocols can easily be moulded to server monitoring. However, these are add-ons and are rarely choices made from best of breed decisions. I.E. what’s the best way to do this as opposed to a way of re-using what we have already made.
Network tools are the biggest user of this method; they are rarely useful server monitoring tools and even worse application monitoring tools.
The developers had to make too many compromises to get where they wanted to go. They often deliver lots of false alerts and make for very noisy alerting solutions leaving your teams having to wade through data – not insights.
Agent-based requires installs on all your servers but are brilliant at seeing what they need to see and are much better at automation.
Agentless, often requires lots of network gymnastics, this is because ports have to be opened and firewalls let through, and servers configured to respond to agentless calls, hardware needs to be configured to do the same. However, they can then see decent amounts of alerting data. Rarely on the same level as agent-based, and as a result, automation always suffers.
For me, you put agents on your vital servers and use agentless for your less important ones. Agent-based where automation is critical, and agentless where none is required. Hybrid gives you the best of both worlds. Remembering all the above look for one that saves time where you can and informs you and automates where you need to be.
Probably the most important thing to know; no single tool does it all and do not believe those that say they can.
The question is, what do you need to know to deliver outstanding service? That’s the starting point and then you can ask yourself the following;
Understanding what you need to know would help you through the maze detailed above. Lots of servers probably mean a unified solution, you may need to add transaction monitoring tools if they use the internet, you might save costs with very basic agentless or opensource. How important is a unified view for context, or does your application live on one Server?
I am more than happy to advise further or indeed show you our unified solution. We have developed Itheon over ten plus years, with IBM i, Windows, Unix, Linux and VMS server and application monitoring in mind.
This is hybrid monitoring, with no weak partner in the stack. Get in touch today to find out more.