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 vom Jobplaner erzeugt werden, haben ein separate Ziele und Protokollierungen:

<target xsi:type="EventLog" name="eventLogQuartz" layout="[Quartz] ${message} ${onexception: ${exception:format=tostring}}" source="Orchestrator" log="Application" />

<logger name="Orchestrator.Quartz.*" minlevel="Info" writeTo="eventLogQuartz" />

Beispiel:

• Quartz-Auftrag konnte nicht erstellt werden.

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:

  • Ungültiger Benutzername/E-Mail-Adresse oder Kennwort.
  • Der Maschinenname „DOC“ ist bereits vergeben.

• Geschäftskonflikte wie zum Beispiel:

  • Lizenz abgelaufen!
  • Die Sitzung des Floating-Roboters ist bereits auf Maschine ROQADOCS06 aktiv!
  • Die Roboter haben bereits anstehende Aufträge für diesen Prozess

• Keine Ausnahmen gefunden wie:

  • WarteschlangenName1 ist nicht vorhanden.

Orchestrator-Ausführungsprotokolle

Die Orchestrator-Ausführungsprotokolle werden von den verbundenen Robotern gesendet und im Abschnitt Protokolle der Seiten Aufträge oder Roboter angezeigt. Die Anwendung empfängt die Daten von den Robotern, fügt eigene Parameter (TenantID, FolderID) hinzu und leitet die Nachrichten an verschiedene Ziele weiter, so wie im Abschnitt <nlog> der Datei UiPath.Orchestrator.dll.config angegeben.

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: Wenn die Anzahl der in der Tabelle gespeicherten Roboterprotokolle mehr als 1 Million beträgt, empfehlen wir, den folgenden Index zu erstellen, 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="" 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 fügen Sie auch Folgendes hinzu: 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 falsefestgelegt. Weitere Informationen finden Sie unter Logs.Elasticsearch.OAuthEnabled.
   • Logs.Elasticsearch.OAuthExpireInSeconds = ”1200” - Dieser Parameter ist optional, es sei denn, der Standardwert von 1200 wird in der Elasticsearch-Einstellung xpack.security.authc.token.timeout geändert. Dieser Parameter muss denselben 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. Um OAuth2 für Nlog zu aktivieren, stellen Sie sicher, dass Sie auch den folgenden Parameter in der UiPath.Orchestrator.dll.config -Datei des Orchestrators konfigurieren. Beachten Sie, dass Sie den Benutzernamen und das Kennwort für die Authentifizierung in Elasticsearch eingeben müssen, da das ursprüngliche Token basierend auf diesen Anmeldeinformationen generiert wird.
   • OAuthEnabled = “true” - Standardmäßig ist es auf falsefestgelegt. Weitere Informationen hierzu 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, indem Sie die folgenden Schritte ausführen.
2. Speichern Sie den API-Schlüssel als geheimen Schlüssel in Ihrem Azure Key Vault.
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.