Secure Global Desktop 4.40 Administration Guide > SGD Servers, Arrays, and Load Balancing > Using Log Filters to Troubleshoot Problems With an SGD Server

Using Log Filters to Troubleshoot Problems With an SGD Server

When you first install SGD, the default log filters log all errors on the SGD server. If you want to obtain more detailed information, for example to troubleshoot a problem, you can set additional log filters. You can set additional log filters as follows:

Type the filter in the Log Filter field on the Global Settings » Monitoring tab of the SGD Administration Console
Each filter must be separated by a RETURN.
Use the following command:
```
$ tarantella config edit --array-logfilter filter ...
```
Each filter must be separated by a space.

Each filter has the form:

component/sub-component/severity:destination

The options for each part of the filter and how you view the log output are described in the following sections.

Note Log filters can create large amounts of data. It is good practice to set as specific a filter as possible and then remove the filter when you have finished with it.

Selecting a Component and Sub-component

Selecting a component and sub-component allows you to choose the area of information you want to log from the SGD server. The table below shows the available component/sub-component combinations and an explanation of the kind of information produced.

Component and Sub-Component	Information Provided
`audit/glue`	Audit of changes made to the SGD server configuration or to your local repository configuration and who made the changes. Example use: to find out who made changes to a user profile object.
`audit/license`	License use across an array of SGD servers. Example use: to find out why the use of licenses is not being recorded.
`audit/session`	Starting and stopping user sessions and application sessions. Example use: to find out how long a user had a running application session.
`cdm/audit`	Authorization of SGD user for client drive mapping (CDM) purposes. Example use: to find out whether a user's credentials are causing CDM to fail.
`cdm/server`	Information about CDM services. Example use: to find out whether a client connection error is causing CDM to fail.
`common/config`	How SGD server configuration is stored and copied across the array. Example use: to find out why a global setting configuration change is not being applied to an SGD server.
`metrics/glue`	Memory and timings. Example use: to find out how long it took to run an SGD command.
`metrics/soap`	The SOAP component of Tomcat's SOAP proxy. Example use: to trace how long it took a SOAP request to finish.
`server/billing`	SGD billing services. Example use: to find out why billing data is being lost.
`server/common`	General SGD information. Example use: to troubleshoot DNS errors.
`server/config`	Changes to SGD server configuration. Example use: to log changes to SGD server configuration or to find out if the configuration has become corrupt.
`server/csh`	The SGD client session handler. Example use: to find out why a user can not re-start an application session.
`server/deviceservice`	Mapping of users to accessible device data. Example use: to find out why a user can not access client drives.
`server/diskds`	Information about the local repository. Example use: to get information about corrupt objects or inconsistencies in the local repository.
`server/glue`	The Secure Global Desktop ASAD protocol used for communication between SGD servers. Example use: to find out why SGD servers cannot communicate.
`server/install`	Installation and upgrades. Example use: to investigate problems with an installation.
`server/kerberos`	Windows Kerberos authentication. Example use: to find out why an Active Directory user cannot log in.
`server/launch`	Launching or resuming applications. Example use: to find out why a user cannot launch an application.
`server/ldap`	Connections to an LDAP server. Example use: to find out why an LDAP user cannot log in.
`server/loadbalancing`	User session and application load balancing. Example use: to find out why an SGD server is not selected to host application sessions.
`server/logging`	Logging. Example use: to find out why log messages are not being written to a file.
`server/login`	Log in to SGD. Example use: to find out which authentication mechanism authenticated a user and the user profile used.
`server/mupp`	The SGD MUPP protocol. Example use: Only use this filter if Support ask you to.
`server/printing`	SGD printing services. Example use: to find out why print jobs are failing.
`server/replication`	Copying data between SGD servers in an array. Example use: to find out why data has not been copied between array members.
`server/securid`	Connections to SecurID RSA Authentication Manager. Example use: to find out why SecurID authentication is not working.
`server/security`	Secure SSL-based connections. Example use: to find out why the SSL Daemon is not running.
`server/server`	The SGD JServer component. Example use: to troubleshoot SGD server failures, such as Java™ runtime exceptions which are not logged elsewhere.
`server/services`	Internal SGD server services. Example use: to find out why a service is failing.
`server/session`	User sessions. Example use: to find out why a session failed to suspend.
`server/soap`	SOAP bean interface Example use: to diagnose problems with the SOAP beans.
`server/soapcommands`	SOAP requests. Example use: to log the SOAP requests received.
`server/tier3loadbalancing`	Application server load balancing. Example use: to find out why a host is not being selected to launch an application.
`server/tokencache`	Authentication token cache. Example use: to find out why an authentication token is not being created for a user.
`server/tscal`	Windows Terminal Services Client Access Licenses (CALs) for non-Windows clients. Example use: to find out why a non-Windows client does not have a CAL.
`server/webtop`	Webtop content. Example use: to find out why an application is not appearing on a user's webtop.

Selecting the Severity

You can select one of the following levels of severity for each log filter:

Severity	Description
`fatalerror`	Logs information on fatal errors. Fatal errors stop the SGD server from running. When you first install SGD, all fatal errors are logged by default.
`error`	Log information on any errors that occur. When you first install SGD, all errors are logged by default.
`warningerror`	Log information on any warnings that occur, for example if system resources are running low. When you first install SGD, all warnings are logged by default.
`info`	Informational logging. Useful for problem solving and identifying bugs.
`moreinfo`	Verbose informational logging.
`auditinfo`	Logs selected events for auditing purposes, for example changes to SGD server configuration. For details see, Using log filters for auditing

The fatalerror severity produces the least amount of information and the moreinfo severity produces the most.

Selecting a severity level is not cumulative. For example, selecting info does not mean you also see warning, error or fatalerror log messages. To log more than one level of severity, use a wild card (see below).

Using Wildcards

You can use a wildcard (*) to match multiple components, sub-components and severities. For example, to log all warning, error and fatal error messages for printing, you could use server/printing/*error.

Note If you use a wildcard on the command line, you must enclose the filter in quotes to stop your shell from expanding them.

Selecting a Destination

When selecting a destination for the logs, you can specify that the output goes to the following:

A log file
A log handler

These destinations are described in the following sections.

Using Log Files

If you direct the output to a log file, you can output to two types of file:

filename.log
SGD formats this log output so that it is easy to read.

This format is required by the tarantella query errlog command. This command only searches log files that have names that end error.log.
filename.jsl
SGD formats this log output for automated parsing and searching.

This format is required by the tarantella query audit command.

The file extension of the destination file controls the format of the file.

You can also create a separate log file for each process ID by including the %%PID%% placeholder in the file name.

The log files are output in the /opt/tarantella/var/log directory. You cannot change the location of the log files, but you can use a symlink to redirect the logs to a different location. Alternatively, you can use the syslog log handler described below.

Using Log Handlers

A log handler is a JavaBeans component used as the destination for the log messages. When specifying a log handler, you must use its TFN name. SGD provides the following two log handlers:

ConsoleSink
SyslogSink

The ConsoleSink writes log messages in a easy-to-read format to standard error. This log handler is enabled by default and logs all errors. The TFN name of this log handler is:

.../_beans/com.sco.tta.server.log.ConsoleSink

The SyslogSink writes log messages to the UNIX or Linux platform syslog facility. The TFN name of this log handler is:

.../_beans/com.sco.tta.server.log.SyslogSink

Example Log Filters

Here are some examples of commonly used log filters:

To debug user logins:

server/login/*:login%%PID%%.log
server/login/*:login%%PID%%.jsl

To troubleshoot client drive mapping:

cdm/*/*:cdm%%PID%%.log
cdm/*/*:cdm%%PID%%.jsl
server/deviceservice/*:cdm%%PID%%.log
server/deviceservice/*:cdm%%PID%%.jsl

To troubleshoot printing problems:

server/printing/*:print%%PID%%.log
server/printing/*:print%%PID%%.jsl

To get timing measurements for server performance:

metrics/*/*info:metrics.log
metrics/*/*info:metrics.jsl

To send all warnings, errors and fatalerrors to syslog:

*/*/*error:.../_beans/com.sco.tta.server.log.SyslogSink

Viewing Log Output

To view the log output, you can either of the following:

Open the .log files in a viewer or text editor
Use the tarantella query command

If you use the tarantella query command, use the following command options:

tarantella query errlog - to see only the errors and fatalerrors for specific SGD server components
tarantella query audit - searches the logs for any messages relating to a person, an application or an application server

Note You can only use these commands to view the log output until the logs are archived. You configure archiving when you install SGD but you can change the settings at any time by running the tarantella setup command.

Related Topics
Using Log Filters for Auditing