Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Solução de problemas

Guia rápido de solução de problemas

Aqui está um guia rápido para solucionar a inicialização do SUSE Observability:

  1. Verifique se a instalação foi concluída com sucesso e se a versão está listada:

    helm list --namespace suse-observability

  2. Verifique se todos os pods no namespace do SUSE Observability estão em execução:

    kubectl get pods

    Em uma primeira implantação, pode ser que os contêineres em vários pods reiniciem algumas vezes, pois estão aguardando outros pods iniciarem e estarem no estado ready. Isso pode ser atrasado devido a agendamento e atrasos no download da imagem do docker.

    Pods que estão no estado pending geralmente indicam um problema:

    • O pod não pode ser agendado devido à falta de recursos no cluster. Se um autoescalador de cluster estiver ativo, ele geralmente conseguirá resolver isso automaticamente; caso contrário, é necessária intervenção manual para adicionar mais nós ao cluster.

    • O pod não pode ser agendado, existem nós nos quais ele se encaixaria, mas esses nós têm taints que o pod não tolera. Para resolver isso, mais nós podem ser adicionados que não têm as taints, mas o SUSE Observability também pode ser configurado para tolerar certas taints e rodar nos nós com taints.

    • O pod está aguardando que os Volumes Persistentes (PVs) sejam montados. Uma causa pode ser que o Helm chart do SUSE Observability não especifique um storageClassName, mas dependa do cluster ter uma classe de armazenamento padrão. Quando não há padrão para o cluster, é necessário especificar uma classe de armazenamento através dos valores do Helm do SUSE Observability.

      Para pods com estado ImagePullBackOff, verifique também a mensagem de erro exata; causas comuns são:

    • Um nome de usuário/senha incorretos usados para puxar as imagens

    • A conexão com o registro do docker falhou, isso pode ser devido a problemas de autenticação ou problemas de conectividade (gateways de segurança, instalações air-gapped)

    • Um erro de digitação na URL do registro de imagem do docker substituído

    Para descobrir uma causa mais detalhada para os estados Pending, ImagePullBackOff ou CrashLoopBackOff, use este comando:

    +

    kubectl describe pod <pod-name>

    + A saída contém uma seção event no final que geralmente contém o problema. Ele também possui uma seção State para cada contêiner que contém mais detalhes sobre a terminação do contêiner.

  3. Quando você é um cliente prime, entre em contato com o suporte da SUSE Observability pelo https://scc.suse.com/ para obter ajuda na configuração do SUSE Observability em seu cluster local. Use Pacote de Suporte (Logs) para coletar informações sobre sua instância para a equipe de suporte.

  4. Se o problema estiver relacionado ao desempenho, execute Pacote de Suporte (Desempenho) para investigar ativamente o desempenho.

  5. Caso os passos acima não tenham resolvido o problema, há um Guia Avançado de Solução de Problemas disponível.