Perguntas frequentes e guia de solução de problemas do CX Cloud Agent

Introdução

Este documento inclui perguntas frequentes e cenários de solução de problemas que os usuários podem encontrar ao trabalhar com o CX Cloud Agent.

Implantação

P. O redirecionamento de URL para cloudfront.net é um comportamento esperado ao se conectar ao domínio back-end da nuvem CX?

A. Sim, para alguns cenários de implantação específicos, o redirecionamento para cloudfront.net é esperado. Oo acesso não associado deve ser permitido com o redirecionamento habilitado na porta 443 para esses FQDNs.

P. Com a opção "Reinstalar", o usuário pode implantar o novo CX Cloud Agent com um novo endereço IP?

A. Sim

P. Quais formatos de arquivo estão disponíveis para instalação?

A. OVA e VHD

P. Em que ambiente o instalável pode ser implantado?

A. Para os ÓVULOS

• VMWare ESXi versão 5.5 ou posterior
• Oracle Virtual Box 5.2.30 ou posterior

Para VHD

• Hipervisor Windows 2012 a 2016

P. O CX Cloud Agent pode detectar um endereço IP em um ambiente DHCP?

R. Sim, a atribuição de endereço IP durante a configuração IP é detectada. No entanto, a alteração de endereço IP esperada para o CX Cloud Agent no futuro não é suportada. Recomenda-se que os clientes reservem o IP para o CX Cloud Agent em seu ambiente DHCP.

P. O CX Cloud Agent é compatível com a configuração IPv4 e IPv6?

R. Não, somente o IPV4 é suportado.

P. Durante a configuração do IP, o endereço IP é validado?

R. Sim, a sintaxe do endereço IP e a atribuição de endereço IP duplicado são validadas.

P. Quanto tempo leva para a implantação do OVA e a configuração IP?

R.A implantação do OVA depende da velocidade da rede que copia os dados. A configuração IP leva aproximadamente de 8 a 10 minutos, incluindo Kubernetes e criações de contêineres.

P. Há alguma limitação em relação a algum tipo de hardware?

R. A máquina host na qual o OVA é implantado deve atender aos requisitos fornecidos como parte da configuração do portal do CX. O CX Cloud Agent é testado com a caixa VMware/Virtual em execução em um hardware com processadores Intel Xeon E5 com a proporção de vCPU/CPU definida como 2:1. Se for usada uma CPU de processador menos potente ou uma proporção maior, o desempenho poderá ser prejudicado.

P. O código de emparelhamento pode ser gerado a qualquer momento?

R. Não, o código de emparelhamento só pode ser gerado quando o CX Cloud Agent não está registrado.

P. Quais são os requisitos de largura de banda entre os Cisco Catalyst Centers (para até 10 clusters ou 20 não clusters) e o CX Cloud Agent?

R.A largura de banda não é uma restrição quando o CX Cloud Agent e o Cisco Catalyst Center estão na mesma rede LAN/WAN no ambiente do cliente. A largura de banda de rede mínima necessária é de 2,7 Mbit/s para coletas de inventário de 5.000 dispositivos +13000 Pontos de Acesso para uma conexão de Agente com o Cisco Catalyst Center. Se syslogs forem coletados para insights de Nível 2, a largura de banda mínima necessária será de 3,5 Mbits/s para coberturas de 5.000 dispositivos +13000 Pontos de acesso para inventário, 5.000 dispositivos syslogs e 2.000 dispositivos para varreduras - todos executados em paralelo do CX Cloud Agent.

P. Como os syslogs do Agente pode ser acessado para monitorar a máquina virtual (VM) do CX Cloud Agent?

R. Os Syslogs para a VM do agente podem ser acessados a partir do login da VM local usando os dois caminhos a seguir:

/var/log/syslog.1 (acessado via logons cxcadmin e cxcroot)

/var/log/syslog (acessado usando a raiz)

Versões e correções

P. Quais são os diferentes tipos de versões listadas para a atualização do CX Cloud Agent?

R. Aqui é mostrado o conjunto das versões lançadas do CX Cloud Agent que estão listadas:

• A.x0 (onde x é a principal versão do recurso de produção mais recente, exemplo: 1.3.0).
• A.x.y (onde A.x.0 é obrigatório e a atualização incremental deve ser iniciada, x é a versão mais recente do recurso principal de produção e y é o patch de atualização mais recente que está ativo, por exemplo: 1.3.1)
• A.x.y-z (onde A.x.0 é obrigatório e o upgrade incremental a ser iniciado, x é a versão mais recente do recurso principal de produção e y é o patch de upgrade mais recente que está ativo e z é o patch spot que é uma correção instantânea por um período de tempo muito curto, por exemplo: 1.3.1-1)

em que A é uma versão de longo prazo distribuída por 3-5 anos.

P. Onde encontrar a versão mais recente do CX Cloud Agent e como atualizar o CX Cloud Agent existente?

R. Para localizar e atualizar para o CX Cloud Agent mais recente:

1. Faça login no portal CX Cloud e navegue até o Admin Center. A janela Fontes de dados é aberta.
2. Selecione CX Cloud Agent para abrir a visualização detalhada e clique na guia Software.
3. Faça uma seleção na lista suspensa Escolha uma versão de software para atualizar e clique em Instalar atualização.

Autenticação e configuração de proxy

P. Qual é o usuário padrão do aplicativo CX Cloud Agent?

A. cxcadmin

P. Como a senha é definida para o usuário padrão?

R. As senhas são definidas durante a configuração da rede.

P. Há uma opção disponível para redefinir a senha após o Dia-0?

R. Nenhuma opção específica é fornecida pelo CX Cloud Agent para redefinir a senha, mas você pode usar os comandos do Linux para redefinir a senha para cxcadmin.

P. Quais são as políticas de senha para configurar o CX Cloud Agent?

R. As políticas de senha são:

• Idade máxima (duração) definida como 90 dias
• Idade mínima (duração) definida como 8 dias
• Comprimento máximo de 127 caracteres
• Pelo menos um caractere maiúsculo e um caractere minúsculo devem ser incluídos
• Deve conter pelo menos um caractere especial (por exemplo, !$%^&*()_+|~-=\`{}[]:";'<>?,/)
• Os seguintes caracteres não são permitidos
• Caracteres especiais de 8 bits (por exemplo, ¬£, √Å √', √¥, √ë, ¬ø, √ü)
• Espaços
• Não devem ser as últimas 10 senhas usadas recentemente
• Não deve conter expressão regular
• Não deve conter as seguintes palavras ou derivações: cisco, sanjose e sanfran

P. Como confirmo o alcance do Secure Shell (SSH) a um dispositivo do CX Cloud Agent?

R. Para confirmar a alcançabilidade SSH:

1. Efetue login como cxcroot user.
2. Execute o seguinte comando para ativar a porta SSH em Iptables:

     Iptables -A OUTPUT -p tcp -m tcp —dport 22 -j ACCEPT

3. Execute o seguinte comando para confirmar a alcançabilidade SSH:

     ssh user@ip-address:port

Para desativar as portas SSH ativadas acima no CX Cloud Agent:

1. Execute o seguinte comando para obter o número de linha da porta SSH habilitada nas iptables:

     iptables -L OUTPUT —line-number | grep dpt | grep ssh | awk '{print $1}'

2. Execute o seguinte comando para excluir o número de linha obtido:

     iptables -L OUTPUT <Número da linha>

P. Como confirmo o alcance de SNMP para um dispositivo do CX Cloud Agent?

R. Para confirmar a acessibilidade do SNMP:

1. Efetue login como cxcroot user.
2. Execute o seguinte comando para ativar as portas SNMP nos Iptables:

      iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT

      iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT

3. Execute o seguinte comando snmpwalk/snmpget para confirmar a acessibilidade do SNMP:

      snmpwalk -v2c -c IPADDRESS cisco

Para desativar as portas SNMP ativadas acima no CX Cloud Agent:

1. Execute o seguinte comando para obter os números de linha das portas SNMP ativadas (dois números de linha são gerados como resposta):

iptables -L OUTPUT —line-number | grep dpt | grep ssh | awk '{print $1}'

2. Execute o seguinte comando para excluir os números de linha (em ordem decrescente):

iptables -L OUTPUT <Número da linha2 Número>

iptables -L OUTPUT <Número da linha1 Número>

P. Como defino a senha do Grub?

R. Para definir a senha do Grub:

1. Execute .ssh como cxcroot e forneça o token [entre em contato com a equipe de suporte para obter o token cxcroot].
2. Execute sudo su, para fornecer o mesmo token.
3. Execute o comando grub-mkpasswd-pbkdf2 e defina a senha do Grub. O hash da senha fornecida será impresso, copie o conteúdo.
4. vi para o arquivo /etc/grub.d/00_header. 
5. Navegue até o final do arquivo e substitua a saída de hash seguida pelo ***** raiz content password_pbkdf2 pelo hash obtido para a senha obtida na etapa 3.
6. Salve o arquivo com o comando :wq!.
7. Execute o comando update-grub.

P. Qual é o período de expiração da senha cxcadmin?

R. A senha expira em 90 dias.

P. O sistema desabilita a conta após tentativas consecutivas malsucedidas de login?

R. Sim, a conta é desativada após cinco (5) tentativas consecutivas malsucedidas. O período de bloqueio é de 30 minutos.

P. Como gerar uma senha?

R. Para gerar uma senha:

1. Execute .ssh e faça login como usuário cxcadmin.
2. Execute o comando remoteaccount cleanup -f.
3. Execute o comando remoteaccount create.

P. O host proxy suporta nome de host e IP?

R. Sim, mas para usar o nome de host, o usuário deve fornecer o IP do Servidor de Nomes de Domínio (DNS) durante a configuração da rede.

Secure Shell SSH

P. Que cifras são suportadas pelo shell ssh?

R. São suportadas as seguintes cifras:

• chacha20-poly1305@openssh.com
• aes256-gcm@openssh.com
• aes128-gcm@openssh.com
• aes256-ctr
• aes192-ctr
• aes128-ctr

P. Como faço login no console?

A. Para fazer login:

1. Efetue login como cxcadmin user
2. Forneça a senha cxcadmin

P. Os logons SSH são registrados?

R. Sim, eles são registrados como parte do arquivo "var/logs/audit/audit.log".

P. Qual é o timeout de sessão ociosa?

R. O tempo limite da sessão SSH ocorre se o CX Cloud Agent estiver ocioso por cinco (5) minutos.

Portas e serviços

Q. Que portas são mantidas abertas no CX Cloud Agent?

R. As seguintes portas estão disponíveis:

• Porta de saída: o CX Cloud Agent implantado pode se conectar ao back-end da Cisco conforme indicado na tabela na porta HTTPS 443 ou através de um proxy para enviar dados à Cisco, conforme indicado na tabela abaixo. O CX Cloud Agent implantado pode se conectar ao Cisco Catalyst Center na porta HTTPS 443.

AMÉRICAS	EMEA (Europa, Oriente Médio e África)	APJC
cloudsso.cisco.com	cloudsso.cisco.com	cloudsso.cisco.com
api-cx.cisco.com	api-cx.cisco.com	api-cx.cisco.com
agent.us.csco.cloud	agent.emea.cisco.cloud	agent.apjc.cisco.cloud
ng.acs.agent.us.csco.cloud	ng.acs.agent.emea.cisco.cloud	ng.acs.agent.apjc.cisco.cloud

Observação: além dos domínios listados, quando os clientes da EMEA ou da APJC reinstalarem o CX Cloud Agent, o domínio agent.us.csco.cloud deverá ser permitido no firewall do cliente.
O domínio agent.us.csco.cloud não é mais necessário após uma reinstalação bem-sucedida.

Observação: certifique-se de que o tráfego de retorno deve ser permitido na porta 443.

• Inbound port: Para o gerenciamento local do CX Cloud Agent, o 514(Syslog) e o 22 (ssh) devem estar acessíveis. Os clientes devem permitir que a porta 443 em seu firewall receba dados do CX Cloud.

Conexão do agente de nuvem CX com o Cisco Catalyst Center e outros ativos

P. Qual é o objetivo e a relação do Cisco Catalyst Center com o CX Cloud Agent?

R. O Cisco Catalyst Center é o agente de nuvem que gerencia os dispositivos de rede nas instalações do cliente. O CX Cloud Agent coleta informações de inventário de dispositivos do Cisco Catalyst Center configurado e carrega as informações de inventário disponíveis na Visualização de ativos do CX Cloud.

P. Onde os usuários podem fornecer detalhes do Cisco Catalyst Center sobre o CX Cloud Agent?

R. Durante o dia 0 - configuração do CX Cloud Agent, os usuários podem adicionar os detalhes do Cisco Catalyst Center no portal CX Cloud. Durante as operações do Dia N, os usuários podem adicionar outros Cisco Catalyst Centers a partir doAdmin Settings > Data Source.

P. Quantos Cisco Catalyst Centers podem ser adicionados?

R. É possível adicionar dez (10) clusters do Cisco Catalyst Center ou 20 clusters não Cisco Catalyst Center.

P. Como remover um Cisco Catalyst Center conectado do CX Cloud Agent? 

R. Para remover um Cisco Catalyst Center conectado do CX Cloud Agent, entre em contato com o Technical Assistance Center (TAC) para abrir um caso de suporte no portal CX Cloud.

P. Que função o usuário do Cisco Catalyst Center pode ter?

R. A função de usuário pode ser admin ou observer.

P. Como as modificações são refletidas no CX Cloud Agent devido a alterações nas credenciais conectadas do Cisco Catalyst Center?

R. Execute o comando cxcli agent modifyController no console do CX Cloud Agent:

    Entre em contato com o suporte para qualquer problema durante a atualização de credenciais do Cisco Catalyst Center.

P. Como o Cisco Catalyst Center e os detalhes de ativos de arquivos de seed são armazenados no CX Cloud Agent?

R. Todos os dados, incluindo as credenciais dos controladores conectados ao CX Cloud Agent (por exemplo, Cisco Catalyst Center) e ativos diretamente conectados (por exemplo, via arquivo semente, faixa de IP), são criptografados usando AES-256 e armazenados no banco de dados do CX Cloud Agent que é protegido com uma ID de usuário e senha seguras.

P. Há alguma limitação para inserir intervalos de IP ao adicionar outros ativos?

R. Sim, o CX Cloud Agent não pode lidar com operações de descoberta para intervalos de IP de sub-rede maiores. A Cisco recomenda o uso de intervalos de sub-rede minimizados, limitados a 10.000 endereços IP.

P. Uma sub-rede pública pode ser usada para a implantação do CX Cloud Agent v2.4 para a sub-rede personalizada de cluster e serviço?

R. A Cisco não recomenda o uso de uma sub-rede IP pública pelos seguintes motivos:

• Riscos à segurança: o endereço IP público expõe clusters e serviços à Internet, aumentando o risco de acesso não autorizado, ataques e possíveis violações de dados.
• Conflitos de endereço IP: o uso de sub-redes IP públicas pode levar a conflitos de IP, especialmente se os mesmos endereços IP forem atribuídos em outro lugar da Internet, levando a problemas de conectividade e comportamento inesperado.
• Complexidade na configuração de rede: o gerenciamento de políticas de rede, regras de firewall e roteamento torna-se mais complexo ao lidar com endereços IP públicos. Isso pode levar a configurações incorretas e aumento da sobrecarga de manutenção.

Uma sub-rede IP pública pode ser usada se for atribuída somente a uma organização do cliente e configurada na rede do cliente.

P. Com que frequência a operação de redescoberta pode ser iniciada?

R. A operação de redescoberta só deve ser executada se houver uma alteração na rede do cliente (por exemplo, depois que os dispositivos são adicionados ou excluídos na rede).

P. Qual é o fluxo de trabalho para adicionar "Outros ativos como fonte de dados" ao carregar um arquivo de seed?

R. O fluxo de trabalho é o seguinte:

1. Carregue o arquivo de seed no CX Cloud.
2. O arquivo de seed é armazenado temporariamente no bucket do Cisco Cloud AWS S3 (com criptografia SSE ativada).
3. O arquivo de seed é enviado para o CX Cloud Agent e o arquivo de seed é excluído do bucket de S3
4. O CX Cloud Agent processa as entradas do arquivo de seed e criptografa as credenciais usando uma chave AES 256 (essa chave é exclusiva para cada CX Cloud Agent). Essas credenciais criptografadas são armazenadas no banco de dados do CX Cloud Agent.
5. O arquivo de seed é excluído do CX Cloud Agent depois que as entradas do arquivo de seed são processadas.

P. Que tipo de criptografia é usada ao acessar a API do Cisco Catalyst Center a partir do CX Cloud Agent?

R. O HTTPS sobre TLS 1.2 é usado para a comunicação entre o Cisco Catalyst Center e o CX Cloud Agent.

Q. Quais operações são realizadas pelo CX Cloud Agent no Cisco Catalyst Center Cloud Agent integrado?

R. O CX Cloud Agent coleta dados do Cisco Catalyst Center sobre dispositivos de rede e usa a interface de execução de comandos do Cisco Catalyst Center para conversar com dispositivos finais e executar comandos CLI (comando show). Os comandos de alteração de configuração não são executados.

P. Que dados padrão são coletados do Cisco Catalyst Center e carregados no back-end?

A. 

• Entidade de rede
• Módulos
• show version
• Config
• Informações da imagem do dispositivo
• Tags

P. Que dados adicionais são coletados do Cisco Catalyst Center e carregados no back-end da Cisco?

R. Consulte este documento para obter mais informações. 

P. Como os dados de inventário são carregados no back-end?

R. O CX Cloud Agent carrega os dados de inventário através do protocolo TLS 1.2 para o servidor back-end da Cisco.

P. Qual é a frequência de upload do inventário?

R. A coleta é acionada conforme a programação definida pelo usuário e é carregada no back-end da Cisco. 

P. O usuário pode reagendar o inventário?

R. Sim, há uma opção disponível em Admin Center > Fontes de dados para modificar as informações de agendamento.

Q. Quando ocorre o tempo limite da conexão entre o Cisco Catalyst Center e o Cloud Agent?

R. Os intervalos são categorizados da seguinte forma:

• Para a conexão inicial, o tempo limite é de no máximo 300 segundos. Se a conexão não for estabelecida entre o Cisco Catalyst Center e o Cloud Agent em no máximo cinco (5) minutos, a conexão será encerrada.
• Para atualizações recorrentes, típicas ou atuais: o timeout de resposta é de 1800 segundos. Se a resposta não for recebida ou não for possível ler dentro de 30 minutos, a conexão será encerrada.

Verificação de diagnóstico usada pelo CX Cloud Agent

P. Quais comandos de varredura são executados no dispositivo?

R. Os comandos que precisam ser executados no dispositivo para a verificação são determinados dinamicamente durante o processo de verificação. O conjunto de comandos pode mudar ao longo do tempo, mesmo para o mesmo dispositivo (e não no controle de Diagnostic Scan).

P. Onde os resultados da varredura são armazenados e perfilados?

R. Os resultados verificados são armazenados e perfilados no back-end da Cisco.

P. As duplicatas (por nome de host ou IP) no Cisco Catalyst Center, são adicionadas à Varredura de diagnóstico quando a origem do Cisco Catalyst Center está conectada?

R. Não, as duplicatas são filtradas de forma que apenas os dispositivos exclusivos sejam extraídos.

P. O que acontece quando uma das varreduras de comando falha?

R. A varredura do dispositivo é interrompida completamente e marcada como malsucedida.

P. O que acontece quando várias varreduras se sobrepõem?

R. A execução simultânea de várias varreduras de diagnóstico pode retardar o processo de varredura e potencialmente resultar em falhas. A Cisco recomenda programar varreduras de diagnóstico ou iniciar varreduras por solicitação com, pelo menos, 6 a 7 horas de diferença em relação às programações de coleta de inventário, para que elas não se sobreponham.

Registros de sistema do CX Cloud Agent

P. Que informações de integridade são enviadas ao portal da nuvem do CX?

R. Registros de aplicativos, status do Pod, detalhes do Cisco Catalyst Center, registros de auditoria, detalhes do sistema e detalhes do hardware.

P. Quais detalhes do sistema e do hardware são coletados?

A. Exemplo de saída: 

system_details":{
"os_details":{
"VersãoTempoExecuçãoContêiner":"docker://19.3.12",
"kernelVersion":"5.4.0-47-generic",
"kubeProxyVersion":"v1.15.12",
"kubeletVersion":"v1.15.12",
"machineID":"81edd7df1c1145e7bcc1ab4fe778615f",
"sistema operacional":"linux",
"osImage":"Ubuntu 20.04.1 LTS",
"UUID do sistema":"42002151-4131-2ad8-4443-8682911bdadb"
},
"detalhes_do_hardware":{
"total_cpu":"8",
"utilização da cpu":"12,5%",
"memória_total":"16007 MB",
"memória_livre":"994 MB",
"hdd_size":"214G",
"tamanho_hdd_livre":"202G"
}
}
}

P. Como os dados de integridade são enviados ao back-end?

R. Com o CX Cloud Agent, o serviço de saúde (manutenção) transmite os dados para o back-end da Cisco.

P. Qual é a política de retenção do registro de dados de integridade do CX Cloud Agent no back-end?

R. A política de retenção do registro de dados de integridade do CX Cloud Agent no back-end é de 120 dias.

P. Que tipos de uploads estão disponíveis?

A. 

1. Carregamento de inventário
2. Carregamento de Syslog
3. Carregamento de integridade do agente, incluindo o carregamento de integridade
   1. Integridade dos serviços - a cada cinco (5) minutos
   2. Podlog - A cada (1) hora
   3. Log de auditoria - a cada (1) hora

Troubleshooting

Problema: Não é possível acessar o IP configurado.

Solução: execute ssh usando o IP configurado. Se o tempo limite da conexão for excedido, o possível motivo será a configuração incorreta do IP. Nesse caso, reinstale configurando um IP válido. Isso pode ser feito por meio do portal com a opção de reinstalação fornecida naAdmin Centerpágina.

Problema: Como verifico se os serviços estão funcionando após o registro?

Solução: siga as etapas abaixo para confirmar se os pods estão em execução:

1. ssh para o IP configurado como cxcadmin
2. Forneça a senha
3. Execute o comando kubectl get pods

Os pods podem estar em qualquer estado (Executando, Inicializando ou Criando contêiner). Após 20 minutos, os pods devem estar no estado Em execução.

Se o estado não estiver em execução ou se Pod Inicializando, verifique a descrição do pod com o comando kubectl describe pod <podname> .

A saída terá informações sobre o status do pod.

Problema: Como verificar se o Interceptor SSL está desabilitado no Proxy do cliente?
Solução: execute o comando curl mostrado aqui para verificar a seção de certificado do servidor. A resposta tem os detalhes do certificado do servidor consoweb.

curl -v —header 'Authorization: Basic xxxxxx' https://concsoweb-prd.cisco.com/

* Certificado do servidor:

* assunto: C=US; ST=Califórnia; L=San Jose; O=Cisco Systems, Inc.; CN=concsoweb-prd.cisco.com

* data de início: 16 de fevereiro 11:55:11 2021 GMT

* data de expiração: Feb 16 12:05:00 2022 GMT

* subjectAltName: o host "concsoweb-prd.cisco.com" corresponde ao "concsoweb-prd.cisco.com" do cert

* emitente: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID SSL CA G3

* Verificação de certificado SSL ok.

> GET / HTTP/1.1

Problema: os comandos kubectl falharam e mostram o erro como "A conexão ao servidor X.X.X.X:6443 foi recusada - você especificou o host ou a porta correta"
Solução:

• Verifique quanto à disponibilidade de recursos. [exemplo: CPU, Memória].
• Aguarde o início do serviço do Kubernetes.

Problema: Como obter os detalhes da falha de coleta para um comando/dispositivo?

Solução:

• Execute kubectl get pods e obtenha o nome do pod da coleção.
• Execute os logs do kubectl <collectionPodName> para obter os detalhes específicos do comando/dispositivo.

Problema: o comando kubectl não está funcionando com o erro "[authentication.go:64] Não foi possível autenticar a solicitação devido a um erro: [x509: o certificado expirou ou ainda não é válido, x509: o certificado expirou ou ainda não é válido]"

Solução:execute os comandos mostrados aqui como cxcroot user

rm /var/lib/rancher/k3s/server/tls/dynamic-cert.json
systemctl restart k3s
kubectl — insecure- skip- tls- verify=true delete secret - n kube- system k3s- servindo
systemctl restart k3s

Respostas à falha de coleta

A causa da falha de coleta pode ser qualquer restrição ou problema observado no controlador adicionado ou nos dispositivos presentes no controlador.

A tabela mostrada aqui tem o trecho de erro para casos de uso vistos no microsserviço de Coleta durante o processo de coleta.

Caso de uso	Snippet de registro no microsserviço de coleta
Se o dispositivo solicitado não for encontrado no Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": " Nenhum dispositivo encontrado com id 02eb08be-b13f-4d25-9d63-eaf4e882f71a " }
Se o dispositivo solicitado não estiver acessível a partir do Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Erro ao executar o comando: show version\nErro ao conectar ao dispositivo [Host: 172.21.137.221:22]Nenhuma rota para o host : Nenhuma rota para o host " }
Se o dispositivo solicitado não estiver acessível a partir do Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Erro ao executar o comando: show version\nErro ao conectar-se ao dispositivo [Host: X.X.X.X]Tempo limite da conexão: /X.X.X.X:22 : Tempo limite da conexão: /X.X.X.X:22" }
Se o comando solicitado não estiver disponível no dispositivo	{   "comando": "show run-config",   "status": "Êxito",   "commandResponse": " Erro ao executar o comando : show run-config\n\nshow run-config\n ^\n% Entrada inválida detectada no marcador \u0027^\u0027.\n\nXXCT5760#",   "mensagem de erro": "" }
Se o dispositivo solicitado não tiver SSHv2 e o Cisco Catalyst Center tentar conectar o dispositivo com SSHv2	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Erro ao executar o comando: show version\nCanal SSH2 fechado: A parte remota usa um protocolo incompatível; ele não é compatível com SSH-2." }
Se o comando estiver desativado no microsserviço de coleta	{   "comando": "desabilitar paginação de configuração",   "status": "Command_Disabled",   "commandResponse": "A coleção de comandos está desabilitada",   "mensagem de erro": "" }
Se a tarefa do executor de comando falhou e o URL da tarefa não for retornado pelo Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Falha na tarefa de execução do comando para o dispositivo %s. A URL da tarefa está vazia." }
Se a tarefa do executor de comandos não for criada no Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Falha na tarefa de execução do comando para o dispositivo %s, RequestURL: %s. Sem detalhes da tarefa." }
Se o microsserviço de Coleta não estiver recebendo uma resposta para uma solicitação do Command Runner do Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Falha na tarefa de execução do comando para o dispositivo %s, RequestURL: %s." }
Se o Cisco Catalyst Center não estiver concluindo a tarefa dentro do tempo limite configurado (5 minutos por comando no microsserviço de coleta)	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Tempo limite da operação esgotado. Falha na tarefa do executor de comandos para o dispositivo %s, RequestURL: %s. Sem detalhes de progresso." }
Se a tarefa do executor de comandos falhou e o ID do arquivo está vazio para a tarefa enviada pelo Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Falha na tarefa de execução do comando para o dispositivo %s, RequestURL: %s. A ID do arquivo está vazia." }
Se a tarefa do executor de comando falhou e a etiqueta de ID do arquivo não for devolvida pelo Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Falha na tarefa de execução do comando para o dispositivo %s, RequestURL: %s. Sem detalhes de ID de arquivo." }
Se o dispositivo não estiver qualificado para a ação do executor de comandos	{     "comando": "desabilitar paginação de configuração",     "status": "Falha",     "resposta do comando": "",     "errorMessage": "Os dispositivos solicitados não estão no inventário, tente com outros dispositivos disponíveis no inventário"   }
Se o executor de comandos está desativado para o usuário	{ "comando": "show version", "status": "Falha", "resposta do comando": "", "errorMessage": "{\"message\":\"A função não tem permissões válidas para acessar a API\"}\n" }

Respostas à falha de verificação de diagnóstico

Falhas de verificação e as causas podem ser de qualquer um dos componentes listados.

Quando os usuários iniciam uma verificação no portal, ocasionalmente ela resulta em "falha: erro interno do servidor".

A causa do problema é um dos componentes listados

• Ponto de controle
• Gateway de dados de rede
• Conector
• Verificação de diagnóstico
• Microsserviço do CX Cloud Agent [gerenciador de dispositivos, coleta]
• Cisco Catalyst Center
• APIX
• Mashery
• Ping Access
• IRONBANK
• IRONBANK
• Broker de Big Data (BDB) 

Para ver os logs:

1. Faça login no console do CX Cloud Agent.
2. Execute kubectl get pods. 
3. Obtenha o nome do pod da coleção, do conector e da facilidade de manutenção.
4. Para verificar a coleta, o conector e os logs de microsserviço de manutenção.

• Execute logs kubectl <collectionpodname>  
• Execute kubectl logs <connector>
• Execute kubectl logs <servicability>

A tabela abaixo exibe o snippet de erro visto nos logs de microsserviço de coleção e microsserviço de manutenção que ocorrem devido aos problemas/restrições com os componentes.

Caso de uso	Snippet de registro no microsserviço de coleta
O dispositivo pode ser acessado e suportado, mas os comandos a serem executados nesse dispositivo estão listados em bloco no microsserviço de coleta	{   "comando": "desabilitar paginação de configuração",   "status": "Command_Disabled",   "commandResponse": "A coleção de comandos está desabilitada", }
Se o dispositivo para uma varredura não estiver disponível. Ocorre em um cenário, quando há um problema de sincronização entre os componentes, como portal, verificação de diagnóstico, componente CX e o Cisco Catalyst Center	Nenhum dispositivo encontrado com a id 02eb08be-b13f-4d25-9d63-eaf4e882f71a
Se o dispositivo que é tentado para varredura estiver ocupado (em um cenário), onde o mesmo dispositivo é parte de outro trabalho e nenhuma solicitação paralela é tratada do Cisco Catalyst Center para o dispositivo	Todos os dispositivos solicitados já estão sendo consultados pela execução do comando em outra sessão. Tente outros dispositivos
Se o dispositivo não for compatível para verificação	Os dispositivos solicitados não estão no inventário, tente com outros dispositivos disponíveis no inventário
Se o dispositivo que tentou fazer a varredura estiver inacessível	"Erro ao executar o comando: show udi\nErro ao conectar ao dispositivo [Host: x.x.x.x:22] Nenhuma rota para o host: Nenhuma rota para o host
Se o Cisco Catalyst Center não estiver acessível do Cloud Agent ou o microsserviço de coleta do Cloud Agent não estiver recebendo resposta para uma solicitação do Command Runner do Cisco Catalyst Center	{   "comando": "show version",   "status": "Falha",   "resposta do comando": "",   "errorMessage": "Falha na tarefa de execução do comando para o dispositivo %s, RequestURL: %s." }

Caso de uso	Snippet de registro no microsserviço do agente de ponto de controle
Se os detalhes do agendamento da solicitação de verificação estiverem ausentes	Não foi possível executar a solicitação. {"message":"23502: valor nulo na coluna \"schedule\" viola a restrição não nula"}
Se os detalhes do dispositivo da solicitação de verificação estiverem ausentes	Falha ao criar política de verificação. Não há dispositivos válidos na solicitação
Se a conexão entre o CPA e a conectividade estiver inativa	Não foi possível executar a solicitação.
Se o dispositivo solicitado para verificação não estiver disponível em Verificações de diagnóstico	Falha ao enviar a solicitação para verificação. Motivo = {\"message\":\"O dispositivo com nome de host=x.x.x.x' não foi encontrado\"}