- Visão geral
- Requisitos
- Instalação
- Pós-instalação
- Migração e atualização
- Atualização do Automation Suite no EKS/AKS
- Etapa 1: mover os dados da organização do Identity, de independente para o Automation Suite
- Etapa 2: restauração do banco de dados de produtos independente
- Etapa 3: backup do banco de dados da plataforma no Automation Suite
- Etapa 4: mesclando organizações no Automation Suite
- Etapa 5: atualização das strings de conexão do produto migradas
- Etapa 6: migração do Orchestrator independente
- Etapa 7: migração do Insights independente
- Etapa 8: exclusão do tenant padrão
- B) Migração de um único tenant
- Migração do Automation Suite no Linux para o Automation Suite no EKS/AKS
- Monitoramento e alertas
- Administração de cluster
- Fazendo a manutenção do banco de dados
- Forwarding application logs to Splunk
- Configuração específica do produto
- Configuração de parâmetros do Orchestrator
- Configurações de aplicativo do Orchestrator
- Configuração do AppSettings
- Configuração do tamanho máximo da solicitação
- Substituição da configuração de armazenamento no nível do cluster
- Configuração dos repositórios de credenciais
- Configuração da chave de criptografia por tenant
- Limpeza do banco de dados do Orchestrator
- Solução de problemas
- A configuração de backup não funciona devido a uma falha na conexão com o Azure Government
- Pods no namespace uipath travaram ao habilitar taints de nó personalizado
- Não é possível iniciar o Automation Hub e o Apps com configuração de proxy
- Os pods não podem se comunicar com o FQDN em um ambiente de proxy
- A cadeia de caracteres de conexão SQL da Automação de Teste é ignorada
Forwarding application logs to Splunk
-
Esta seção abrange a exportação de logs de POD. Para exportar logs de robôs, consulte Orchestrator – Sobre Logs.
-
Splunk é uma ferramenta externa, e a UiPath® não tem uma diretriz sobre como você deve definir a configuração do Splunk. Para obter mais detalhes sobre o Coletor de eventos HTTP, consulte a documentação oficial do Splunk.
A pilha Splunk-Fluentd é uma solução de registro centralizada que permite pesquisar, analisar e visualizar dados de registro. O Fluentd coleta e envia os logs para o Splunk. O Splunk recupera os logs e permite visualizar e analisar os dados.
Crie um segredo do Kubernetes com o token do HTTP Event Collector (HEC) gerado na interface do Splunk. Esse token é usado para a autenticação entre o Automation Suite e o 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
define para onde seus logs são enviados e descreve as configurações e detalhes de autenticação.
Para configurar o ClusterOutput para Splunk, execute o seguinte comando:
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
< >
pelos valores correspondentes usados na configuração do Splunk. Para detalhes, consulte a seguinte tabela:
Atributo |
Description |
---|---|
|
O host de rede da sua instância do Splunk. Geralmente é o endereço IP ou FQDN do Splunk. |
|
A porta Splunk para comunicação com o cliente. Essa porta geralmente difere da porta na qual você inicia o painel do Splunk. A porta HEC convencional para Splunk é
8088 .
|
|
A chave secreta do token Splunk. Este é o nome da chave no segredo que você criou na etapa anterior, que contém o token Splunk HEC. O manifesto apresentado já contém a chave:
splunk_hec_token . Se você não alterou o comando para criar um segredo, não precisa alterar esse valor.
|
splunk_hec_timekey valor em splunkHec.buffer |
A frequência de saída ou com que frequência você deseja enviar logs. Recomendamos usar um intervalo de 30 segundos (
30s ).
|
|
O protocolo URL. Os valores válidos são
http e https . Você deve usar o protocolo HTTPS se tiver a comunicação SSL habilitada no Splunk.
|
|
O identificador para o índice Splunk. Usado para indexar eventos. |
|
O campo de origem para eventos. |
|
O tipo de origem para eventos. |
source
.
O seguinte exemplo é baseado na configuração apresentada nesta página.
ClusterFlow
para definir:
- os logs que você deseja coletar e filtrar;
- o
ClusterOutput
para o qual enviar os logs.
Para configurar o ClusterFlow no Fluentd, execute o seguinte comando:
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
-
Clique em Pesquisar e Relatar.
-
Busque com base em Origem, Índice e Tipo de Origem.
Se, por algum motivo, os logs do aplicativo não forem enviados para o Splunk, siga as seguintes etapas:
- Altere o nível de log do Fluentd para depuração.
- Consulte o pod do 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/outObservação: os logs do Fluentd devem indicar a causa dos dados não serem enviados para o Splunk. - Após corrigir o problema, restaure o nível de log do 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}]'