Installing monitoring software on a production SAP system creates a dependency that becomes visible at the worst possible time. The SAP kernel is patched. The monitoring agent, which sits on the application server reading low-level process data, is not compatible with the new kernel version. The monitoring tool goes dark for that system while the vendor works on a fix. Nobody knows whether the system is healthy or not. The fix arrives four days later, requires a restart, and creates a new change management ticket.
That scenario is not hypothetical. It plays out in environments that chose agent-based monitoring without fully accounting for the maintenance it creates. At one system, the cost seems manageable. At ten systems with different patch cycles, different SAP versions, and different agent configurations, the maintenance work becomes a parallel operational track that nobody explicitly budgeted for.
Agentless monitoring solves this by removing the agent from the SAP system entirely. The monitored system has no monitoring software installed on it. No transport requests. No ABAP programs deployed. No processes running on the application server. The connection is made entirely from outside, using standard SAP interfaces that already exist. This article covers exactly how that works technically, what it means operationally, and where the approach has limits worth being honest about.
What agentless actually means in an SAP context ?
The agent as a maintenance dependency
An agent in the traditional monitoring sense is a software process running on or within the monitored system. For SAP, this takes several forms. An OS-level agent running on the Linux or Windows host reads process metrics, file system data, and network statistics. An ABAP agent deployed via transport runs programs, reads tables, and executes function modules directly inside the SAP ABAP stack. A Java monitoring agent hooks into the JVM to read thread states, heap memory, and class loading. Each of these is software that needs to exist, run reliably, and remain compatible with the SAP environment as it evolves.
The maintenance dependency each agent creates is specific to its type. An OS-level agent needs to be updated when the operating system changes, tested when the hardware changes, and restarted when it crashes. An ABAP agent deployed via transport needs to pass through the SAP transport landscape: installed in development, tested in QA, promoted to production, and re-tested after every SAP upgrade that might have changed the behavior of the functions it calls. A Java agent needs version compatibility with the SAP Java VM, which changes with enhancement packages and feature packs.
When an organization runs a single SAP system, these maintenance tasks are manageable. When an MSP manages 40 SAP systems for different clients, each with its own patch cycle, each requiring independent agent validation, the maintenance volume becomes the operational cost that was not in the original pricing model.
What the connection looks like without an agent ?
Agentless monitoring connects to the SAP system from the outside using interfaces the system already provides. The connection path depends on which layer of the SAP stack is being monitored.
For the ABAP application layer, the connection is an RFC of type 3: an external RFC connection pointing to the SAP system’s message server or gateway. The monitoring collector sends RFC calls to the SAP system, which executes standard function modules or reads from standard tables and returns the result. No custom code runs on the SAP side. No transport is needed. The SAP system receives and processes RFC calls using the existing RFC infrastructure it uses for all other external connections.
For the SAP HANA database layer, the connection is a JDBC or ODBC connection to the HANA database, authenticated with a dedicated database-level monitoring user. The collector sends SQL queries against the system views in the SYS and _SYS_STATISTICS schemas: M_MEMORY_OVERVIEW, M_SERVICE_REPLICATION, M_DISK_USAGE, M_EXPENSIVE_STATEMENTS, and others. The HANA database executes these queries and returns the results. No HANA-side software is needed beyond the database user and its authorizations.
The monitoring collector, the software that initiates these connections and stores the returned data, runs on infrastructure separate from the SAP systems. It is external to everything being monitored. From the SAP system’s perspective, the monitoring collector looks like any other RFC client or database application: a connection that authenticates, queries, and disconnects.
How agentless data collection works technically ?
RFC-based collection: reading the ABAP layer
The RFC protocol is SAP’s standard mechanism for inter-system communication. An external application that wants to call a function module in a remote SAP system establishes an RFC connection, sends a call request with the function module name and parameters, and receives the return parameters. This is exactly what SAP systems use to communicate with each other in distributed landscapes. The monitoring collector uses the same mechanism.
The function modules and table reads available via RFC cover the full set of ABAP-layer monitoring data: SM50 equivalent data is available through standard function modules that return work process state and statistics. SM37 job data is accessible via RFC-enabled batch job interfaces. IDoc and qRFC queue states are readable through standard ALE and RFC API function modules. System log data from SM21 is accessible through the system log read interfaces. None of this requires custom code. It uses the same RFC-accessible interfaces that CCMS, Solution Manager, and various SAP standard tools have used for years.
The collection interval is determined by the monitoring collector’s schedule. A collector configured for 60-second polling sends an RFC call every 60 seconds, receives the current system state data, and stores it. A collector configured for 30-second polling doubles the collection frequency. The SAP system processes these calls like any other RFC request, drawing from its available background or dialog work processes depending on how the RFC connection is configured. The overhead is proportional to the collection frequency and the data volume per call, and is generally small relative to production transaction load.
HANA SQL collection: reading the database layer
HANA system views, prefixed M_ in the SYS schema, are the primary source of HANA monitoring data. They expose real-time information about memory allocation, service states, active queries, replication status, disk usage, and dozens of other metrics. These views are standard HANA objects, documented by SAP, and queryable by any application with appropriate database privileges.
The monitoring collector connects to HANA via JDBC using a database user with MONITORING system privilege and CATALOG READ privilege. With those two privileges, it can query every M_* view in the SYS schema. No additional setup is required on the HANA side. No scripts are deployed. No stored procedures are installed. The monitoring user exists as a database user, its privileges are documented and auditable, and it can be reviewed or revoked at any time through standard HANA user management.
The separation between the ABAP RFC connection and the HANA SQL connection reflects the architecture of the SAP system itself. ABAP metrics and HANA metrics come from different layers with different access mechanisms. The monitoring collector maintains both connections independently. A change in the HANA configuration does not affect the RFC connection. A change in the ABAP authorization profile does not affect the HANA database user.
The collector: where the non-agent lives
Saying a monitoring approach is agentless does not mean there is no software involved. There is software: the monitoring collector. The distinction is where it runs. The collector runs on infrastructure that the SAP team controls but that is separate from the monitored SAP systems. It might be a dedicated server, a virtual machine, a container in a management network, or a cloud-hosted service. The key property is that it is not on the SAP application server, not installed in the HANA database, and not deployed through the SAP transport system.
This placement means the collector has its own lifecycle, independent of the SAP systems it monitors. When a SAP kernel is patched, the collector does not need to be updated. When SAP changes a standard function module interface, the collector’s next scheduled version update handles the adjustment without requiring any change on the monitored system. The monitored system has no knowledge of which monitoring tool version the collector is running. It only knows that an RFC client authenticated, sent a call, and received a response.
The collector’s availability matters for monitoring continuity. A collector that goes down stops collecting data, which means monitoring gaps. Collector high availability, whether through redundant instances or automatic failover, is a design concern for the monitoring infrastructure, not for the SAP systems. The SAP team does not manage the collector’s availability. The monitoring team or the MSP does.
The operational cost of agents that becomes visible at scale
One system, one agent: the cost seems manageable
A single agent installation on a single SAP system is a few hours of work. Create the transport, test in DEV, promote to QA, test, promote to production. Maybe a restart. Document the change. The overhead is real but contained. The compatibility test after the next SAP upgrade is another half-day. Over a year, the agent maintenance for one system might be 5 to 10 person-hours.
At that scale, the argument against agents is not compelling. The agent works, the data flows, the maintenance is occasional. Teams accept the overhead because it is invisible against the total operational workload.
Twenty systems, twenty agents: where the math changes
At 20 SAP systems, the agent maintenance scales linearly. Twenty transport sets to manage. Twenty compatibility tests per SAP upgrade cycle. Twenty restart windows to coordinate. Twenty change management records to create and close. If the organization runs quarterly SAP upgrades, that is 80 compatibility tests per year. If the agent vendor releases updates twice per year, that is 40 update deployments across 20 systems.
The math compounds when the 20 systems have different SAP versions, different operating systems, or different patch schedules. An agent that has been validated for S/4HANA 2023 FPS02 may behave differently on S/4HANA 2022 FPS04. The monitoring team needs to maintain a compatibility matrix and test each agent version against each SAP version before deploying. In a heterogeneous landscape, that matrix has real dimensions.
The invisible cost in this calculation is the project overhead. Every SAP upgrade project that includes agent compatibility testing is a larger project than it would be without agents. The testing effort is not always attributed to the monitoring tool in the project budget. It shows up as “upgrade project overrun” without a clear cause.
The upgrade problem: why agent maintenance compounds with SAP patch cycles
SAP releases kernel patches, enhancement packages, feature packs, and major releases on a schedule that has accelerated since the introduction of S/4HANA. Each release is a potential compatibility event for any software running on or within the SAP system. The monitoring vendor needs to test their agent against the new release, release an updated version, and customers need to deploy it before updating their SAP systems.
In practice, the sequence is rarely that clean. The SAP update releases ahead of the agent update. The customer has a maintenance window for the SAP patch but no compatible agent version. The options are to delay the SAP patch (unacceptable for security patches), to proceed with the patch and accept a monitoring gap until the agent update ships (which defeats the purpose of monitoring), or to remove the agent before patching and reinstall after (which is three change management records instead of one).
With agentless monitoring, this problem does not exist. The SAP kernel patch changes nothing about the RFC interface or the HANA system views. The monitoring collector continues collecting without modification. The upgrade project scope is smaller because monitoring compatibility is not a test item. The SAP team patches on schedule without coordinating with the monitoring vendor.
| In practice: In regulated environments such as GxP-compliant pharmaceutical or financial systems subject to SOX controls, every software installation on a production system requires documented change control. An agent installation is a software installation. It enters the change control process, requires validation testing, and may require regulatory documentation depending on the system’s validation status. Agentless monitoring avoids this category of overhead entirely: no software is installed on the validated system, so no change control is triggered. |
Authorization design: the agentless security model
What the monitoring user actually needs
An RFC-based monitoring connection authenticates as an SAP user. That user needs authorizations to execute the RFC calls and read the data the monitoring tool requires. The principle of least privilege applies here exactly as it does anywhere: the monitoring user should have exactly the access needed for monitoring and nothing beyond that.
The core authorization objects for ABAP-layer monitoring are S_RFC, which controls which RFC function groups and function modules can be called from external connections, S_TCODE, which controls access to transaction codes whose data the monitoring tool reads, and in some cases S_ADMI_FCD for specific system administration read functions. The exact values depend on which metrics the monitoring tool collects, and a well-documented monitoring tool provides a list of required authorization objects with their specific values.
Creating the monitoring user with a custom role built from these specific authorizations produces an account whose access is explicitly defined, documented, and auditable. A security team can review the role and confirm that the monitoring user cannot modify any SAP data, cannot execute any business transactions, and cannot access any application data beyond what is needed for system health metrics. That audit trail does not exist for an agent that has been granted broad OS-level process access or has been installed with a high-privilege account for convenience.
Why minimal authorization is more auditable than agent installation ?
An agent running on the OS level with root or Administrator privileges to access process information has a broad authorization footprint that is difficult to scope in an access review. The access control model for OS-level processes is binary: the process can read anything accessible by its user account, and scoping that to only monitoring-relevant data requires OS-level policy enforcement that is separate from the monitoring tool itself.
An RFC monitoring connection with a specifically configured authorization role has an explicit scope defined in SAP’s own access control system. The authorization review for the monitoring user is done in SU01 and the role editor, using the same tools the security team uses for all other user access reviews. The monitoring user’s access is no different in kind from any other functional SAP user. It is just narrower in scope.
The practical value of this auditability is most visible during security audits and penetration testing exercises. The question “what access does the monitoring system have” has a clear, precise answer that comes directly from the SAP authorization documentation, not from an external agent’s configuration files. That precision is valued by auditors and by the security teams responsible for the production systems.
What agentless monitoring cannot do, and what fills the gap ?
OS-level metrics and the hybrid approach
Agentless SAP monitoring via RFC and HANA SQL provides coverage of the SAP ABAP application layer and the HANA database layer. It does not provide coverage of the operating system layer: file system utilization on non-HANA volumes, network interface traffic, hardware-level temperature and fan status, kernel-level memory pressure indicators that are not surfaced through SAP APIs.
This is the honest limitation of the architecture. RFC and SQL interfaces expose what SAP exposes. Some OS-level data is available through SAP APIs, because SAP reads OS metrics internally and exposes them through CCMS or through HANA system views. But the coverage is not complete.
The practical resolution for most environments is a hybrid approach. OS-level metrics are collected by standard infrastructure monitoring tools, whether that is a lightweight OS agent from the infrastructure monitoring platform, SNMP polling, or cloud provider native monitoring in hyperscaler deployments. SAP application and database metrics are collected agentlessly through the monitoring platform. The two data sources are presented in integrated dashboards where OS events and SAP events can be correlated without requiring either tool to cross into the other’s domain.
This hybrid is generally preferable to trying to extend the SAP-specific monitoring tool into OS coverage. OS monitoring is a solved problem with mature tooling. SAP application monitoring is a specialist problem with specific tooling requirements. Combining them in a purpose-built SAP monitoring tool that also installs OS agents reintroduces the maintenance dependency that agentless monitoring is designed to avoid.
When an agent is still the right answer
There are scenarios where an agent is the appropriate choice even in an environment that otherwise uses agentless monitoring. Custom metric collection that requires access to data not exposed through SAP’s standard APIs may need a custom ABAP report or a lightweight agent to collect and forward it. Some hardware monitoring scenarios require access to data that only the OS or BMC provides. Specific regulatory requirements may mandate a monitoring architecture that places monitoring code on the monitored system for chain-of-custody reasons.
Agentless is not a universal rule. It is the right default architecture for SAP monitoring because the standard SAP interfaces cover the metrics that matter most, the maintenance overhead is the dominant operational cost at scale, and the authorization model is cleaner. Where a specific requirement cannot be met through standard interfaces, an agent is a justified exception rather than a philosophical defeat.
The important operational discipline is treating agents as exceptions that are documented and reviewed, rather than as defaults that accumulate silently. An SAP landscape where every system has six different agents installed by six different teams over five years, none of them fully documented and some of them incompatible with current SAP versions, is the condition that agentless architecture prevents.
Deployment speed and onboarding at scale
The per-system connection timeline
Connecting a single SAP system to an agentless monitoring platform takes a predictable amount of time. Create the RFC monitoring user in SU01 with the required authorization role: 20 minutes. Create the RFC destination in SM59 pointing to the monitoring collector: 10 minutes. Verify the RFC connection test passes and the authorization test passes: 5 minutes. Configure the HANA monitoring database user with the required system privileges: 15 minutes. Verify HANA connectivity from the collector: 5 minutes. Start data collection and confirm metrics are appearing in the monitoring dashboard: 10 minutes.
Total elapsed time to add a new SAP system to monitoring: roughly 1 hour, plus any internal approval time for creating the monitoring user. No transport request. No SAP restart. No change management ticket for software installation. No compatibility testing against the specific SAP version. No involvement from the SAP vendor or the monitoring vendor beyond the initial platform setup.
In an agent-based scenario, the equivalent timeline includes creating and testing a transport in development, scheduling a promotion to QA, testing in QA, scheduling a promotion to production, executing the production deployment in a change window, and verifying the agent is running. Depending on the organization’s change management cadence, that sequence takes one to three weeks. For an MSP onboarding a new client system, the difference between one hour and three weeks has direct commercial implications.
How MSPs and large IT teams use this differently ?
For an MSP managing SAP environments for multiple clients, the agentless architecture changes the economics of each new system onboarded. The onboarding cost is consistently low. The ongoing maintenance cost does not grow with the number of systems. A team that manages 50 SAP systems with agentless monitoring has the same per-system ongoing maintenance burden as one managing 5. The team managing 50 systems with agents has ten times the maintenance volume.
This difference is not just about efficiency. It affects what services the MSP can offer credibly. An MSP with low-overhead monitoring can offer monitoring coverage as part of a standard managed services package without inflating the per-system price to cover maintenance costs. An MSP with high-overhead monitoring either absorbs the maintenance cost as a margin reduction or passes it to clients as a monitoring surcharge that makes the pricing less competitive.
For large enterprise IT teams managing SAP landscapes internally, the advantage is different. The constraint is usually not per-system cost but engineering time. An architecture that does not require engineering involvement in every SAP upgrade cycle, and does not require coordination between the SAP upgrade team and the monitoring team for compatibility testing, returns engineering time to higher-value work. The SAP team owns the upgrades. The monitoring team owns the monitoring platform. Neither team needs the other’s involvement for routine maintenance.
The architecture that shrinks as you scale it
Most infrastructure grows more complex as the number of managed systems increases. More systems mean more agents, more configurations, more compatibility matrix entries, more maintenance tracks running in parallel. The operational overhead is proportional to the scale, and at a certain point it becomes the primary operational constraint rather than a background cost.
Agentless monitoring inverts this relationship. Adding a new SAP system to the monitoring landscape is the same operation regardless of whether it is the fifth system or the fiftieth. It is one RFC user, one authorization role, one database user, one collector configuration entry. The complexity of the monitoring infrastructure does not grow with the number of systems it covers. It grows with the complexity of the collector itself, which is a single point of investment shared across the entire monitored landscape.
That property, stable operational overhead as the landscape scales, is what makes agentless monitoring the appropriate default architecture for any organization managing more than a handful of SAP systems. Not because agents are always wrong, but because the maintenance cost of agents is a variable that compounds and eventually dominates, while the absence of agents removes that variable from the equation entirely.
Redpeaks connects to SAP systems via RFC and HANA SQL without agents, transports, or SAP-side software. A new system is typically live in monitoring within an hour of the RFC user being created. See the connection architecture in detail.
