When technical issues occur with Studio Server or any of the client applications that are logged in to the server, logging can be enabled for troubleshooting purposes. The created log files store all SQL queries and Web service details.
|
Notes:
|
How it works
The working of this feature revolves around two areas:
- The location where the log files need to be stored. The log files are by default output to a local disk, but when multiple server instances are used, centralized logging can be enabled in order to output or stream errors, warnings and information about the use of deprecated features to a central location. This makes it easier and more efficient to detect problems from multiple servers from just one location.
- The level of detail that needs to be logged in the log files. This can range from errors that occur only in rare occasions to very detailed information for debugging purposes. This log level can be configured in two places:
- At server level in a configuration file.
- At user level on the User Maintenance page for that user.
When information needs to be written, the system uses the highest level of detail that is configured in either of these places.
Configuration
Logging is configured in three areas:
- Logging itself is enabled or disabled (by default it is disabled).
- When logging is enabled, the level of detail to log needs to be defined.
- When logging is enabled, centralized logging can be enabled (by default it is disabled).
Viewing log files
Log files that are stored on disk can be viewed directly from within the Maintenance pages of Studio Server.
Use case
A typical scenario for logging is to configure the system once and to then control the logging per user when needed through the Maintenance pages of Studio Server without having to touch the configuration files.
Each area is explained in more detail in the sections below.
Information detail
The most important aspect of the working of this feature is the level of detail that is logged and what effect the interpretation by the system of the configuration has on the actual output.
Available detail levels
The system is capable of logging information in various level of detail: from no information at all (level NONE) to detailed information for debugging purposes (level DEBUG).
The following table shows each of these levels, from lowest to highest.
| Log level | Description |
|---|---|
| NONE | No details are logged. |
| ERROR | Logs exceptional errors that in most cases stop execution. |
| WARN | Logs everything logged by ERROR plus warnings. Can be used to monitor potential problems. |
| DEPRECATED | Logs everything logged by ERROR and WARN plus the use of features that are deprecated. Can be used for compatibility checking. |
| INFO |
Logs everything logged by ERROR, WARN, and DEPRECATED plus operations that were successful. Can be used for analysis purposes. It also logs additional information related to licensing auto renewal. This makes it possible to log the renewal activities without having to switch to the higher-level DEBUG mode. |
| DEBUG | Logs everything logged by ERROR, WARN, DEPRECATED, and INFO plus details that can be used for debugging purposes by developers. |
Configuration options
The level of detail that should be logged is configured in two locations:
- Centrally in the DEBUGLEVELS option of the configserver.php file of Studio Server.
- Individually in the Log Levels field of a user in the User Maintenance page for that user.
This is done by defining / choosing one of the log levels described above such as NONE, INFO, DEBUG, and so on.
This setup makes it possible to define a general log level on the server and to then set a higher log level only for the users that experience technical issues when needed.
Applied log level
The configuration of the log level that is set for the server and the log level set for a user can either match each other or they could be different from each other.
Example: The log level for the server could be set to a lower level of detail (such as WARN) than the log level that is set for a user (such as INFO).
When the log levels are different, the highest level of detail is always used. This is referred to as the 'applied log level'.
This means that a message is only written to a log file when its log level matches the applied log level or the log level is lower than the applied log level, else it is ignored.
|
Examples:
|
Usage
By knowing that the system always takes the highest configured log level, the system can be configured for a production environment as follows:
- Set the DEBUGLEVEL for the server to a low level (anything lower than INFO).
- When logging is needed for one or more users because they are experiencing technical difficulties, temporarily set the Log Level option on their User Maintenance page to INFO or DEBUG.
Users for background processes
Processes that are run in the background are triggered by the current user or they can have a dedicated user defined. Think of processes such as Studio Server Jobs, MadeToPrint jobs, jobs for archiving to Assets Server, and so on.
Each of these users also exist in Studio Server and any log level that is set for that user can also influence the applied log level.
The following table shows the various background processes and the user that is taken into account when determining the log level:
| Background process | User |
|---|---|
| Studio Server Jobs | The configured user. This could also be the current or acting user such as for the ContentStation job type. |
| InDesign Server Jobs | The current or acting user. |
| MadeToPrint | The configured user. |
| Send to archive | The user configured for the SendToArchive server job. |
| Restore from archive | The current or acting user. |
| Smart Mover | The configured user. |
About the structure
Files are written to the logging directory in the following structure:
OUTPUTDIRECTORY > day > client IP
- ‘day’ directory: this represents the day (in YYYYMMDD format) on which a log operation took place. This bundles all logging operations on a daily basis, thereby making it easy to clean up. For example, you can throw away directories older than one week manually or by your home-brewed batch job.
- ‘client IP’ directory: this is created within the ‘day’ folder whenever logging was done in context of a certain client application. The client works from a certain IP address which is used as the folder name. Logging written for all applications working from that IP are bundled in this directory which makes it easy to for example identify problematic work stations. This directory contains HTML files (or text files) named after the PHP module used as entry point by the client application, or the name of the Web service requested.
Functionality
The way the system behaves very much depends on whether or not centralized logging is used. Because you will use either one method or the other, each is described separately in the following sections.
|
Info: Use the filter to only show the information for one method: |
Centralized logging disabled
In this scenario, centralized logging is disabled; all log files are output to a local disk.
Types of files that are logged
The following files can be found in the logging directory:
| Name | Details | Description |
|---|---|---|
| php.log | In the directory defined in OUTPUTDIRECTORY. | Indicates that a fatal error has occurred. The full context can be found in the file itself. |
| ent_log_errors.htm |
In a ‘client IP’ directory when the applied log level is INFO or DEBUG. Logs the following types of messages:
|
Indicates that an error has occurred for this client or that a feature has been marked as deprecated. The full context can be found in any of the logged files in the same folder. |
| phpinfo.htm |
This file always appears in the ‘day’ folder and in the ‘client IP’ folder. For performance reasons it is only generated once per day, just before the first server operation gets executed. The server log folder can be empty when the applied log level is NONE, no path is configured for the OUTPUTDIRECTORY option, the applied log level is ERROR but no errors have occurred, and so on. When no log files exist in the log folder, no phpinfo.htm file is available. If this information is needed or requested, access the Health Check page of Studio Server and click Config Overview in the menu. The HTML page shown can be downloaded via the Save As menu of your Web browser. |
Contains valuable information for analysis. When contacting WoodWing Support, make sure to include this file. |
|
sce_profile_mysql.htm sce_profile_mssql.htm |
Only available when the applied log level is INFO or DEBUG, and depending on the configuration of the PROFILELEVEL option. |
Server profile logs containing information about how long operations take and how much memory is used. |
| Log files with SQL statements |
Available depending on the configuration of the LOGSQL option. |
|
| Log files related to RabbitMQ services. |
Available depending on the configuration of the LOG_RABBITMQ_SERVICES option. |
Logs internal RabbitMQ Web services. RabbitMQ requests that are fired by Studio Server to RabbitMQ Server as well as the corresponding responses are logged. |
| Log files related to internal services |
Available depending on the configuration of the LOG_INTERNAL_SERVICES option. |
Logs internal Web services. The log files contain a PHP dump of request and response data. |
|
All web service requests and responses |
Available only when the applied log level is DEBUG. | The log files contain request and response data. |
Centralized logging enabled
In this scenario, centralized logging is enabled. Depending on the scenario and the applied log level, log messages are output or streamed to a central location or to local disk.
Fatal errors
When centralized logging is enabled, any fatal error messages that occur are streamed to the configured output stream / location.
Note: No php.log file containing these errors is generated (regardless of the applied log level).
Location of output files
Even when centralized logging is enabled, some files or messages are still stored to local disk. Which location is chosen depends on the applied log level.
When the applied log level is ERROR, WARN, or DEPRECATED, only messages of these levels are output to the central location:
| Severity of log message | Local disk | Central location |
|---|---|---|
|
ERROR WARN DEPRECATED |
No | Yes |
|
INFO DEBUG |
No | No |
When the applied log level is INFO or DEBUG, messages of these levels are output to the following locations:
| Severity of log message | Local disk | Central location |
|---|---|---|
|
ERROR WARN DEPRECATED |
Yes | Yes |
|
INFO DEBUG |
Yes | No |
Types of files that are logged
The following files can be found in the logging directory:
| Name | Details | Description |
|---|---|---|
| ent_log_errors.htm |
|
Indicates that an error has occurred for a client. The full context can be found in any of the logged files in the same folder. |
| phpinfo.htm |
This file always appears in the ‘day’ folder and in the ‘client IP’ folder. For performance reasons it is only generated once per day, just before the first server operation gets executed. Only available when the applied log level is INFO or DEBUG. The server log folder can be empty when the applied log level is NONE, no path is configured for the OUTPUTDIRECTORY option, the applied log level is ERROR but no errors have occurred, centralized logging is enabled but the log level is set to ERROR, WARN, or DEPRECATED, and so on. When no log files exist in the log folder, no phpinfo.htm file is available. If this information is needed or requested, access the Health Check page of Studio Server and click Config Overview in the menu. The HTML page shown can be downloaded via the Save As menu of your Web browser. |
Contains valuable information for analysis. When contacting WoodWing Support, please make sure to include this file. |
|
sce_profile_mysql.htm sce_profile_mssql.htm |
Only available when the applied log level is INFO or DEBUG, and depending on the configuration of the PROFILELEVEL option. |
Server profile logs containing information about how long operations take and how much memory is used. |
| Log files with SQL statements |
Available depending on the configuration of the LOGSQL option. |
|
| Log files related to RabbitMQ services. |
Available depending on the configuration of the LOG_RABBITMQ_SERVICES option. |
Logs internal RabbitMQ Web services. RabbitMQ requests that are fired by Studio Server to RabbitMQ Server as well as the corresponding responses are logged. |
| Log files related to internal services |
Available depending on the configuration of the LOG_INTERNAL_SERVICES option. |
Logs internal Web services. The log files contain a PHP dump of request and response data. |
|
All web service requests and responses |
Available only when the applied log level is DEBUG. | The log files contain request and response data. |
General notes
This section contains general information around server logging.
Flushing log messages
- When the applied log level is DEBUG, each message is flushed to disk to ensure that any problem is immediately visible. In the exceptional case where a web service execution makes the PHP process exit unexpectedly, it may be crucial to have the log information outputted just before such a fatal moment. Obviously, flushing each and every message to disk slows down the web service execution.
- The acting user is unknown at the very arrival of a web service request as the request data must be interpreted and validated first. Nevertheless, in the very first few milliseconds of a web service execution, log messages could already be sent for output. Without knowing the acting user, the applied log level is undetermined yet as the log level of the user is not yet resolved.
To bridge this moment, DEBUG is assumed and logs are cached in memory. Once the user is known, the applied log level is determined and cached messages are flushed to output based on the latest resolved applied log level. This mechanism applies to both the log disk and the centralized logging system. This happens for most of the web services, except for the following:
- For LogOn requests no session yet exists and the user is determined much later (compared to other services).
- For the GetServers request no ticket is required and the acting user therefore remains unknown. For this service the acting user could not be resolved and therefore the log level configured for the acting user is ignored and it falls back to the log level configured for the DEBUGLEVELS option.
Running the Health Check
- When running tests on the Health Check page and log files are required for further assistance or analysis, it is advisable to set the log level in the DEBUGLEVELS option while setting the log level on the User Maintenance page for the user defined in the TESTSUITE option to NONE.
- The log level that is used depends on the version of Studio Server that is used.
- For Studio Server 10.4 to 10.22, the used log level depends on whether or not the test performs a LogOn request:
| LogOn request used | Log level used |
|---|---|
| No | The log level from the DEBUGLEVEL option is taken. |
| Yes | When the user that is defined in the TESTSUITE option has a more detailed log level set than configured in the DEBUGLEVELS opiont, then the log level set for the user level is taken. That particular test case then has a different log output than the test cases that do not perform a LogOn request. |
- For Studio Server 10.23 or higher:
- The log level from the DEBUGLEVEL option is taken.
Comment
Do you have corrections or additional information about this article? Leave a comment! Do you have a question about what is described in this article? Please contact Support.
0 comments
Please sign in to leave a comment.