In system monitoring you can monitor if ABAP system certificates are expiring or are already expired. SAP provides a standard metric for this based on configuration validation rule SAP ABAP PSE CERTIFICATES CHECK. This rule is taking all certificates that are to be expired in the next 7 days and all expired certificates.
This rule has two setbacks:
7 days upfront warning might be too short
It reports all expired certificates that are already years expired and don’t harm the system
New rule for ABAP PSE certificate monitoring
For the improved setup we will defined 2 new rules:
To be expired certificates, with date selection -30 till tomorrow
Expired certificates, with date selection today till next 30 days.
Start with creating the policy in configuration validation (more on configuration validation in this blog):
Add a new policy Z_ABAP_PSE_TO_BE_EXP for the to be expired, and give it this syntax:
Add a new policy Z_ABAP_PSE_EXP for the expired ones:
Both are basically a copy of the standard SAP one with the changed dates.
Please note you need to change both the dates in the Compliant and Non-Compliant section.
Create custom metric
Now you can create a custom metric using the newly created rule. For full description on how to create custom metrics, read this blog. Create the custom metric in the ABAP system template:
Refer to the newly create custom CoVa (configuration validation) rule:
And set the threshold:
For the to be expired certificates, we only want warning.
We repeat the same for the expired certificates, but now we make it a red alert by setting the thresholds differently.
Make sure both are now activated for monitoring:
Trouble shooting
There might be false alerts raised for this metric. This is for both the custom and standard SAP metric. The source is usually the data collection.
Go to the configuration and configuration validation FIORI tile and select the system and search for the PSE certificates data collection details:
Monitoring Host Agent PSE Certificate Expiry
You have configured SSL for enabling secure connections to SAP Host Agent. In such a case you need to regularly update or extend the validity of the SAP Host Agent PSE certificate. With Focused run System Monitoring you can create custom metric for monitoring SAP Host Agent PSE certificate expiry.
Setup Monitoring Host Agent PSE Certificate Expiry
Step1: Navigate to Host Template maintenance
SAP Host Agent resides at OS level of each host of systems that you are monitoring using Focused Run. Hence you need to monitor the PSE certificate for SAP Host Agents of each host in your customer network.
In our recent blog we have explained how you can configure URL Certificate monitoring in Health Monitoring in SAP Focused Run. However configuring certificate monitoring for each SAP Host Agent in your customer network using Health Monitoring will be very cumbersome.
An easier way will be to setup a custom metric in the host level system monitoring template which when activated will be automatically applied to all hosts for which the monitoring template is used.
For template maintenance you can navigate to System Monitoring Template Maintenance app on the Focused Run launch pad.
In the template maintenance app navigate down to the Host (Server) node and then to the respective template which you want to edit and click on Edit button.
Step2: Create Custom Metric
In order to create a custom metric you need to activate expert mode. For this click on the Expert Mode button as shown below.
After enabling expert mode you can click on Create button. Select Metric in the drop down from Create button.
In the Metric creation pane, under Overview tab enter the details as shown below.
Then in the Data Collection tab, provide the details as shown below.
For the URL field you need to mention the URL https://$SAP_ComputerSystem.FQDName$:1129/SAPHostControl/?wsdl in which the expression $SAP_ComputerSystem.FQDName$ will dynamically resolve the respective FQDN of the host picked up from LMDB. Hence it is important to select the check box under Placeholder and select LMDB under Placeholder type.
Then navigate to the Threshold tab and provide the threshold as shown below. In this example the threshold is Yellow if certificate is expiring in 30 days and Red if its expiring in 15 days.
Then click on Next button to navigate to the Assignment tab where we assign this metric to an existing alert. In this step just click on the Finish button to save the metric. In this step we don’t assign to any alerts yet as we are yet to create a custom alert for this custom metric.
Step3: Create custom Alert and assign to custom Metric
In the expert mode maintenance go to the Create button and then from the drop down select Alert.
Enter the details as shown below and click on Next button.
Then in the Assignments tab you will see the custom metric you just created. Select the check box for this metric and click on Finish to save the alert.
Now your custom metric is ready together with alerting active.
To activate this template update on all hosts navigate to Managed Objects tab for the template and click on Apply and Activate button.
Upon activation the new metric will be available in system monitoring as shown below.
For more details on how to setup SSL for SAP Host Agent you can refer to the SAP documentation here.
SNC certificate expiry monitoring
SNC Certificate expiry is very critical for ABAP systems where SNC logon is used. As soon as the certificate expires users will no more be able to login to system.
In System Monitoring for ABAP systems SAP provides a standard metric called Expiring PSE Certificates which monitors all PSE certificates that includes SNC certificates. When this metric turns red it will tell how many certificates are expiring/expired but not which one. Hence its beneficial to monitor separately the status of SNC Certificates.
You can create a custom policy with the below XML code that checks the PSE_CERT store to check on status of SNC Certificate.
<?xml version="1.0" encoding="utf-8"?> <targetsystem desc="SNC Certificate about to expire" id="ASML_SNCERT_TOBE_EXP" multisql="Yes" version="0000"> <configstore name="PSE_CERT" system_type="ABAP"> <checkitem desc="Valid in range" id="1" operator=""> <compliant>APPLICATION like '%SNCS%' and CONTEXT like '%' and TYPE like '%' and SUBJECT like '%sapci%' and ISSUER like '%' and SERIALNO like '%' and VALID_FROM like '%' and ( ( ( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) > to_number(replace(add_days(current_date, 30), '-', '')||replace(current_time, ':', '') )) or (( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) < to_number(replace(add_days(current_date, 0), '-', '')||replace(current_time, ':', '') )) )</compliant> <noncompliant>APPLICATION like '%SNCS%' and CONTEXT like '%' and TYPE like '%' and SUBJECT like '%sapci%' and ISSUER like '%' and SERIALNO like '%' and VALID_FROM like '%' and not ( ( ( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) > to_number(replace(add_days(current_date, 30), '-', '')||replace(current_time, ':', '') )) or (( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) < to_number(replace(add_days(current_date, 0), '-', '')||replace(current_time, ':', '') )) )</noncompliant> </checkitem> </configstore> </targetsystem>
Note: In the above XML code, SUBJECT like ‘%sapci%’, you have to replace sapci with a hostname pattern that you use for all your SAP ABAP system hostnames.
Once you have created the policy, you can directly activate alerting on the policy.
For that go to the Configuration and Security Analytics app in the Advanced Configuration Monitoring area.
In the app navigate to Configuration Validation Alert Management under the the Related links tab.
In the Alert Management app click on Create button to create the alerting for the policy you just created.
In the next popup, enter details as shown below and then click on Select policy to select the policy for which you want to activate the alert.
In the next popup select the policy by clicking on the policy name.
Now click on Save to activate the alerting.
Additionally you can also activate email notification on the alert. For this in the Alert Management main screen, select the alert and then click on Notification/Outbound.
In the next popup select the notification variant and save.
Cloud Connector BTP certificate expiry
With SAP Focused Run 3.0 FP 2 SAP has delivered a configuration validation policy using which you can monitor Cloud Connector BTP Certificate expiry.
Note:For using this functionality you just have to ensure that you have registered your cloud connector managed system to your Focused Run System and have performed SSI for the cloud connector managed system.
You can do the monitoring via the Configuration & Security Analytics app in the Advanced Configuration Monitoring area of Focused Run Launchpad.
In the app click on the select button to select the policy to monitor Cloud Connector BTP Certificates.
In the pop-up you can search for SCC and then select the policy SAP_SCC_PSE_CERT. This is the standard policy delivered by SAP that performs configuration validation on Cloud Connector BTP Certificate expiry.
This policy monitors if a BTP certificate in cloud connector system is going to expire in less than 30 days or is already expired.
The first view upon selecting the policy is the Systems view. In this view all SAP Cloud Connector systems registered in Focused Run system are listed. A systems is marked as non compliant if it has any certificate which is going to expire in less than 30 days or has any expired certificates. This view also tells how many certificates are there in the system and how many are non compliant.
You can click on the row to see the details of the certificates which are expiring or expired.
To know more about Configuration and Security Analytics you can refer here.
Also you can find more detail at SAP documentation here.
<< This blog was originally posted on SAP Focused Run Guru by Manas Tripathy (Simac) and Frank Umans. Repost done with permission. >>
For activating SAP Focused RUN monitoring functionalities on an SAP ABAP system you need to perform Simple System Integration of SAP ABAP Systems
Simple System Integration, or shortly known as SSI, is a guided procedure similar to the managed system setup in SAP Solution Manager. SSI is used for integrating a managed system to SAP Focused Run system. Unlike SAP Solution Manager managed system setup, SSI is fully automatic and has no manual steps.
In order to ensure SSI is completed successfully we need to ensure all -prerequisites are met.
The term SSI is bit misleading. It is not so simple as it seems. Once you have the procedure known for your landscape it does become simple. The first one is NOT simple.
Focused Run Prerequisites
Before you can perform SSI for any managed system, you need to ensure the basic framework setup prerequisites are met. For this ensure all activities mentioned in section 5.2.4 Preparing Simple System Integration of the SAP Focused Run master guide.
Managed System Prerequisites
1.) Simple Diagnostics Agent deployed on all hosts of ABAP Managed system.
See below for description on how to do this. You can also refer the SAP documentation here.
2.) ABAP Managed system is registered in LMDB and Data Supplier Completeness check is green.
In our future blogs we will explain how to register various types of managed systems into LMDB. And for troubleshooting in case Data Supplier Completeness check is not green, you can follow SAP’s documentation here.
3.) Database preparation is complete.
You need to perform certain database specific pre-requisite configurations in order to perform the integration of the underlying database of the managed system. In this SAP documentation SAP has outlined the steps for various types of databases.
4.a) For ABAP a system user is created in the managed system production/main client. This user will be required for RFC connection to the managed system. We refer to this user as FRUN user. You can refer to this SAP documentation to get the list of roles that needs to be assigned to this FRUN user for an ABAP based system.
4.b) For JAVA a system user is created in the managed system production/main client. This user will be required to authenticate local HTTP and P4 calls by the simple Diagnostics Agent for data collection. We refer to this user as FRUN user. You can refer to this SAP documentation to get the list of JAVA roles that needs to be assigned to this FRUN user.
Deploying Simple Diagnostic Agents on Managed Systems
Deploying Simple Diagnostic Agents (SDA) on Managed System hosts is a prerequisite to performing Simple System Integration (SSI) of Managed systems on focused run system.
The SDA is installed/deployed as an add-on to the SAP host agent. Hence it’s mandatory to install SAP Host Agent on each host of the managed system which needs to be monitored by SAP Focused Run System.
The deployment of the SDA on the managed system system host is carried out from the SAP Focused Run system itself.
Below steps need to be performed for deploying SDAs on managed system hosts.
Download binaries from marketplace
Download the latest version of the binaries SDA and SAP JRE (Java Runtime Environment) from SAP Support Portal as follows:
Select tab Support Packages & Patches –> By Category –> SAP Technology Components –> Focused Run –> Focused Run 3.0 –> Downloads –> Comprised Software Component Versions
Download from SAP JRE 8.1 and SIMPLE DIAGNOSTICS AGENT 1.0
Following platforms are supported:
IBM AIX
HP-UX on IA64
Linux on Power BE & LE
Linux x86_64
Oracle Solaris SPARC
Oracle Solaris x86
Microsoft Windows Server on x86_64
You can find all information regarding latest available version of SDA and its compatible JRE version in SAP Note 2369401 – Release Note for Simple Diagnostics Agent 1.0.
Upload Binaries onto SAP Focused Run system
Upload the binaries to SAP Focused Run, by running the report SRSM_AMA_UPLOAD_BINARY, with transaction SA38.
Upon completion of the upload you will see the below output.
Deploy SDA on Managed system host
Register Managed system host on Focused Run system: Before you can deploy SDA on managed system host, the host has to be registered to the Focused Run System. For this execute the following script at OS level as sapadm user from folder /user/sap/hostctrl/exe
./saphostctrl -function ConfigureOutsideDiscovery -enable -sldusername FRN_LDDS_FRS -sldpassword xxxxxxxxxx -sldhost <hostname of FRUN system> -sldport <http/https port of FRUN system>
Upon executing the above commands at host level, you can see the host listed in Agent Administration of Focused Run system. Navigate to the Agent Administration app in the Infrastructure Administration block of the Focused Run launchpad.
In the Agent Administration App, select the host for which you want to deploy the SDA, select Install/Update Agent and click on Go.
Upon completion of the deployment, you will see the agent version listed in the Diagnostic Agent Version column.
After SDA installation/update is successful you also need to configure the agent. This will enable the agent to receive monitoring definitions from the focused run systems as well as enable Self Monitoring of the agent.
Upon completion of configuration, you will see green icon under availability column. Also Configuration status updated to Confirmed.
You need to follow the same steps for installing and configuring agents on all application server hosts as well as database hosts of the managed system.
Note: You should perform the Simple System Integration of a managed system only after you install and configure agents on all its hosts. You can also list hosts and their agent status of a particular managed system in the By Technical System tab of the Agent Administration app.
Performing SSI of ABAP managed system
For executing SSI navigate to the SSI app in the Infrastructure Administration section of the Focused Run launchpad.
In the SSI app scope selection area you can enter the managed system extended SID individually or you can select a more generic filter to list multiple systems.
SSI is performed in 2 steps for ABAP systems.
Step 1: Edit Configuration
For ABAP systems in this step you need to enter the details of the FRUN user that you created as a prerequisite.
For this select the row for the ABAP system and click on the Edit Configuration button as shown in below screenshot. Next in the pop-up enter the credentials of the FRUN user.
Step 2: Configure Automatically
In this step, select the ABAP managed system for which you want to perform the SSI and click on the button Configure Automatically.
Note: When you perform SSI for the main technical system, it will automatically perform the SSI for all the underlying components in the system hierarchy. That is, if you perform SSI for Application Server ABAP, it will also perform the SSI for the system's database. However the if you perform first the SSI of the system's database it will not automatically perform the SSI of the main technical system and you will again have to perform the SSI for the technical system again separately.
Additional Pre-requisite for JAVA Managed Systems.
Other than the above mentioned pre-requisites, for JAVA systems, you also need to Install BCI Adapter ( CA Introscope Wily Adapter) to collect performance metrics and trace data of the NW Java.
You can also refer to section SAP NetWeaver Application Server Java in this SAP Focused Run expert portal blog for managed system preparation.
Installing CA Wily Introscope BCI Adapter for SAP Java Systems
SAP Focused Run system collects performance metrics and trace data of the SAP Netweaver Java systems through the CA Wily Introscope Byte Code Injection (BCI) Adapter.
Before you perform SSI for a SAP JAVA system you need to install and configure the BCI Adapter on each instance of the Java stack
Upon installing the BCI Adapter, SAP JAVA system reports performance and trace data to the CA Wily Enterprise Manager (Wily EM) and later on SAP Focused Run monitoring will collect the data from Wily EM for the relevant monitoring metrics.
Unlike SAP Solution Manager, for SAP Focused Run BCI Adapter setup for managed system is a completely manual step. This blog is therefore intended for the technical or SAP Basis consultants who are responsible for installation and setup of SAP Focused Run system.
The following steps are required to install and configure the Introscope Agent
Extract the Introscope Agent files
Configure the Introscope Agent
Introscope-enable the application code by setting Java VM parameters
Pre-Requisite for BCI adapter
The BCI Adapter needs to connect to a Wily Enterprise Manager. You must ensure the Wily Enterprise Manager is already connected and configured for your SAP Focused Run system. In our blog we have explained how to configure Wily EM to connect to a Focused Run system.
Extract the agent installer file ISAGNTJ5STD*.zip into the Netweaver CCMS directory, usually: :\usr\sap\ccms.
Upon extracting you will find wily directory in the :\usr\sap\ccms directory
Configuring Introscope Agent Settings
For a SAP JAVA System the agent configuration settings are found by default in the file :\usr\sap\ccms\wily\core\config\IntroscopeAgent.profile.
To configure the Introscope Agent you need to locate the following parameter and set the values.
1. introscope.agent.enterprisemanager.transport.tcp.host.DEFAULT = <IP address or hostname of the Enterprise Manager
2. introscope.agent.enterprisemanager.transport.tcp.port.DEFAULT = <port on which the Enterprise Manager listens for Agent connection. Default is 6001>
3. introscope.autoprobe.directivesFile = < DEFAULT is sap_typical.jar,sap_ep.jar,sap_ep_iviews.jar,sap_xi_typical.jar > . You may need to add further duirective jar files by adding entries to the property, separated by comma.
Below table shows the various directive file names for various java application types.
sap_typical.jar
Main instrumentation set for SAP Netweaver. Includes support for generic Netweaver functionality, like database, JCO, Web Services. This jar is always mandatory.
sap_sapvm.jar
For SAP Netweaver 7.10 and higher with JDK5 or higher. Specific instrumentation, e.g. memory allocation. Do not activate for Java 1.4!
sap_bo_enterprise.jar
SAP Business Objects Enterprise 3.x instrumentation
sap_boe_webapp.jar
SAP Business Objects Enterprise 4.x instrumentation
sap_ep.jar
SAP Portal specific instrumentation
sap_ep_iviews.jar
AP Portal instrumentation: One node per iView – should be preferred for installations with many roles or when collaboration rooms are used. Requires sap_ep.jar
sap_ep_iviews_rolename.jar
Re-activate metrics for each iView/rolename combination. Activate only one of these 2: sap_ep_iviews.jar or sap_ep_iviews_rolename.jar!
sap_duet.jar
SAP Duet specific instrumentation
sap_hybris.jar
Instrumentation for Hybris.
sap_smp.jar
Instrumentation for SAP Mobile Platform.
sap_omnichannelbanking.jar
SMP instrumentation extension for Omni Channel Banking
sap_xi_typical.jar
Default and mandatory instrumentation file for PI
sap_xi_adapters.jar
Extended instrumentation for PI adapters.
sap_xi_passport.jar
Extended PI instrumentation to detect passport propagation.
sap_xi_full.jar
Extended instrumentation for PI. Some of these metrics might have a performance impact
sap_smd.jar
Solution Manager self-monitoring
sap_mdm.jar
SAP Master Data Management
sap_compliance.jar
SAP Compliance (SAP GRC, SAP EC, SAP REACH, …)
sap_epm.jar
SAP EPM (SAP SSM, …) instrumentation
sap_retail.jar
SAP Retail (SAP POS, SAP Triversity…)
sap_hilo.jar
SAP Visual Intelligence instrumentation
sap_srm_crm.jar
SAP SRM & SAP CRM (SAP Convergent Charging, SAG Frictionless e-Commerce, …)
sap_manufacturing.jar
SAP Manufacturing (SAP SAP Manufacturing Execution, SAP xMII, …)
Sap_hadoop.jar
SAP Hadoop instrumentation
sap_partner.jar
Instrumentation for SAP partner products. See SAP Note 1852015.
sap_tomcat_typical.jar
Default and mandatory instrumentation file for Apache Tomcat
sap_tomcat_full.jar
Extended instrumentation for Apache Tomcat
sap_websphere_typical.jar
Default and mandatory instrumentation file for IBM WebSphere Application Servers
sap_websphere_full.jar
Extended instrumentation for IBM WebSphere Application Servers
sap_weblogic_typical.jar
Default and mandatory instrumentation file for Oracle WebLogic Server
sap_cem_integration.jar
Instrumentation for integration with CA product CEM (only for SED)
Activating the Agent: Set Java VM Parameters
You have to add Java VM options to enable the agent. Typically, you will only want to activate the agent on the SAP J2EE server nodes, not on dispatchers.
You need to set the following parameters for the Java VM.
Run the SAP J2EE Configtool.
Navigate to Instance/VM Parameters/System and enter the following new parameters
3. Navigate to Instance/VM Parameters/Additional and enter the following new java parameter
-javaagent:/usr/sap/ccms/wily/Agent.jar
4. Save and Repeat steps 1 to 3 for all instances of the SAP JAVA system.
5. Restart the SAP instances.
To verify that Config tool changes were made, open the file: :\usr\sap\\\j2ee\cluster\instance.properties and check for a line beginning with ID.JavaParameters, and see if it contains the lines you entered in the step above.
Configuring Wily Enterprise Manager for monitoring in SAP Focused Run
Configuring Wily Enterprise Manager for monitoring in SAP Focused Run
The BCI adapters send the monitoring data to the central Wily EM . The Wily EM then sends the monitoring data to Focused Run System
Configuring Wily Enterprise Manager (Wily EM) for monitoring in SAP Focused Run is required if you monitor following types of systems where many monitoring metrics data is collected by BCI adapters.
SAP Netweaver AS Java
SAP BusinessObjects Business Intelligence
BOE Web Application Server
SAP Data Services
Apache Tomcat
SAP Archiving and Document Access (ADA) by OpenText for Tomcat
SAP Invoice Management (IM) for OCR Option by OpenText
SAP Convergent Charging
SAP Mobile Platform
SAP Hybris Commerce Suite
Unlike SAP Solution Manager, no Wily EM is required for monitoring in Focused Run if none of the managed systems use BCI adapters for their monitoring.
For connecting to a SAP Focused Run System the Wily EM installation should be of version 10.5 or higher and the EM Management Module (MM) Packages shall have minimum version MM 10.5 SP02 Patch 0 or higher.
Note: You can have only one Wily EM per customer network, however, if you install an Enterprise Manager Cluster, you can install any number of Enterprise Manager Collector Instances in the same Customer Network.
You can follow SAP Note 797147 for instructions on how to install Wily EM.
Prerequisite for Wily EM
The only prerequisite for connecting a Wily EM to a Focused Run system is that you should have installed host agent on the host of the Wily EM and have configured outside discovery of the host agent to connect to the Focused Run system.
To configure outside discovery of the host agent execute the following command:
Execute the below script from /usr/sap/hostctrl/exe:
./saphostctrl -function ConfigureOutsideDiscovery -enable -sldusername <FRUN LDDS or SLDR user> -sldpassword xxxxxxxxxx -sldhost <FRUN host or SLDR host> -sldport <FRUN or SLDR port>
Configuring the Wily EM
To connect the Wily EM to the Focused Run system perform the following steps.
For executing SSI navigate to the SSI app in the Infrastructure Administration section of the Focused Run launchpad.
In the SSI app scope selection area you can enter the managed system extended SID individually or you can select a more generic filter to list multiple systems.
SSI is performed in 2 steps for JAVA managed systems.
Step 1: Edit Configuration
In this step you provide the credentials for the SDA agent to connect to JAVA Managed System.
The FRUN User and password you created as a pre-requisite
The HTTP and P4 ports for connecting to the Java managed system.
Step 2: Configure Automatically
In this step, select the JAVA managed system for which you want to perform the SSI and click on the button Configure Automatically.
Note: When you perform SSI for the main technical system, it will automatically perform the SSI for all the underlying components in the system hierarchy. That is, if you perform SSI for Application Server JAVA, it will also perform the SSI for the system's database. However the if you perform first the SSI of the system's database it will not automatically perform the SSI of the main technical system and you will again have to perform the SSI for the technical system again separately.
Mass SSI and Mass Agent Update
Focused Run also provides even higher level of automation by allowing to perform SSI at a time for multiple systems.
Once the SSI automatic activities finish, you can check the logs of the SSI automation steps in the Log Messages area.
SAP Focused Run also provides a mass agent update app in the Focused Run launchpad using which you can update SDAs in all connected hosts of a particular data center on a single go. This is specifically useful for updating the SDA’s for all hosts after SAP releases a new version of SDA.
You can access the Agent Mass Update app in the Infrastructure Administration section of Focused Run Launchpad.
However before you use this app , you have to ensure that you have already uploaded the binaries as we have explained above.
For updating the agent just open the app and select the Data Center for which you want to update the agents and click on Update agents to start the update.
After you start the update, you can monitor the progress with the progress bar where it also lists how many agent installations were successful and how many have failed.
Note: SAP normally releases a new version of SDA every 2 to 3 months. You can download the latest version of SDA from here.
Connecting Managed Systems to Multiple Focused Run Systems
You may need to connect the same managed system to more than one Focused Run System. For instance, connecting a sandbox managed system to a development Focused Run system for test purpose and to a production Focused Run system where it is actually monitored.
For connecting the same system to one more Focused Run system you basically need to perform the same steps again but this time targeting to the new Focused Run systems.
Perform host outside discovery to register the host on focused run system. Execute the following commands using the credentials of the new focused run system to which you want to connect the managed system.
On the new Focused Run system agent administration configure the agent on the host you registered in previous step..
Install/Update Agent
2. Configure Agent
Note: The agent installation will not deploy a new SDI binary to the hostagent in this case as there is already a SDI in the host agent coming from the previous Focused Run system. However the installation step will simply link the new Focused Run system to the existing SDI by pushing its new configuration XML file to the SDI. This you can check by logging on to agent internals.
Configure SLDR to send data to both Focused Run Systems. This the most important step that you do differently than connecting the managed system to the first Focused run system. This will ensure data suppliers from managed system get forwarded to both Focused Run systems. Two know more about SLDR setup you can follow the SAP documentation here.
Now update the data supplier settings of the managed system to send data to this SLDR .( For example RZ70 in SAP ABAP system and NWA in SAP JAVA system).
Now the managed system will be listed in the Simple System Integration app of the new Focused Run system. Configure the SSI of the managed system to enable the managed system in the new Focused Run systems monitoring.
Decommissioning Managed Systems
We need to perform decommissioning of a managed system if
1. The managed system itself has been decommissioned or
2. The managed system is not required to be monitored in the Focused Run system anymore.
Case 1: Managed System is Decommissioned
Step 1: The first step of decommissioning would be to disconnect the Simple Diagnostic Agent from the Focused Run system. For this you can directly uninstall the Host Agent.
You can uninstall by running the following command at OS level
UNIX, IBM i: ./saphostexec -uninstall
Windows: saphostexec.exe -uninstall
Step 2: Deactivate all monitoring for managed system in Focused Run system
For this in transaction SA38 execute report RSRSM_SSI_CLEANUP
Select a Customer Network
Go to the Cleanup Technical System tab
Select a Technical System
Select the option to Cleanup unused hosts
Press Delete Selected Objects
Case 2: Managed System is not required to be monitored in the Focused Run System
Step 1: You have to ensure the managed system is no more sending landscape data to the Focused Run system. For this disable all SLD data suppliers for the technical system. (In case of ABAP systems its in transaction RZ70 and in case of Java systems its the Data Supplier settings in the NWA.)
Step 2: Disable outside discovery for all hosts of the technical system by executing the following command.
UNIX, IBM i: ./saphostctrl -function ConfigureOutsideDiscovery -disable
Step 3: Execute the decommissioning report RSRSM_SSI_CLEANUP as mentioned in step 2 of case 1.
For further details you can refer to SAP documentation here.
In addition to the above two cases, you might need to decommission system if the system is being migrated or upgraded to a different or higher version. For example migrating a standard ECC system to S4HANA. Instead of adjusting the monitoring of existing system, you decommission the system and then reconnect the system to Focused Run system. In our future blog we will explain how to decommission in such cases.
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] com.sap.solman.agent.mai.http.WebDispGetServerListCollector com.sap.solman.agent.mai.cim.EvaluationException: division by zero at com.sap.solman.agent.mai.cim.ExpressionEvaluator.evaluate(ExpressionEvaluator.java:72)
In this case, you will want to put to debug this class: com.sap.solman.agent.mai
Following Application components of SDA for which logging can be enabled.
Application / Component
Name (Column in Log Configuration Dialog)
JCo
com.sap.solman.agent.conn.jco
MAI
com.sap.solman.agent.mai
SDA Core
com.sap.solman.agent.core
SSL
com.sap.solman.agent.core
SLDR
com.sap.solman.agent.sldr
To enable logging you can follow the following steps.
Step 1 : Open Agent Administration
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.
All new functions and innovations for SAP Focused Run are delivered in either upgrades or feature packs. This blog will explain how to plan and execute upgrade for SAP Focused Run.
Needed versions of the SDA (simple diagnostics agent)
Scenario specific pre and post actions required
Updates to authorizations in SAP Focused Run
Updates to authorizations in the connected systems
Pre upgrade and post upgrade actions to be performed
The HANA database can be upgraded before the actual upgrade or can be combined with the upgrade. The same applies for the SDA agent.
Best practice is to execute the HANA and SDA upgrades before. Upgrade your Focused Run test system first, leave the versions there for a few weeks to prove stability, then deploy on productive Focused Run system.
In case of changes to authorizations in the connected systems, you can already update these before the upgrade.
Start your upgrade first on your SAP Focused Run development system and write down all the steps you execute. You will need to repeat all steps in your productive system later on.
During the technical upgrade, you will have to perform with the SUM tool, you will need to execute the SPDD and SPAU technical upgrade actions. Store the actions in transport to be used in productive upgrade. After SPUA is done, also apply the updated collective notes listed in the central note 3374888 – Release Information Note for SAP Focused Run 4.0 FP02.
After the technical upgrade has been completed, follow and document carefully all the steps in the OSS upgrade note. For example running extra tasks lists, programs, redo SSI for JAVA, etc.
It can also be you come across items and issues that are not documented in the OSS note. Please write them down in your own runbook for production. When upgrading to SAP Focused Run 3.0 we found that the standard jobs are switched to the technical job repository SJOBREPO (since the 3.0 ABAP stack is based on the S4HANA 1909 version).
Apply all collective notes for all functions you are using. The collective note numbers are listed in the Release Information Note.
After the documented steps, update the authorizations in SAP Focused Run to get the new tiles for new functions available.
Rerun the task lists for the initial setup in STC01 (SAP_FRUN_SETUP_FOUNDATION and SAP_FRUN_SETUP_USECASE) with the variants of the use cases that you are using.
Check in the upgrade manual if any SSI needs to be redone. This is often the case with JAVA systems.
Finally when all actions are done, refresh your browser cache and backend FIORI cache (follow all steps from this blog).
Testing
Before deploying the Focused Run upgrade in production, you must test all your functions in the Focused Run development system. It is very helpful if you have a set of documented test cases that you can easily repeat each upgrade. With testing first focus on testing the current functions you are using. In a later stage you can explore, activate and test new functions.
While testing you will find issues. Solutions are normally:
Updates in authorizations
OSS notes to be applied
SICF services and Gateway services activation
Forgotten step in the activation
Capture all fixes in either transports or in your runbook.
If you still have key issues with bugs, you will need to raise a message to SAP.
<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>
SAP Focused Run has offer guided procedures guide and automate tasks
Questions that will be answered in this blog are:
How to run the guided procedure for ABAP health check?
When to run the guided procedure for ABAP health check?
Running the ABAP health check guided procedure
The goal of the ABAP health check guided procedure is to structurally check the health of an ABAP system.
To start the guided procedure for system health check, open the Guided Procedures Fiori tile:
Now select from the guided procedure for advanced system monitoring the System health check for ABAP systems:
Select the Plus icon to execute a new guided procedure:
Add the scope of systems to the guided procedure:
Then press the Execute Manually button to start.
The guided road map will now open:
Select the checks and press Perform to execute the checks. After the checks are done, you can zoom in the detailed results:
The next checks are shown below:
When to run this ABAP system health check guided procedure?
he ABAP system health check guided procedure can be run:
In case of reported system issues with performance: to quickly find potential root cause
For example monthly or quarterly to check how system is doing
You can also automate the guided procedure and run it on scheduled basis and mail the results to you. This you can for example setup for your primary ECC production system on daily basis.
Automated scheduling of health checks including mail sending
SAP Focused Run provides a mechanism to periodically schedule automatic execution of guided procedures. With this you can optionally enable email notification. This way we can schedule periodic run of System Health Check guided procedure. From each automatic execution of the guided procedure, an email will be sent with the status of the system health check.
Scheduling Guided Procedures
In the Guided Procedures app navigation block click on Guided Procedure Planning.
In the Guided Procedure Planning area, click on the “+” sign to create a new Plan and follow the steps to create a plan.
Step 1: Select guided procedure System Health Check for ABAP Systems.
Step 2: Scope Selection: Select the systems (Ext. System ID) for which you want to run the system health check.
Step 3: Processing Parameters: Select for one time execution or periodic execution.
Step 4: Notification Settings: In this step provide the following details for setting up the email layout for sending the email notification for the guided procedure execution result.
Email Customization (Optional) : Select either of the two options available for this field. With this selection we use the pre-built/inbuilt SAP eMail template provided by SAP.
To: Provide the Recipient List to which you want to send the mail to (You can’t provide direct mail IDs here).
Type: Select Single or Aggregated. The single option sends individual mails for every single system selected in the scope whereas the Aggregated option send an aggregated mail including all systems selected in the scope.
Finally you can click on the Create button as shown below to schedule your guided procedure.
Once scheduled, you can navigate back to the Guided Procedure Planning home screen to see the list of scheduled guided procedures and their current execution status.
Below is sample email for your reference.
<< This blog was originally posted on SAP Focused Run Guru by Manas Tripathy (Simac) and Frank Umans. Repost done with permission. >>
With Focused Run a dashboarding framework is available called Operation Dashboard. This enhancement comes under the Advanced Analytics & Intelligence (AAI) functionality of Focused Run.
With Operation Dashboard you can configure a 3 level drilldown dashboard to track the current situation of monitoring and alerting in the areas of System Monitoring and Real User Monitoring.
Currently you can track metrics and alerts only from areas of System Monitoring and Real User Monitoring.
Views in Operations Dashboard
Operation Dashboard provides 3 types of view to provide a consolidated view of the current status of monitoring and alerting.
Analytics Map: Consolidate monitors to a specific region on the world map. The region is colour coded to the aggregated monitoring status of the monitors included. Aggregation uses worst case rule i.e The colour of the region is green only if all the involved monitors are in green.
2. Tile View: Shows the consolidated monitoring status of a specific Scenario/System/Managed Object. Aggregation uses worst case rule.
3. List Deatils View: Shows the list of involved monitors.
The above three views are linked automatically to eachother to enable the drill down functionality. That is, if you click on a perticular region which is rated in the world map view, you will get the correspoding systems/componenets for that region in the tiles view and the corresponding monitoring metrics in the list view.
Operation Dashboard Setup
To access Operations Dashboards click on Operations Dasboard tile under Advanced Analytics & Intelligence section in the Focused Run Launchpad.
Step 1: Create a new Operation Dashboard
Create a new Operations Dashboard by clicking on Add Custom Page in the navigation pannel of Operations Dashboard app.
Step 2: Name your dashboard
When you create a new dashboard, the dashboard setup are will appear on the right hand side of your screen. Click on the rename button as shown below.
Step3: Configure layout
You can configure the layout of your dashboard in a Grid format. Each grid in the layout will hold a view of your dashboard. As we have 3 types of views you can form a layout of 3 grids. To configure the grid layout click on the Grid button in the setup area – View Management section:
In the pop-up you can drag and drop to form a Grid layout:
Step4: Select monitoring content
To customize your Operations Dashboard, you first need to select the monitoring content as the source of data from either of System Monitoring or Real User Monitoring or both. For this navigate to Page Personalization area.
In the Default Settings area you can
Select or deselect monitoring area (System Monitoring/ Real User Monitoring)
Select or deselect metric or alerts
Select or deselect category (Availability/Exception/Performance)
Alert Severity ( Alerts of same or more severity are included in the scope of the dashboard)
Step 5: Create scenarios
In Order to link systems/ components to a particular region in the world map you need to create scenarios and link them to specific regions in the world map.
In this step you create named Scenarios or Regions to which you can later on tag your monitors. For this navigate to the Content Settings Area , Custom Scenarios Settings. To create a new scenario click on the + sign.
In the pop-up you can directly enter the country name or code or you can click on search to search for your respective country/region and it’s code.
You can see the list of all scenarios you created in the Custom Scenarios section.
Step 6: Add monitors and tag monitors
In this step you add systems/components and tag them to specific scenarios you created in the previous step.
For this navigate to Content Settings area, Data Source Settings and click on the + sign.
In the pop-up screen select the system/component you want to add and accept to continue.
Now back in the Data Sources list select the scenario for the system/component you just added.
Now your Operations Dashboard is ready.
In View 1: World Map, the regions are coded as per the aggregated rating of all systems/componenets tagged to a specific scenario in the Data Sources settings in Step 6.
In View 2: Tiles View, by default shows the Region/scenarios aggregated rating in tiles. In this view you can drill down to aggregated rating for each system/Compoenent/monitor by simply clicking on the tile. (For instance below shows the Tile view of the systems in Germany shown in the image 2 of this blog.
3. In View 3: the List View, shows the monitors for all the system/componenet shown in Tiles view, that is, if you drill down in Tiles View, accordingly filtered monitors are shown in Tiles view.
<< This blog was originally posted on SAP Focused Run Guru by Manas Tripathy. Repost done with permission. >>
This blog will explain specific items to keep in mind when monitoring certain applications.
Applications discussed and explained:
Adobe document servers (ADS)
BW systems
Cloud connectors
Content servers
ECC and S4HANA servers
EWM (enterprise warehouse management) servers
GTS (global trade system) servers
Netweaver gateway FIORI hub systems
SCM (supply chain management) servers
SLT servers
Web dispatchers
For each system we explain the monitoring of productive and non-productive system.
Adobe document server (ADS) application monitoring
Adobe Document Server (ADS) is used to generate PDF’s for output and/or interactive PDF forms.
Monitoring productive ADS systems
When monitoring a productive system, you will need to finetune the monitoring templates for:
SAP J2EE 7.20 – 7.50 Application template, for the JAVA application
SAP J2EE 7.20 – 7.50 Technical instance template, for the JAVA application servers
System host template
Database template
JAVA APPLICATION TEMPLATE for adobe document server monitoring
Make sure you cover in the JAVA application template the following items:
Availability:
JAVA HTTP availability
Expiring certificates
JAVA license expiry
From the JAVA instance template make sure to cover the following items:
J2EE application status
Instance HTTP availability and logon
JAVA server node status
GC (Garbage collection)
Fine tune the metrics so you are alerted on situation where the system is having issues.
ADobe document server template for monitoring
ADS has a specific Technical instance template.
Make sure you activate it:
Most important here is the first one: ADS availability. Please make sure you are alerted when this one is not available.
BW application monitoring
BW systems are at the often used as reporting systems within an SAP landscape.
The basic monitoring of a BW system is the same as for any ABAP based system.
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 a BW system.
Process chain monitoring
BW uses process chains. To monitor process chains, read this dedicated blog.
Cloud connector application monitoring
The Cloud connector is used between on premise systems and Cloud solutions provided by SAP.
Monitoring of cloud connector focuses on availability and connectivity.
Monitoring productive cloud connector systems
The cloud connector template contains all the needed elements out of the box:
If your landscape has only one 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.
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 content server monitoring
For system host the regular CPU, memory, disc template is sufficient. Finetune the thresholds to your comfort level.
Database template for content server monitoring
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).
EWM systems are at the often used as stand alone systems that make sure logistics and warehousing can keep running at high availability. If the connected ECC or S4HANA system is down, EWM can continue to support logistics operations.
EWM can be older version based on SCM/BI system core. Newer EWM systems are using S4HANA with EWM activated as standalone.
Extra in an EWM system are the use of qRFC and the CIF (Core interface). And many EWM systems have users that interact with the system via ITS GUI based handheld scanners.
EWM systems are at the often used as stand alone systems that make sure logistics and warehousing can keep running at high availability. If the connected ECC or S4HANA system is down, EWM can continue to support logistics operations.
EWM can be older version based on SCM/BI system core. Newer EWM systems are using S4HANA with EWM activated as standalone.
Extra in an EWM system are the use of qRFC and the CIF (Core interface). And many EWM systems have users that interact with the system via ITS GUI based handheld scanners.
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:
Many EWM systems are having interaction with scanners via the ITS server. Basically this is a small web page on a scanning device.
Make sure you monitor the availability of the URL’s that the scanners are using. More on URL monitoring can be found in this blog.
GTS (global trade system) application monitoring
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
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).
The basic monitoring of an SCM system is the same as for any ABAP based system.
For an SCM 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 an SCM system.
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:
SCM uses process chains. To monitor process chains, read this dedicated blog.
SLT system application monitoring
SLT systems are mainly used to replicate data from source systems like ECC and S4HANA towards target systems like Enterprise HANA, HANA cloud and other data pool systems.
SLT DMIS template for SLT system
For SLT systems, apply the SLT DMIS template:
In the SLT system itself, make sure job /1LT/IUC_HEALTH_C with program R_DMC_HC_RUN_CHECKS runs. This will collect data that is needed for SLT itself, but which is also re-used by SAP Focused Run.
Anyhow you should make sure to regularly apply the notes for the DMIS component. See this blog.
SLT DMIS dummy template backend system
For SLT to work, the DMIS component is installed in both the SLT system and the backend system. For the backend system SLT component, Focused Run will pick up the template as well. But this will not make any sense in monitoring, since it is the source system and not the SLT system.
For this reason, set up a dummy empty template with every monitoring item disabled:
Assign this dummy template to your backend system.
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, connectivity and 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 monitoring.
Health Monitoring provides a functionality called Availability Monitoring wherein we can monitor:
HTTP Availability: Monitoring availability of URLs.
TCP Availability: Monitoring the availability of a TCP port or the availability of a host.
RFC Availability: Monitoring availability of RFCs specifically for measuring availability of an application server instance of an SAP system or the availability of a message server port of an SAP system.
In this blog we will explain how you can configure a HTTP Availability monitor to monitor availability of a URL.
Setup of URL availability monitoring
Step1: Assign Agent for data collection
The HTTP availability is measured by making a URL http or https call by a designated Simple Diagnostic Agent from your specific customer network in the Focused Run system.
The first step is to assign a Simple Diagnostic agent as the collector for this metric.
For this open the Health Monitoring App from the Focused Run launchpad.
Navigate to Configuration area by clicking on the Configuration button.
Expand the Customer Networks node and click on the change button.
In the next popup select the agent from the list of all connected agents to this customer network.
Step2: Configure HTTP Availability Metric
In the Configuration area expand the metric node and click on the change button for Availability under Metrics node.
In the next pop-up screen click on the Plus button to add a metric.
In the next pop-up screen select HTTP Availability
Enter the following details for a basic URL Availability check.
Field
Description
Metric Name
A descriptive name for the metric
Customer Network
Select the customer network for which you want to create the metric
Collection Frequency
Specify the collection frequency, how frequently the check should be performed.
URL
Enter the URL to be monitored
Proxy
Enter the proxy detail if the URL is reached via a proxy from the customer network. Else select None.
Authentication
Enter the authentication type None or Basic or oAuth and enter the details based on authentication type.
Timeout
Period in milliseconds (ms) before a call fails.
Number of Retries
Number of times the data collector calls a URL until it receives a response.
You can also further customize based on type of call you want to do to the URL for instance sending a POST request. For details you can refer to the SAP documentation here.
Optionally you can also enable alerting and notification in the Alert section of the configuration.
After entering all the details save your configuration to activate the metric.
URL availability monitoring usage
To navigate to the URL availability monitors you can click on the Availability button in the navigation panel.
Or you can also navigate from home screen.
Upon navigating to the Availability monitor metric list you will see the status of all URL availability metrics configured. The metric list view shows us the number of days and hours since the URL is available or unavailable. It also shows us the response time when accessing the URL.
This way you can not only monitor the URL availability but also the performance of an URL with regards to the response time while accessing the URL.
OS process monitoring
With OS Process Monitoring functionality we can monitor the availability of critical OS level processes on any host.
With System Monitoring templates you can also activate custom metric for monitoring OS processes however this will be applicable for all system/hosts for which you activate the template.
For monitoring critical OS processes for specific hosts you need to setup using Health Monitoring functionality.
To access Health Monitoring functionality you can navigate to Health Monitoring app in the Focused Run launch pad.
Prerequisite for OS process monitoring
The only prerequisite for configuring OS process monitor in Health Monitoring is that you should have registered the host and deployed Simple Diagnostic Agent (SDA) on the host where you want to monitor the critical process.
Setup of OS process monitoring
For setting up the OS process monitor you need to navigate to the settings page of the Health Monitoring App.
In the settings area expand the metrics node and click on the pencil button (Edit Metric) for OS Processes.
In the OS Process edit metric screen click on Add Metric button to start creating the OS Process Metric.
In the OS Process edit metric screen click on Add Metric button to start creating the OS Process Metric.
Field
Description
Process Name
Name of the OS process. This parameter needs to be maintained as a regular expression. SDA will use this expression for searching for the respective OS process at OS level.
User (Optional)
You can further restrict the search for processes running through a specific user. You need to enter the name as a regular expression
Command Line (Optional)
You can further restrict by the specific command line with which the process is running . This is specifically useful if there are multiple processes running with the same name but you want to monitor the process which is running with a specific argument or parameter. This also needs to be maintained as regular expression.
Hostname
Name of the host where the process to be monitored. You can select from a list of all hosts connected (also SDA deployed) to the Focused Run system.
In the General Settings tab you can also specify the data collection frequency and the threshold. By default 5 minutes frequency and Already Rated threshold is set.
Optionally you can update the alert settings for this metric in the Alert Settings tab. By default alerting is active with medium severity.
After entering all details, to activate the metric click on Save button.
You can monitor all you OS process metrics in the OS Processes tab of the Health Monitoring App.
SSL certificate monitoring
You can configure monitors to monitor the SSL certificate of a URL using Health Monitoring functionality in SAP Focused Run system. This monitor measures the remaining validity (in days) of a SSL certificate for a https call to a URL. The URL is called by Simple Diagnostics Agent of a designated host in your customer network.
The Health Monitoring app also provides a separate section called as URL Certificate Monitor where in you can centrally monitor expiry of SSL certificates of any https URL.
To navigate to URL Certificates monitor you can click on the URL Certificate button as shown below in the navigation panel of the app.
Setup of SSL certificate monitoring
To configure URL Certificate monitors , navigate to the Configuration area, expand the Metrics node and click on the change button.
In the popup window click on the Add Metric.
In the Metric Configuration window enter the following details in the General tab.
Field
Description
Metric Name
A meaningful name to the monitor
URL
URL whose certificate to be monitored.
Proxy URL (Optional)
The Proxy URL if the URL is accessible via a proxy URL
Customer Network
The Customer Network to which this URL belongs. The designated SDA from this customer network will be performing the check.
Technical System (Optional)
You can optionally link this monitor to a specific cloud service you have registered in your LMDB. This is the Cloud Service you would have created if you are using AIM scenario for Cloud Service Monitoring. Select from the drop down.
Collection Interval
Frequency of data collection. Select from available options.
Threshold
Threshold for remaining days for expiry. By default 200 Days for Yellow and 100 days for Red.
Additionally and optionally in the Alert Settings tab you can activate alerting and notification settings as shown below.
That’s it, now your monitor is active.
Using SSL certificate monitoring
To monitor navigate to the URL Certificate tab in the Health Monitoring App.
You can also refer to this SAP documentation to know more about various features available with Focused Run Health Monitoring.
<< This blog was originally posted on SAP Focused Run Guru by Manas Tripathy and Frank Umans. Repost done with permission. >>
manage the figures you need for service availability management:
Uptime of the system
Planned and unplanned downtime of the system
All service availability management functions are present using this Fiori tile:
On the left hand side there is the menu with all options:
Service availability management definitions
There are 2 definitions we need to configure:
The outage customization
Service availability definitions
First we start with the outage customizing:
Make the required settings for planned and unplanned downtime.
Now you add a new service management definition:
Provide a name and validity date for the definition and use the + symbol to add systems for which the definition is relevant.
In the tab availability set the SLA threshold for the availability percentage:
If relevant you can set specific contractual maintenance time in the last tab:
Example of use for this tab: you are running your SAP system hosted on for example AWS or Azure. Those platforms can have scheduled maintenance as well. That is not in your control.
Carefully check your entries and definition before saving. They cannot easily be changed later!
You cannot delete an active definition. To make it inactive you need to change the end date of the definition to today, and then delete it next day.
Each system can only be in one SLA definition!
Classifying the outages
On the Outages overview you can see the outages. The outages can be 0, or there can be open and/or confirmed outages:
Click on the open alert to classify it (click once for the line, click on the line for the details):
Classify the outage (planned/unplanned) and set the status. Fill out the text to clarify. And then save the update.
Outage reporting
There are 2 main reports. The uptime and outage reporting. The uptime reporting shows how long your system is up since the last reported planned or unplanned downtime. This overview is not so useful.
The useful overview is the outage reporting which shows you the downtime per system and per month:
In the example above 1 system had outage, but that was short enough to still meet the SLA target. Availability was 99.64% versus SLA target over 99.5%.
<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>
There will be planned maintenance on SAP systems, databases, operating systems and the below infrastructure. During this planned maintenance, you don’t want any alerts and mails from SAP Focused Run, since the application is not available for a planned time.
Using the work mode management function you plan these maintenance events.
Questions that will be answered in this blog are:
How can I set up planned maintenance for systems monitored by SAP Focused Run to temporarily suppress the alerts during maintenance?
How can I see the current maintenance and planned upcoming maintenance?
Can I make a public page for the IT calendar?
Planning maintenance
Goto the IT calendar and workmode management tile:
Select the system (or select multiple systems in one go) and create the work mode for maintenance, and immediately switch to Expert Mode:
With expert mode you can simply set start and stop date and time.
You also should check the scope (the system will make a proposal) and extend if needed:
After saving, you can send notification via mail on the planned maintenance:
You can now see the planned maintenance in the calendar mode.
Overview of upcoming events
If you are in the calendar mode there can be a lot of systems. The overview screen for upcoming events will filter on the systems which have maintenance mode planned:
Can I select multiple systems for planned maintenance in one go? Yes you can, this will save you a lot of time to input.
Can I make a recurring maintenance? Yes you can, in the scheduling screen mark the maintenance as recurring.
IT Calendar access for Non-SAP Focused Run Users
During the maintenance the alerts are suppressed. The same information can also be made generally available to serve as a IT calendar for all interested persons. This can be people for the IT department and the business. These users are mainly interested in planned downtime of the IT systems.
Use of the IT calendar for non-SAP focused run users
Create a system user with copy of role SAP_FRN_APP_ITC role and update it with the UI5 application “itcal_external”(IWSG and IWSV).
Also add these 4 not documented authorizations:
Display for service availability management:
2. Display for work modes:
3. Add generic services:
4. Add filter bar rights:
Activate and save this role.
Activate these 2 SICF services:
/default_host/sap/bc/bsp/sap/itcal_external
/default_host/sap/bc/ui5_ui5/sap/itcal_external
On the Logon tab of these 2 services set the user ID and password of the newly created system user.
Do the same for the external system alias /sap/itcalnonsolman (also in SICF transaction): also here set the user ID and password for the newly created system user with the assignment of the newly created role.
After settings are done, execute testing. Most issues are coming from lack of auhtorizations.
OSS note for IT calendar function
Relevant OSS notes:
2926433 – IT Calendar access to Non-SAP Focused Run Users
3150979 – Number of systems in scope is limited, while using External IT Calendar
<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>
ultiple systems. Items that are part of the tactical dashboard is database backup status, performance, logged on users, software maintenance status.
Questions that will be answered in this blog are:
How to use the Focused Run tactical dashboards?
How to fine tune the tactical dashboards?
How to setup your own tactical dashboard?
Tactical dashboards usage
To start the tactical dashboard, click the corresponding Fiori tile:
You now reach the tactical dashboard overview screen:
By clicking the Expand Group icon at the right you get first level of details:
By clicking the tile you are interested in you get the details.
Examples are hardware resources for current week and last month:
Dialog response times:
Amount of logged on users:
And software maintenance status for detailed components:
An alternative for manageming software components is via Security and Configuration management. More details be found in this detailed blog. The tactical dashboard is nice for 1 system. The configuration validation tool is useful for overview of components across multiple systems.
Configuration of the tactical dashboard
By clicking the personalization button top right:
you will reach the configuration screen. Here you can add and delete systems from the overview:
And you can set the view properties and thresholds for each of the categories:
This fine-tuning you do as per your companies needs. By clicking on the Visibility symbol, you can hide an aspect from your overview. Like above the Database backup was put to invisible.
Creating your own tactical dashboard
You can create your own tactical dashboard for your own specific needs. We will take the example here to make a dedicated dashboard for the backups. Since we want to check daily in the overview if the backups were successful.
Start by clicking top left on the big + symbol to add a new dashboard:
The personalization view screen will open:
Important here are a few things. Set the tick box Public if you want to share this dashboard. Find the keyword for the right SAP icon (use the SAP icons link and read this blog). Rename the dashboard by clicking the Rename button.
Now Save the page. Close the personalization. You are now in the empty screen. Open peronalization again to add the system(s):
Also hide the not needed views. On the left hand side you can immediately see the result updating.
Hint: start with one or two systems only when making a new dashboard. First fine tune what you want to see. When all is ok, add the systems later. If you have a lot of systems, the updating of the left hand screen will be slowing you down.
Don’t forget to save off course.
Using a dashboard created by a different user
If you want to use a dashboard created by a different user, go to the personalization option and select the add page option:
Now you can select any created dashboard, which has been set to public.
If you don’t see the correct dashboard, check with the owner that he made it public.
