Orchestrator Job Logs Are Missing or Not Showing

News Knowledge Base
1

What to perform when Orchestrator Job logs are missing or not showing?

Issue Overview: Orchestrator Job logs are missing or not showing.

Root Cause: There are a few different scenarios that can cause this condition. This scenario usually arises after the making incorrect configuration changes to Orchestrators logging functionality.


Diagnosing the Issue

  1. If the issue only occurs with certain Robot machines, go to the section “Robot Cannot Send Logs to Orchestrator”
  2. Open the Orchestrator server Event Viewer and check the application logs to see if Orchestrator events are displaying in the logs
  • Run -> eventvwr ->Applications
  • Or search our KB articles for more detailed instructions
  1. If there are no logs with Orchestrator as the source, that most likely means that the nlog section of the web.config file has a misconfiguration. Go to the section “Validate Nlog Configuration”
  2. If logs for Orchestrator exist in Event Viewer, then that means that logging is working. If there are any Orchestrator errors, make sure to address those before continuing.
  3. Check to see where Orchestrator is writing logs to.
  • Open the web.config file
  • Search for “<logger name="Robot.*" final="true" writeTo=”
  • This will return web.config key that specifies where the Robot logs are written to. It can contain multiple values. (i.e. <logger name="Robot.*" final="true" writeTo="database" /> or <logger name="Robot.*" final="true" writeTo="database,robotElasticBuffer" />)
  • The default value will be “Database” but if using ElasticSearch it may be “robotElasticBuffer”. It also may have both values depending on how it was configured in the past.
  • If using a third-party tool for logging besides ElasticSearch (like splunk) this value needs to include “database” as Orchestrator needs a source to read from for displaying Robot logs.
  1. Check to see where Orchestrator is reading the job logs from
  • In the web.config file search for <add key="Logs.RobotLogs.ReadTarget" value="
  • This will return the web.config key that controls the source Orchestrator uses to populates its logs.
  • It should look something like: <add key="Logs.RobotLogs.ReadTarget" value="database" />
  1. If the Logs.RobotLogs.ReadTarget does not match one of the included values captured in step 4 go to the section “Fix Orchestrator Robot Logs Read Write Mismatch”
  2. If none of the fixes mentioned above, it either means the logs are not being sent from the Robot machine, or there is an issue between Orchestrator and where it writes the logs to.
  3. Make sure that Orchestrator is receiving logs:
  • Open the web.config file
  • Search for: <logger name="Robot.*" final="true" writeTo=”
  • Add “eventLog” as a target. (i.e. <logger name="Robot.*" final="true" writeTo="database,eventLog" />
  • Run a Job from Orchestrator and see if the Robot logs are displayed in the event viewer.
  • Back out the change.
  1. If the Robot logs did not show up in the event viewer, that means the Robot is having issues sending the logs to Orchestrator. Go to the section “Robot Cannot Send Logs to Orchestrator”
  2. If the Logs show up in the event viewer, that means the logs are reaching Orchestrator and the issue is between Orchestrator and the database or ElasticSearch.
  • To troubleshoot the database, go to “Troubleshooting the Database”
  • To troubleshoot ElasticSearch, go to “Troubleshooting ElasticSearch”
  1. If none of the above steps helped to resolve the issue, open a ticket with UiPath support.

Troubleshooting the Database: Periodically the database may get larger than it needs to be.

  1. Read and follow the instructions listed in the Maintenance Considerations
  2. If the issue persists after following these steps, please open a ticket with UiPath.

Troubleshooting ElasticSearch

If Orchestrator cannot reach ElasticSearch or ElasticSearch is having issues, then that can prevent the Robot logs from displaying or even being recorded in ElasticSearch.

  1. Make sure that the version of ElasticSearch matches our software requirements
  2. See the section “ElasticSearch Workaround” in case a short term workaround is needed.
  3. In the web.config file, search for the elasticSearch Target configuration in the nlog section. There will be two targets configured. Search the following strings:
  • < target name="robotElasticBuffer
  • <target name="serverElasticBuffer"
  1. Under each entry, search for the URI attribute (they should be the same for each entry).
  2. From the Orchestrator machine, try going to this URL.
  3. If the URL is reachable, it should take the browser to a page displaying a json string, or it will download a file containing a JSON string.
  4. If a Json string is not displayed or a file containing a json string is not downloaded, it means that the URL being used is incorrect. Check with the admin of the elasticSearch server to determine the correct URL
  1. If the URL is unreachable, it could be that the wrong host name is being used, or possibly that the wrong protocol is specified (i.e. http vs https). A network admin should be able to help diagnose this problem.
  2. If the URL is reachable, login Kibana and verify that an indices has been created for the tenant (This should be “Default-year-month” ).
  3. If none of the above steps helped to determine the issue, please open a ticket with UiPath. Additionally, consider opening a ticket with ElasticSearch as it may not be an Orchestrator issue.
  4. Also see “ElasticSearch Workaround”

ElasticSearch Workaround: If having an issue getting logs to generate in ElasticSearch, consider this work around until the issue is resolved.

  1. Make sure the database is included in the “writeTo” property of the Robot log rules. (It should look like: <logger name="Robot.*" final="true" writeTo="database,robotElasticBuffer" />)
  2. Set the Logs.Robot.Logs.ReadTarget to be the database. (<add key="Logs.RobotLogs.ReadTarget" value="database”)
  3. The above changes will ensure that the logs are written and read from the database.
  4. After the ElasticSearch issue is resolved, the changes can be backed out.
  5. If the workaround does not work, check the section “Troubleshooting the Database” and open a ticket with UiPath if needed.


Robot Cannot Send Logs to Orchestrator

  1. Logon to the Robot Machine
  2. Go to the following directory:
  • For x86:
C:\Windows\SysWOW64\config\systemprofile\AppData\Local\UiPath\Logs\execution_log_data
  • For x64:
C:\Windows\System32\config\systemprofile\AppData\Local\UiPath\Logs\execution_log_data
  1. Delete the contents
  2. This will flush out the local database used by the Robot for storing logs. There was an issue in the past where intermittently the Robot would stop sending logs until this cache was flushed.
  3. If the issue happens consistently, please open a ticket with UiPath so it can be investigated by our support team.

Fix Orchestrator Robot Logs Read Write Mismatch: When Orchestrator receives the logs from a Robot, it writes them to the target or targets configured in the nlog section of the web.config. When a user accesses the logs in the Orchestrator GUI, Orchestrator pulls them from whatever source is configured in the appSettings of the web.config. Orchestrator can only read from the sources “database” or “robotElasticBuffer”. Obviously, Elasticsearch needs to be configured for it to be Orchestrators read source.

  • Ensure that the value configured for Logs.RobotLogs.ReadTarget is included in in the writeTo target for the entry <logger name="Robot.*" final="true" writeTo=".

Validate Nlog configuration: There are three ways in which no logs from Orchestrator are sent to Event Viewer:

  1. A certain Registry key was modified that disabled the log.
  • Registry Key: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\Orchestrator
  1. The nlog section of the web.config file has been modified to intentionally disable event viewer logs.
  2. There is a critical error in the nlog syntax or configuration that has “broken” Orchestrator logging.


This section is meant to address the third scenario.

  1. Given that that this scenario would only occur after making changes to the web.config file were made, back out those changes and check to see if the Orchestrator logs start working again.
  2. If the Orchestrator logs start working, check to make sure that the Robot logs also work.
  3. If the Orchestrator logs work, but the Robot logs do not work, go back to the “Diagnosing the Issue” section.
  4. If all logs are now working, it means that the change made to the web.config nlog section broke logging. This usually happens when trying to add a custom data source. Make sure to fix any syntax error or open a ticket with UiPath support for assistance in making the change.

NLog also has an internal log that can be enabled. Try modifying the following line to enable the log:

  • <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="">

Try

  • <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" throwExceptions="true" internalLogLevel="Trace" internalLogFile="nlogtrace.txt">
  1. If neither the Robot logs or the Orchestrator logs are working and the first two scenarios mentioned previously do not apply, contact UiPath Support. If neither the Robot logs nor the Orchestrator logs work and the first two scenarios mentioned previously do not apply, contact UiPath Support.



3 Likes