Simple Diagnostic Agent Log Configuration – Enabling Debugging for Troubleshooting…

In case of data collection issues you will need to troubleshoot Simple Diagnostic agent logs .

In some cases you might need to get further details after you see an error message in the standard SDA logs in Agent Internals. In such cases you will need to enable application specific logging. E.g. activate debug logging in order to analyze issues with a specific application or component of the SDA

For E.g.: You saw an error in agent internals like

2019-08-15 15:48:01,696 ERROR [MAI FRD 5] division by zero

In this case, you will want to put to debug this class:

Following Application components of SDA for which logging can be enabled.

Application / ComponentName (Column in Log Configuration Dialog)

To enable logging you can follow the following steps.

Step 1 : Open Agent Administration in Focused Run Launchpad.

Step 2: Select the agent/host for which you want to enable logs in Debug, on the option Agent Action select “Open Log Configuration” and click on Go.

In the next dialog screen enter the application classes for which you want to enable debug as shown below. After entering the classes click on Save.

In the next execution, the Agent logs will present more details.

You can collect the log files by selecting the Option Download Log File and then click on Go. It will download all SDA logs in a zip file to your desktop/laptop.

Note: Do not forget to remove the log configurations after downloading the logfiles.

Reference SAP Note 2696231 – How to set the Simple Diagnostic Agent to debug.

Monitoring SAP Cloud Connector…

This blog will focus on monitoring of Cloud Connector systems.

Monitoring productive cloud connector systems

The Cloud connector is used between on premise systems and Cloud solutions provided by SAP.

Monitoring of cloud connector focuses on availability and connectivity.

The cloud connector template contains all the needed elements out of the box:

If your landscape has only 1 cloud connector that is also used for non-productive systems, you might find a lot of issues in the non-productive system. Like expired certificates, channels not working, many logfile entries. If the cloud connector is very important for your business, it is best to split off the productive cloud connector from the non-productive usage.

This way you can apply sharp rule settings for production: even single issue will lead to alert. While on non-production the developers will be making a lot of issues as part of their developer process.

Monitoring non-productive cloud connector systems

In your landscape you might have a non-productive cloud connector that is used for testing purposes. In the non-productive cloud connectors you might apply a different template with less sensitive settings on certificates, logfiles and amount of tunnels that are failing.

Relevant OSS notes