Skip to Content
Technical Articles

Monitoring of ABAP System on AWS Using CloudWatch – Part III

This is in continuation of my previous blog post Monitoring of ABAP System on AWS Using CloudWatch – Part II

6. POST-CONFIGRUATION

As a part of post configuration, we must do the below steps for regular execution

6.1 Enable Scheduler

We must enable the scheduler so that AWS Lambda function can be triggered after regular interval of time to fetch the required data for CloudWatch

To do the same, go to Amazon EventBridge → Event and click on Rules. We can find sap-monitor’s Rule already configured.

Select the Rule and then click on Enable, confirm the action to Enable the Rule

Once the Rule is enabled, then as per the schedule Lambda Function will fetch the data from SAP.

7. DASHBOARD

For monitoring multiple metrics at the same time, we can create and configure the our own dashboard using AWS CloudWatch.

7.1 Creation of Dashboard

To-do the same, go to AWS CloudWatch from AWS Console and then click on Create Dashboard

Then we need to specify the name of the Dashboard which will be created and click Create Dashboard

Dashboard has been created for Monitoring of the system.

7.2 Adding Widgets

Once the dashboard has been created then we need to add different Widgets as per the requirement. To do the same, we need to go to the newly created Dashboard and click on Add Widget

Then we need to specify the data source that will be used to create widgets which is Metrics

Then we need to select the Metric Name that needs to be displayed on the CloudWatch Dashboard and click on Create Widget

We can now see the Graphed Metrics on the Dashboard

Similarly, we can select more widgets to pin the graphical metrics on the CloudWatch Dashboard as below

We must save the dashboard so that widgets can be saved and can be utilized for quicker view.

8. NOTIFICATION

We can also specify the settings by which a notification can be sent as per the requirement.

8.1 Setting Up Alarms

We can setup alarms for sending any type of notification as per the requirement, to do so we need to go to CloudWatch → Alarms and click on Create alarm

Then we need to Specify the metric and conditions to trigger the notification, for that we need to click on Select Metric

Specify the Metric for which we need to generate the Alarm and then click on Select metric

Then we need to specify the time period and statistics for which alarm needs to be set. Here we need time period of 5 mins

Then we need to specify the condition on which alarm needs to be raised by the CloudWatch. Here we have defined the threshold value to 60 and click Next

Then we need to specify the configuration actions when Alarm get a catch. Here we have specified the Amazon SNS topic

We can also specify the Auto scaling group, EC2 action any systems manager Ops Center action, if required and then click on Next

Then we need to specify the name and description of the Alarm and click Next

Then we need to review the specified parameter and create the alarm

Below screen will appear after successful creation of Alarm, but state will be Insufficient Data till the first recording of data

After the first recording of the statistics from the CloudWatch, the status should change to OK

We can also see the Data collection in graphical manner for Alarm

When there is any breach in the threshold specified in the alarm settings then it gets recorded in AWS EventBridge

And information of this breach has been sent via email to the stakeholders as per the SNS configuration

9. CONSIDERATIONS

For using this solution in live customer environment, we have below points which needs to be considered

9.1 Performance

From performance point of view, this solution uses two ways to connect to SAP System Regularity and collect insights: –

  • One Minute interval for /SDF/MON data with a 30 second granularity which is scheduled daily on demand. According to SAP, CPU and memory overhead on the SAP system caused by /SDF/SMON is negligible and can safely be run in production. Link can be referred for further details
  • Five Minute interval for ST03 “Last Minute Load”. SAP statistical records (STAD) and related aggregation (ST03) are usually enabled by default, if it’s not enabled then need to check SAP note 2369736. They are the foundation of any SAP monitoring, especially for SAP GoingLive Check, SAP EarlyWatch Alert and SAP Solution Manager.

9.2 Cost

There no addition cost for using this service, but one need to pay for the underlining AWS services which is getting used, such as AWS Lambda, CloudWatch, AWS SNS etc. For a single SAP system with two application servers, the estimated cost is 16 USD per month per SID without considering any free tiers. These are estimated cost which is depend on various factors, please check link for calculation details

To limit the stored log data and reduce the cost in the long run, make sure to also reduce the retention period for /aws/lambda/sap-monitor-<SID> to one week. For more details on this please refer link.

9.3 Capture Metric

A full list of currently captured metrics and their importance can be found below:

Generic (1 - per SID):
"PING" = SAP Monitor RFC Execution Time (/SDF/SMON) "TOTAL_APP_SERVERS" = Number of active SAP Application Servers

/SDF/SMON (14 - per Instance), granularity 1 min:
"ACT_WPS" = Number of Active Work Processes
"ACT_DIA" = Number of Active Dialog Work Processes
"TRFC_FREE" = Number of Available Work Processes for RFCs
"SESSIONS" = Number of Sessions
"USERS" = Number of Logins
"UPDQ" = Update Queue Length
"ENQQ" = Enqueue Queue Length
"DIAQ" = Dialog Queue Length
"PRIVWPNO" = Number of Work Processes in Priv Modes
"DIAAVG20" = Average Load last 20s
"DIAAVG60" = Average Load last 60s
"FREE_MEM_PERC" = Free Memory in % of RAM
"USR_TOTAL" = CPU Utilization (User) in %
"SYS_TOTAL" = CPU Utilization (System) in %

SWNC_GET_WORKLOAD_SNAPSHOT = st03 Last Minute Load (12 - per SID), granularity 5 min

Currently enabled for Tasktypes DIA & RFC:

"ST03_AVG_SNAP" = Average Response Time per Step in ms (ideally < 1s)
"ST03CPU_TIME_PERC_SNAP" = Average CPU Time in % as part of average response time (ideally ca. 40%)
"ST03DB_TIME_PERC_SNAP" = Average DB Time in % as part of average response time (ideally ca. 40%)
"ST03AVG_DB_DIR_SNAP" = Average Database Request Time per Direct reads in ms (ideally max. 10ms)
"ST03AVG_DB_SEQ_AVG_SNAP" = Average Database Request Time per Sequential reads in ms (ideally max. 10ms)
"ST03_AVG_DB_CHG_AVG_SNAP" = Average Database Request Time per Changes in ms (ideally max. 10ms)

If we also like to monitor other OS-related metrics such as free hard disk space, then we can also deploy the CloudWatch Agent on top.

10. LOGS

10.1 CloudFormation

As the deployment triggers Cloud Formation stack internally, hence we can navigate to CloudFormation → Stacks → Events which can provide details of the steps which were carried out during the execution

10.2 CloudWatch

We also have detailed logs which we can see from AWS Cloudwatch, for which need to navigate to proper log groups from CloudWatch

 

Now SAP System installed on AWS EC2 is getting monitored using AWS Services.

BEST OF LUCK!!

11. CONCLUSION:

In this 3 parts of article, we have discussed how we can  Deploy, Test, Post Configuration, Dashboard of Monitoring ABAP Systems via AWS.

 

THANK YOU..

Be the first to leave a comment
You must be Logged on to comment or reply to a post.