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

Solucione problemas com o Temporal como um serviço no Automation Suite no OpenShift.

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 TaaS. O valor padrão do PostgreSQL de 100 não é suficiente. 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 de TaaS no cluster passivo para zero réplicas. Para obter detalhes sobre requisitos ativos/passivos para TaaS, consulte Visão geral.

O trabalho de inicialização de TaaS falha em um ambiente de proxy

Description

Quando o Maestro ou o Temporal como serviço (TaaS) são habilitados em um ambiente de proxy, o trabalho init do TaaS falha com o seguinte erro:

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

Os logs de pods taas-temporal-frontend, taas-temporal-history e taas-temporal-internal-frontend contêm o seguinte erro:

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

Os serviços TaaS conectam-se entre si por endereço IP do pod. Se a lista no_proxy não cobrir um endereço IP de pod, a conexão vai para o proxy, que não pode alcançar endereços IP de pod e rejeita a solicitação. Isso acontece quando os endereços IP dos pods ficam fora dos intervalos na lista no_proxy , por exemplo, quando o CIDR clusterNetwork fica fora de 10.0.0.0/8.

Solução

Para solucionar o problema, siga as seguintes etapas:

1. Adicione os intervalos de CIDR do pod e os intervalos de CIDR da sub-rede de nós a proxy.no_proxy em input.json. Para obter detalhes, consulte Proxy.

2. Aplique a configuração:

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