Tracing, Logging and Troubleshooting 3.7

Editor's Notes

• #3: The goals of this lesson are to provide users with an understanding of how to setup logging inside of Neuron ESB as well ahs how to use logging in both business processes and workflow definitions. We will also be looking at how to troubleshoot installations of Neuron ESB that may encounter errors.
• #4: To facilitate our goals this lesson has been broken down into four sections to make the information easier to understand. The sections that we will be covering are Configure logging in Neuron ESB View Neuron Event and Trace logs Using Code Editors to log from Business Processes and Workflows Learn how to troubleshoot Neuron ESB installations
• #5: The logging level used by the Neuron ESB instance can be configured via the logging tab of the configure server dialog window in the Neuron ESB Explorer. By default the Trace Level value is set to Verbose, but can be changed using the Trace Level drop down list. Changing these values will set the appsettings and system.diagnotics section of the esbservice.exe.config file as well as the corresponding system.diagnotics setting in the Neuron ESB Explorer and Test Client app.config files.
• #6: On the left you will see the values for logging as they appear in the appsettings section of the esbservice.exe.config file. Notice that all the same values that appear in the configure server dialog window appear here except the Trace Level. That value is contained in the system.diagnotics section as shown on the right. Each numerical value corresponds to a Trace Level in the Neuron ESB Explorer, which is outlined in the comments section.
• #7: The Neuron ESB Event log is usually the first place you will go when you notice that an error has occurred in your Neuron ESB instance. This log usually provides a summary of the issue that is occurring and points you in the direction of which log file to look at for more detailed information about the error. The application event log is most commonly written to by any application implementing the Neuron Client API, such as the Test Client or custom .NET applications. You will also find service crashes written by SCM appear in this log file as well. Both the Neuron ESB event log and the Application Event log can be accessed via the Servers selection of the Deployment tab of the Neuron ESB Explorer.
• #8: The Neuron ESB event log will contain information regarding the Neuron ESB runtime, Neuron ESB endpoint hosts, the Neuron ESB discovery service as well as other information such as when a subscriber is not online to receive a message, an error occurred on a topic or endpoint etc.
• #9: The Neuron ESB trace logs contain detailed information about the entities in your Neuron ESB solution. These files contain everything that appears in the Neuron ESB event log, along with additional information, depending on your configured logging level. These files are most commonly used by the product team to diagnose errors in a solution, and it is a good idea to become familiar with them and the information they contain. While there is a single logs folder, each instance of Neuron ESB installed an a machine will have it’s own master folder inside the logs folder where these log files can be found. The logs folder is located at <Neuron Install Folder>\Neuron ESB v3\logs.
• #10: Nearly every entity in your Neuron ESB solution will have it’s own log file. From adapter endpoints, to service endpoints, to every topic and every service that Neuron ESB relies on to operate, such as the discovery service, the configuration service and the management service. While it might seem a bit overwhelming at first, it is far easier to locate an error which occurred in an adapter endpoint in a file dedicated to that adapter, then it would be to locate it in a file which contained information about every adapter in your solution.
• #12: In addition to the base logging provided by Neuron ESB, it is possible to write your own custom information to the Neuron ESB log files from a business process. This is achieved either via the Trace process step, or in the language editor process steps. The trace process step writes the body of the message as an information level record. At design time it will put that information in the output window of the Neuron ESB Explorer Business Process Designer. At runtime these records will be written to the log file of the endpoint hosting the party which hosts the business process. Neuron ESB will respect the logging level when considering whether or not to write a trace step record to the log file. Meaning that if your instance is set to record errors and warnings only, the trace step records will not appear in the log files, but will still output to the output window at design time. Trace methods called from inside the language editors operate in much the same way as the trace process step. The major difference being that you can set what level the record is considered, where as the trace process step records are always considered informational. Trace methods used in the language editors write to the output window and log files the same as the trace process step and respect the logging level of the instance in the same manner as well.
• #13: Like business processes workflows also allow for messages to be written to the log files using language editors. The Log methods of the workflow language editors works in the exact same way as the trace methods of the business processes language editors, writing both to the output window or appropriate log file, and respecting the logging level of the Neuron ESB instance.
• #14: WCF Tracing, which is configured on the logging tab of the configure server dialog window, provides internal WCF logging for each Neuron service. When turned on a separate WCF log file will be generated for each corresponding Neuron ESB trace log file. These WCF log files provide information on the WCF connection as well as error details at the channel level. Though rare, sometimes WCF does not bubble up error information to a level where it can be captured by Neuron ESB and written to the trace log files and these WCF log files will capture that information. However, the WCF log files generate an enormous amount of data very quickly and so it is recommended that you not leave this option selected for too long a period of time.
• #15: Sometimes it is necessary to centralize all the Neuron ESB trace logs to a central file share. For example if you are running multiple instances of Neuron in a farm, all with the same solution you may want all the log files for that solution in the same place and not spread out across the farm. In order to do this you will need to change a few registry settings on each machine to the location where you want the logs to be placed. Once you have the logs going to the desired location, whether that be the default location or one of your choosing, you should decide how often, in days, you would like Neuron to clean out the old log files.
• #16: While Neuron ESB is incredibly easy to install, from time to time one might encounter and issue with the installation process. The most common issues to run into are an invalid license key error, the setup files fail to copy to the machine, or the services fail to start up. Each of these is easy to troubleshoot and resolve in their own right.
• #17: If you receive an invalid license key error, the first thing to do is ensure that the license key is correct and the one provided to you by the Neuron ESB team. If after having done that, you are still receiving the same error look at your group policies and see if FIPS is enabled on your machine. Disable FIPS and retry the Neuron ESB installation.
• #18: In the case of the setup files failing to copy or the services failing to start, Neuron ESB generates a log file in the Temp directory during installation that will inform you of any errors that it encountered during the installation. Look at the log file to determine what the cause of the error was. To generate a detailed log file during installation to help you track down any errors that occur you can run the MSI command line provided.