- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Post-installation
- Migration et mise à niveau
- Mise à niveau d'Automation Suite sur EKS/AKS
- Étape 1 : Déplacement des données d'organisation Identity d'installation autonome vers Automation Suite
- Étape 2 : Restauration de la base de données du produit autonome
- Étape 3 : Sauvegarder la base de données de la plate-forme dans Automation Suite
- Étape 4 : Fusion des organisations dans Automation Suite
- Étape 5 : Mise à jour des chaînes de connexion du produit migré
- Étape 6 : migration de la version autonome d'Orchestrator
- Étape 7 : Migration d’Insights en version autonome
- Étape 8 : suppression du locataire par défaut
- B) Migration à locataire unique
- Migration d'Automation Suite sur Linux vers Automation Suite sur EKS/AKS
- Surveillance et alerte
- Administration du cluster
- Effectuer la maintenance de la base de données
- Transfert des journaux d'application vers Splunk
- Configuration spécifique au produit
- Configuration des paramètres d'Orchestrator
- Paramètres de l'application Orchestrator
- Configuration des paramètres d'application
- Configuration de la taille maximale de la requête
- Remplacement de la configuration du stockage au niveau du cluster
- Configuration des magasins d'informations d'identification
- Configuration de la clé de chiffrement par locataire
- Nettoyer la base de données Orchestrator
- Rotation des informations d’identification de stockage d’objets blob
- Désactivation de l'utilisation d'URL pré-signées lors du téléchargement de données vers le stockage Amazon S3
- Configuration de la sécurité de l'application de processus
- Configurer une authentification Kerberos avec l’authentification MSSQL de base pour Process Mining
- Résolution des problèmes
- La configuration de sauvegarde ne fonctionne pas en raison d’un échec de connexion à Azure Government
- Pods dans l'espace de noms uipath bloqués lors de l'activation des rejets de nœuds personnalisés
- Impossible de lancer Automation Hub et Apps avec la configuration proxy
- Les pods ne peuvent pas communiquer avec le nom de domaine complet dans un environnement proxy
- La chaîne de connexion SQL de l’automatisation de test est ignorée
Transfert des journaux d'application vers Splunk
-
Cette section traite de l’exportation des journaux POD. Pour exporter les journaux du robot, consultez la section Orchestrator - À propos des journaux.
-
Splunk est un outil externe et UiPath® ne saurait vous conseiller sur la façon dont vous devez configurer votre paramètre Splunk. Pour en savoir plus sur le collecteur d’événements HTTP, consultez la documentation officielle de Splunk.
La pile Splunk-Fluentd est une solution de journalisation centralisée qui vous permet de rechercher, d'analyser et de visualiser les données de journal. Fluentd collecte et envoie les journaux à Splunk. Splunk récupère les journaux et vous permet de visualiser et d'analyser les données.
Créez un secret Kubernetes avec le jeton HTTP Event Collector (HEC) généré dans l'interface Splunk. Ce jeton est utilisé pour l'authentification entre Automation Suite et Splunk.
kubectl -n logging create secret generic splunk-hec-token --from-literal=splunk_hec_token=<splunk_hec_token>
kubectl -n logging create secret generic splunk-hec-token --from-literal=splunk_hec_token=<splunk_hec_token>
ClusterOutput
définit où vos journaux sont envoyés et décrit les détails de configuration et d'authentification.
Pour configurer la SortieCluster (ClusterOutput) pour Splunk, exécutez la commande suivante :
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: splunk-output
spec:
splunkHec:
buffer:
tags: '[]'
timekey: <splunk_hec_timekey>
timekey_use_utc: true
timekey_wait: 10s
type: file
hec_host: <splunk_hec_host>
hec_port: <splunk_hec_port>
hec_token:
valueFrom:
secretKeyRef:
key: splunk_hec_token
name: splunk-hec-token
index: <splunk_hec_index>
insecure_ssl: true
protocol: <splunk_hec_protocol>
source: <splunk_hec_source>
sourcetype: <splunk_hec_source_type>
EOF
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: splunk-output
spec:
splunkHec:
buffer:
tags: '[]'
timekey: <splunk_hec_timekey>
timekey_use_utc: true
timekey_wait: 10s
type: file
hec_host: <splunk_hec_host>
hec_port: <splunk_hec_port>
hec_token:
valueFrom:
secretKeyRef:
key: splunk_hec_token
name: splunk-hec-token
index: <splunk_hec_index>
insecure_ssl: true
protocol: <splunk_hec_protocol>
source: <splunk_hec_source>
sourcetype: <splunk_hec_source_type>
EOF
< >
par les valeurs correspondantes utilisées dans votre configuration Splunk. Pour plus de détails, consultez la table suivante :
Attribut |
Description |
---|---|
|
L'hôte réseau de votre instance Splunk. Il s'agit généralement de l'adresse IP ou du nom de domaine complet (FQDN) de Splunk. |
|
Le port Splunk pour la communication client. Ce port diffère généralement du port sur lequel vous lancez le tableau de bord Splunk. Le port HEC conventionnel pour Splunk est
8088 .
|
|
La clé secrète du jeton Splunk. Il s'agit du nom de la clé dans le secret que vous avez créé à l'étape précédente, qui contient le jeton HEC Splunk. Le manifeste présenté contient déjà la clé :
splunk_hec_token . Si vous n'avez pas modifié la commande pour créer une clé secrète, vous n'avez pas besoin de modifier cette valeur.
|
Valeur
splunk_hec_timekey dans splunkHec.buffer |
La fréquence de sortie ou la fréquence à laquelle vous souhaitez transférer les journaux. Nous vous recommandons d'utiliser un intervalle de 30 secondes (
30s ).
|
|
Le protocole de l'URL. Les valeurs valides sont
http et https . Vous devez utiliser le protocole HTTPS si la communication SSL est activée sur Splunk.
|
|
L'identifiant de l'index Splunk. Utilisé pour indexer les événements. |
|
Le champ relatif à la source des événements. |
|
Le champ relatif au type de source des événements. |
source
.
L'exemple suivant est basé sur la configuration présentée sur cette page.
ClusterFlow
pour définir :
- les journaux que vous souhaitez collecter et filtrer ;
- le
ClusterOutput
vers lequel envoyer les journaux.
Pour configurer FluxCluster (ClusterFlow) dans Fluentd, exécutez la commande suivante :
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: splunk-flow
namespace: logging
spec:
filters:
- tag_normaliser:
format: ${namespace_name}/${pod_name}.${container_name}
globalOutputRefs:
- splunk-output
match:
- select:
container_names:
- istio-proxy
namespaces:
- istio-system
- exclude:
container_names:
- istio-proxy
- istio-init
- aicenter-hit-count-update
- istio-configure-executor
- on-prem-tenant-license-update
- curl
- recovery
- aicenter-oob-scheduler
- cert-trustor
- exclude:
namespaces:
- default
- exclude:
labels:
app: csi-snapshotter
- exclude:
labels:
app: csi-resizer
- select: {}
EOF
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: splunk-flow
namespace: logging
spec:
filters:
- tag_normaliser:
format: ${namespace_name}/${pod_name}.${container_name}
globalOutputRefs:
- splunk-output
match:
- select:
container_names:
- istio-proxy
namespaces:
- istio-system
- exclude:
container_names:
- istio-proxy
- istio-init
- aicenter-hit-count-update
- istio-configure-executor
- on-prem-tenant-license-update
- curl
- recovery
- aicenter-oob-scheduler
- cert-trustor
- exclude:
namespaces:
- default
- exclude:
labels:
app: csi-snapshotter
- exclude:
labels:
app: csi-resizer
- select: {}
EOF
-
Cliquez sur Recherche et Rapport (Search & Reporting).
-
Recherche basée sur la Source, l'Index et le Type de source (Source Type).
Si, pour une raison quelconque, les journaux d'application ne sont pas transmis à Splunk, procédez comme suit :
- Modifiez le niveau du journal Fluentd pour déboguer.
- Interrogez le pod Fluentd :
kubectl patch logging -n logging logging-operator-logging --type=json -p '[{"op":"add","path":"/spec/fluentd/logLevel","value":debug}]' kubectl -n logging exec -it sts/logging-operator-logging-fluentd cat /fluentd/log/out
kubectl patch logging -n logging logging-operator-logging --type=json -p '[{"op":"add","path":"/spec/fluentd/logLevel","value":debug}]' kubectl -n logging exec -it sts/logging-operator-logging-fluentd cat /fluentd/log/outRemarque : les journaux Fluentd doivent indiquer la raison pour laquelle les données ne sont pas transmises à Splunk. - Après avoir résolu le problème, restaurez le niveau de journal Fluentd :
kubectl patch logging -n logging logging-operator-logging --type=json -p '[{"op":"remove","path":"/spec/fluentd/logLevel","value":debug}]'
kubectl patch logging -n logging logging-operator-logging --type=json -p '[{"op":"remove","path":"/spec/fluentd/logLevel","value":debug}]'