Skip to Content

Java Earlywatch Alert Report – Make it tell the truth

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 (ISAGENT 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 ( –> 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 double values 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 zero values 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. log location picture 1.7 Next change the Log Location to SMDAgentApplication..log (see picture 1.7). log level debug 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. LM service picture 1.9 On picture 1.9 you can see the relevant component line from the Java component page listing. The numbering 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. solution manager diagnostics picture 2.0 bug fix patch 2

You must be Logged on to comment or reply to a post.
  • Well done. There's enough material here for several blogs.

    I was especially glad to see how to remove the annoying doubled rows in EWA. I had mistakenly assumed that would eventually be fixed in an SPS update but couldn't understand why it was taking them so long to fix it.

  • ... and a confirmation for me that our decision of NOT implementing EWA (for both ABAP + Java) is still valid; just too much efforts and fiddling for a word document with nice graphics.

    Too many notes and wily and smd agent versions need to match to each other, the technical dependency factor of all components is high, too high to be handled automatically and too high to be re-matched manually after a support package implementation on either SolMan and/or external systems - for us. Your mileage may vary.


    • Hello Markus

      I also have doubts on the fact that diagnostics scenario lowers TCO 🙂

      It has come in handy for me in troubleshooting situations (combination of Wily Introscope and root cause analysis tools) so I do find it to have value but the product still needs to be improved.

      One of the things which annoys me the most is the need for a system stop/start after running a managed system setup.

      It might not be a problem when you have 3 SAP systems running but when you have 200 SAP systems running it becomes an issue.

      I have heard the SMD agents will be used in future Solution Manager scenarios besides diagnostics and it does make sense as the new version of SMD Agent is a mini SAP system (using SAPJVM) it would be a good choice to centralize/replace smaller existing agents by one agent.

      Kind regards


      • The main issue starts for us with ST/A-PI on ABAP systems, then the fact, that the "wily autoprober" is delivered for Sun JDK and not for the IBM JDK (we're on Linux) so each time we do a "setup" we have to regenerate the autoprobe again on more than 30 systems.

        So the method of installing/updating/applying patches to SMD is changed again? Even if it's a mini system using SAPJVM it's just too much to handle for an avg. system admin whose resources are limited. I've got usually too much production work to do than messing with "gimmicks" 😉 Let's see what will evolve.