ST06 OS host monitoring

If you want to see how well your OS is doing in terms of CPU, memory, disc utilization, etc, then transaction ST06 OS host monitoring is your solution.

Questions that will be answered in this blog are:

  • How to use transaction ST06?
  • How to get information on CPU, memory and disc usage on OS level?
  • What is different in ST06 when my SAP system runs in the cloud?

ST06 transaction

Start transaction ST06:

Top left you can select the application server you want to inspect. On the right screen you see the details. Bottom left you can select different tools or specific sections and history.

For more background on all ST06 issues and functions, read OSS note 2067546 – ST06/OS07N: Overview note.

ST06 and systems running in cloud

If your SAP system runs on infrastructure in the cloud, your infrastructure provider may have a certain setup that may not allow all ST06 functions to work as with a system installed in your own data center.

OSS notes on this topic:

ABAP code to write to application log

The SLG1 application log is a powerful mechanism to support team in SAP systems.

This blog will explain how you can write to the application log in your own custom ABAP code using ABAP code below.

It is recommended to create one single SE24 ABAP class for the application log that can be re-used in all your custom code.

Instantiation method

First method to create is the instantiation method:

   DATA: zls_log        TYPE bal_s_log,
         zlt_log_handle TYPE bal_t_logh,
         zlt_message    TYPE bal_t_msg. 

      zls_log-object     = ziv_object.
      zls_log-subobject  = ziv_subobj.
      zls_log-extnumber  = ziv_extnumber.
      zls_log-aluser     = sy-uname.
      zls_log-alprog     = sy-repid.


 CALL FUNCTION 'BAL_LOG_CREATE'
      EXPORTING
        i_s_log                 = zis_log
      IMPORTING
        e_log_handle            = zgv_log_handle
      EXCEPTIONS
        log_header_inconsistent = 1
        OTHERS                  = 2.

As input you have to give SLG1 object name and sub object name. You can re-use existing or create new custom one in transaction SLG0.

Now you have a log handler.

Add the messages

Now you can add a method to add one or more messages, re-using the log handler:

zls_msg      TYPE bal_s_msg,

      CALL FUNCTION 'BAL_LOG_MSG_ADD'
        EXPORTING
          i_log_handle     = zgv_log_handle
          i_s_msg          = zls_msg
        EXCEPTIONS
          log_not_found    = 1
          msg_inconsistent = 2
          log_is_full      = 3
          OTHERS           = 4.

Save the log

Create a method for saving the application log, again re-using the log handle:

    CALL FUNCTION 'BAL_DB_SAVE'
      EXPORTING
        i_t_log_handle   = zlt_log_handle
      EXCEPTIONS
        log_not_found    = 1
        save_not_allowed = 2
        numbering_error  = 3
        OTHERS           = 4.

Set up once and re-use

Set up the application logging helper class once in SE24 and tell all your developers to re-use it. You might find out that you developer already used the function modules above a lot in their Z code. This can be found with the ABAP code scanner tool. Check case by case when it makes sense to swap to the central helper class.

SLG1 application log

SLG1 application log is a powerful function in supporting productive system. This blog will explain the backgrounds.

Questions that will be answered in this blog are:

  • What is the intended use of SLG1 application log?
  • Should SLG1 application log be used by the business or IT only?
  • How can I download or export the logs from SLG1?
  • How can I clean up or delete SLG1 logging?

Intended use of SLG1 application log

The SLG1 application log is primarily intended for use by IT staff to support the SAP system. The logging can be used to analyze issues that the user is reporting, without IT staff requiring direct access to the business data transactions (not even to display data). Most standard SAP applications will log errors in the application log.

The logging can be for:

  1. Technical errors
  2. Functional error (like missing customizing)
  3. (master) data errors

When you are having frequent (master) data errors that primarily show in SLG1 application logging, it can make sense to give access to SLG1 for your business key users. You should train them on the transaction, since it might be too technical for them.

Use of SLG1 application logging transaction

Start the application logging with transaction SLG1 and fill the required fields:

Best to start with Only important logs to reduce the volume.

Output can look like below:

On top open the alert and click on it. At the bottom part of the screen the details will be displayed.

SLG1 objects

The object and subobjects for data filtering in SLG1 are defined in transaction SLG0:

Export of SLG1 logging

To export SLG1 logging, start transaction SLGD:

The output of SLGD can be done on ALV screen, from which you can download the data.

More background in OSS note 2546052 – Transaction SLG1 – Cannot download or export error logs.

Deleting SLG1 application log

You can use transaction SLG2 to delete the application log. For more details see blog on technical clean up.

Logging levels

Next to deletion there is another option to reduce the amount of application log entries: setting the logging level. In many customizing settings for diverse applications, the log level can be set. This can range from: error only to everything. The everything setting is typical for a development system. The error only is typical for a productive system. Upon issues, you can still set the productive system temporarily to everything. Unfortunately: this feature is per function and has to be setup in customizing in the specific application, and not all functions support the log level settings function.

ABAP code to write to application log

If you want to write entries to the application log in your custom ABAP code, read this blog.