UiPath Documentation
automation-suite
2.2510
true
Guia de instalação do Automation Suite no EKS/AKS
Importante :
A tradução automática foi aplicada parcialmente neste conteúdo. A localização de um conteúdo recém-publicado pode levar de 1 a 2 semanas para ficar disponível.

Runbooks de alertas

Alerte os níveis de gravidade e os procedimentos de solução de problemas para alertas do Automation Suite no EKS/AKS.

Observação:
  • For general instructions on using the available tools for alerts, metrics, and visualizations, refer to Using the monitoring stack.
  • For more on how to fix issues and how to create a support bundle for UiPath® Support engineers, refer to Troubleshooting.
  • Ao entrar em contato com o Suporte da UiPath®, certifique-se de incluir todos os alertas que estão sendo disparados no momento.

Chave de gravidade do alerta​

A tabela a seguir descreve os níveis de severidade de alerta.

Gravidade do alertaDescription
InformaçõesInesperado, mas inofensivo. Pode ser silenciado, mas pode ser útil durante o diagnóstico.
AvisoIndicação de uma degradação direcionada da funcionalidade ou uma probabilidade de degradação em um futuro próximo, que pode afetar todo o cluster. Sugere ação imediata (geralmente dentro de dias) para manter o cluster íntegro.
CríticaConhecido por causar séria degradação da funcionalidade que geralmente é difundida no cluster. Requer ação imediata (no mesmo dia) para reparar o cluster.

Regras.Geral​

TargetDown​

O Prometheus não pode coletar métricas do destino no alerta, o que significa que os painéis do Grafana e outros alertas com base nas métricas desse destino não estarão disponíveis. Verifique outros alertas relativos a esse destino.

Kubernetes-storage​

KubePersistentVolumeFillingUp​

When Warning: The available space is less than 30% and is likely to fill up within four days.

When Critical: The available space is less than 10%.

Para qualquer serviço que fique sem espaço, pode ser difícil recuperar os dados, portanto, os volumes devem ser redimensionados antes de atingir 0% de espaço disponível.

For Prometheus-specific alerts, refer to PrometheusStorageUsage for details.

kubernetes-apps​

KubePodNotReady​

Um pod foi iniciado, mas não está respondendo à investigação de integridade com sucesso. Isso pode significar que ele está travado e não é capaz de atender ao tráfego. Você pode verificar os logs do pod com kubectl logs para conferir se há alguma indicação de progresso. Se o problema persistir, entre em contato com o Suporte da UiPath®.

kubernetes-system-kubelet​

KubeNodeNotReady, KubeNodeUnaccessable, KubeletDown​

Esses alertas indicam um problema com um nó. Em clusters de produção prontos para alta disponibilidade de vários nós, os pods provavelmente seriam reprogramados para outros nós. Se o problema persistir, você deverá remover e drenar o nó para manter a integridade do cluster. Em clusters sem capacidade adicional, é necessário primeiro associar outro nó ao cluster.

Se os problemas persistirem, entre em contato com o Suporte da UiPath®.

kubernetes-system​

KubernetesMemoryPressure​

Esse alerta indica que o uso de memória está muito alto no nó do Kubernetes.

Os nós do Kubernetes com tipo de incidente MemoryPressure ocorrem quando um nó do cluster do Kubernetes está com pouca memória, o que pode ser causado por um vazamento de memória em um aplicativo. Esse tipo de incidente requer atenção imediata para evitar tempo de inatividade e garantir o funcionamento adequado do cluster do Kubernetes.

Se esse alerta for disparado, tente identificar o pod no nó que está consumindo mais memória, seguindo estas etapas:

  1. Recupere as estatísticas de CPU e memória dos nós:
    kubectl top node
    kubectl top node
    
  2. Recupere os pods em execução no nó:
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME}
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME}
    
  3. Verifique o uso de memória para pods em um namespace usando:
    kubectl top pod --namespace <namespace>
    kubectl logs -f <pod-name> -n <ns>
    kubectl top pod --namespace <namespace>
    kubectl logs -f <pod-name> -n <ns>
    

Se você conseguir identificar qualquer pod com alto uso de memória, verifique os logs do pod e procure erros de vazamento de memória.

Para resolver o problema, aumente a especificação de memória para os nós, se possível.

If the issue persists, generate thesupport bundle and contact UiPath® Support.

KubernetesDiskPressure​

Esse alerta indica que o uso do disco é muito alto no nó Kubernetes.

Ao surgir esse alerta, tente ver qual pod está consumindo mais disco:

  • Confirme se o nó está sob DiskPressure usando o seguinte comando:
    kubectl describe node <node-name>
    kubectl describe node <node-name>
    

Identifique a condição DiskPressure na saída.

  • Verifique o uso do espaço em disco no nó afetado:
    df -h
    df -h
    

Isso mostra o uso do disco em todos os sistemas de arquivos montados. Identificar onde está o alto uso.

  • Se o disco estiver cheio e a limpeza for insuficiente, considere redimensionar o disco para o nó (principalmente em ambientes de nuvem, como AWS ou GCP). Esse processo pode envolver a expansão de volumes, dependendo de sua infraestrutura.

node-exporter​

NodeFilesystemSpaceFillingUp​

O sistema de arquivos em um nó específico está sendo preenchido completamente.

Ao surgir esse alerta, considere as etapas a seguir:

  • Confirme se o nó está sob DiskPressure usando o seguinte comando:
    kubectl describe node <node-name>
    kubectl describe node <node-name>
    

Identifique a condição DiskPressure na saída.

  • Limpe os logs e arquivos temporários. Verifique se há arquivos de log grandes em /var/log/ e limpe-os, se possível.
  • Verifique o uso do espaço em disco no nó afetado:
    df -h
    df -h
    

Isso mostra o uso do disco em todos os sistemas de arquivos montados. Identificar onde está o alto uso.

  • Se o disco estiver cheio e a limpeza for insuficiente, considere redimensionar o disco para o nó (principalmente em ambientes de nuvem, como AWS ou GCP). Esse processo pode envolver a expansão de volumes, dependendo de sua infraestrutura.

NodeNetworkReceiveErrs​

Esses erros indicam que o driver de rede está relatando um número alto de falhas. Isso pode ser causado por falhas de hardware físico ou configuração incorreta na rede física. Esse problema pertence ao sistema operacional e não é controlado pelo aplicativo UiPath®.

O alerta é acionado monitorando o contador/proc/net/dev que o kernel do Linux fornece.

Entre em contato com seu administrador de rede e a equipe que gerencia a infraestrutura física.

NodeNetworkTransmitErrs​

Esses erros indicam que o driver de rede está relatando um número alto de falhas. Isso pode ser causado por falhas de hardware físico ou configuração incorreta na rede física. Esse problema pertence ao sistema operacional e não é controlado pelo aplicativo UiPath®.

O alerta é acionado monitorando o contador/proc/net/dev que o kernel do Linux fornece.

Entre em contato com seu administrador de rede e a equipe que gerencia a infraestrutura física.

InternodeCommunicationBroken​

O nó parou de responder devido a algum problema que causou comunicação interrompida entre nós no cluster.

If the issue persists, reach out to UiPath® Support with the generated support bundle.

uipath.prometheus.resource.provisioning.alerts​

PrometheusMemoryUsage, PrometheusStorageUsage​

Esses alertas advertem quando o cluster está se aproximando dos limites configurados para memória e armazenamento. É provável que isso aconteça em clusters com um aumento substancial recente no uso (geralmente de robôs em vez de usuários) ou quando os nós são adicionados ao cluster sem ajustar os recursos do Prometheus. Isso se deve a um aumento na quantidade de métricas coletadas.

Isso também pode ser devido a um grande número de alertas que estão sendo disparados, é importante verificar por que a grande quantidade de alertas está sendo disparada.

If this issue persists, contact UiPath® Support with the generated support bundle.

alertmanager.rules​

AlertmanagerConfigInconsistent​

Este alerta é acionado quando as instâncias Alertmanager dentro do mesmo cluster têm configurações diferentes. Isso pode indicar um problema com a implantação da configuração que não é consistente em todas as instâncias do Alertmanager.

Para corrigir o problema, siga as seguintes etapas:

  1. Execute uma ferramenta diff entre todos os alertmanager.yml implantados para identificar o problema.
  2. Exclua o segredo incorreto e implante o correto.

Se o problema persistir, entre em contato com o Suporte da UiPath®.

AlertmanagerFailedReload​

AlertManager has failed to load or reload configuration. Please check any custom AlertManager configurations for input errors and otherwise contact UiPath® Support and provide the support bundle. For details, refer to Using the Automation Suite support bundle.

AlertmanagerMembersInconsistent​

Este alerta é acionado quando Alertmanager não encontrou todos os outros membros do cluster.

UiPathAvailabilityHighTrafficBackend, UiPathAvailabilityMediumTrafficUserFacing, UiPathAvailabilityMediumTrafficBackend, UiPathAvailabilityLowTrafficUserFacing, UiPathAvailabilityLowTrafficBackend​

A quantidade de respostas http 500 dos serviços da UiPath® excede um determinado limite.

A tabela a seguir lista os limites de nível de tráfego e taxas de erro.

Nível de tráfegoQuantidade de solicitações em 20 minutosLimite de erro (para http 500s)
Alta>100.0000,1%
MédioEntre 10.000 e 100.0001%
Baixa< 10.0005%

Os erros em serviços voltados para o usuário provavelmente resultariam em funcionalidade degradada que é diretamente observável na interface do usuário do Automation Suite, já os erros em serviços de back-end teriam consequências menos óbvias.

O alerta indica qual serviço está apresentando uma alta taxa de erro. Para entender quais problemas de cascata podem haver de outros serviços dos quais o serviço de relatório depende, você pode usar o painel de carga de trabalho do Istio, que mostra os erros entre os serviços.

Verifique novamente todos os produtos do Automation Suite recentemente reconfigurados. Logs detalhados também estão disponíveis com o comando kubectl logs. Se o erro persistir, entre em contato com o Suporte da UiPath®.

uipath.cronjob.alerts.rules​

IdentityKerberosTgtUpdateFailed​

Este trabalho atualiza o tíquete do Kerberos mais recente para todos os serviços da UiPath®. Falhas neste trabalho fariam com que a autenticação do SQL Server falhasse. Entre em contato com o Suporte da UiPath®.

ceph.rule, cluster-state-alert.rule​

CephMgrIsAbsent​

Esse alerta indica que o Ceph Manager desapareceu da descoberta de destino do Prometheus.

Se esse alerta for disparado, verifique e se o pod do Ceph Manager está funcionando e íntegro. Se o pod estiver íntegro, verifique os logs e verifique se o pod está habilitado para emitir métricas do Prometheus.

Nó Ceph Abaixo​

Esse alerta indica que um nó que executa pods do Ceph está inativo. Embora as operações de armazenamento continuem a funcionar, pois o Ceph foi projetado para lidar com uma falha de nó, é recomendável resolver o problema para minimizar o risco de outro nó ficar inativo e afetar as funções de armazenamento.

Se esse alerta for disparado, no caso de um cluster de vários nós, o pod deverá ser agendado em outro nó. Certifique-se de que os novos pods osd no namespace rook-ceph estejam em execução e em estado íntegro no novo nó.

Você pode verificar a falha do nó descrevendo o nó usando o seguinte comando:

kubectl get nodes
kubectl get nodes

Verifique o nó para identificar a causa raiz do problema e entre em contato com o Suporte da UiPath®.

Alertas Ceph​

CephClusterCriticallyFull​

Esse alerta indica que a utilização do cluster de armazenamento Ceph superou 80% e se tornará somente leitura aos 85%.

Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.

Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento.

CephClusterReadOnly​

Esse alerta indica que a utilização do cluster de armazenamento do Ceph ultrapassou 85% e se tornará somente leitura agora. Libere algum espaço ou expanda o cluster de armazenamento imediatamente.

Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.

Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento.

CephPoolQuotaBytesCriticallyExhausted​

Esse alerta indica que o uso do pool de armazenamento do Ceph ultrapassou 90%.

Se esse alerta disparar, libere algum espaço no CEPH excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.

Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento.

CephClusterErrorState​

Este alerta indica que o cluster de armazenamento Ceph está em estado de erro por mais de 10m.

Este alerta reflete que a tarefa rook-ceph-mgr esteve em estado de erro por um período de tempo inaceitável. Verifique se há outros alertas que possam ter sido acionados antes deste e solucione-os primeiro.

CephOSDCriticallyFull​

Quando a gravidade do alerta é Critical, o espaço disponível é inferior a 20%.

Para qualquer serviço que fique sem espaço, pode ser difícil recuperar os dados, portanto, você deve redimensionar os volumes antes de atingir 10% de espaço disponível. Consulte as instruções a seguir: .

uipath.requestrouting.alerts​

UiPathRequestRouting​

Erros na camada de roteamento de solicitação resultariam em funcionalidade degradada que é diretamente observável na interface do usuário do Automation Suite. As solicitações não serão roteadas para serviços de back-end.

Você pode encontrar o log de erro detalhado do roteamento de solicitações em pods istio-ingressgateway no namespace istio-system. Recupere o nome do pod executando os seguintes comandos:

kubectl get pods -n istio-system
kubectl logs <istio-ingressgateway-pod-name> -n istio-system
kubectl get pods -n istio-system
kubectl logs <istio-ingressgateway-pod-name> -n istio-system

Se o erro persistir, entre em contato com o Suporte da UiPath®.

osd-alert.rules​

CephOSFlaping​

Esse alerta indica que o daemon de armazenamento foi reiniciado mais de 5 vezes nos últimos 5 minutos.

Se esse alerta disparar, siga os seguintes passos:

  1. Verifique a integridade do cluster do Ceph. O YO deve executar ceph status na caixa de ferramentas do Ceph para identificar os OSDs flutuantes:

    kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
    kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
    

    Você pode identificar o pod de ferramentas do Ceph listando os pods no namespace:

    kubectl -n rook-ceph get pod | grep tools
    kubectl -n rook-ceph get pod | grep tools
    
  2. Verifique os logs do OSD para o pod do OSD para identificar problemas:

    kubectl -n rook-ceph logs <osd-pod>
    kubectl -n rook-ceph logs <osd-pod>
    
  3. Identificar problemas no nível do nó:

    • Verifique o uso do recurso:
      kubectl top node <node-name>
      kubectl top node <node-name>
      
    • Verifique a integridade do disco. Você precisa fazer o SSH no nó e executardf -h e dmesg para verificar os erros do disco.
  4. Reinicie o pod do OSD. Se o problema for transitório, será necessário reiniciar o pod do OSD:

    kubectl -n rook-ceph delete pod <osd-pod>
    kubectl -n rook-ceph delete pod <osd-pod>
    
  5. Certifique-se de que não haja problemas de conectividade de rede entre os OSDs e os monitores Ceph.

  6. Se necessário, marque temporariamente o OSD abaulado como out:

    ceph osd out <osd-id>
    ceph osd out <osd-id>
    
  7. Continue a monitorar o cluster para garantir que o problema não se repita.

CephOSDDiskNotResponding​

Esse alerta indica que o dispositivo de disco do host não está respondendo.

Se esse alerta disparar, siga os seguintes passos:

  1. Verifique o status do cluster do Ceph. Você precisa confirmar a integridade geral do cluster do Ceph e obter mais detalhes sobre o status do OSD:

    • Execute o seguinte comando dentro do pod da caixa de ferramentas do Ceph:
      kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
      kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
      
    • Identifique o pod de ferramentas do Ceph listando os pods no namespace:
      kubectl -n rook-ceph get pod | grep tools
      kubectl -n rook-ceph get pod | grep tools
      
  2. Verifique o status do pod do OSD. Você precisa verificar se os pods OSD estão em execução. Execute o seguinte comando para verificar todos os status do pod OSD:

    kubectl -n rook-ceph get pods | grep osd
    kubectl -n rook-ceph get pods | grep osd
    

    Se algum pod do OSD estiver em um estado CrashLoopBackOff ou Pending, isso pode indicar um problema com o disco OSD ou o nó subjacente.

  3. Reinicie o pod do OSD afetado. Se um pod do OSD estiver em um estado defeituoso (CrashLoopBackOff, Error etc.), você deve reiniciar o pod para ver se o problema se resolve sozinho. O Kubernetes tenta reagendar o pod automaticamente.

    kubectl -n rook-ceph delete pod <osd-pod>
    kubectl -n rook-ceph delete pod <osd-pod>
    

    O pod OSD será reiniciado e, se for um problema transitório, isso pode resolvê-lo.

  4. Verifique os logs do OSD. Se a reinicialização não resolver o problema, verifique os logs do pod OSD para obter mais detalhes sobre o motivo pelo qual o disco não está respondendo:

    kubectl -n rook-ceph logs <osd-pod>
    kubectl -n rook-ceph logs <osd-pod>
    

    Procure por erros relacionados ao disco ou outros problemas (por exemplo, erros de E/S, falhas de montagem).

  5. Identificar problemas no nível do nó. Se o disco OSD não estiver montado corretamente ou tiver sido desconectado, faça login no nó afetado e verifique o status de montagem do disco:

    ssh <node> df -h
    ssh <node> df -h
    

Procure por discos ausentes ou não montados que o Ceph está esperando. Se necessário, remonte o disco ou substitua-o se ele tiver falhado.

CephOSDDiskIndisponível​

Esse alerta indica que o disco OSD do Ceph não está acessível no host.

Se esse alerta disparar, siga os seguintes passos:

  1. Verifique o status do cluster do Ceph. Você precisa confirmar a integridade geral do cluster do Ceph e obter mais detalhes sobre o status do OSD:

    • Execute o seguinte comando dentro do pod da caixa de ferramentas do Ceph:
      kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
      kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
      
    • Identifique o pod de ferramentas do Ceph listando os pods no namespace:
      kubectl -n rook-ceph get pod | grep tools
      kubectl -n rook-ceph get pod | grep tools
      
  2. Verifique o status do pod do OSD. Você precisa verificar se os pods OSD estão em execução. Execute o seguinte comando para verificar todos os status do pod OSD:

    kubectl -n rook-ceph get pods | grep osd
    kubectl -n rook-ceph get pods | grep osd
    

    Se algum pod do OSD estiver em um estado CrashLoopBackOff ou Pending, isso pode indicar um problema com o disco OSD ou o nó subjacente.

  3. Reinicie o pod do OSD afetado. Se um pod do OSD estiver em um estado defeituoso (CrashLoopBackOff, Error etc.), você deve reiniciar o pod para ver se o problema se resolve sozinho. O Kubernetes tenta reagendar o pod automaticamente.

    kubectl -n rook-ceph delete pod <osd-pod>
    kubectl -n rook-ceph delete pod <osd-pod>
    

O pod do OSD será reiniciado e, se for um problema transitório, isso pode resolvê-lo. 4. Verifique os logs do OSD. Se a reinicialização não resolver o problema, verifique os logs do pod do OSD para obter mais detalhes sobre por que o disco não está respondendo:

kubectl -n rook-ceph logs <osd-pod>
kubectl -n rook-ceph logs <osd-pod>

Procure por erros relacionados ao disco ou outros problemas (por exemplo, erros de E/S, falhas de montagem).

persistent-volume-alert.rules​

PersistentVolumeUsageCritical​

Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.

Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento.

Alertas de certificado TLS do servidor​

SecretCertificateExpiry7Days​

Esse alerta indica que o certificado do servidor TLS expirará nos 7 dias seguintes.

To fix this issue, update the TLS certificate. For instructions, refer to Managing server certificates.

CertificadoDoRKE2Expiry7Days​

Esse alerta indica que o certificado do servidor RKE2 expirará nos 7 dias seguintes.

Alertas de certificado de assinatura de token de identidade​

IdentityCertificateExpiry30Days​

Este alerta indica que o certificado de assinatura do token de identidade expirará nos próximos 30 dias.

To fix this issue, update the Identity token signing certificate. For instructions, refer to Managing server certificates.

IdentityCertificateExpiry7Days​

Esse alerta indica que o certificado de assinatura do token de identidade expirará nos 7 dias seguintes.

To fix this issue, update the Identity token signing certificate. For instructions, refer to Managing server certificates.

Alertas etdc​

EtcdGrpcRequestsSlow​

Este alerta indica que as solicitações etcd GRPC estão lentas. Este é um aviso.

Se esse alerta persistir, entre em contato com o Suporte da UiPath®.

EtcdHttpRequestsSlow​

Este alerta indica que as solicitações HTTP estão ficando lentas. Este é um aviso.

Alertas de tamanho de disco​

LowDiskForRancherPartition​

Este alerta indica que o espaço livre para a partição /var/lib/rancher é menor que:

  • 35% - a gravidade do alerta é warning
  • 25% - a gravidade do alerta é crítica

Se esse alerta disparar, aumente o tamanho do disco.

LowDiskForKubeletPartition​

Este alerta indica que o espaço livre para a partição /var/lib/kubelet é menor que:

  • 35% - a gravidade do alerta é warning
  • 25% - a gravidade do alerta é crítica Se esse alerta for acionado, aumente o tamanho do disco.

LowDiskForVarPartition​

Este alerta indica que o espaço livre para a partição /var é menor que:

  • 35% - a gravidade do alerta é warning
  • 25% - a gravidade do alerta é crítica
Observação:

Os requisitos de armazenamento para habilidades de ML podem aumentar substancialmente o uso do disco.

Se esse alerta disparar, aumente o tamanho do disco.

PoucoDiscoParaPartiçãoDeVarLog​

Este alerta indica que o espaço livre para a partição /var/lib/var é menor que:

  • 25% - a gravidade do alerta é crítica

Se esse alerta disparar, aumente o tamanho do disco.

Alertas de backup​

NFSServerDisconnected​

Este alerta indica que a conexão do servidor NFS foi perdida.

Você precisa verificar a conexão do servidor NFS e o caminho de montagem.

VolumeBackupFailed​

Este alerta indica que o backup falhou para um PVC.

Para solucionar esse problema, siga as seguintes etapas:

  1. Verifique o status do PVC para garantir que seja Bound em relação a um Volume Persistente (PV).

    kubectl get pvc --namespace <namespace>
    kubectl get pvc --namespace <namespace>
    

    O comando lista todos os PVCs e seus status atuais. O PVC deve ter um status de Bound para indicar que reivindicou um PV com sucesso.

    Se o status for Pending, significa que o PVC ainda está aguardando um PV adequado, e é necessária uma investigação mais aprofundada.

  2. Se o PVC não estiver em um estado Bound ou se você precisar de informações mais detalhadas, use o comando describe:

    kubectl describe pvc <pvc-name> --namespace <namespace>
    kubectl describe pvc <pvc-name> --namespace <namespace>
    

    Procure informações sobre o status, eventos e quaisquer mensagens de erro. Por exemplo, um problema pode estar relacionado a configurações incorretas de classes de armazenamento ou limitações de cota.

  3. Verifique a integridade do Volume Persistente (PV) que está vinculado ao PVC:

    kubectl get pv <pv-name>
    kubectl get pv <pv-name>
    

    O status deve ser Bound. Se o PV estiver em um estado Released ou Failed, isso pode indicar problemas com o armazenamento subjacente.

  4. Se o PVC for usado por um pod, verifique se o pod montou o volume com sucesso:

    kubectl get pod <pod-name> --namespace <namespace>
    kubectl get pod <pod-name> --namespace <namespace>
    

    Se o pod estiver em um estado Running, isso indica que o PVC foi montado com sucesso. Se o pod estiver em um estado de erro (como InitBackOff), isso pode indicar problemas na montagem do volume.

  5. Se houver problemas com a montagem do PVC, descreva o pod para verificar se há erros de montagem:

    kubectl describe pod <pod-name> --namespace <namespace>
    kubectl describe pod <pod-name> --namespace <namespace>
    

BackupDesabilitado​

Este alerta indica que o backup está desabilitado.

Você precisa habilitar o backup.

Backup parcialmente falhado​

Esse alerta indica que o backup do Velero falhou.

Você precisa entrar em contato com o Suporte da UiPath®.

Esta página foi útil?

Conectar

Precisa de ajuda? Suporte

Quer aprender? Academia UiPath

Tem perguntas? Fórum do UiPath

Fique por dentro das novidades