Configuration de NLog

Ajoutez des extensions NLog et configurez des cibles de journalisation avancées dans Orchestrator sur OpenShift.

Ajout d'extensions NLog

Orchestrator charge les extensions suivantes par défaut, vous n'avez donc pas besoin de les inclure dans le dossier ou la configuration NLog :

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

Seules les extensions compatibles Linux peuvent être utilisées dans cette configuration. Assurez-vous donc que l'extension NLog choisie respecte cette règle.

Pour que l’extension soit disponible, elle doit être téléchargée sur le stockage du cluster. L’outil de ligne de commande uipathctl peut le faire via la commande uipathctl config orchestrator upload :

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

Si vous utilisez une configuration de stockage externe au niveau du cluster, vous devez l'indiquer en incluant le paramètre --is-external-storage.

Configuration avancée de NLog

Création de la configuration avancée de NLog

1. Créez le fichier nlog.config.json contenant les sections standards : extensions, cibles et règles.

   La section d'extensions est un tableau d'éléments qui spécifient les assemblys d'extension, via assemblyFile, et le chemin de l'assembly.

   Si des plug-ins nlog personnalisés ont été chargés (comme décrit dans Ajout d’extensions NLog), ils seront référencés dans la section extensions.

2. Configurez la cible et la règle dans le fichier nlog.config.json.

3. Appliquez le fichier nlog.config.json en utilisant l'outil de ligne de commande uipathctl :

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

   Important :

   Cette action remplace la configuration NLog personnalisée existante. Vous pouvez vérifier quelle est la configuration existante en utilisant cette commande :

   uipathctl config orchestrator get-config --nlog-config
   

Exemple de fichier nlog.config.json qui écrit des journaux dans Azure Blob :

{   "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" } }
    }
}

Exemple de fichier nlog.config.json qui écrit les journaux du robot dans Splunk :

{
    "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" }
        }
    }
}

Dimensionner le Splunk queueLimit

La file d’attente ), le retour de Splunk lors des ralentissements. Dimensionnez-le à votre débit maximal, et non à votre moyenne:

queueLimit = peak_logs_per_sec × acceptable_backlog_seconds

Déploiement	Taux de pic	tolérance au retour	LimiteFileAttente
Petite	~10 journaux/sec	60 s	600
Moyenne	~35 journaux/sec	300 s	10000
Grande	Environ 200 journaux/sec	60 s	12000

Meilleures pratiques pour les cibles Splunk

• Utilisez overflowAction: Discard pour les cibles secondaires. Les cibles de journaux externes telles que Splunk sont généralement des destinations d’analyse ou d’observabilité, la base de données Orchestrator est la source de la vérité. Si la cible externe ne peut pas se tenir informée, il est préférable de déposer sa copie plutôt que de bloquer les fils d’application.
• Réserver overflowAction: Block pour les cibles où la perte n'est pas acceptable. Block empêche la perte d'événements, mais n'empêche pas le blocage. Lorsque la file d'attente se remplit sous une charge importante, elle revient au même comportement de blocage du fil de discussion que BufferingWrapper. Utilisez-le uniquement lorsque la cible externe est une exigence de conformité ou d’audit, et dimensionnez queueLimit généreusement pour faire correspondre le débit de pic.
• Conservez toujours database dans la règle writeTo avec une cible externe. Cela garantit qu'aucun journal de robot n'est définitivement perdu, quels que soient la disponibilité ou les performances de la cible externe.
• Vider avant l’arrêt. AsyncWrapper contient les événements dans une file d'attente en mémoire. Assurez-vous que les cibles NLog sont vides lors de l'arrêt en douceur pour éviter de perdre la fin de la file d'attente lorsque le processus se termine.

Mise à jour de la configuration avancée de NLog

Les commandes uipathctl nécessaires à la mise à jour de la configuration NLog sont :

• uipathctl config orchestrator get-config --nlog-config - Exporte la configuration actuelle dans un fichier json de paire clé-valeur, prête à être modifiée.
• uipathctl config orchestrator update-config --nlog-config nlog.config.json : met à jour la configuration avec vos modifications.

1. Exportez la configuration NLog personnalisée actuelle vers un fichier json à l'aide de cette commande :

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

2. Modifiez le fichier nlog.config.json exporté selon vos besoins. Vous pouvez ajouter, supprimer ou modifier l'un de ses paramètres.
   Remarque :

   Vous devrez exporter le fichier à nouveau chaque fois que vous devrez apporter une modification, car la mise à jour aura pour effet d’écraser tous les paramètres NLog.

3. Mettez à jour la configuration NLog à l'aide de cette commande :

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