How do I monitor my SAP systems?

Implementing SAP monitoring takes one thing above all: time. For base administrators and module maintainers, it is a huge feat to create the necessary conditions for monitoring SAP in the back end.

But only those who comprehensively monitor their SAP systems can operate their business processes in a stable manner.

Why monitor SAP?

Step 1: As trite as it sounds, before you start setting up SAP monitoring, you should ask yourself what you want to achieve with it.

Save costs? Prove stable services? Reduce manual activities? Of course, most users will have the stability of their SAP systems in mind and want to keep outages and bottlenecks to a minimum.

But cost savings and the creation of transparent IT services can also play a role.

Other reasons can be the automation of routine activities, such as the continuous checking of log files or the checking of individual instances. Monitoring relieves administrators and gives them more time for their core tasks.

In addition, since monitoring is automated and always based on the same criteria, human errors are minimized. The availability of reliable performance data makes the system transparent and generates trust.

Many IT departments want to use the values as a basis for reporting, to be able to use them as proof of availability or as a data basis for performance analysis and capacity management.

So SAP monitoring can do much more and there are many good reasons for it.

Measure what?

Step 2: Anyone who has ever dealt with the topic of SAP monitoring knows that there is an almost unmanageable number of performance indicators and metrics that can be monitored.

The second step should therefore be devoted to selecting the parameters that are critical for operations. This step is elementary, because good monitoring is not characterized by the quantity of monitored metrics, but by a healthy ratio of important metrics and deliberate "non-measurement".

In SAP monitoring in particular, it is easy to collect countless data but do little with it.

Measure with what?

Step 3: SAP has developed quite a few monitoring tools in its long history. These are very useful, but do not necessarily contribute to a better overview. In the third step, you should therefore look at the various monitoring tools from SAP.

While SAP's own monitoring tools such as the SAP Computer Center Management System (CCMS), CEN, GRMG, the SAP Performance Monitor (ST03n) or eCATT provide a differentiated insight into the inner workings of an SAP system, open source software such as Nagios gives you an overview of the entire network infrastructure.

This is an invaluable advantage, especially in the event of system failures with a cause that is not immediately apparent. And with Solution Manager 7.2, SAP has delivered another new architecture (which I will refer to below as SolMan).

SAP admins have a number of new topics ahead of them as a result. For example, the integration of Wily Introscope has significantly enhanced SAP, particularly in the Java environment.

SAP also no longer relies solely on information from the CCMS, but also uses other sources such as database connections and the SAP Diagnostics Agent.

The complexity of the monitoring landscape has thus increased significantly. In addition, SolMan has another disadvantage: Non-SAP systems can either be monitored only rudimentarily or not at all.

Consequently, SolMan represents a monitoring island within the SAP cosmos. The connections between SAP and other system components and applications should not be underestimated:

Often, a supposed SAP problem is actually a problem with the base infrastructure or third-party applications. Admins should therefore think about integrating SAP into general monitoring.

Integration into infrastructure monitoring?

Step 4: In addition to the complexity of SAP and the very high demands this places on staff knowledge, the biggest challenge in setting up SAP monitoring is actually setting up comprehensive monitoring that takes into account all the dependencies between SAP and third-party systems.

The next step should therefore be to address the question of how to close the gap between SAP and third-party systems. In my experience, an open approach is the most promising.

Therefore, I recommend the use of open technologies or open source solutions. For the open source monitoring solution Nagios there are some plug-ins that get their information from the SAP CCMS.

Unfortunately, however, a pure CCMS connection is not enough. If you want to be prepared for the long term, you should consider integrating multiple interfaces and connecting new technologies.

For example, the Java-based SAP systems can only be monitored to a very limited extent by the CCMS. This means that an alternative must be found here. The new starting point is called SAP Control Webservice and offers the following functions:

• AbapReadSyslog: Transaction SM21 style information;
• AbapGetWPTable: Transaction SM50 style information;
• GetAlertTree: information in the style of transaction RZ20;
• GetAlerts: Information about all alerts;
• GetProcessList: Monitoring of message server and dispatcher;
• J2EE: Information about various Java metrics and statistics;
• EnqGetStatistic: enqueue statistics (enqueue errors, dequeue errors);
• EnqGetLockTable: Information about lock entries

What the SAP Control Web Service can provide depends on the version and type of system.

Create the monitoring architecture

Step 5: Now it gets concrete: Create the architecture for your SAP monitoring. With SolMan 7.2, SAP offers central monitoring that no longer draws its information only from the CCMS, but also connects other data sources and provides all information in a central interface.

When setting up monitoring, I recommend breaking it down into sub-areas. This allows you to measure SAP and individual components such as the database, operating system, hardware, etc. independently of each other.

• Hardware: An often neglected but elementary component in the monitoring of SAP is functioning hardware. The hardware information can be provided by the hardware agents of the individual manufacturers (Dell, Fujitsu, HP, IBM) via Simple Network Management Protocol (SNMP) and can thus be integrated into the central monitoring.This is important because even the best redundancies such as RAID (Redundant Array of Independent Disks) are of no use in the long term if their status is not also monitored.
• Operating system: In addition to the hardware, the operating system is another important component. It forms the basis for the applications to be monitored and must therefore naturally also be recorded.To avoid dependencies on the CCMS, it is recommended that monitoring be carried out using operating system agents. In particular, the utilization and fill levels of hard disks are an important factor in the SAP area, because experience shows that a full partition is often the reason for SAP coming to a standstill.CPU and memory statistics also provide a good overview of whether the operating system is reaching its performance limits.
• Database: The database is required by SAP and should therefore also be monitored. Here too, in addition to the criterion of successful connection to the database, the "memory utilization" parameter in particular plays a central role.Error messages from databases are usually written in log files, which should be evaluated. The method used should not just "bluntly" search the log file for hits, but should provide various mechanisms for looking at errors.A good method is characterized by the fact that it is also possible to specify critical, warning and Ok patterns, log rotations and the exclusive observation of newly added lines.

Set up SAP Basis Monitoring

Step 6: The sixth step is the actual monitoring of the SAP base system. Basic monitoring includes the following metrics:

SM04 Number of users, SM12 Lock entries: Enqueue Errors/Dequeue Errors, SMQ1 Status qRFC Output, SMQ2 Status qRFC Input, SM13, Update Aborts, SM37 Aborted Jobs/Longrunners, SM 50 Error in Dialog, Batch, Update Processes, SM 51 Status SAP Server SM21 Syslogfrequency, SM 56 Number Ranges Still Free, SM58 TRFC Status, SPAD Spool Status/Spool Used Numbers, ST03N Dialog Response Time, ST22 Shortdumps/Shortdump Frequency, SM21 Syslogfrequency, SCC4 System Changeability (Table T000), WE02 Incorrect IDOCs.

The selected metrics from CCMS and SAP Control Webservice are chosen based on the most important transactions. Make sure that the selected monitoring can always be easily adapted to your requirements.

If your SAP monitoring covers the points described so far, you can pat yourself on the back: You now have comprehensive monitoring of the SAP basis. You have thus created the basis for a functioning SAP system.

Include applications in the monitoring

Step 7: Monitoring SAP does not end with monitoring performance indicators. It is equally important to look at the application from the user's point of view in order to keep an eye on the function of the SAP system as a whole.

Experience shows that the best way to monitor applications is via end-to-end monitoring. This is the only way to ensure that the application really works.

A good end-to-end monitoring is characterized by the fact that it is not only recorded with a recorder, but can also react to actions. Therefore, the processes and any special features and problems that occur should be described as precisely as possible.

I recommend using special end-to-end robots that cyclically perform defined user actions via the SAP GUI. These can be actions ranging from SAP login to filling search masks.

The elapsed time between the freely defined measuring points is evaluated, analyzed and transmitted to the monitoring system. Ideally, these probes are located at different points in the network topology to ensure that the general conditions are as real as possible.

Optimize your SAP monitoring

Step 8: Most SAP users are skeptical about open source. The system seems too powerful to be "managed" with open technologies.

Open source solutions can be used to address the CCMS, the SAP Control Web Service, RFC functions and BAPI and thus integrate them into a central monitoring system.

Such integration offers further possibilities in addition to overarching monitoring: For example, metrics from SAP monitoring can be linked to metrics from the infrastructure.

The fact that all IT systems involved in a business service are correlated with each other creates a comprehensive and business-suitable monitoring system that can be used to seamlessly monitor even large SAP and IT landscapes.

I therefore recommend considering open technologies when setting up SAP monitoring. In my eyes, two systems are the most suitable for this.

Nagios Plug-ins for CCMS

When you think of open source software for network monitoring, you think of Nagios. The GPLv2 solution has been the de facto standard in this area for years.

The modular structure and expandable architecture make the tool suitable for monitoring complex system landscapes with SAP and other proprietary applications. With Nagios, plug-ins take over the monitoring of the various components.

The Nagios Plug-ins for CCMS are probably the best known for the CCMS and are considered the model for the integration of CCMS metrics in Nagios. With the plug-ins it is possible to get and display parameters from the CCMS.

However, the number of connections to SAP and the execution of many active checks in Nagios are problematic. Therefore, one often creates a special monitoring set that is retrieved. The output is stored in a text file.

In general, this is a good approach, as it relieves the SAP system. The configuration is done via the configuration files. It is mandatory to have access to SAP in order to obtain the information about metrics and monitoring sets.

The SAP monitoring module from OpenITCockpit

Available monitoring solutions have one thing in common: The relief has a positive effect either on the performance of SAP or on that of the monitoring system - but not on both at the same time.

One approach that relieves both systems equally is the Nagios-based solution OpenITCockpit. The SAP monitoring module pursues two goals: The integration of the SAP Control Webservice guarantees a future-proof monitoring of SAP systems.

The architecture of the plug-ins and their interaction with an active check and multiple passive checks relieve the SAP systems and the monitoring system. With OpenITCockpit SAP monitoring, no SolMan is required as a data source.

The option of distributed monitoring also significantly increases scalability, enabling OpenITCockpit to monitor even large SAP landscapes and wide-ranging infrastructure environments.

For independent and extended monitoring, additional data sources can be connected beyond the CCMS. These include: Databases, operating system agents, SAP Control web services and calling RFC functions as well as BAPI modules.

Conclusion: Keep the overview

Many paths lead to the goal and basic monitoring of SAP is possible with many different tools. SAP's on-board tools provide access to all relevant data and also make it possible to monitor components beyond the pure SAP landscape.

Unfortunately, the setup and configuration of the various tools is very complex and sometimes not possible automatically.

In order to create the basis for comprehensive monitoring of SAP in the long term, it is important to rely on technologies such as the SAP Control Web Service.

Open source software such as Open-ITCockpit provides a unified view of the entire IT including network, server and SAP. Configuration and operation are simpler than with Solution Manager.