SAP monitoring with openITCOCKPIT
The openITCOCKPIT SAP monitoring module gives you the ability to manage the monitoring of your SAP environments in a comprehensive and resource-efficient way. It's easy to install via the integrated openITCOCKPIT Package Manager and provides a variety of pre-assigned host and service templates according to established best practice approaches. With a minimum of effort, these templates can then be customised to suit your individual needs.
- openITCOCKPIT SAP monitoring features that speak for themselves
- Graphical user interface for administration and visualisation
- Practical example
- Non-SAP checks
- SAP monitoring with holistic approach
- SAP monitoring: Motivations
- SAP monitoring architecture
- SAP Basis
- SAP open-source monitoring solutions
With openITCOCKPIT SAP monitoring, you don't need a SAP Solution Manager as a data source!
This module will help you determine information about
- the Computing Centre Management System (CCMS)
- the Business Application Programming Interface (BAPI)
- RFC functions and
- the SAPControl Web Service
directly from the SAP system you want to monitor.
openITCOCKPIT SAP monitoring features that speak for themselves
- SAP systems are integrated simply and without laborious agent registration, because the interfaces for the SAP systems are accessed directly.
- openITCOCKPIT determines the data directly from the SAP systems and therefore doesn't need a SAP Solution Manager for gathering data.
- In conjunction with the distributed monitoring module, openITCOCKPIT is scalable in very large SAP environments and offers full flexibility when the number of systems grows.
- openITCOCKPIT's system monitoring is very resource-efficient, because multiple metrics can be determined in a single data query.
- Additional data sources can be connected for carrying out an independent monitoring of the CCMS:
- Operating system agents
- SAPControl Web Services
- Calling RFC functions / BAPI building blocks
- openITCOCKPIT, in combination with the event correlation module, can detect the actual reason (root cause) for a failure.
- The delivery of external events and the transmission of results from End-2-End checks can easily be integrated via the API in openITCOCKPIT.
- It's also easy to extend system monitoring through the use of in-house developed scripts in openITCOCKPIT.
Graphical user interface for administration and visualisation
A key feature of openITCOCKPIT is its simple and intuitive administration using the graphical user interface. This applies in particular to setting up monitoring templates, adding hosts and services, as well as setting up maps, reports, and event correlations.
The dashboard displays the status of the entire IT landscape through the use of maps, traffic lights, gauges and graphs – including the causes of outages for important nodes and services.
Using a finely adjustable roles and authorisation scheme, individual dashboards can be provided for every department.
And with the event correlation module it's possible to monitor not just individual services, but also clusters and entire process chains.
The openITCOCKPIT maps module represents status information and correlations in the form of appealing graphs and charts.
The ifm group also monitors its SAP landscape with openITCOCKPIT. Nearly 50 application servers and ca. 40 databases are integrated into the monitoring system. This enables the company to oversee its entire IT infrastructure, including SAP applications, with a single monitoring software. The data is centrally available in openITCOCKPIT and does not have to be drawn and summarized from different systems.
The SAP monitoring module of openITCOCKPIT identifies the data directly in the SAP systems and therefore does not require a SAP Solution Manager as data source. Because the SAP systems are accessed directly, the SAP monitoring is agentless and thus resource-conserving and very performant.
Read the entire project report here.
With openITCOCKPIT, all you need is a monitoring tool to be able to keep fully on top of your entire IT landscape, including network, servers, and SAP system. This means you save on resources while achieving a single view of your entire IT infrastructure.
Non-SAP checks: Hardware, operating system, database, tools
In general, a comprehensive monitoring plan includes not only the monitoring of SAP systems, but also views of non-SAP services. This includes checks on mail services, network infrastructure and a whole lot more. This is where openITCOCKPIT offers the ability to implement a variety of audits.
"SAP monitoring with openITCOCKPIT guarantees the availability and stability of our SAP systems. It contributes decisively to the satisfaction of the users and to our business success."
Thomas Rössler, Head of Information Technology, Municipal Utility Gießen
"The SAP monitoring of openITCOCKPIT allows us to monitor our SAP systems seamlessly. The key benefit is that we do not see the data from SAP in isolation from the rest of the infrastructure, instead all data is grouped in openITCOCKPIT. This gives us a comprehensive view of our IT landscape. "
Martin Wiggermann, ifm electronic
SAP monitoring with holistic approach
When people think of SAP monitoring, they almost instantly think of SAP's own solution manager. It should come as no surprise then that most users are sceptical about using an open-source approach. However, a variety of tools and functions such as CCMS, the SAPControl Web Service, RFC functions and BAPI can be managed and thus integrated into a central monitoring system using open-source technologies. Such an integration offers further possibilities in addition to just monitoring. For example, metrics gained from SAP monitoring can be combined and evaluated with metrics obtained from the company's infrastructure. By interconnecting all these using a single, business service-centred IT system, comprehensive and professional business monitoring suitable for even the largest SAP and IT landscapes can be achieved.
When it comes to standardised, computer-based business processes, there is no doubt SAP has set standards and made life a lot easier for professional users around the globe. However, for SAP Basis and module administrators, this requires an enormous effort on their part to create the necessary conditions in the back end. It should be noted this also includes SAP monitoring, because if a comprehensive SAP monitoring solution has not been established, stable business processes cannot be established.
In this document you will be introduced to a variety of SAP monitoring options made possible using open-source technologies. You can then decide for yourself whether they are right for your particular SAP landscape.
SAP monitoring: Motivations
Why monitor your SAP landscape? The primary motivation for using or optimising SAP monitoring is to increase the stability of your SAP installation as well as reduce outages and bottlenecks to a minimum. Cost savings and ensuring you have transparent IT services also play an important role.
This includes the automation of routine tasks such as running continuous checks on log files or reviewing individual SAP instances. By performing regular monitoring, administrators are relieved of these tasks and can concentrate more on their core tasks and responsibilities. And because monitoring is automated and always carried out according to the same criteria, human error is also avoided.
Also, the availability of reliable performance data ensures system transparency and builds confidence. These values can be used as the basis for a reporting structure and serve as proof of availability or base data for performance analysis and capacity management. When prepared accordingly, the data can also be used to support management in decision-making. As you can see, there are many reasons to set up a monitoring system, particularly for any SAP instances you may have.
Anyone who has ever dealt with the topic of SAP-Monitoring will have noticed a number of performance indicators and metrics can be tracked. Selecting operationally critical parameters is of fundamental importance, because a good monitoring system is not just characterised by the amount of metrics being monitored, but also by a healthy ratio of important metrics and conscious decisions about what not to monitor. That is, it's easy to collect enormous amounts of data, but then find you can do very little with them.
In its long history, SAP has developed a vast array of management tools and platforms. Although SAP's own monitoring tools such as the SAP Computing Centre Management System (CCMS), CEN, GRMG, SAP Performance Monitor (ST03n) and eCATT offer sophisticated and detailed insights into the inner workings of an SAP system, the open-source solution Nagios enables users to view their entire network infrastructure. This is an invaluable advantage when companies experience system failures where the cause is not immediately discernible.
Unfortunately, however, this does not necessarily contribute to a better system overview. With the introduction of Solution Manager 7.2 (SolMan), SAP has delivered a further new architecture and thus presented SAP Basis Administrators with a number of new topics and issues. For example, with the integration of Wily Introscope, SAP has evolved even further – particularly with regard to Java. SAP also no longer relies solely on information obtained from the CCMS. Instead, it now also uses other sources such as database connections and the SAP diagnostics agent.
Quite apart from its increased complexity, the SolMan has another distinct disadvantage: non-SAP systems can either only be monitored at the most rudimentary level or not at all. The SolMan thus represents a somewhat limited "monitoring island" within the SAP cosmos. SAP connections to other system components and applications, however, should not be underestimated: Often problems assumed to be SAP related are, in fact, down to basic infrastructure issues or third-party applications.
In addition to SAP's complexity and the very high demands placed on employee knowledge of the system, the principle challenge for SAP monitoring is setting up a comprehensive monitoring structure that takes into account all dependencies between SAP and any third-party systems.
In this document we will try, on the one hand, to reduce the complexity of SAP monitoring by describing how it can be set up using all its dependencies. We will also attempt to show, on the other hand, how when setting up a monitoring instance the gaps between SAP and third-party systems can be closed with the help of open-source tools.
In order to create a sensible and monitoring system from what would otherwise just be an SAP monitoring system, it is necessary to think outside the box. For instance, the Nagios monitoring solution contains a number of plugins that draw information from the SAP CCMS. SAP monitoring, however, goes far beyond a simple connection to the CCMS. To ensure systems have sustainable, long-term coverage, a number of interfaces and connections with new technologies need to be in place. Thus, any monitoring of Java-based SAP systems using only the CCMS will be severely limited. Clearly an alternative needs to be found.
This alternative, new approach is called SAPControl Web serviceand offers the following functions:
- ABAPReadSyslog: Information in the manner of transaction SM21
- ABAPGetWPTable: Information in the manner of transaction SM50
- GetAlertTree: Information in the manner of transaction RZ20
- GetAlerts: Information on all alerts
- GetProcessList: Monitoring of the message server and dispatcher
- J2EE: Information on various Java metrics and statistics
- EnqGetStatistic: Enqueue statistics (enqueue errors, dequeue errors)
- EnqGetLockTable: Information on lock entries
The information SAPControl Web servicecan provide, however, depends on the version and type of system used.
SAP monitoring architecture
With SolMan 7.2, SAP introduced a monitoring system that no longer drew information solely from the CCMS. As of 7.2, other sources are also included and the information obtained is displayed in a central interface.
A recommended approach for setting up an SAP monitoring system stipulates dividing the instance into subsections that enable the independent monitoring of SAP and the other individual component elements such as databases, operating systems and hardware.
An often overlooked, but nonetheless elementary component in monitoring SAP systems is hardware. Hardware information can be provided by the individual manufacturers' own hardware agents (DELL, Fujitsu, HP, IBM) using simple SNMP (network management protocol). This information can then be integrated into the central monitoring system. This is important, because even the best redundancy systems such as RAID (redundant array of independent disks) are worthless in the long run if their status is not being monitored.
In addition to hardware, the operating system is another important component of SAP monitoring. It forms the base level for the applications to be monitored and so must also be reported on. To avoid relying on the CCMS, we recommend that monitoring be performed using operating system agents. In particular, the utilisation and rate at which hard drives fill with data are an important factors when it comes to SAP, because experience shows that a full partition is often the reason for an SAP system failure. CPU and memory statistics also provide a good overview of whether the operating system has reached the limits of its performance.
Likewise, the database being used by SAP should also be monitored. In addition to having a successful database connection, disk space usage also plays a central role. Normally, database error messages are written to log files that should be reviewed and evaluated. Whichever method is used, it should not just blindly crawl through these files, but rather provide different mechanisms for reviewing any errors that are found.
Such a solution should include the ability to review important messages (warnings, critical entries, all-clear messages), carry out log rotation and exclusively view newly added lines.
While the previous chapter listed the components that serve as basic elements for an SAP system, in this chapter we will be dealing with the actual monitoring of the SAP Basis system.
A basic monitoring setup should include the following metrics:
- SM04 User List
- SM12 Display and Delete Locks: Enqueue Errors / Dequeue Errors
- SMQ1 qRFC Status Outbound
- SMQ2 qRFC Status Inbound
- SM13 Update Requests
- SM37 Overview of Job Selection
- SM50 Work Process Overview
- SM51 List of SAP Systems
- SM56 Number Range Buffer
- SM58 TRFC Status
- SPAD Spooler Status / Spool Used Numbers
- ST03N Dialog Response Time
- ST22 Short Dumps / Short Dump Frequency
- SM21 Syslog Frequency
- SCC4 System Change (Table T000)
- WE02 Incorrect IDOCs
The selected metrics from CCMS and the SAPControl Web servicehave been chosen based on the most important of these transactions. In doing so, it should be kept in mind that the selected monitoring setup can always be easily adapted to suit your own requirements.
If your SAP monitoring includes the points described so far, you have a comprehensive monitoring instance for your SAP Basis system and have laid the foundation for a functioning SAP system.
SAP monitoring does not, however, end with the monitoring of performance indicators. It is equally important to regard the applications from the viewpoint of the user in order to keep the SAP system as a whole in mind.
Experience shows that applications can best be monitored using an End-2-End approach. This is the only way to ensure that applications are actually working. Good End-2-End monitoring is characterised by the fact that it not only records events, but can also respond to actions. This means that procedures and specific characteristics and problems should be described as precisely as possible.
It is recommended that special End-2-End robots be used to perform cyclically defined user actions via the SAP GUI. This makes it possible to carry out actions ranging from completing SAP logins to filling in forms. The time elapsed between the freely defined measurement points is evaluated, analysed and transferred to the monitoring system. Ideally, these probes are located at various points in the network topology so that the most realistic view of the existing circumstances can be obtained.
SAP open-source monitoring solutions
Nagios plugins for CCMS
When it comes to open-source network monitoring solutions, the clear leader is Nagios. This GPL v2 solution has been the de facto open-source standard for years. With its modular design and extensible architecture, this tool is suitable for monitoring complex system landscapes with SAP and other proprietary applications. Additional Nagios plugins also handle the monitoring of different components.
The Nagios CCMS plugins are probably the best known of the CCMS plugins and are considered to be the model for integrating CCMS metrics into Nagios. Using these plugins, it is possible to obtain and represent various parameters from the CCMS.
The number of connections to SAP and performing many active checks in Nagios, however, can be problematic. For this reason, it is a common practice to create a special monitoring set that can be called as needed, with the output being stored in a text file. Generally, this is a good approach for reducing the resource load on the SAP system.
This is normally set up via the configuration files. To do this, it is necessary to have access to the SAP system so that information regarding metrics and monitoring sets can be obtained.
openITCOCKPIT and the SAP monitoring module
The various monitoring solutions currently available have one thing in common: You can either achieve a reduced load and positive performance for SAP or for the monitoring system itself – but not for both.
An approach, however, that reduces the load for both systems is the Nagios-based solution openITCOCKPIT. The SAP monitoring module in openITCOCKPIT has two objectives: First, the integration of the SAPControl web service ensures the future-proof monitoring of SAP systems. And second, due to the plugins' architecture and their efficient interaction with one active check and multiple passive checks, they effectively reduce the amount of resource load on both the SAP and monitoring systems. Also, with openITCOCKPIT there is no need to use the SAP Solution Manager (SolMan) as a data source. Due to the ability to set up distributed monitoring, scalability is significantly increased making it possible to use openITCOCKPIT to monitor very large SAP landscapes and extensive infrastructure environments.
To achieve an independent and expanded monitoring instance, further data sources can be connected using the CCMS. These include:
- Operating system agents
- SAPControl web services
- Calling RFC functions / BAPI building blocks
openITCOCKPIT is available as a free Community Version on Github and provides comprehensive network monitoring capabilities. However, to monitor SAP systems, the corresponding SAP module must be purchased to unlock this capability.
There are many paths to the same goal and setting up basic SAP monitoring can be done using a variety of different tools. The standard native SAP tools provide access to all relevant data and enable components to be monitored over and beyond just the pure SAP landscape. Unfortunately, setting up and configuring the various different tools is complex and to a certain extent not automatically possible.
To achieve a long-term basis for comprehensively monitoring your SAP landscape it is important to rely on technologies such as the SAPControl Web Service. Open-source software solutions such as openITCOCKPIT enable users to gain a consistent, unified view of the entire IT landscape including networks, servers and SAP instances while at the same time providing simple and intuitive configuration and operation compared with SolMan.