This is in continuation of my previous blog post Monitoring of ABAP System on AWS Using CloudWatch – Part II
As a part of post configuration, we must do the below steps for regular execution
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.
For monitoring multiple metrics at the same time, we can create and configure the our own dashboard using AWS CloudWatch.
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.
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.
We can also specify the settings by which a notification can be sent as per the requirement.
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 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
For using this solution in live customer environment, we have below points which needs to be considered
From performance point of view, this solution uses two ways to connect to SAP System Regularity and collect insights: -
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.
A full list of currently captured metrics and their importance can be found below:
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.
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
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!!
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..
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 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..
- SAP Managed Tags:
