Konfigurieren von NLog

Konfigurieren Sie die NLog-Protokollierung für den Orchestrator in der Automation Suite auf EKS/AKS.

Hinzufügen von NLog-Erweiterungen

Der Orchestrator lädt die folgenden Erweiterungen standardmäßig, sodass Sie sie nicht in den Ordner oder die NLog-Konfiguration aufnehmen müssen:

• NLog.Targets.ElasticSearch
• UiPath.Orchestrator.Logs.Elasticsearch
• Microsoft.ApplicationInsights.NLogTarget
• NLog.Extensions.AzureEventHub

In diesem Setup können nur Linux-kompatible Erweiterungen verwendet werden, also stellen Sie sicher, dass die ausgewählte NLog-Erweiterung dieser Regel entspricht.

Um die Erweiterung für die Verwendung verfügbar zu machen, muss sie in den Clusterspeicher hochgeladen werden. Das uipathctl -Befehlszeilentool kann dies über den Befehl uipathctl config orchestrator upload tun:

uipathctl config orchestrator upload --nlog-extensions-directory /path/to/extensions/directory

Wenn Sie eine externe Speicherkonfiguration auf Clusterebene verwenden, müssen Sie dies angeben, indem Sie den Parameter --is-external-storage einschließen.

Erweiterte NLog-Konfiguration

Erstellen der erweiterten NLog-Konfiguration

1. Erstellen Sie die Datei nlog.config.json mit den Standardabschnitten: Erweiterungen, Ziele und Regeln (extensions, targets, rules).

   Der Erweiterungsabschnitt ist ein Array von Elementen, die über assemblyFile die Erweiterungsassemblys und den Pfad der Assembly angeben.

   Wenn benutzerdefinierte NLog-Plugins geladen wurden (wie im Abschnitt Hinzufügen von NLog-Erweiterungen beschrieben), wird im Abschnitt extensions auf sie verwiesen.

2. Konfigurieren Sie das Ziel und die Regel in der Datei nlog.config.json.

3. Wenden Sie die Datei nlog.config.json mit dem uipathctl -Befehlszeilentool an:

   uipathctl config orchestrator update-config --nlog-config nlog.config.json
   

   Wichtig:

   Diese Aktion überschreibt die vorhandene benutzerdefinierte NLog-Konfiguration. Sie können die vorhandene Konfiguration mit diesem Befehl überprüfen:

   uipathctl config orchestrator get-config --nlog-config
   

   Beispiel für eine nlog.config.json-Datei, die Protokolle in Azure Blob schreibt:

   {   "NLog": {
           "extensions": [
               { "assemblyFile": "NLog.Extensions.AzureBlobStorage.dll" }
           ],
           "targets": {
               "azureBlob": {
                   "type": "AzureBlobStorage",
                   "connectionString": "DefaultEndpointsProtocol=https;AccountName=test;AccountKey=key;EndpointSuffix=core.windows.net",
                   "container": "orchestratorlogs",
                   "blobName": "${date:format=yyyy-MM-dd hh.mm}",
                   "layout": {
                     "type": "JsonLayout",
                     "includeAllProperties": true,
                     "Attributes": [
                       {"name": "ts","layout": "${longdate}"},
                       {"name": "level","layout": "${level:upperCase=true}"},
                       {"name": "logger","layout": "${logger}"},
                       {"name": "message","layout": "${message}"},
                       {"name": "exception","layout": "${onexception:${ui-pretty-exception}}"}
                     ]
                   }
               }
           },
           "rules": { "70_Final": { "writeTo": "stdout,azureBlob" } }
       }
   }
   

   Beispieldatei nlog.config.json, die Roboterprotokolle in Splunk schreibt:

   {
       "Nlog": {
           "extensions": [
               { "assemblyFile": "NLog.Targets.Splunk.dll" },
               { "assembly": "UiPath.Orchestrator.Logs.DatabaseBulk.NLogTarget" }
           ],
           "targets": {
               "Splunk": {
                   "type": "AsyncWrapper",
                   "overflowAction": "Discard",
                   "queueLimit": 10000,
                   "batchSize": 200,
                   "timeToSleepBetweenBatches": 1,
                   "target": {
                       "type": "SplunkHttpEventCollector",
                       "serverUrl": "http://splunk.example.com",
                       "token": "splunk-token",
                       "channel": "",
                       "source": "${logger}",
                       "sourceType": "_json",
                       "index": "uipath",
                       "retriesOnError": "0",
                       "batchSizeBytes": "0",
                       "batchSizeCount": "0",
                       "includeEventProperties": "true",
                       "includePositionalParameters": "true",
                       "includeMdlc": "true",
                       "maxConnectionsPerServer": "10",
                       "ignoreSslErrors": "false",
                       "useProxy": "false",
                       "proxyUrl": "",
                       "proxyPassword": ""
                   }
               }
           },
           "rules": {
               "20_Robot_Primary": { "writeTo": "Splunk,database,insightsRobotLogs" }
           }
       }
   }
   

Formatieren des Splunk queueLimit

Die Warteschlange aufnimmt Splunk-Rückstand während Verlangsamungen auf. Passen Sie ihn an Ihren Spitzendurchsatz an, nicht an Ihren Durchschnitt:

queueLimit = peak_logs_per_sec × acceptable_backlog_seconds

Bereitstellung	Spitzenrate	Tolerierung des Rückstands	Warteschlangenlimit
Klein	~10 Protokolle/Sek	60 Sek	600
Mittel	~35 Protokolle/Sek	300 Sek	10000
Groß	~200 Protokolle/Sek	60 Sek	12000

Best Practices für Splunk-Ziele

• Verwenden Sie overflowAction: Discard für sekundäre Ziele. Externe Protokollziele wie Splunk sind in der Regel Analyse- oder Beobachtungsziele, die Orchestrator-Datenbank ist die Source of Truth. Wenn das externe Ziel nicht mithalten kann, ist das Verwerfen seiner Kopie dem Blockieren von Anwendungs-Threads vorzuziehen.
• Reservieren Sie overflowAction: Block für Ziele, bei denen der Verlust nicht akzeptabel ist. Block verhindert den Ereignisverlust, aber nicht die Blockierung. Wenn sich die Warteschlange unter Dauerlast füllt, wird sie wieder zu demselben Thread-Blockierungsverhalten wie BufferingWrapper. Verwenden Sie sie nur, wenn das externe Ziel eine Compliance- oder Prüfungsanforderung ist, und dimensionieren Sie queueLimit großflächig, um dem Spitzendurchsatz gerecht zu werden.
• Behalten Sie immer database in der Regel writeTo neben einem externen Ziel bei. Dadurch wird sichergestellt, dass kein Roboterprotokoll dauerhaft verloren geht, unabhängig von der Verfügbarkeit oder Leistung des externen Ziels.
• Vor dem Herunterfahren wischen. AsyncWrapper enthält Ereignisse in einer Warteschlange im Arbeitsspeicher. Stellen Sie sicher, dass NLog-Ziele beim ordnungsgemäßen Herunterfahren geleert werden, um zu vermeiden, dass der Ende der Warteschlange verloren geht, wenn der Prozess beendet wird.

Aktualisieren der erweiterten NLog-Konfiguration

Die uipathctl -Befehle, die zum Aktualisieren der NLog-Konfiguration erforderlich sind, sind:

• uipathctl config orchestrator get-config --nlog-config – Exportiert die aktuelle Konfiguration in eine JSON-Datei für Schlüssel-Wert-Paare, die für die Bearbeitung bereit ist.
• uipathctl config orchestrator update-config --nlog-config nlog.config.json – Aktualisiert die Konfiguration mit Ihren Änderungen.

1. Exportieren Sie die aktuelle benutzerdefinierte NLog-Konfiguration mit diesem Befehl in eine JSON-Datei:

   uipathctl config orchestrator get-config --nlog-config > nlog.config.json
   

2. Bearbeiten Sie die exportierte nlog.config.json -Datei nach Bedarf. Sie können beliebige Einstellungen hinzufügen, entfernen oder ändern.

   Hinweis:

   Sie müssen die Datei jedes Mal erneut exportieren, wenn Sie eine Änderung vornehmen müssen, da die Aktualisierung alle NLog-Einstellungen überschreibt.

3. Aktualisieren Sie die NLog-Konfiguration mit diesem Befehl:

   uipathctl config orchestrator update-config --nlog-config nlog.config.json
   orchestrator config updated