“Our IT uses agentless monitoring solution, why can’t we use it for SAP?”
Do you hear that often? There are a lot of thoughts and misconceptions out there about SAP monitoring that can create unfounded doubts about the right way to manage your SAP health and performance. Fortunately, thanks to 20+ years of SAP system monitoring experience, we can help you separate fact from fiction. In this blog, we will discuss myths related to agent-based vs. agentless monitoring solutions.
Before we start..
A monitoring agent is a small piece of software that resides on each server, gathering information on the server, database and application layers. It then shares this valuable information back to the master monitoring tool which in turn analyze the data and provides monitoring, reporting and alerting. In recent years, non-SAP specific monitoring tools have made great advancement in moving off agent-based monitoring into agentless monitoring where the remote master monitoring tool can reach across the network and gather the information directly without using an agent. They have suggested using a similar approach to SAP systems monitoring. So why doesn’t it work well in SAP environments?
A proper SAP monitoring tool will need to have several multi point connections, one to the application layer itself, another to the database and a last to the operating system. This multi point connection method is necessary if you want a full view of your system health. Any single point connection method, say just to the application layer, for SAP monitoring limits the data you will be able to utilize.
It’s important to note that each of these connections needs credentials to connect and collect the information. Without an agent, those credentials will need to continuously be passed over various (possibly public) networks. Let’s be very clear here. The last thing you want to do is pass along your SAP database credentials (repeatedly) over any network, exposing it to any looking eyes. Conversely, utilizing agents on the servers will keep those credentials local to the server. The agent will connect, gather and encrypt the data before sending back to the monitoring tool.
Risk-wise, while hacking and getting access to your IT monitoring data such as CPU, memory, disk space or any other similar data won’t pose too much of a risk to your organization. Would it be so simple of the same hacker got his hands on your SAP data?
There seems to be a false myth of agents running away with system resources, degrading the performance of the true applications on the servers. While that may have been the case back in the day, most monitoring agents have been modified where system resource consumption is not an issue.
Even with SAP monitoring, where enormous amounts of data is analyzed and scrutinized, a well-designed SAP monitoring agent should not incur any issues. SAP agents should only be watching for changes in the various health data points. If the monitored data points have not changed, no change will be recorded. On the flip side, without an agent, that data needs to be continuously pulled over the network and reviewed. So with an agentless solution instead of having the agents do a quick check, the workload is put on the network, degrading the performance of ALL systems and servers.
Another concern around the work to maintain agents. It does sound like a lot of work, especially if you are monitoring hundreds or thousands of servers. Any agent upgrade would require hours of logging onto each server to re-deploy the agent, right? Not so much. Any agent-based monitoring tool these days will have a way to monitor the health of, and upgrade the agent from the central monitoring solution. This makes rolling out updates with new functionality a breeze.
The term "agent" refers to the presence or non-presence of the integrity monitoring application on each device. Agentless software lives on a gateway server to capture changes remotely. In contrast, an agent-based software has the ability to capture all user activities regardless of how they are connected to the network infrastructure.
Should the network connection between the agentless monitor and the SAP system disconnect there will be gaps in historical data and trends. In an agent-based scenario, should the network connection become disrupted, the agent will retain the data and pass back when the network connection is reestablished. One situation where it becomes extremely important is when migrating to HANA. You may find this post about HANA migration monitoring best practices interesting as well.
Furthermore, agentless systems collect data every pre-defined amount of time (some don’t even let you adjust that polling frequency). Agent-based solutions can identify, report and notify of issues in REAL-TIME. Allowing you to handle and resolve an issue before it spiral and becomes critical
Your SAP ecosystem is probably the backbone of your organization. It’s perhaps holding financial, sales, HR, production, distribution, customer data (and the list goes on….). In other words, this is not some simple application that can survive on degraded performance or even come down for a period of time. An IDC report (“DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified”) estimates that system outages can cost a company between $500,000 to $1 million or more per hour.
When it comes to your businesses most critical application, remember that monitoring SAP is not the same as monitoring standard server metrics. Not only the amount of data that needs to be reviewed and analyzed, but the sensitivity of that data do not lend themselves to properly be monitored via remote connections.
To see how Avantra utilizes robust, yet slim agents to properly monitor SAP ecosystems and provide full health analysis all in a secure manner, watch this 15-minute technical demo.