Introduction
Diagnostics logging is one of the most useful feature 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, 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.
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 Debug level. All the tracing messages will be logged.
- Information: Only tracing messages that have business meaning will be 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 will be enabled on 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.
Note: This setting hasn’t worked yet. We will finish supporting it in one of the next weekly updates for version 4.3.
4. Enable WCF tracing log – Admin
When ticked, WCF tracing log will be enabled on Runtime site. The only WCF-powered service that is hosted in Identify*Admin is SMPL service.
Note: This setting hasn’t worked yet. We will finish supporting it in one of the next weekly updates for version 4.3.
5. Enable REST APIs verbose error to client side
When ticked, error responses that are sent to client side will be contained verbose messages.
Note: This setting hasn’t worked yet. We will finish supporting it in one of the next weekly updates for version 4.3.
6. Enable Identify*STS verbose error to client side
When ticked, error responses that are sent to client side will be contained verbose messages
Note: This setting hasn’t worked yet. We will finish supporting it in one of the next weekly updates for version 4.3.
New default logging folder
Each sites of an Identify tenant used to have a log folder inside the site’s own folder: Admin’s log folder is “LogFiles” while that 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.
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 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, value of the Source column is “Identify [Safewhere] – Runtime”.
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.