UiPath Orchestrator Guide

Logging Configuration

The web.config file (C:\Program Files (x86)\UiPath\Orchestrator) contains multiple settings that enable you to configure Orchestrator to your liking. Most of the parameters that interest you can be found under appSettings, but there might be some logging configurations that can be changed after install.

Note:

It is recommended that only administrators change the values of these parameters.
Additionally, it is recommended that you stop the IIS site in order to modify web.config settings under any circumstances.

Logging Classification

1. Robot: <logger name="Robot.*" writeTo="database,robotElasticBuffer" final="true" />. Used to log messages generated by Robots. The following parameters have to be configured:

  • writeTo - The location where log messages generated by the Robot are written. The following values are accepted:
    • database - Logs are sent to Orchestrator's SQL database. This is one of the default values.
    • robotElasticBuffer - Logs are sent to ElasticSearch. This is the second default value. Please remember this requires additional settings. Details here.
      Having logs sent both to the Orchestrator's SQL database and ElasticSearch enables you to have non-repudiation logs. Delete one of the values to stop logging to that location.
    • robotMongoBuffer - Logs are sent to MongoDB. Please note that this requires additional settings. Details here.
      Due to having similar APIs, you may use other services which use the MongoDB protocol as well.
  • final - A flag that indicates what to do when a match between a logged message and the logger name is found. When set to true, it does not look for another match. When set to false, other rules matching the same source are checked. By default, it is set to true.

2. Schedules: <logger name="Quartz.*" minlevel="Info" writeTo="eventLogQuartz" final="true" />. Used to log messages generated by schedules.

Note:

To ensure a smooth run for schedules in an Orchestrator setup with a load balancer you should also set the quartz.jobStore.clustered parameter to true.

3. All others: <logger name="*" minlevel="Info" writeTo="eventLog" />. Used to log all other messages besides the ones described above, including those generated by Orchestrator.

Note:

If you maintain more than two million logs in the SQL database, you might have some performance issues. For more than that, we recommend using Elasticsearch.

Additional Settings

ElasticSearch

The following NLog target must be populated according to your ElasticSearch configuration:

<target xsi:type="ElasticSearch" name="robotElastic" uri="<elasticSearch_url>" index="${event-properties:item=indexName}-${date:format=yyyy.MM}" documentType="logEvent" includeAllProperties="true" layout="${message}" excludedProperties="agentSessionId,tenantId,organizationUnitId,indexName" />
  • uri - the ElasticSearch URL; note that you have to include the protocol and port, such as http://elastic_server:9200;
  • excludedProperties - data that you do not want to be saved to ElasticSearch.

MongoDB

The following NLog target must be populated according to your MongoDB configuration:

<target name="robotMongoBuffer" xsi:type="BufferingWrapper" flushTimeout="5000">
	<target xsi:type="Mongo" name="robotMongo" connectionString="<connection_string>" databaseName="<database_name>" collectionName="<collection_name">
		<field name="windowsIdentity" layout="${event-properties:item=windowsIdentity}"/>
		<field name="processName" layout="${event-properties:item=processName}"/>
		<field name="jobId" layout="${event-properties:item=jobId}"/>
		<field name="rawMessage" layout="${event-properties:item=rawMessage}"/>
		<field name="robotName" layout="${event-properties:item=robotName}"/>
		<field name="indexName" layout="${event-properties:item=indexName}"/>
		<field name="machineId" layout="${event-properties:item=machineId}"/>
		<field name="tenantKey" layout="${event-properties:item=tenantKey}"/>
		<field name="levelOrdinal" layout="${event-properties:item=levelOrdinal}" bsonType="Int32"/>
	</target>
</target>
  • <connection_string> - the connection string corresponding to the database as obtained from Azure Cosmos DB;
  • <database_name> - the name of the database as defined in Azure Cosmos DB;
  • <collection_name> - the name of the corresponding Azure Cosmos DB collection.

Logging Events in the Database

To store system event logs in the database rather than Event Viewer, follow these steps:

  1. Create a new database table, for example:
CREATE TABLE [dbo].[EventLogs](
    [Id] [bigint] IDENTITY(1,1) NOT NULL,
    [Timestamp] [datetime] NOT NULL,
    [Level] [int] NOT NULL,
    [Message] [nvarchar](max) NULL,
    [Exception] [nvarchar](max) NULL)

In the above query, we create a table named EventLogs with the following columns:

  • Id - to hold an ID number for each log, here starting with 1 and incrementing the value with each log added;
  • Timestamp - to hold the time each event was logged;
  • Level - to hold the numerical logging level of each event;
  • Message - to hold the message of each event, if applicable;
  • Exception - to hold the exception logged for each event, if applicable.

Note:

Your can use any name for your table, and remove any columns from the above query or add others to suit your needs.

  1. In the web.config file, add a new NLog target:
<target xsi:type="Database" connectionStringName="Default" name="eventLogDatabase" keepConnection="true">
        <commandText>
          INSERT INTO dbo.EventLogs (Timestamp, Level, Message, Exception)
          VALUES (@timestamp, @level, @message, @exception)
        </commandText>
        <parameter name="@timestamp" layout="${date:format=yyyy-MM-dd HH\:mm\:ss.fff}" />
        <parameter name="@level" layout="${event-properties:item=levelOrdinal}" />
        <parameter name="@message" layout="${message}" />
        <parameter name="@exception" layout="${onexception:${exception:format=tostring:maxInnerExceptionLevel=5:innerFormat=tostring}}" />
</target>

Defining a corresponding parameter for the data to be added in each database column, in this example @timestamp, @level, @message, and @exception.

  1. Lastly, associate the newly created target with the NLog logger classification for all Orchestrator messages, from above, by adding:
<logger name="*" minlevel="Info" writeTo="eventLog,eventLogDatabase" />

Enabling NLog Debugging

NLog is an open-source, easily configured, and extensible logging platform for a variety of .NET platforms. With NLog, you can store or pass log data to any number of predefined or custom targets, such as a local file, an event log, email, or database.

Though there exists some overlap, NLog and Orchestrator have several differentiating logging levels. For NLog you can select either Trace, Debug, Info, Warn, Error, Fatal, or Off. See Logging Levels for a description of the available levels in Orchestrator.

You can enable debugging in NLog to ensure that it is functioning properly. By default NLog is set to Off, it is enabled by configuring the following section of the web.config file:

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" throwExceptions="false" internalLogLevel="Off" internalLogFile="">

The attributes which must be set are:

  • internalLogLevel - the desired logging level
  • internalLogFile - the location of the log file

For example:

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" throwExceptions="false" internalLogLevel="Debug" internalLogFile="C:\logs.txt">

Note:

The user profile under which Orchestrator is running must have access to the path specified in the internalLogFile attribute.


See Also

App Settings

Logging Configuration


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.