Release 4.3’s diagnostics logging changes

Introduction


Diagnostics logging is one of the most useful features to investigate problems when something doesn’t behave the way it should be, either it is an SSO flow, an STS token request, or a REST API call. While the feature is not a new thing in Identify, we have improved the user experience aspect by adding support for configuring it via Identify*Admin instead of having to modify configuration files. In addition, all log folders for Identify*Admin and Identify*Runtime are now put in the same folder of the tenant. Finally, the Safewhere event log can be shown in the Source field of a logged item name of the tenant from which it is logged. This is a big help when deploying where multiple tenants are running on the same server.

Enable/Disable Diagnostics Logging via Identify*Admin UI


You can find the UI under System Setup -> Troubleshooting tab.

Troubleshooting_tab

1. Log Level – Runtime

This setting is used to set up the diagnostics log level for Identify*Runtime. The supported levels are:

  • Verbose: Equivalent to the Debug level. All the tracing messages are logged.
  • Information: Only tracing messages that have business meaning are logged.
  • Error: Only errors and exceptions are logged.
  • Off: No messages are logged at all.

When troubleshooting a problem or when running on a test environment, the recommended setting is Verbose. Otherwise, the recommended setting is Error or Off.

2. Log Level – Admin

Similar to the Log Level setting for Runtime, but this is used for Identify*Admin.

3. Enable WCF tracing log – Runtime

When ticked, WCF tracing log is enabled on the Runtime site. Some of the WCF-powered services include Identify*STS, SAML 2.0 Artifact resolution service, SAML 2.0 SOAP logout service, and SAML 2.0 Attribute query service.

4. Enable WCF tracing log – Admin

When ticked, WCF tracing log is enabled on the Runtime site. The only WCF-powered service that is hosted in Identify*Admin is SMPL service.

5. Enable REST APIs verbose error to client side

When ticked, error responses that are sent to client side are contained verbose messages.

6. Enable Identify*STS verbose error to client side

When ticked, error responses that are sent to client side are contained verbose messages.

New Default Logging Folder


Each site of an Identify tenant used to have a log folder inside the site’s own folder: Admin’s log folder is “LogFiles” while Runtime is “Diagnostics”. In addition, WCF log files are usually put somewhere else. In version 4.3, we have revamped the log folder structure so that all the folders are put under the [tenant]\Logs.

new_defaut_logging_folder

Source Name of Safewhere Event Log


Safewhere*Identify has a dedicated event log that can be found at Event Viewer\Applications and Services Logs\Safewhere. Before 4.3, if multiple tenants are installed in a machine, logged event data from all the tenants have the Source column set to “Identify”. That causes one obvious issue: It is almost impossible to figure out which tenant logged a specific event. In Identify 4.3, we have solved this problem by adding the tenant’s name and site information into the source field. As a result, format of the new Source column is “Identify [tenant name] – [site]”. For example, if a tenant name is Safewhere and an event is logged from Runtime, the value of the Source column is “Identify [Safewhere] – Runtime”.

source_name_of_event_log

One side effect of this change is that existing systems that are using tools like SCOM to monitor event log data may need to reconfigure the monitoring rules to deal with the new Source name format.

Was this helpful ?Good Somewhat Bad