Introduction
You subscribed SAP cloud services, and eventually operate systems, to fulfil the business needs of your company. This service & system landscape is processing every day vast amounts of transactions.
Even so, in general everything works smoothly in your landscape, you must detect promptly any unexpected behavior and evaluate its potential impact without delay.
Such problems are usually producing exception data in logs. You can of course review those various logs, using local monitoring tools provided by the respective solutions. But this approach turns out to be fastidious, as you need to use different tools, day-in and day-out. And you will end up analyzing thousands of logs.
My blog series will guide you through the capabilities offered by SAP Cloud ALM Exception Monitoring, unveiling also upcoming evolutions.
Note:
SAP Cloud ALM is available free of charge under fair usage, for customers having cloud subscriptions with SAP Enterprise Support. Get you own tenant in less than 1 hour.
One place to review all collected exceptions
Using SAP Cloud ALM Exception Monitoring, you get a comprehensive overview of the exceptions occurring across your landscape. It also offers a wide range of downstream actions, like a built-in alerting mechanism, and a central e-mail notification. Furthermore, you can integrate your ticketing system, or execute maintained operation flows.
Exception Monitoring features are articulated into pages, as follow:
Exceptions
Here you start your analysis, using an overview of the total number of exceptions that occurred in a time interval, across all supported products and log categories.
You will then drill down to the actual exceptions for the log category you would like to analyze first.Tracking
With this tool you swiftly find back all exceptions that match any provided keyword. The entered keywords can be technical identifiers, like a W3C trace ID, or any value from the exception payloads.Alerting
In case you activated the built-in alerting, you can review and process in this page, all alerts that were created, based on the rules that you defined for the Exception Logs.Exception Pattern Analysis (Planned)
Using AI generated indicators you will…
Stay tuned for my next blog posts, unveiling the details.
Exceptions (Page)
This page provides an overview of the number of exceptions, across your landscape.
Using the page header, you will quickly identify exception bursts, impacting the monitored products.
Accordingly, the page content displays one card per monitored service and system, clustered per product. You additionally benefit from a summary card, in case you monitor several services or system, belonging to the same product.
The cards display a list of exception categories. A category could be considered as a log-type, like System logs, Java Application logs, etc. Per category you see an exception count and a trend. The trend is reflecting the evolution of the number of exceptions, comparing the amount for the current time interval selection, with the previous interval.
For instance, if your time selection is last 2 days (Thursday to Friday), the trend will display: increasing, if the number of exceptions for this category was lower the 2 days before (Tuesday to Wednesday). Taking a second example, if your time selection is CW 45, the trend will display: decreasing, if the number of exceptions was lower on CW 44.
By clicking on the entry “ABAP Application Log” from the card “All SAP S/4HANA”, you will drill down into the following screen. There you can centrally review all SLG1 error logs from the S/4HANA private cloud services that you added into your application shell scope-selector.
Note:
Exception Monitoring is displaying exception logs only for the categories where you enabled the data collection, during the configuration process (see next section). In case you don’t see some error logs you are expecting, keep in mind to review the configuration, as the collection might be restricted to only retrieve a log data subset of the monitored service or system.
As shown below, using the powerful multilevel filter capabilities, you can stepwise narrow-down the number of exceptions to be analyzed, concentrating on specific flaws.
Note:
Exception Monitoring is designed to reflect errors and warnings, as provided by the supported log sources.
Therefore, do not expect to see all types of log entries, including the ones with a log level info or debug! However, Exception Monitoring offers a very convenient “Resolved” status, for log sources that provide context-sensitive logs.
For instance, let’s take the category Artifact Integration Content as an example. Exception Monitoring will report all newly occurring Artifact deployment errors. Whenever such an erroneous Artifact is later-on undeployed or fixed, the status of the previously reported exception is updated to “Resolved”. You therefore understand that this past issue is no longer actual, and you may skip its analysis.
Tracking (Page)
This efficient search tool will assist you in most circumstances.
Imagine you are currently analyzing an exception. Now, you would like to cross check whether this issue has further related errors, or if it is the consequence of some integration calls. In case you see a tab “Association Context” for the analyzed exception, open it and take one of the provided correlators, like the transaction ID or the W3C trace ID. Use this Identifier in the tracking tool.
Otherwise, imagine an end-user is reporting a technical error message that he encountered in one of the services you are monitoring. Using the Tracking page, you can look up the mentioned error message, for the services and systems you have in your scope selection or your home page favorites.
Note:
Exception Monitoring is in general collecting backend exceptions. Frontend errors, occurring at UI level, are usually not in scope.
Finally, imagine that you don’t remember when and where a given error occurred the last time. Simply open the tracking page and lookup any information you know about the error. The tool will report all occurrences.
How to setup Exception Monitoring?
Connectivity
SAP Cloud ALM for Operations requires, as a central platform, to access the data you want to monitor.
I recommend you to follow the expert poral documentation, which describes how to enable the integration, product per product.
Be aware that the integrations are of different kinds:
[SAP managed]
Most products are now natively integrated with SAP Cloud ALM and therefore do not require any preparation work.[Customer built]
Open Telemetry based integrations are possible, as documented in the expert portal. You should carefully follow the instructions to enable this type of integration.[S/4HANA public cloud & SAP BTP ABAP environment]
Currently you still need to explicitly setup a push-base data collection, using a communication arrangement.[S/4HANA private cloud]
As described in the expert portal, run the mentioned ABAP transaction to enable the integration.[Pull-based]
Finally a few other products, still rely on pull-based data collections. Here, you need to declare within SAP Cloud ALM the endpoints to connect to the monitored services or systems.
Data collection activation
Finally, once you fulfilled all preparation work, you need to explicitly turn on the data collection for the relevant systems and cloud services.
Exception Monitoring data is clustered into product specific log sources, designated as categories. You can turn on the data collection globally at system or cloud service level, or selectively at category level.
Keep in mind that some categories (log sources) could be very verbose, producing a lot of exception data. For such categories, eventually consider fine-tuning the data collection, by specifying which data subsets you want to monitor.
Enable downstream actions (Alerting, E-mail notifications, etc.)
By setting up IEP event actions, you can typically generate alerts or get e-mail notifications for the collected exceptions.
Be aware that the configuration UI currently doesn’t offer the possibility to define filters. This means, in case you enable such actions, you will get a significant stream of alerts or e-mails, as long as your system or services produces exceptions.
Future evolution
Most configuration screens were designed in the early times of SAP Cloud ALM, as a bootstrap solution. A redesign is currently ongoing to streamline the configuration screens and offer long awaited features, like advanced filtering capabilities at data collection and event creation level.
Stay tuned for my next blog posts, unveiling the details.
Final thoughts
With the advent of cloud solutions an increasing amount of software operation related tasks are delegated. Take this as an opportunity to increase your attention, monitoring tightly the business value chain of the integrated solutions.
Therefore, consider that Exception Monitoring will remain an essential activity, evolving from infrastructure-centric alerts to a business-value-centric observability.
IntroductionYou subscribed SAP cloud services, and eventually operate systems, to fulfil the business needs of your company. This service & system landscape is processing every day vast amounts of transactions.Even so, in general everything works smoothly in your landscape, you must detect promptly any unexpected behavior and evaluate its potential impact without delay.Such problems are usually producing exception data in logs. You can of course review those various logs, using local monitoring tools provided by the respective solutions. But this approach turns out to be fastidious, as you need to use different tools, day-in and day-out. And you will end up analyzing thousands of logs.My blog series will guide you through the capabilities offered by SAP Cloud ALM Exception Monitoring, unveiling also upcoming evolutions.Note:SAP Cloud ALM is available free of charge under fair usage, for customers having cloud subscriptions with SAP Enterprise Support. Get you own tenant in less than 1 hour. One place to review all collected exceptionsUsing SAP Cloud ALM Exception Monitoring, you get a comprehensive overview of the exceptions occurring across your landscape. It also offers a wide range of downstream actions, like a built-in alerting mechanism, and a central e-mail notification. Furthermore, you can integrate your ticketing system, or execute maintained operation flows.Exception Monitoring features are articulated into pages, as follow:ExceptionsHere you start your analysis, using an overview of the total number of exceptions that occurred in a time interval, across all supported products and log categories.You will then drill down to the actual exceptions for the log category you would like to analyze first.TrackingWith this tool you swiftly find back all exceptions that match any provided keyword. The entered keywords can be technical identifiers, like a W3C trace ID, or any value from the exception payloads.AlertingIn case you activated the built-in alerting, you can review and process in this page, all alerts that were created, based on the rules that you defined for the Exception Logs.Exception Pattern Analysis (Planned)Using AI generated indicators you will…Stay tuned for my next blog posts, unveiling the details.Exceptions (Page)This page provides an overview of the number of exceptions, across your landscape.Using the page header, you will quickly identify exception bursts, impacting the monitored products.Accordingly, the page content displays one card per monitored service and system, clustered per product. You additionally benefit from a summary card, in case you monitor several services or system, belonging to the same product.The cards display a list of exception categories. A category could be considered as a log-type, like System logs, Java Application logs, etc. Per category you see an exception count and a trend. The trend is reflecting the evolution of the number of exceptions, comparing the amount for the current time interval selection, with the previous interval.For instance, if your time selection is last 2 days (Thursday to Friday), the trend will display: increasing, if the number of exceptions for this category was lower the 2 days before (Tuesday to Wednesday). Taking a second example, if your time selection is CW 45, the trend will display: decreasing, if the number of exceptions was lower on CW 44. By clicking on the entry “ABAP Application Log” from the card “All SAP S/4HANA”, you will drill down into the following screen. There you can centrally review all SLG1 error logs from the S/4HANA private cloud services that you added into your application shell scope-selector.Note:Exception Monitoring is displaying exception logs only for the categories where you enabled the data collection, during the configuration process (see next section). In case you don’t see some error logs you are expecting, keep in mind to review the configuration, as the collection might be restricted to only retrieve a log data subset of the monitored service or system. As shown below, using the powerful multilevel filter capabilities, you can stepwise narrow-down the number of exceptions to be analyzed, concentrating on specific flaws. Note: Exception Monitoring is designed to reflect errors and warnings, as provided by the supported log sources.Therefore, do not expect to see all types of log entries, including the ones with a log level info or debug! However, Exception Monitoring offers a very convenient “Resolved” status, for log sources that provide context-sensitive logs.For instance, let’s take the category Artifact Integration Content as an example. Exception Monitoring will report all newly occurring Artifact deployment errors. Whenever such an erroneous Artifact is later-on undeployed or fixed, the status of the previously reported exception is updated to “Resolved”. You therefore understand that this past issue is no longer actual, and you may skip its analysis.Tracking (Page)This efficient search tool will assist you in most circumstances.Imagine you are currently analyzing an exception. Now, you would like to cross check whether this issue has further related errors, or if it is the consequence of some integration calls. In case you see a tab “Association Context” for the analyzed exception, open it and take one of the provided correlators, like the transaction ID or the W3C trace ID. Use this Identifier in the tracking tool.Otherwise, imagine an end-user is reporting a technical error message that he encountered in one of the services you are monitoring. Using the Tracking page, you can look up the mentioned error message, for the services and systems you have in your scope selection or your home page favorites.Note:Exception Monitoring is in general collecting backend exceptions. Frontend errors, occurring at UI level, are usually not in scope.Finally, imagine that you don’t remember when and where a given error occurred the last time. Simply open the tracking page and lookup any information you know about the error. The tool will report all occurrences. How to setup Exception Monitoring?ConnectivitySAP Cloud ALM for Operations requires, as a central platform, to access the data you want to monitor.I recommend you to follow the expert poral documentation, which describes how to enable the integration, product per product.Be aware that the integrations are of different kinds:[SAP managed]Most products are now natively integrated with SAP Cloud ALM and therefore do not require any preparation work.[Customer built]Open Telemetry based integrations are possible, as documented in the expert portal. You should carefully follow the instructions to enable this type of integration.[S/4HANA public cloud & SAP BTP ABAP environment]Currently you still need to explicitly setup a push-base data collection, using a communication arrangement.[S/4HANA private cloud]As described in the expert portal, run the mentioned ABAP transaction to enable the integration.[Pull-based]Finally a few other products, still rely on pull-based data collections. Here, you need to declare within SAP Cloud ALM the endpoints to connect to the monitored services or systems.Data collection activationFinally, once you fulfilled all preparation work, you need to explicitly turn on the data collection for the relevant systems and cloud services.Exception Monitoring data is clustered into product specific log sources, designated as categories. You can turn on the data collection globally at system or cloud service level, or selectively at category level.Keep in mind that some categories (log sources) could be very verbose, producing a lot of exception data. For such categories, eventually consider fine-tuning the data collection, by specifying which data subsets you want to monitor.Enable downstream actions (Alerting, E-mail notifications, etc.)By setting up IEP event actions, you can typically generate alerts or get e-mail notifications for the collected exceptions.Be aware that the configuration UI currently doesn’t offer the possibility to define filters. This means, in case you enable such actions, you will get a significant stream of alerts or e-mails, as long as your system or services produces exceptions.Future evolutionMost configuration screens were designed in the early times of SAP Cloud ALM, as a bootstrap solution. A redesign is currently ongoing to streamline the configuration screens and offer long awaited features, like advanced filtering capabilities at data collection and event creation level.Stay tuned for my next blog posts, unveiling the details. Final thoughtsWith the advent of cloud solutions an increasing amount of software operation related tasks are delegated. Take this as an opportunity to increase your attention, monitoring tightly the business value chain of the integrated solutions.Therefore, consider that Exception Monitoring will remain an essential activity, evolving from infrastructure-centric alerts to a business-value-centric observability. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
