Solution Manager 7.1 allows you to monitor almost anything in an SAP landscape. When an alert fails to generate an email alert, what tools do you have to find the root cause of an error? Review the tools that are provided by SAP to analyze the back-end processes of Technical Monitoring. See how to manage and use the monitoring infrastructure to its fullest potential.
Key Concept
Technical Monitoring is designed to provide alerts on the critical components of an SAP landscape, allowing you to respond quickly to urgent situations that need immediate attention.
As time goes on, Solution Manager only becomes more advanced. It is increasingly designed to monitor more applications in various ways. This inherently means that issues can be more difficult to resolve, especially if you are not managing Solution Manager on a daily basis. This article is meant to assist in the process of troubleshooting issues with Technical Monitoring.
Technical Monitoring is an extremely dense tool provided by SAP’s Solution Manager 7.1. Beyond the standard operations that most people are accustomed to using, it allows you to monitor almost anything. As of Solution Manager 7.1 Support Package 12 (SP12), Technical Monitoring is divided into five specific types of monitoring:
- System monitoring
- Solution Manager self-monitoring
- End-user experience monitoring
- Interface and Process Orchestration (PO) monitoring
- Job and SAP Business Warehouse (SAP BW) monitoring
First and foremost I go over the basics to prevent issues from coming up in the first place. Then I describe the Monitoring and Alerting Infrastructure (MAI) analysis tools, the Data Provider Check, and the Metric Troubleshoot. You will see how the Extractor/Alerting Framework, diagnostics agent administration, E2e-MAI Servlet, and the Alerting Directory Browser tools allow you to find the root cause of an issue. These tools are available to troubleshoot the primary components that are used by Solution Manager to collect data on SAP systems.
Note
This article is written for SAP administrators who have experience
configuring and managing Technical Monitoring. It is based on Solution
Manager 7.1 SP12. If you aren’t familiar with some of the concepts that
are discussed here, refer to my article “
An Advanced Lesson on Technical Monitoring within Solution Manager 7 1.” You must know
how data is collected before you can use these tools to troubleshoot why
data is failing to be collected.
Troubleshooting 101: Resolve Issues Before They Exist
The first thing to learn about troubleshooting Technical Monitoring is to start at the source. Eighty percent of the time an issue with data collection is directly related to the source. Either the tool that is collecting the data needs to be patched or it is not functioning properly. Whenever I start a new Solution Manager Technical Monitoring project, I review all the basics.
The first thing I check is Solution Manager itself. If it isn’t configured properly and updated, nothing functions properly. I always complete an in-depth review of the system, including system preparation, basic configuration, and managed system configuration for all systems.
The most important piece is the Solution Manager composite note. This note is a compilation of all the SAP Notes that are required for Solution Manager to function properly. This note is updated regularly by SAP with new fixes. I verify that the latest version has been implemented properly.
Next is a note that SAP releases and updates regularly, Recommended Corrections. This note includes all the components that must be patched to their latest releases, specifically a number of SAP NetWeaver Java components, including the two most important: LM-Service and Wily agents. As you know, LM-Service (also called SOLMANDIAG) is the primary component of the diagnostics agents. When LM-Service is patched in Solution Manager, the new patch is automatically pushed out to all diagnostics agents. The same goes for the Wily agents. These agents are pushed out during the execution of managed system configuration.
Next is to ensure that all the steps of managed system configuration are completed and executed correctly. The first step is to ensure that the Landscape Management Database (LMDB) has the most up-to-date information on the managed system. Ensure that Solution Manager is aware of all the components installed in a managed system.
The second step is to ensure that the managed system has the latest versions of Solution Tools Plug-in (ST-PI) and Service Tools for Applications Plug-in (ST-A/PI) installed. The third step is to validate that all the Solution Manager system users have the latest security roles in the managed system, including the Remote Function Call (RFC) users SM_<SID>, SMTM<SID>, SMB_<SID>, SM_ADMIN_<SID>, SM_COLL_<SID>, and SMDAGENT_<SID>.
The fourth step is to ensure that the managed system has a diagnostics agent installed on every host. The most important piece (overlooked 50 percent of the time) is the host agent on the hosts. The host agent must be patched to the latest available release.
The fifth step is to ensure the database is connected properly. Lastly make sure all the automatic steps have been executed successfully. All of them must be complete to ensure Solution Manager can manage and collect data from each managed system successfully.
How Do I Know I Have an Issue and Where Do I Begin to Troubleshoot?
You know you have an issue with a metric or alert by viewing the status of the metric. The primary symptom of a failing metric is a gray status. All metrics have four statuses, green, yellow, red, and gray. Green, yellow, and red mean that data is at least being collected. A gray status is the result of either a broken or misconfigured metric. The system monitoring dashboard accessed from the Technical Monitoring work center tells you which metrics are gray (Figure 1).
Figure 1
System monitoring dashboard
The system monitoring dashboard also has a very useful troubleshooting tool that kicks off your troubleshooting Check Data Collection option (Figure 2). When executed, it goes through all the required steps for that specific metric and tells you which step is failing. It gives you a place to begin the process of finding the root cause to the issue. Select the arrow next to the gray metric to display the drop-down menu and select the Check Data Collection option.
Figure 2
The Check Data Collection tool
A menu pops up with a complete list of all the steps required for the metric to function (Figure 3). On the left you see the results (Status) of each step. Additional documentation helps with understanding each step. Each step also has a link to additional tools for troubleshooting. As you can see, this metric is looking for a specific file to monitor. It cannot find the file, causing the metric to be gray.
Figure 3
Check the data collection results
MAI Analysis Tools
The MAI analysis tools collection allows you to troubleshoot alerts in all the areas of Technical Monitoring. It is also a central location to access configuration and other related areas of the MAI. These tools are accessed by executing transaction code MAI_TOOLS (Figure 4). The security role SAP_SM_TECH_MON_TOOL is required to be able to access the transaction. The transaction code MAI_TOOLS is broken up into five categories: Analysis, Logs & Traces, Configuration, Simulation, and Related Links.
Figure 4
Categories of MAI tools
The Analysis section is broken up into five categories: General, Alerting Directory, Data Provider Connector, Event Calculation Engine, and Reporting (Figure 5). Each section has its own tools that are specifically designed for these areas of MAI. There are four tools in this section that I have found to be the most useful.
Figure 5
Available tools in the Analysis section
Alerting Directory Browser
The Alerting Directory Browser is essentially a complete list of all the alerts that have been activated in Technical Monitoring (Figure 6). This tool is specifically useful for two reasons. First, it allows you to quickly analyze which systems have monitoring activated and how the alerts are configured. Second, it gives you all the technical requirements needed for using the Metric Troubleshoot and some of the other MAI tools, including the Metric and Managed Object IDs that are needed to execute the Metric Troubleshoot.
Figure 6
Alerting Directory Browser
Metric Troubleshoot Tools
The Metric Troubleshoot analysis tool allows you to analyze all the steps that are required for an alert to function properly, from data collection to data processing (Figure 7). First, you must use the Alerting Directory Browser to get the Metric ID or the Managed Object ID. This information is needed to enter into the Metric Troubleshoot. Once you have this information, enter it and execute the Metric Troubleshoot by clicking the execute icon.
Figure 7
Metric troubleshooting tool
In this case I am executing a search to test all of the alerts for this specific Monitored Object.
The tool provides a complete list of all the alerts and every single step within each alert. It provides complete logs for each step within an alert, allowing for the in-depth analysis of each alert to perform quick troubleshooting of a failing alert (Figure 8).
Figure 8
Results screen from the Metric Troubleshoot tool
Data Provider Check for Pull Metrics
If Metric Troubleshoot doesn’t provide enough information on the issue, the Data Provider Check can get you more detailed information on the actual data that is being collected. This tool is specifically used to troubleshoot a failing pull extractor. It provides the current status and the measured values of a specific pull metric. (For more information about pull extractors see my article “An Advanced Lesson on Technical Monitoring within Solution Manager 7 1.”)
The Data Provider Check for PULL_RFC Metrics (Figure 9) allows you to search in two ways, first by a specific Metric ID and the corresponding Managed Object ID, and second in a more general format using a specific data provider type.
Figure 9
Search by Metric ID or by a Data Provider in the Data Provider Check screen
The first option allows you to keep the search narrowed to a specific alert that is assigned to a specific managed object. You search with the Metric ID and the Managed Object ID, ensuring the results are specific to one system or managed object. Figure 10 shows the results when you search for a specific metric and managed object.
Figure 10
Search results by metric type
The second option is a wider search that is based on the data provider used and the system. This provides all the alerts that fall under that data provider and their statuses. The results of this search type are shown in Figure 11. There are five source types for the pull RFC extractors:
- ST – Extractors based directly in Solution Manager itself
- ST_PI – Extractors that pull data using applications and function modules within the component ST-PI installed in the managed system
- ST_BW – Extractors that pull data that is stored directly in the SAP BW component of Solution Manager itself
- ST_DBMS – Extractors that pull data from the DBACOCKPIT connection configured in Solution Manager to the managed system’s database
- ST_PI_CLNT – Extractors that pull client-specific data using the ST-PI component installed in the managed system
Figure 11
Results from the data provider search
As you can see in the screenprints above, this tool allows you to see a variety of details, including the status of data collection, the data collected, and the thresholds set for the alert. This enables a detailed analysis of any pull metric.
E2eMAI Support Servlet
The E2eMAI Support Servlet allows you to view similar data, but from the perspective of an individual diagnostics agent. It allows you to view the current configuration and log files for a specific diagnostics agent. This tool is specifically used for investigating the failure of push extractors only.
The primary data that is significant for troubleshooting are Show Current Configuration, Download Current Configuration, Show Collection Statistics, Show Last Collection Errors, and Show Log Files, which are shown in Figure 12.
Figure 12
E2eMAI Support Servlet
When you apply and activate a template to the system, Solution Manager deploys an XML file with all the metrics and thresholds. The deployment of this XML file configures the diagnostics agent to monitor and send specific data to Solution Manager. The E2eMAI Support Servlet tools allow you to inspect this XML file, per diagnostics agent. When displaying the current configuration you can verify that the metrics and thresholds that you configured in System Monitoring were actually deployed to the diagnostics agent. Using the Download Current Configuration button allows you to download the XML file to your PC, enabling you to examine the configuration locally (Figure 13).
Figure 13
Display of the XML configuration file
Displaying the collection statistics allows you to view the last 25 runs or metric executions, whether they were successful or not (Figure 14). This displays the values collected and they are sorted into metric groups.
Figure 14
Display of the collection statistics
The ability to display the last collection errors is by far the most valuable tool. Any metrics that are failing to collect data are displayed (Figure 15). You then can analyze the specific data that is being collected by the diagnostics agent so you can determine exactly why the metric is failing to collect data properly. At times it may be an operating system-level issue or possibly a threshold type that doesn’t work with the type of data being collected.
Figure 15
The last collection errors results
Displaying the log files can be valuable, as well as a detailed analysis of the log files that can lead to the root cause of an issue, especially when the issue lies with the diagnostics agent itself and not the actual data collection of a metric.
Diagnostics Agent Administration Portal
The Diagnostics Agent Administration portal is the central and primary tool for maintaining all the diagnostics agents in your SAP landscape. It allows you to do a wide variety of operations, including viewing logs, checking versions, checking connectivity, and changing configuration. To access the Diagnostics Agent Administration portal from the Solution Manager Administration work center, follow menu path solman_workcenter > SAP Solution Manager Administration > Infrastructure > Framework > Agent Framework > Admin > All Agents as shown in Figure 16.
Figure 16
Steps to navigate to the Agent Administration portal
At the top of the screen shown in Figure 17 you have a variety of tabs. I only touch on a few of the primary options in this article: Agents, Agent Connectivity, Application Configuration, SAP Host Agent, and Agent Log Viewer.
Figure 17
The diagnostics agent administrative portal
The Agents tab (Figure 18) gives you the current status of all the agents that are or were connected to Solution Manager. You can see the version of the agent, its connection status, and the hostname of the host the agent is running on. It also allows you to restart any agent remotely from Solution Manager.
Figure 18
Current status of agents
The Agent Connectivity tab (Figure 19) allows you to change how each agent connects to Solution Manager. This enables you to change the connectivity type between a standard user authentication to a certificate-based Secure Socket Layer (SSL) connection. The certificate-based connection is key for anyone with security concerns.
Figure 19
Change the connectivity type
The SAP Host Agent tab (Figure 20) displays the current status of the host agents and their version. This is a new tab with Solution Manager 7.1 SP12. This is a great enhancement, as in the past this could only be displayed in managed system configuration for each system, one at a time.
Figure 20
Current status of host agents
The Application Configuration tab (Figure 21) allows you to change the configuration of the parameters of each diagnostics agent. This can be done either globally or in an agent-specific manner.
Figure 21
Change the application configuration parameters
The Agent Log Viewer tab (Figure 22) allows you to view the individual logs for each agent, allowing you to troubleshoot issues with the agent itself.
Figure 22
View individual logs
Alerting and Extractor Frameworks
The Alerting Framework and the Extractor Framework allow you to view the current status and logs for all the extractors. The Alerting Framework displays the push extractors and the Extractor Framework displays the pull extractors. These are accessed via menu path transaction solman_workcenter > SAP Solution Manager Administration > Infrastructure > Framework > Extractor Framework or Alerting Framework, as shown in Figure 23.
Figure 23
Display the push and pull extractors
These two tools are critical for troubleshooting gray metrics as every single metric has a corresponding extractor. Figure 24 shows the Extractor Framework and Figure 25 shows the Alerting Framework.
Figure 24
The Extractor Framework
Figure 25
The Alerting Framework
Final Tip to Ensure All Your Alerts Are Functioning – Keep It to a Minimum
Now that you have the tools you need it is just a matter of finding the root cause and fixing it. Don’t be surprised if you have a lot of gray metrics. Due to Solution Manager’s expansive abilities to monitor a variety of applications, you inevitably end up with issues in Technical Monitoring.
This is normally due to organizations taking on more alerts than they have time to manage. This is why I recommend starting with a minimal number of alerts. Starting with only the alerts you absolutely need to keep a system running is critical to ensuring you don’t have a lot of false alarms coming from Solution Manager. Then, once you have all the issues worked out, expand upon what you have active. Following this advice will ensure your organization is getting the value it needs from Solution Manager.
Jereme Swoboda
Jereme Swoboda is an experienced SAP Solution Manager and NetWeaver consultant focusing on proactive technical monitoring of SAP and non-SAP systems, supporting critical business processes. He has tremendous experience pairing real-world scenarios with Solution Manager’s Technical Monitoring capabilities. He is an expert at collecting requirements, creating a monitoring strategy, and then putting that strategy to work for SAP customers. Jereme has had the opportunity to work on a variety of platforms for companies large and small integrating Solution Manager 7.1.
You may contact the author at jereme.swoboda@benimbl.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
