Better, Faster, and more Reliable problem resolution for distributed WebSphere Application Server
James D Austin 270000NYNH Comment (1) Visits (11602)
Problem identification and resolution efforts are made faster and more efficient by reducing the number of interactions required between the various groups that are involved in operations and support. This especially is true for interactions with IBM or other support organizations that involve creation of problem tracking and contact in an asynchronous mode by email, telephone or web session. Reducing the number of interactions needed to identify problems can be gained by experience. As the first time you resolve a problem you should then know what is needed to identify and resolve the problem in future. Or you may benefit from using the experience of others and save time and effort by collecting the information needed for problem identification and resolution. Fortunately, the experience of others is captured and available for use on the distributed platforms (Solaris, Linux, HPUX, AIX, and Windows) for WebSphere Application Server. Please review and bookmark this link: Read
The first order of business in problem resolution is to collect the needed information at the time the problem is happening. The needed information is very seldom entirely contained in the SystemOut.log. There are a great many logs and artifacts that will be produced if WebSphere Application Server detects an exception or an error. There are also many cases where you will need to request and capture other information in situations where an error or exception is not generated, such as performance issues. The links in the document above will cover all of these situations. In those cases that require a PMR (problem record or SR service request) to proceed, having the diagnostic information and a clear explanation of the problem to be resolved with the time line and the details will remove a number of time consuming communications by telephone, email, or screen shares between IBM and yourself to explain the problem, identify the diagnostic information to be collected, and then collect it. Given a long enough time span while communicating on what to collect and some diagnostic information may be deleted before problem investigation can begin.
In all cases it is usually true that the diagnostic information is much more informative if there is some context of the problem and its impact. The basic context information will always come down to what was noticed, when was it noticed, and what changed. Having the context aids in understanding what diagnostic files are needed and collecting them. As a best practice, it is always a good plan to know which files and what information to collect. IBM does provide a tool to collect the required diagnostic information. This tool is based on the default naming conventions and placement of artifacts and is therefore prone to failure in environments that have been customized by the System Administrators and WebSphere Administrators. It is also difficult to keep track of all virt
In those cases where there is no access to the online links for the documentation to be collected (secure environments or the links are down), there are some general guidelines on what diagnostic information to collect. There is also a good case to collect all information available, particularly for the first instance of a problem, in case the problem detected is not the root cause. For these reasons, the following information is given. WebSphere Application Server will produce the usual logs and all of them should be collected for any problem. There is also a "flight recorder" directory where some WebSphere Application components logs failure information that is in the ffdc (first failure data capture) directory. This information is often useful to resolve issues with those components. In addition, WebSphere will produce other flight recorder type information in many cases. These diagnostic files will vary by the version of Java™ (Oracle or IBM), the operating system, and the version of WebSphere in use. For WebSphere running on Oracle JAVA, there will usually be log entries in native_stdout.log for these artifacts. For IBM JAVA, the logging happens in native_stderr.log. FYI - these logs can contain quite a lot of information from a variety of source. You should also save any files that show up in your <WebSphere Home dire
Once the data is collected and the context is clear, you may use in-house expertise to resolve the issue or you may open a PMR with IBM to go forward with the resolution process. So, that is the essence of reducing the number of steps to resolve problems for WebSphere Application Server. In conclusion, please review and bookmark this link: Read