How do I Collect TeamConnect Logs?
This guide will give a brief summary of the most commonly used logging views and how/when to set the logging levels to DEBUG in order to gather information that is not readily available by the ERROR level logger. INFO, WARN, and FATAL are not logging levels that are generally used, so this guide will focus on ERROR and DEBUG levels.
NOTE: ALWAYS REMEMBER TO SET THE LOGGING LEVEL BACK TO ERROR AFTER GATHERING DEBUG LOGS
How to get to the Logging Page
1. Navigate to your instance’s Admin tab.
2. Expand the Logging tab, and click System.
3. At the bottom of the page, in the ‘System Appenders’ block, you will see a group of logs. Click the clear link next to the ‘Default’ log. Not doing this can result in a very large log file, which will may make it more difficult to send and for your Support Engineer to diagnose the issue.
4. At this time, perform the action which originally triggered the error. The logger will record the system output.
5. Return to the Logging page and click View Log next to the Default log. This will open the log file in a new tab. Right click and Save As to download the .txt file, which you can then attach to your case for further troubleshooting.
If you are running on a cluster, a drop-down list to the left of the View Log link allows you to choose the specific node whose log you wish to view. You may need to save both nodes if you are unsure which one you are on.
For any questions on the logging levels see In TeamConnect system logs, what do “INFO”, “ERROR”, “WARN”, “FATAL” and “DEBUG” mean?
Most Commonly Used Logging Views
| ROOT | General System Logger |
| Set to DEBUG if you do not know where the error you're receiving is coming from. This logger is the most likely to crash your system if left on DEBUG for too long | |
| REQUEST | Identify webservice calls sent to TeamConnect |
| DEBUG when you want to get a full breakdown of calls that are coming into TeamConnect as well as point of failure | |
| RESPONSE | Identify webservice calls sent from TeamConnect |
| DEBUG when you want to get a full breakdown of the calls being sent out of TeamConnect as well as point of failure | |
| SQL | Identify the SQL that is being run by reports/searches/updates |
| DEBUG will need to be used to gather SQL statements, as most SQL logging is turned off at the ERROR level. This is the second riskiest logger to leave on DEBUG so remember to set it back to error. | |
| RULE | Identify custom rule statements |
| DEBUG will show specific debug statements written into the custom rules. ERROR will generally just tell you what rule is running. DEBUG helpful for identifying point of failure in the rule | |
| XML | Identify actions being taken when working with the XML worksheet. |
| DEBUG if you are experiencing issues with the XML worksheet or custom rules that use XML in their logic |
System Appenders and Gathering Logs
| Default | Full Log file. Useful when looking for general failure. First place to check if you are lost |
| CSM Appender | Only logs related to CSM sync. Use this when trying to diagnose issues with the CSM sync. Most CSM sync errors will show up in default logs, but these make it easier to find. |
| XML Appender | Only logs related to XML. XML logs often do not show up in default logs, so if you're having trouble finding them there, look here. |
General Logging Etiquette
- If possible reproduce in Non-Production environment
- Clear logs and set appropriate logging levels
- Reproduce error
- Capture logs (input into a .txt file)
- Attach Logs with any relevant screenshots and a descriptions of the error
- If you can only reproduce in PROD
- If possible clear the logs and have the user reproduce the error
- Provide logs to support and indicate the username of the user experiencing the error and a rough time stamp of when the error occurred.