This blog focuses specifically on SLT integration monitoring. Monitoring an SLT system itself is explained in this dedicated blog.
Set up SLT integration scenario
Start the integration and exception monitoring FIORI tile:
On the configuration add the SLT system:
Select SLT as specific scenario:
On the Monitoring part you can filter on a specific source system and/or SLT schema:
On the 3rd tab you can set the Alerting in cases of errors:
Now save and activate. The monitoring is active now.
Next step is to use this system in a model for your scenario:
Using the SLT integration monitor
If you open the FIORI tile and you have selected your scenario, you still need to perform an extra click to go to the SLT monitor:
First you get overview of your system(s):
You need to click on the blue numbers to drill down:
This gives overview of errors, source connection status and target connection status.
You cannot drill down further on this tile. If you see an error, you need to go to your SLT server and start transaction LTRO to see all detailed error and start fixing from there. Transaction LTRO can have errors shown that are not visible in transaction LTRC. Focused Run uses LTRO data.
This blog will focus on monitoring of standalone web dispatchers. Standalone web dispatchers are used to load balance web traffic towards ABAP and/or JAVA systems. Common use case is to have web dispatcher for a large Netweaver Gateway FIORI installation.
Monitoring productive cloud web dispatchers
Monitoring of web dispatchers focuses on availability and connectivity/performance.
The web dispatcher template contains most needed elements out of the box:
Issues with performance are often caused by limitations set in the web dispatcher configuration. Keep these settings active.
You might want to add specific custom metric to monitor the most important URL for your web dispatcher. Read more in this specific blog.
Next to this setup the normal host monitoring to make sure the file system and CPU of the web dispatcher are not filling up and causing availability issues for the web dispatcher function.
Monitoring non-productive web dispatcher systems
For monitoring non-productive web dispatcher systems, it is normally sufficient to restrict to host and availability moniotoring.
Content servers are often used to store attachment and data archiving files. They are technical systems with usually no direct access for end user. End users normally fetch and store data form content server via an ABAP or JAVA application.
The main part of content server monitoring is availability.
ABAP connection to content server monitoring
In some cases both your ABAP stack and content server are up and running, but communication between them is failing on application level. This leads to not working system for end users. Root causes can be firewall issues, certificate issues, or somebody altered settings.
To test the ABAP system connection to content server a custom ABAP program is needed. See this blog. You can schedule the program in batch and set up a new custom metric to capture the system log entry written by the program.
System host template
For system host the regular CPU, memory, disc template is sufficient. Finetune the thresholds to your comfort level.
Database template
Important items of the database template:
Database availability
Database health checks
Backup
In most installations it is chosen to install Content Server with the SAP MaxDB database (similar to LiveCache).
Some filesystems are critical to a business, such as those used in interfaces. This custom metric group will alert if a filesystem is not mounted.
Create the Bash Script to Check the Filesystem Status
Firstly, we need to create a bash script that takes the filesystem as its input argument and then checks its status. Create the following script called /sbin/checkfilesystemmounted.sh (owner is root, permissions 755). You may put this script somewhere else if you prefer, but be sure to refer to the correct location later on in this post.
The findmnt command returns the mount details if the filesystem is mounted. The filesystem is passed as a script argument in variable $1. If the filesystem is mounted, the script returns integer 1. If the filesystem is not mounted, the script returns integer 0. For example, to check your desired filesystem, execute it like this as root:
The result should be as per the following example:
Webmethod returned successfully
Operation ID: 0A02C69098121EDDA68C041B50FE858D
----- Response data ----
description=Check if filesystem is mounted
{type:integer, name:FileSystemMounted, value:1}
exitcode=0
Create the Custom Alert in SAP Focused Run
In Focused Run, we create an alert in a Linux host monitoring template. For example, the alert name is “Interface Filesystem not Mounted”. The Alert should be in Category “Exceptions” and the Severity is up to you. In this case it is 9.
Create the Custom Metric Group in SAP Focused Run
Next, we create the custom Metric Group . A Metric Group allows variants to be created, and each variant corresponds to a filesystem you wish to monitor.
Overview Tab:
Name: “Interface Filesystem not Mounted”
Category: Exceptions
Class: Metric Group
Data Type: Integer
Technical Name: INTERFACE_FILESYSTEM_NOT_MOUNTED
Data Collection Tab:
Data Collector Type: Diagnostic Agent (push)
Data Collector Name: OS: ExecuteOperation
Collection Interval: 5 Minutes (depending on the criticality)
CUSTOM_OPERATION_NAME: checkfileystemmounted – This corresponds to the custom operation for saphostctrl created earlier
METRIC_NAME: FileSystemMounted – This corresponds to the name of the metric in the JSON output by the bash script
RETURNFORMAT: JSON – This is the output format of the bash script
Usage Tab:
Threshold Tab:
As the script returns a numeric value 0 if the filesystem is not mounted, then the threshold will alert if the value is 0.
Assignment Tab
Assign to the custom alert created earlier.
Add Variants
The variable passed to the saphostctrl operation is “FILESYSTEM”. We can add the rest of the filesystems as individual variants. The format for the operation parameters is as follows:
FILESYSTEM:/the/filesystem/you/want/to/check
For example:
You can enter as many filesystems as you like as separate variants.
Activate Alert
Go to the “Metrics, Events, Alerts Hierarchy” tab, and activate System Monitoring.
Testing the Metric
In a non-Production environment, try to unmount a filesystem, and at most 5 minutes later, there should be an alert produced.
This blog will focus on monitoring on GTS systems.
Monitoring productive GTS systems
GTS systems are at the not frequent in use. When in use they do play a vital role in import and export business scenario’s when good are crossing borders.
Since a GTS system is normally installed, and often no to little maintenance and software changes are performed on the system. Also basis teams tend not to look at it too often, since it normally runs stable.
In case of non-availability of GTS, ECC scenario’s linked to GTS might fail and can causes severe business disruptions.
For this reason it is important to set up monitoring in FRUN for your GTS system and also configure mail alerts in case of issues. They will not happen too often, but when they happen you can act fast. This will also save the basis team spending a lot of time on checking GTS system for log (most cases, the checks are good).
When monitoring a productive system, you will need to finetune the monitoring templates for:
ABAP 7.10 and higher Application template, for the ABAP application
ABAP 7.10 and higher Technical instance template, for the ABAP application servers
System host template
Database template
ABAP application template
Make sure you cover in the ABAP application template the following items:
This blog will focus on monitoring on SCM systems. Also known as APO systems.
Monitoring productive SCM systems
SCM systems are at the often used logistics optimization systems. They are mainly used in combination with traditional ECC systems. They are less needed in combination with S4HANA systems (or you can use the embedded SCM of HANA).
The core of an SCM system is a BI system. Many data is using similar extractors and process chains as a BI system. Hence follow the tuning needed for a BI system.
Extra in an SCM system are the LiveCache and the CIF (Core interface).
LiveCache monitoring
LiveCache is normally running on a MaxDB database.
So it is important to activate, assign and finetune the metrics for the MaxDB database:
Focus on:
Availability
Backup
Performance
Next to the database, you also need to activate, assign and finetune the LiveCache specific application template:
This template contains the primary elements to monitor for the LiveCache functions like:
Availability of LiveCache as a function
Structure check for LiveCache
Memory issues for LiveCache specifically
Fine tune the metrics so you are alerted on situation where the system is having issues.
CIF monitoring
The CIF is the core interface between SCM and ECC system. The interface typically uses RFC and qRFC. And it is working both ways.
Setup for the CIF specific RFC’s and qRFC’s the monitoring:
For a BW system some numbers are typically higher than on an ECC or S4HANA system. Response times of 1.5 seconds would indicate horrible performance on ECC, but are normal on BW system.
System host template
For system host the regular CPU, memory, disc template is sufficient. Finetune the thresholds to your comfort level.
Database template
Important items of the database template:
Database availability
Database health checks
Backup
Functions monitoring
Next to the availability and performance mentioned above, check also for monitoring certain functions: