

By default, Relativity logs Errors and Health Checks. (Health Checks log at the Information log level - this is the only subsystem that has a default rule that logs below the Error level). With the default configuration, Error and Health Checks logs are persisted to the system database without requiring the overall log level to be set to Information.
When troubleshooting application problems, use the EDDSLogging database objects and configuration files to change the default configuration and capture the level of detail that meets your needs.
See these related pages:
Relativity logging is centrally configured in the EDDSLogging database. Logging config files provides backup for the database logging configuration.
Note: If both the central database configuration is unavailable (for example, due to connection failure) and the logging config files are missing or cannot be parsed because of invalid or malformed XML, no logging takes place.
When troubleshooting Relativity, you can change logging to meet your particular needs by using logging configurations, sinks, and rules.
Note: Logging changes take effect without an IIS reset.
By default logging is enabled for all Relativity modules. See Configurations for more information.
The following are the default logging level, sink, and log file location settings.
By default, Relativity logs at the Error (4) level for all machines, systems, subsystems, and applications (except for the Health Check subsystem which by default logs at the Information (2) level to ensure that important health check logs are captured without defaulting all logging to the Information level). For information on changing the logging level, see Rules.
By default, logs are stored in the EDDSLogging.RelativityLogs database table. For information on changing sinks, see Sinks and Rules.
For file logging, the log file location is set by the RELATIVITY_LOGS environment variable.
Note: The Relativity installer does not set RELATIVITY_LOGS. Instead you must set it manually on all machines in the Relativity environment.
You can also change this variable to a direct folder path within the LogConfig.xml file.
To restore default logging settings for the database only, execute the ResetToDefault stored procedure in the EDDSLogging database. When this stored procedure runs, it also outputs the results from the PrintCurrentSetup stored procedure. The output is a runnable SQL script of the configuration that was just deleted. If the @WithParamNames bit parameter is set to 1, the generated script includes the @Param = [Value] notation and additional usage comments.
EXEC [EDDSLogging].[eddsdbo].[ResetToDefault] @WithParamNames = 1
This deletes all custom rules, configurations, and rule-sinks defined for your Relativity environment in the database.
To restore all logging setting back to default and delete all customizations including sinks, run the ResetToDefault_WithSinks stored procedure.
EXEC [EDDSLogging].[eddsdbo].[ResetToDefault_WithSinks] @WithParamNames = 1
Note: You can't remove the default values entirely from the database or assign them a higher order value than any other rule or configuration.
Relativity uses the EDDSLogging database to store logging configuration and as the default sink for Relativity logs. In a distributed environment, it is hosted on the same SQL Server as the EDDS database.
The database objects include tables, views, and stored procedures.
The EDDSLogging.SinkType table defines the following sink types:
The EDDSLogging.Sink table defines the available sinks. The entries in EDDSLogging.Sink are linked to the EDDSLogging.SinkType table by TypeID. By default, only the EDDSLogging sink is set up in the Sink table:
The data column accepts JSON-formatted strings for the Sink Type used. The easiest way to insert data is to use the stored procedures.
You can add and update sinks by using the stored procedures in the EDDSLogging database. If a sink with the specified name already exists in the table, it is updated.
Run the EnsureSink_File stored procedure.
EXEC [EDDSLogging].[eddsdbo].[EnsureSink_File] @Name = 'File1', @LogFileLocation = 'C:\Temp\Logs\', @MaxFileSizeInMB = 10000
Note: The stored procedure attempts to escape any single backslash to make the LogFileLocation JSON serializable.
Run the EnsureSink_SQLServer stored procedure.
EXEC [EDDSLogging].[eddsdbo].[EnsureSink_SQLServer] @Name = 'SQL1', @ConnectionString = 'data source=localhost;initial catalog=EDDSLogging;persist security info=False;user id=EDDSdbo;password=FAKE123; workstation id=localhost;packet size=4096', @TableName = 'RelativityLogs'
Note: Do not use double-quotes in the connection string because that breaks the eddsdbo.PrintCurrentSetup script. The connection string does not need double quotes to work. The TableName does not need the database schema of the targeted table to work.
Output from running all three of the above scripts:
Note: Note that the data field that defines the sink (for example, the database connection string or file path) must be formatted as JSON and the stored procedures automatically do it for you.
Rules defined in the EDDSLogging.Rule table are used to set the logging level for a combination of machine/system/subsystem/application.
By default the table contains two rules:
Note: The Order field defines the order in which Relativity logging parses the rule for a given combination of machine/system/subsystem/application. The rule with the lowest Order value is used once machine/system/subsystem/application are matched.
To change the logging level, update the LoggingLevel value. For example, this statement turns logging level up to DEBUG for everything:
update [EDDSLogging].[eddsdbo].[Rule] set LoggingLevel = 1
You can define additional rules as necessary. For example, the following rules set logging for all Relativity core agents ('Default' application) on the agent-srv1 machine to INFORMATION and to the Default sink:
Output:
The rules also add a row to the eddsdbo.RuleSink table to link the sink to the rule.
The following rule turns up logging to INFORMATION only for Relativity telemetry agents (Telemetry Host and Telemetry Metrics Transmission):
Output:
The following configuration enables logging for all Relativity services on rel-srv1 to WARNING and to both the Default sink and a File sink:
Output:
The configuration also adds two rows to eddsdbo.RuleSink to link the sink to the rule.
Using the eddsdbo.EnsureRule stored procedure, you can remove or add sinks linked to our rule by simply adding or removing them to the parameter. The stored procedure ensures that only the sink names that exists in the value are linked to the rule.
Note: When making changes to logging rules, make sure to select an appropriate logging level to avoid flooding the logs.
The entries in EDDSLogging.RuleSink table associate rules with sinks. You can use the table to set up logging to multiple sinks from a single rule.
By default the table contains only one row:
This instructs the system to log everything to the EDDSLogging.RelativityLogs table. The entries in EDDSLogging.RuleSink are linked to the EDDSLogging.Sink table by name.
The logging config files provide a fallback in case of a database connection failure. The files are named LogConfig.xml and are located next to the main configuration file for each Relativity system. The following example shows LogConfig.xml in a production environment, right next to web.config.
The following is the LogConfig.xml file installed by default for all modules.
<?xml version="1.0" encoding="utf-8" ?> <!--Information on how to use this file can be found here https://platform.relativity.com/9.3/Content/Logging/Local_config_files.htm --> <kCuraLogging masterLoggingConfiguration="EDDS"> <rules enabled="true"> <rule system="*" loggingLevel="Error" sink="File1"/> </rules> <sinks> <fileSink name="File1" logFileLocation="%RELATIVITY_LOGS%" maxFileSizeInMB ="10000" /> </sinks> </kCuraLogging>
<kCuraLogging masterLoggingConfiguration>
<rules enabled>
<rule system subSystem application loggingLevel sink>
sink="MyFileSink" or sink="MyFileSink;MySQLSink;..."
Note: If multiple sinks are specified, the same information logged to each sink.
If you have multiple <rule> elements in the <rules> section, the <rule> elements are evaluated in the order they are found, so you must put more specific rules first. For example, this is how you set logging level to Verbose for the Processing application (specified by GUID) while logging is set to Error for the rest of Relativity:
<rules enabled="true"> <rule application="ed0e23f9-da60-4298-af9a-ae6a9b6a9319" loggingLevel="Verbose" sink="File1"/> <rule system="*" loggingLevel="Error" sink="File1"/> </rules>
<sinks>
<fileSink name logFileLocation maxFileSixeInMB>
Note: If you use a relative path for logFileLocation, the output is relative to the location where you are running your application and not to the path of the executable or the bin directory. It is strongly recommended to only use an absolute path.
<eddsLogSink name>
<sqlSink name connectionString tableName>
You experience problems with Relativity Data Grid. It could be related to the Data Grid Worker Agent on the rel-dg-srv-1 machine, so you need to increase logging level for Data Grid agents on the machine to capture additional information. To do that, you must define a new logging rule. The rule can be defined in the database or the logging configuration file.
<rule system="Agent" subsystem="CustomAgent" application="6a8c2341-6888-44da-b1a4-5bdce0d1a383" loggingLevel="Information" sink="EDDS"/>
This sets logging level for Data Grid Core application agents on the rel-dg-srv-1 server to INFORMATION.
Logging failures can occur when logging configuration is missing or cannot be processed due the central database connection failure or malformed XML in the config files. If logging for a Relativity component fails to initialize, Windows records error messages in the Event Viewer. Look for the messages in Server Manager > Diagnostics > Event Viewer > Applications and Services Logs > kCura.
Why was this not helpful?
Check one that applies.
Thank you for your feedback.
Want to tell us more?
Great!