Solução de problemas de Temporal como um serviço

Soluções para problemas temporários como um serviço no Automation Suite no EKS/AKS.

Os fluxos de trabalho do Maestro estão travados ou não estão iniciando

Problema: as instâncias de processo do Maestro permanecem em um estado pendente ou em execução sem progredir.

Causa: os pods do TaaS estão indisponíveis ou não estão íntegros, impedindo que as tarefas de fluxo de trabalho sejam enviadas ou coletadas pelos trabalhadores.

Resolution

1. Verifique o status de todos os pods TaaS:

   kubectl get pods -n uipath | grep taas
   

2. Identifique quaisquer pods que não estejam no estado Running e revise seus logs:

   kubectl logs -n uipath <pod-name> --tail=100
   

3. Procure entradas de nível warn e error . As causas comuns incluem falhas de conectividade do banco de dados e esgotamento de recursos.
4. Se o pod taas-temporal-history estiver reiniciando, verifique o uso de memória. O serviço de histórico faz uso intensivo de memória, e seu dimensionador automático é configurado na utilização de memória.

Os pods TaaS estão gerando um loop de falhas

Problema: um ou mais pods taas-temporal-* estão no estado CrashLoopBackOff .

Causa: a causa mais comum é uma falha na conexão com o banco de dados PostgreSQL na inicialização.

Resolution

1. Revise os logs do pod afetado:

   kubectl logs -n uipath <pod-name> --previous
   

2. Verifique se há erros de conexão que fazem referência ao armazenamento de persistência ou visibilidade.
3. Verifique se o servidor PostgreSQL é acessível a partir do cluster e se as credenciais no segredo taas-temporal-app-secrets estão corretas.
4. Confirme se o valor PostgreSQL max_connections atende ao requisito mínimo para seu perfil do TaaS. O valor padrão do PostgreSQL de 100 é insuficiente. Para os valores necessários por perfil, consulte Banco de dados SQL.

A execução do fluxo de trabalho está lenta

Problema: os fluxos de trabalho do Maestro são iniciados, mas as tarefas demoram mais do que o esperado para serem selecionadas ou concluídas.

Causa: o TaaS está com falta de recursos, o pool de conexões do PostgreSQL está esgotado ou o número de pesquisadors de trabalho é insuficiente para a carga atual.

Resolution

1. Verifique as métricas do Prometheus para temporal_activity_schedule_to_start_latency_bucket e temporal_workflow_task_schedule_to_start_latency_bucket. Valores altos indicam que as tarefas estão esperando na fila por mais tempo do que o esperado.
2. Verifique se a instância do PostgreSQL tem conexões disponíveis suficientes. O esgotamento do pool de conexões causa tempos limite de persistência sob carga.
3. Revise o uso de recursos do pod para taas-temporal-history e taas-temporal-matching. Se os pods forem restritos por CPU ou memória, considere ajustar os limites de recursos ou dimensionar a implantação.

Acesso à interface gráfica Temporal para diagnóstico

A interface gráfica da Web Temporal (taas-temporal-web) não fica exposta fora do cluster por padrão. Para acessá-lo para fins de diagnóstico, encaminhe a porta para o pod:

kubectl port-forward -n uipath deployment/taas-temporal-web 8008:8008

Abra http://localhost:8008 em um navegador. Não é necessário fazer login ao acessar via encaminhamento de porta.

A Interface Gráfica Temporal permite inspecionar execuções de fluxos de trabalho individuais, visualizar o histórico de execuções e identificar atividades com falha ou expiradas.

Erros de contenção de bloqueio em logs do TaaS

Problema: os logs do TaaS contêm erros que fazem referência à contenção de bloqueios ou gravações de banco de dados conflitantes.

Causa: dois clusters do Kubernetes estão conectados ao mesmo armazenamento de persistência do PostgreSQL simultaneamente. Apenas um cluster pode executar ativamente o TaaS por vez.

Resolution

Em uma implantação ativa/passiva, dimensione todas as implantações do TaaS no cluster passivo para zero réplicas. Para obter detalhes sobre requisitos ativos/passivos para o TaaS, consulte Visão geral.

TaaS init job fails in a proxy environment

Description

When Maestro or Temporal as a Service (TaaS) is enabled in a proxy environment, the TaaS init job fails with the following error:

Unable to get namespace default info ... context deadline exceeded

The taas-temporal-frontend, taas-temporal-history, and taas-temporal-internal-frontend pod logs contain the following error:

failed to do connect handshake ... HTTP/1.1 503

TaaS services connect to each other by pod IP address. If the no_proxy list does not cover a pod IP address, the connection goes to the proxy, which cannot reach pod IP addresses and rejects the request. This happens when pod IP addresses fall outside the ranges in the no_proxy list, for example with EKS custom networking or AKS with Azure CNI Overlay.

Solução

Para solucionar o problema, siga as seguintes etapas:

1. Add the pod CIDR ranges and the node subnet CIDR ranges to proxy.no_proxy in input.json. For details, refer to Proxy.

2. Apply the configuration:

   uipathctl manifest apply input.json --versions versions.json