You have got your X3 Version 12 system working, but either want to understand how something works in more detail or are now seeing some issue which you need to investigate further.
In order to understand what is going on within your X3 system you want to enable additional logging, but what logging is available and is it useful to enable for your particular issue? My ambition in this article is to answer these very questions!
I am assuming you will be using X3 Version 12, although previous versions will work in a very similar fashion.
NOTE: This article discusses the logging available through the Syracuse web server. To get logging for Classic processes themselves you may want to consider running an Engine Trace, described in KB article "How to run an Engine trace in Sage X3" If you need a complete SQL trace, you can find the details in KB article "How to generate a SQL trace for one user session"
Before you begin
Read through the articles highlighted in the “Related Articles” (below) as these will give you most of the basics first, as I am not repeating here what is discussed in these previous articles.
Warning
When you modify Syracuse logging levels (In the “Global Settings” function), the changes take effect immediately and effect all connected sessions as well as new sessions. You therefore need to be cautious on LIVE systems not to increase logging so much such that it will impact performance and/or run your server out of disk space!
What is the impact of the different logging levels?
The different logging levels in order of how much detail it generates are Error, Warning, Info, Debug and Silly.
Exactly what messages are logged at each logging level for each area of code is decided on by the individual developers (conforming to Sage programming standards), so is difficult to give general guidelines on exactly what you should expect to see in different areas. For example, sometimes setting logging to “Silly” will not provide additional details, sometimes nothing much is logged unless you go to at least “Debug” level. You can of course experiment to see what logging level gives you the level of detail you need in your TEST system, before implementing on a LIVE system.
What additional logging to enable?
It depends on what you are trying to achieve and what the circumstances are. In general, if you have a test system where you want to diagnose an easily reproduceable problem, you could enable a lot of “Debug” level logging, but if you have an intermittent issue which you only see on your LIVE server, then you might want to start with enabling the minimum number of areas at “Info” level before then considering increasing logging only if the initial additional information you selected is not useful.
The “code” used in the “Server Logs” section is fairly self-explanatory but have tried to list below the areas in which I have often found useful to consider enabling more detailed logging for. I normally start with Info or Debug level depending on what I am looking for, then adjust further if necessary.
Logging to consider as generally useful for various situations
--- http.in
--- http.out
--- loadBalancer.http
--- loadBalancer.main (Only debug level is useful)
--- loadBalancer.mock (Only debug level is useful)
--- loadBalancer.session (Only debug level is useful)
Logging to consider for anything to do with classic sessions (Users, Batch, SOAP)
--- x3Comm.client
--- x3Comm.conn (No longer there from V12 p27)
--- x3Comm.dispatcher
--- x3Comm.gateway
--- x3Comm.jsRunner
--- x3Comm.loadBalancer (No longer there from V12 p26)
--- x3Comm.pool (No longer there from V12 p27)
--- x3Comm.runtime (Introduced in V12 P26+)
--- x3Comm.sadfsq
Logging to consider for specific areas of functionality
User login/session issues
--- login.accessRights
--- login.authentication
--- login.user
--- login.saml2 (If using SAML2)
--- session
Batch Server
--- batch
Webservices SOAP calls
--- soap.classic
--- soap.request
--- soap.server
--- x3Comm.soap
Webservices REST calls
--- rest
X3 Services (New ADC) issues
--- etna
MTD issues
--- sage-rr
Elastic Search
--- search
Patching
--- patch
--- x3Comm.patch
Printing
--- x3Comm.print
Syracuse Administration data Import / Export processes
--- exports
--- imports
Issues with LDAP import process
--- ldap.import
MongoDB data being corrupted
--- orm.mongodb
When to disable the additional logging you implement
For LIVE systems, you should certainly be aiming to only have the additional logging running for the minimum time that is needed to achieve your objective. This is so there is no unnecessary overhead on the system caused by needless logging, but also to ensure log file sizes are kept to a minimum as these can grow very large potentially (depending on your configuration of course) or even worse you may lose the log files you need due to the automatic log file archiving/sizing.
The same principles do also apply to TEST systems, but assuming the TEST server is less used you can generally be more relaxed about how much logging is turned on.
Related articles
Should I change the Default Syracuse Logging?
Understanding and troubleshooting Sage X3 "Updates" patching mechanism
Conclusion
I hope this article has given you some tips on when and what logging may be useful to you in various circumstances.