h3. Introduction In one of my previous blogs ({code:html}Java Earlywatch Alert report - Is it telling the truth ?{code}) I wrote about the misleading message a Java Earlywatch Alert report can give to the receiver, everything is fine (green light) while it might not be the case at all. Now I’m back to provide you with information on how to fix the issue (and other related issues) which I discussed in the previous blog so you can hopefully see a truthful result in the end. The information provided is from Wily Introscope 8.2.2.0 (ISAGENT 8.2.2.0) and SMD Agent 7.11. There might be minor differences in other versions but the logics to find the root cause stay the same. The example SAP system is a SAP Netweaver BI 7.0 EHP1 (Kernel 701) residing on HP/UX. h3. Troubleshooting guide You can already solve certain issues by following the Wily Introscope troubleshooting guide on SAP service marketplace under https://service.sap.com/diagnostics (https://service.sap.com/diagnostics) --> media library or through {code:html}SAP Note 797147 - Wily Introscope Installation for SAP Customers{code} which contains an attachment "IntroscopeFAQ.pdf".
h3. Solving issues h4. Double values in EWA
picture 1.1 In the Earlywatch alerts I checked at our customer side, double values existed (see picture 1.1). {code:html}SAP Note 1392762 - RSDRI_INFOPROV_READ_RFC does not aggregate usg.InfoProviders{code} can possibly solve this issue (it did for me). Also don’t forget to check the related notes as those point out some other SAP notes that are relevant to specific Java Earlywatch Alert issues (wrong values being reported etc). h4. Zero values in EWA 
picture 1.2 Zero values can also exist on metrics that shouldn’t be zero (see picture 1.2), for example %time spent on GC (garbage collection). h5. Introscope metrics The garbage collection time placed on the Java Earlywatch alert is fetched from BI Infocube 0SMD_PE2H and the metric used (metric name) is *% GC TIME (LAST 5 MINUTES)*.{code:html}SAP Java Administration - Troubleshooting part III - Java VM settings basics{code}. For the example the SAP system resides on HP/UX and the parameters are in place: -XX:+PrintGCTimeStamps
-XX:+PrintGCDetails Make sure you don’t have other (none recommended) Platform JDK or SAP JVM parameter settings in place that redirect the garbage collection to another filename (such as –Xloggc). The file std_dispatcher.out also contains entries so the file itself is not the root cause of the problem (in this example). h5. SMD agent logs One of the best sources to track down and fix issues with diagnostics are the log files of the *Solution Manager Diagnostics agents*. I do advice you set the *log level* to *debug* to see sufficient information. Go to transaction solman_workcenter and click on the root cause analysis tab. Next click on agent administration in the left pane. In the Agent Administration application click on the tab Agent Log Viewer. Once you are in the tab you will have to select the agent of which you want to check the log files. Select the agent of the managed SAP system which has issues and click on Display.
picture 1.7 Next change the Log Location to SMDAgentApplication..log (see picture 1.7). 
picture 1.8 Now change the Log Level Control dropdown from to Debug as shown in picture 1.8 and click Apply. Now you should get the logging of the SMDAgentApplication in debug level (lots of information), refresh from time to time to check for errors or leave it running for a bit and check for errors. Problems reading the garbage collection logs can exist because of the access rights on the garbage collection logs. {code:html}SAP Note 1163751 - E2E Root Cause Analysis required standard UMASK 027{code} gives information on the rights which are needed on the relevant files/filesystems. h3. Extractor framework Another application in which you should check the logs is the Extractor FWK (framework) Administration. It holds the logging of the relevant SAP jobs extracting the data for the different areas of root cause analysis (workload analysis, change analysis and so on). I’m not going to go into detail on this part as it is well documented. When you have issues with a managed SAP system you can go on the tab Managed System, select or type your SAP system SID in the input field, click on select and then click on the Show Log button under the Logging header to the right. This opens up a screen with loggings from all jobs running for the managed SAP system. h3. Want less issues, start patching Something which is very much true for most of the SAP products, want to have less issues, start patching. Often the customer doesn’t like this recommendation that much though as it requires downtime and possibly requires some functional test to be performed after the patching. This is certainly the case for SAP Solution Manager and definitely for the diagnostics scenario. You are better off with a SAP Solution Manager that has the latest support package stack in terms of encountering issues. h4. The confusion starts again Seriously as if the product naming isn’t enough, there are also aliases for the components. The java component which is used for the diagnostics scenario is LM-SERVICE. 
picture 1.9 On picture 1.9 you can see the relevant component line from the Java component page listing. The numbering 7.01.7.2 extracted from the long number means the following: 7.01 for SAP Netweaver 7.0 EHP1 Support Package stack 7 patch level 2. The patch level 2 means that there bug fix patch 2 is installed. You can see it as an equivalent of applying SAP notes in the ABAP stack. 
picture 2.0 
h3. Solving issues h4. Double values in EWA
picture 1.1 In the Earlywatch alerts I checked at our customer side, double values existed (see picture 1.1). {code:html}SAP Note 1392762 - RSDRI_INFOPROV_READ_RFC does not aggregate usg.InfoProviders{code} can possibly solve this issue (it did for me). Also don’t forget to check the related notes as those point out some other SAP notes that are relevant to specific Java Earlywatch Alert issues (wrong values being reported etc). h4. Zero values in EWA picture 1.2 Zero values can also exist on metrics that shouldn’t be zero (see picture 1.2), for example %time spent on GC (garbage collection). h5. Introscope metrics The garbage collection time placed on the Java Earlywatch alert is fetched from BI Infocube 0SMD_PE2H and the metric used (metric name) is *% GC TIME (LAST 5 MINUTES)*.{code:html}SAP Java Administration - Troubleshooting part III - Java VM settings basics{code}. For the example the SAP system resides on HP/UX and the parameters are in place: -XX:+PrintGCTimeStamps-XX:+PrintGCDetails Make sure you don’t have other (none recommended) Platform JDK or SAP JVM parameter settings in place that redirect the garbage collection to another filename (such as –Xloggc). The file std_dispatcher.out also contains entries so the file itself is not the root cause of the problem (in this example). h5. SMD agent logs One of the best sources to track down and fix issues with diagnostics are the log files of the *Solution Manager Diagnostics agents*. I do advice you set the *log level* to *debug* to see sufficient information. Go to transaction solman_workcenter and click on the root cause analysis tab. Next click on agent administration in the left pane. In the Agent Administration application click on the tab Agent Log Viewer. Once you are in the tab you will have to select the agent of which you want to check the log files. Select the agent of the managed SAP system which has issues and click on Display.
picture 1.7 Next change the Log Location to SMDAgentApplication..log (see picture 1.7). picture 1.8 Now change the Log Level Control dropdown from to Debug as shown in picture 1.8 and click Apply. Now you should get the logging of the SMDAgentApplication in debug level (lots of information), refresh from time to time to check for errors or leave it running for a bit and check for errors. Problems reading the garbage collection logs can exist because of the access rights on the garbage collection logs. {code:html}SAP Note 1163751 - E2E Root Cause Analysis required standard UMASK 027{code} gives information on the rights which are needed on the relevant files/filesystems. h3. Extractor framework Another application in which you should check the logs is the Extractor FWK (framework) Administration. It holds the logging of the relevant SAP jobs extracting the data for the different areas of root cause analysis (workload analysis, change analysis and so on). I’m not going to go into detail on this part as it is well documented. When you have issues with a managed SAP system you can go on the tab Managed System, select or type your SAP system SID in the input field, click on select and then click on the Show Log button under the Logging header to the right. This opens up a screen with loggings from all jobs running for the managed SAP system. h3. Want less issues, start patching Something which is very much true for most of the SAP products, want to have less issues, start patching. Often the customer doesn’t like this recommendation that much though as it requires downtime and possibly requires some functional test to be performed after the patching. This is certainly the case for SAP Solution Manager and definitely for the diagnostics scenario. You are better off with a SAP Solution Manager that has the latest support package stack in terms of encountering issues. h4. The confusion starts again Seriously as if the product naming isn’t enough, there are also aliases for the components. The java component which is used for the diagnostics scenario is LM-SERVICE. picture 1.9 On picture 1.9 you can see the relevant component line from the Java component page listing. The numbering 7.01.7.2 extracted from the long number means the following: 7.01 for SAP Netweaver 7.0 EHP1 Support Package stack 7 patch level 2. The patch level 2 means that there bug fix patch 2 is installed. You can see it as an equivalent of applying SAP notes in the ABAP stack. picture 2.0
6 Comments
