Orchestrator-Protokolle

Orchestrator-Diagnoseprotokolle

Dies sind Diagnoseprotokolle, die von UiPath Orchestrator in Bezug auf dessen Verhalten erzeugt werden.

Aktivierung der UiPath-Orchestrator-Diagnoseprotokolle

Die UiPath-Orchestrator-Diagnoseprotokolle sind aktiviert, sobald UiPath Orchestrator erfolgreich installiert ist. Sie hängen von der NLog-Infrastruktur ab, und deren Konfiguration findet sich in der Datei UiPath.Orchestrator.dll.config unter dem Tag <nlog>.

Hinweis:

Bitte berücksichtigen Sie, dass beide Serverausnahmen von Orchestrator und der Stacktrace im Fenster Jobdetails (Job Details) unabhängig von der vom Benutzer gewählten Sprache in englischer Sprache angemeldet werden.

Ziele der UiPath-Orchestrator-Diagnoseprotokolle

Alle Anwendungsprotokolle werden in der Ereignisanzeige auf der untersten Protokollierungsstufe Information protokolliert. Dies wird in den folgenden Zeilen der Datei UiPath.Orchestrator.dll.config angegeben:

<target xsi:type="EventLog" name="eventLog" layout="${message}" source="Orchestrator" log="Application" />

<logger name="*" minlevel="Info" writeTo="eventLog" />

Protokolle, die von Geschäfts- und anderen Validierungsregeln generiert werden, haben separate Ziele und Protokollierungen:

<target xsi:type="EventLog" name="businessExceptionEventLog" layout="${message}${onexception:${exception:format=tostring:maxInnerExceptionLevel=5:innerFormat=tostring}}" source="Orchestrator.BusinessException" log="Application" />

<logger name="BusinessException.*" minlevel="Info" writeTo="businessExceptionEventLog" final="true" />

Diese Arten von Fehlermeldungen werden in den folgenden Fällen in der Ereignisanzeige protokolliert:

• Validierungsprobleme wie zum Beispiel:
  • Invalid username/email address or password.
  • The machine name DOC is already taken
• Geschäftskonflikte wie zum Beispiel:
  • License expired!
  • The floating robot's session is already active on machine ROQADOCS06!
  • The robots already have pending jobs for this Process.
• Keine Ausnahmen gefunden wie:
  • QueueName1 does not exist.

Orchestrator-Ausführungsprotokolle

The Orchestrator Execution Logs are sent by the Robots connected to it and are displayed in the Logs section of the Jobs or Robots pages. The application receives the data from the Robots, adds its own parameters (TenantID, FolderID), and forwards the messages to different targets, as specified in the <nlog> section from the UiPath.Orchestrator.dll.config file.

Ziele der Orchestrator-Ausführungsprotokolle

Standardmäßig werden alle Robot-Protokolle an die Tabelle Protokoll der Standard-Orchestrator-Datenbank gesendet, in der der UiPath Orchestrator auch andere Informationen speichert.

Sie können Robot-Protokolle jedoch an eine andere Datenbank senden, indem Sie diese im Abschnitt target xsi:type="Database" connectionString="..." der Datei UiPath.Orchestrator.dll.config konfigurieren.

Die Seite Protokolle (Logs) zeigt Informationen aus der Tabelle Protokolle (Logs) von der Standarddatenbank an. Wenn also dieser Abschnitt nicht existiert oder die Protokolle in einer anderen Datenbank gespeichert werden, ist die Seite leer. Alle Parameter sollten gemäß dem Tabellenschema, das wie folgt aussieht, vorliegen:

<target xsi:type="Database" name="database" connectionString="${ui-connection-strings:item=Default}" keepConnection="true">
 <commandText>
  insert into dbo.Logs (OrganizationUnitId, TenantId, TimeStamp, Level, WindowsIdentity, ProcessName, JobKey, Message, RawMessage)
  values (@organizationUnitId, @tenantId, @timeStamp, @level, @windowsIdentity, @processName, @jobId, @message, @rawMessage)
 </commandText>
  <parameter name="@organizationUnitId" layout="${event-properties:item=organizationUnitId}" />
  <parameter name="@tenantId" layout="${event-properties:item=tenantId}" />
  <parameter name="@timeStamp" layout="${date}" />
  <parameter name="@level" layout="${event-properties:item=levelOrdinal}" />
  <parameter name="@windowsIdentity" layout="${event-properties:item=windowsIdentity}" />
  <parameter name="@processName" layout="${event-properties:item=processName}" />
  <parameter name="@jobId" layout="${event-properties:item=jobId}" />
  <parameter name="@message" layout="${message}" />
  <parameter name="@rawMessage" layout="${event-properties:item=rawMessage}" />
</target>
 <logger name="Robot.*" writeTo="database" final="true" />

Andere Ziele können zu den Protokollen durch Konfigurieren der Datei UiPath.Orchestrator.dll.config hinzugefügt werden. Eine Liste der verfügbaren Ziele finden Sie hier.

Hinweis:

Beim Aktualisieren des Orchestrators werden Nlog-Ziele gelöscht und wie folgt neu erstellt:

• Nach dem Upgrade auf 2022.4 Nlog-Datenbankziele werden auf ihre Standardwerte zurückgesetzt.
• Nach dem Upgrade auf 2022.10 Nlog-Datenbankziele werden gelöscht und durch neue und verbesserte Ziele ersetzt.

Dies deckt database-, monitoring- und insightsRobotLogs-Ziele ab.

Hinweis:

Wenn die Anzahl der in der Tabelle gespeicherten Roboterprotokolle höher als 1 Million ist, empfehlen wir die Erstellung des folgenden Indexes, um die Suchleistung zu verbessern:

CREATE NONCLUSTERED INDEX [IX_Search] ON [dbo].[Logs]
(
[TenantId] ASC,
[OrganizationUnitId] ASC,
[Level] ASC,
[TimeStamp] DESC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO

Elasticsearch-Server

Standardmäßig gibt es ein Elasticsearch-Ziel, das im Installationsskript konfiguriert wurde. Der Index unterscheidet sich bei jedem Mandanten, aber dies kann vom angegebenen Ziel im Abschnitt <nlog> konfiguriert werden.

Für Elasticsearch-Versionen vor 8.0:

<target name="robotElasticBuffer" xsi:type="BufferingWrapper" flushTimeout="5000">
<target xsi:type="ElasticSearch" name="robotElastic" uri="uritoelasticsearchnode" index="${event-properties:item=indexName}-${date:format=yyyy.MM}" documentType="logEvent" includeAllProperties="true" layout="${message}" excludedProperties="agentSessionId,tenantId,organizationId,indexName" />
</target>
</target>

Für Elasticsearch-Version 8.0 und höher:

<target name="robotElasticBuffer" xsi:type="BufferingWrapper" flushTimeout="5000">
<target xsi:type="ElasticSearch" name="robotElastic" uri="uritoelasticsearchnode" index="${event-properties:item=indexName}-${date:format=yyyy.MM}" documentType="" enableApiVersioningHeader="true" includeAllProperties="true" layout="${message}" excludedProperties="agentSessionId,tenantId,organizationId,indexName" />
</target>
</target>

Damit Elasticsearch ab Version 8.0 ordnungsgemäß funktioniert, werden diese Parameter wie folgt festgelegt:

• documentType ist leer.
• enableApiVersioningHeader ist festgelegt auf true.

Elasticsearch-Versionen vor 7.16.3

Obwohl Elasticsearch Version 7.16.3 bevorzugt wird, können Sie eine frühere Version verwenden, indem Sie den Parameter disableProductCheckStatus true im Nlog-Ziel (<target xsi:type="ElasticSearch") auf festlegen.

Dieser Parameter ist ausgeblendet und sein Standardwert ist false.

Hinweis:

Die Option zum Speichern von Roboterprotokollen auf einem Elasticsearch-Server wird erst nach dem Konfigurieren wirksam und nicht rückwirkend angewandt. Das bedeutet, dass Sie keinen Zugriff mehr auf Protokolle haben, die sich zum Zeitpunkt des Konfigurierens der Option bereits in der Datenbank befanden, da Protokolle nur von einem einzigen Ziel abgerufen und angezeigt werden können.

X-PACK-Authentifizierung

Hinweis:

Standardmäßig sind die Elasticsearch-Sicherheitsfunktionen deaktiviert, wenn Sie eine Basis- oder Testlizenz haben. Wir empfehlen dringend, sie zu aktivieren.

Benutzername-und-Kennwort-Authentifizierung

Um die Authentifizierung über einen Benutzernamen und ein Kennwort zu aktivieren, müssen Sie die folgenden Schritte ausführen:

1. Konfigurieren Sie den Elasticsearch-Server wie folgt:

   • Fügen Sie die xpack.security.enabled -Einstellung zur elasticsearch.yml -Konfigurationsdatei hinzu.

   • Richten Sie einen Benutzernamen und ein Kennwort ein.

     Weitere Informationen dazu finden Sie in der Elasticsearch-Dokumentation.

2. Konfigurieren Sie die UiPath.Orchestrator.dll.config -Datei des Orchestrators wie folgt:

• Option 1 : Wenn Sie kein NLog-Ziel verwenden, müssen Sie die folgenden Parameter konfigurieren: Logs.Elasticsearch.Username und Logs.Elasticsearch.Password . Stellen Sie sicher, dass ihre Werte mit den Elasticsearch-Einstellungen aus Schritt 1 übereinstimmen.

• Option 2 : Wenn Logs.RobotLogs.ReadTarget auf ein NLog-Ziel festgelegt ist (z. B. robotElasticBuffer ) und die Einstellung Logs.Elasticsearch.Nodes nicht angegeben ist, konfigurieren Sie das Ziel, indem Sie Folgendes hinzufügen: requireAuth="true" username="XPACKuser" password="p@$$w0rd" . Stellen Sie sicher, dass diese Parameterwerte mit den Elasticsearch-Einstellungen aus Schritt 1 übereinstimmen.

  Ein Konfigurationsbeispiel finden Sie im Folgenden:

  <target name="robotElasticBuffer" xsi:type="BufferingWrapper" flushTimeout="5000">
          <target xsi:type="ElasticSearch" name="robotElastic" uri="" requireAuth="true" username="XPACKusername" password="p@$$w0rd" index="${event-properties:item=indexName}-${date:format=yyyy.MM}" documentType="logEvent" includeAllProperties="true" layout="${message}" excludedProperties="agentSessionId,tenantId,indexName" />
        </target>
  

• Option 3 : Wenn Logs.RobotLogs.ReadTarget auf ein NLog-Ziel festgelegt ist (z. B. robotElasticBuffer ) und ein Elasticsearch-Knoten über die Einstellung Logs.Elasticsearch.Nodes angegeben ist, müssen Sie ihn explizit konfigurieren (da er die NLog-Zieleinstellungen überschreibt). , und stellen Sie sicher, dass Sie auch Folgendes hinzufügen: requireAuth="true" username="XPACKuser" password="p@$$w0rd" . Stellen Sie sicher, dass diese Parameterwerte mit den Elasticsearch-Einstellungen aus Schritt 1 übereinstimmen.

OAuth 2-Authentifizierung

Um zu OAuth2 als Authentifizierungsmethode für Elasticsearch zu wechseln, müssen Sie die folgenden Schritte ausführen. Beachten Sie, dass Sie Ihre aktuellen Anmeldeinformationen angeben müssen, um zu dieser tokenbasierten Authentifizierungsmethode zu wechseln.

1. Konfigurieren Sie den Elasticsearch-Server wie folgt:

   a. Aktivieren Sie TLS (HTTPS) für die Transportschicht.

   b. Aktualisieren Sie die folgenden Einstellungen in der Konfigurationsdatei elasticsearch.yml :

   • xpack.security.authc.token.enabled: true

   • xpack.security.enabled: true

   • xpack.security.authc.token.timeout - Diese Einstellung ist optional und steuert, wie lange ein Token gültig ist. Standardmäßig ist der Wert auf 20 Minuten festgelegt.

     Weitere Informationen dazu finden Sie in der Elasticsearch-Dokumentation.

2. Aktualisieren Sie die folgenden Parameter in der UiPath.Orchestrator.dll.config -Datei des Orchestrators, um die Einstellungen widerzuspiegeln, für die Sie sich in Schritt 1 entschieden haben.

   • Logs.Elasticsearch.TlsEnabled = ”true” - Standardmäßig ist dieser Parameter auf true festgelegt und stellt sicher, dass TLC (HTTPS) aktiviert ist.

   • Logs.Elasticsearch.OAuthEnabled = ”true” – Standardmäßig ist dieser Parameter auf false. festgelegt. Weitere Informationen finden Sie unter Logs.Elasticsearch.OAuthEnabled.

   • Logs.Elasticsearch.OAuthExpireInSeconds = ”1200” – Dieser Parameter ist optional, außer der Standardwert von 1200 wird in der Elasticsearch-Einstellung xpack.security.authc.token.timeout geändert. Dieser Parameter muss den gleichen Wert wie in der Elasticsearch-Konfiguration haben. Weitere Informationen finden Sie unter Logs.Elasticsearch.OAuthExpireInSeconds.

     Hinweis:

     Die ersten beiden Schritte helfen Ihnen, einen tokenbasierten Authentifizierungsmechanismus zum Lesen von Protokollen zu konfigurieren. Wenn Sie NLog verwenden, ist ein zusätzlicher Schritt erforderlich.

3. To enable OAuth2 for Nlog, make sure to also configure the following parameter in Orchestrator's UiPath.Orchestrator.dll.config file. Note that you must fill in the username and password for authentication in Elasticsearch because the initial token is generated based on those credentials.

   • OAuthEnabled = “true” – Standardmäßig auf false festgelegt. Weitere Informationen dazu finden Sie auf der Seite UiPath.Orchestrator.dll.config .

     Wichtig:

     Wenn Logs.RobotLogs.ReadTarget auf ein NLog-Ziel festgelegt ist (z. B. robotElasticBuffer ) und die Einstellung Logs.Elasticsearch.Nodes nicht angegeben ist, wird Logs.Elasticsearch.OAuthEnabled aus der NLog-Zielkonfiguration gefüllt. Dieselbe Logik wird für Benutzername und Kennwort angewendet.

API-Schlüsselauthentifizierung

Um die Authentifizierung über einen API-Schlüssel zu aktivieren, befolgen Sie die unten beschriebenen Schritte.

1. Generieren Sie den API-Schlüssel mit diesen Schritten.

2. Speichern Sie den API-Schlüssel als Geheimnis in Ihrem Azure-Schlüsseltresor.

3. Konfigurieren Sie die folgenden Nlog-Zielparameter mit Ihren Daten und erstellen Sie so eine Verbindung zwischen dem Orchestrator und Ihrem Schlüsseltresor, die das Abrufen des Schlüssels ermöglicht:

   apiKeyEnabled="true"
   apiKeyProvider="AzureKeyVault"
   apiKeySecretName="<SecretName>"
   azureKeyVaultUri="<KeyVaultUri>"
   azureKeyVaultDirectoryId="<KeyVaultDirectoryId>"
   azureKeyVaultClientId="<KeyVaultClientId>"
   azureKeyVaultCertificateThumbprint="<KeyVaultCertificateThumbprint>"
   azureKeyVaultCertificateStoreLocation="CurrentUser/LocalMachine"
   

   Die folgenden Parameter müssen mit Ihren Werten bearbeitet werden:

   • <SecretName> – der Name, den Sie für Ihren API-Schlüssel im Schlüsseltresor festgelegt haben
   • <KeyVaultUri> – der URI Ihres Schlüsseltresors
   • <KeyVaultDirectoryId> – Ihre Schlüsseltresorverzeichnis-ID
   • <KeyVaultClientId> – Ihre Key Vault-Client-ID
   • <KeyVaultCertificateThumbprint> – der Fingerabdruck Ihres Key Vault-Zertifikats
   • CurrentUser/LocalMachine – der Speicherort, an dem das Zertifikat gespeichert ist

Ablauf des API-Schlüssels

Standardmäßig laufen API-Schlüssel nicht ab, Sie können jedoch ein Ablaufdatum für sie festlegen.

Wenn Ihr API-Schlüssel ablaufen soll, müssen Sie einen neuen generieren und vor dem Ablaufdatum im Schlüsseltresor speichern, um sicherzustellen, dass Orchestrator immer einen gültigen Schlüssel abrufen kann.

Der Orchestrator liest alle 15 Minuten API-Schlüssel aus dem Schlüsseltresor. Dies ist also die maximale Verzögerung, die Sie erwarten können, bevor Ihr neuer Schlüssel weitergegeben wird.