Verificando a conectividade da ferramenta de descoberta com o vCenter Solução de problemas do WinRM Solução de problemas do Kerberos Solução de problemas do banco de dados Solução de problemas de SNMP Erros de coleta de rede Erros de coleta de métricas do sistema operacional Problemas de acesso no inventário descoberto Solução de problemas de autenticação com chave SSH Solução de problemas do instalador Linux Mensagens de erro comuns

Solução de problemas

Verificando a conectividade da ferramenta de descoberta com o vCenter

Quando você encontrar erros de configuração do módulo VMware, siga estas etapas para verificar a conectividade:

Acesse a ferramenta de descoberta VM

Log-in para a ferramenta de descoberta VM, abra o console remoto no vCenter
- Nome de usuário: discovery
- Senha: senha

Teste a conectividade do vCenter

Teste o acesso à API vCenter:


curl -v --insecure -u <username>:<password> https://<vcenter-ip-or-hostname>:443/mob

Resultado de sucesso esperado:


[ec2-user@discoverytool ~]$ curl -v --insecure -u <user>:<password> https://vcsa/mob > tmp.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.2.125:443...
* Connected to vcsa (192.168.2.125) port 443 (#0)
...
</xml>
* Connection #0 to host vcsa left intact

Teste o certificado SSL

Execute este comando:


openssl s_client -showcerts -servername <hostname> -connect <hostname>:443

Resultado de sucesso esperado:

Deve mostrar detalhes do certificado vSphere
Verifica a SSL/TLS conectividade na porta 443


[ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443
CONNECTED(00000003)
depth=0 CN = vcsa.onpremsim.env, C = US
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = vcsa.onpremsim.env, C = US
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=vcsa.onpremsim.env/C=US
   i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=vcsa.onpremsim.env/C=US
issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
---

Solução de problemas do WinRM

Se você estiver enfrentando problemas de conectividade com o WinRM, siga estas etapas para testar a conexão. Essas etapas também se aplicam a problemas de Hyper-V conectividade, porque a ferramenta de descoberta usa o WinRM para se comunicar com os hosts. Hyper-V

Teste a conectividade básica do WinRM usando as portas 5985 (HTTP) e 5986 (HTTPS). Precisamos garantir que a conectividade funcione na porta 5986 (HTTPS)


# Check WinRM listener configuration
winrm enumerate winrm/config/listener

# Note: Replace <HOST> with the target computer's hostname or IP address. Adjust the username and password as needed. 
# Test WinRM connection on port 5985 (HTTP)
$cred = Get-Credential
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5985

# Test WinRM connection on port 5986 (HTTPS)
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5986

Se os testes acima falharem, tente estabelecer uma PowerShell sessão com a validação do certificado desativada:


$cred = Get-Credential
$so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Enter-PSSession -ComputerName <HOST> -Credential $cred -Port 5985 -SessionOption $so

Solução de problemas do Kerberos

Se você tiver falhas de autenticação Kerberos ao coletar dados de servidores Windows, use as seções a seguir para diagnosticar e resolver problemas comuns.

Verifique os requisitos de rede

Antes de solucionar problemas de autenticação Kerberos, verifique se a ferramenta de descoberta pode alcançar os endpoints de rede necessários.

Para verificar os requisitos de rede para Kerberos

Verifique a resolução de DNS para o controlador de domínio. Execute o seguinte comando na ferramenta de descoberta VM:
```
nslookup dc01.example.com
```
Você também pode usar dig:
```
dig dc01.example.com
```
Se a resolução de DNS falhar, verifique se a VM da ferramenta de descoberta está configurada para usar um servidor DNS que possa resolver seu domínio do Active Directory. Verifique /etc/resolv.conf e confirme se as entradas do servidor de nomes apontam para os servidores DNS do seu domínio.
Verifique a conectividade com o Centro de Distribuição de Chaves (KDC) na porta 88. Execute este comando: .
```
nc -zv dc01.example.com 88
```
Saída esperada:
```
Connection to dc01.example.com 88 port [tcp/kerberos] succeeded!
```
Se a conexão falhar, verifique se nenhuma regra de firewall bloqueia o tráfego da VM da ferramenta de descoberta para o controlador de domínio na porta 88.
Verifique a conectividade com os servidores Windows de destino nas portas WinRM. Execute os seguintes comandos :
```
nc -zv <windows-server> 5985
nc -zv <windows-server> 5986
```
Se a conexão falhar, verifique se o WinRM está habilitado no servidor de destino e se as regras de firewall permitem tráfego de entrada nas portas 5985 e 5986.

Problemas comuns do Kerberos

A seguir estão os problemas comuns do Kerberos e suas soluções.

Erros de distinção entre maiús

Sintoma: Você recebe um erro “Servidor não encontrado no banco de dados Kerberos” durante a autenticação.

Esse erro geralmente ocorre quando o nome do território Kerberos não está em maiúsculas. As regiões Kerberos devem ser especificadas em maiúsculas em seu arquivo. krb5.conf Por exemplo, use EXAMPLE.COM em vez de example.com.

Prevenção de bloqueio de conta

A ferramenta de descoberta usa um mecanismo de recuo para evitar bloqueios de contas devido a repetidas tentativas de autenticação malsucedidas. Se sua conta de serviço for bloqueada, você poderá redefinir o processo de coleta interrompendo e iniciando o módulo de coleta por meio da interface web da ferramenta de descoberta emhttps://<discovery-tool-vm-ip>:5000.

kinit falha na CLI

A tabela a seguir lista kinit os erros comuns e suas soluções.

Erro	Causa	Solução
Não é possível encontrar o KDC para o reino	O nome do host ou endereço IP do KDC não está acessível ou o território não está configurado em. `krb5.conf`	Verifique se o `krb5.conf` arquivo contém o nome de host e o território KDC corretos. Confirme a resolução do DNS e a conectividade de rede com o KDC na porta 88.
Falha na pré-autenticação	A senha da conta de serviço está incorreta.	Verifique a senha e tente novamente. Se a conta estiver bloqueada, desbloqueie-a no Active Directory antes de tentar novamente.
Cliente não encontrado no banco de dados Kerberos	O nome principal não corresponde a nenhuma conta no Active Directory.	Verifique se o nome principal corresponde exatamente ao nome da conta, incluindo maiúsculas e minúsculas. Use o formato `username@REALM` com o reino em maiúsculas.
Não é possível resolver o endereço de rede do KDC	O DNS não pode resolver o nome do host KDC.	Verifique a configuração do DNS em`/etc/resolv.conf`. Confirme se o servidor DNS pode resolver o nome do host KDC. Teste com `nslookup` ou`dig`.

A coleta falha apesar do sucesso da triagem

Se for kinit bem-sucedido, mas a coleta de dados ainda falhar, verifique o seguinte:

Verifique se o nome principal usado para a coleta corresponde kinit exatamente ao caso usado durante.
Verifique se a conta de serviço tem as permissões necessárias nos servidores de destino.
Verifique se o WinRM está habilitado nos servidores de destino.
Verifique se o nome do host usado para a coleta corresponde ao nome do host registrado no Active Directory.

O Kerberos funciona para alguns servidores, mas não para outros

Se a autenticação Kerberos for bem-sucedida em alguns servidores, mas falhar em outros, investigue as seguintes áreas:

Se seus servidores abrangem vários domínios do Active Directory, configure uma credencial Kerberos separada para cada domínio. Certifique-se de que seu /etc/krb5.conf arquivo inclua entradas para todos os reinos. Cada domínio exige sua própria credencial com o username@REALM principal correto.

Compare a configuração do WinRM em um servidor em funcionamento com um servidor com falha. Execute o seguinte comando em cada servidor:


winrm get winrm/config

Teste a conectividade com a Área de Trabalho Remota para isolar o problema. A ferramenta de descoberta usa o formatousername@DOMAIN, enquanto a Área de Trabalho Remota usa o formatoDOMAIN\username.

Verifique se a conta de serviço é membro do grupo local de administradores no servidor com falha. Execute o seguinte comando no servidor de destino:


net localgroup Administrators

O WMI exige privilégios de administrador local para acessar as informações do sistema operacional. A coleção do SQL Server também exige que a conta de serviço tenha acesso de administrador local no servidor de destino.

Lista de verificação de configuração do Kerberos

Use a lista de verificação a seguir para verificar a configuração do Kerberos antes de iniciar a coleta de dados.

O krb5.conf arquivo existe na ferramenta de descoberta VM.
O nome do reino está em maiúsculas em. krb5.conf
A execução kinit com a conta de serviço é bem-sucedida sem erros.
klistA corrida mostra um tíquete válido e não expirado.
O nome principal corresponde exatamente ao nome da conta do Active Directory.
A resolução de DNS funciona para o nome do host KDC.
A conectividade de rede com o KDC na porta 88 está confirmada.
A conectividade de rede para servidores Windows de destino nas portas 5985 e 5986 está confirmada.
(Multi-domain) Cada domínio do Active Directory tem sua própria credencial configurada na ferramenta de descoberta [realms] e krb5.conf contém [domain_realm] entradas para todos os domínios.

Solução de problemas do banco de dados

Para diagnosticar problemas de coleta do Oracle Database, como dados ausentes ou erros, verifique o seguinte.

Conexão recusada ou tempo limite

Sintoma: O status da coleta do Oracle mostra um erro de conexão para um servidor.

Para solucionar esse problema, verifique o seguinte:

Verifique se o ouvinte Oracle está sendo executado no host de destino: lsnrctl status
Verifique a conectividade de rede da ferramenta de descoberta com o host Oracle na porta 1521 (ou sua porta personalizada): nc -zv <oracle-host> 1521
Verifique se as regras de firewall permitem conexões de entrada na porta do ouvinte Oracle.
Verifique o nome do serviço executando lsnrctl services no host Oracle. Se o nome do serviço estiver incorreto, o ouvinte Oracle rejeitará a conexão.

Falhas de autenticação (ORA-01017)

Sintoma: falha na coleta com um erro de nome de usuário ou senha inválidos.

Para solucionar esse problema, verifique o seguinte:

Verifique se a conta de serviço Oracle existe e não está bloqueada: SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';
Verifique se a senha está correta conectando-se manualmente: sqlplus discovery_user/<password>@<host>:1521/<service_name>
Se a conta estiver bloqueada, desbloqueie-a: ALTER USER discovery_user ACCOUNT UNLOCK;

Privilégios insuficientes () ORA-01031

Sintoma: a conexão é bem-sucedida, mas a coleta retorna dados incompletos.

Para solucionar esse problema, verifique o seguinte:

Verifique se SELECT_CATALOG_ROLE foi concedido: SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';
Conceda a função necessária se estiver faltando: GRANT SELECT_CATALOG_ROLE TO discovery_user;

A credencial manual mostra erro, mas a conexão automática funciona

Quando você fixa uma credencial manualmente em um servidor, a ferramenta de descoberta não retrocede se a conexão falhar. Verifique se a porta e o nome do serviço que você configurou na credencial correspondem ao ouvinte Oracle nesse servidor específico. Se o servidor tiver uma porta ou nome de serviço não padrão, atualize a configuração da credencial adequadamente.

OS-level fallback não detectando o Oracle

Se nenhuma credencial do banco de dados estiver configurada e o OS-level fallback não detectar o Oracle:

Verifique se as credenciais SSH ou WinRM OS estão configuradas e funcionando para o servidor (verifique o status da coleta de métricas do sistema operacional).
Para hosts Linux, verifique se /etc/oratab existe ou se os processos do Oracle process monitor (pmon) estão em execução.
Para hosts Windows, verifique se as entradas do registro Oracle existem HKLM\SOFTWARE\Oracle ou se os oracle.exe processos estão sendo executados.

Solução de problemas de SNMP

Acesse a ferramenta de descoberta VM

Log-in para a ferramenta de descoberta VM, abra o console remoto no vCenter
- Nome de usuário: discovery
- Senha: senha

Instale as ferramentas SNMP (se necessário)

sudo yum install net-snmp-utils -y

Teste a conexão SNMP com servidores Linux

snmptable -v 2c -c <COMMUNITY_STRING> <REMOTE_SERVER_IP> .1.3.6.1.2.1.6.13.1

Exemplo:


#SNMPv2c:
snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1

#SNMPv3 (with authentication):
snmptable -v 3 -u <username> -a MD5 -A <auth_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

#SNMPv3 (with privacy):
snmptable -v 3 -u <username> -a MD5 -A <auth_password> -x DES -X <priv_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

Erros de coleta de rede

é necessário um terminal para ler a senha

Erro:


ss command failed on <host>: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required

O comando ss está solicitando a senha do usuário. O usuário ssh configurado deve estar no grupo sudoers e estar configurado com sudo sem senha para o comando. ss/netstat Para configurar o sudo sem senha:

Crie um novo arquivo sudoers:
```
sudo vi -f /etc/sudoers.d/<username>
```

Adicione a linha:


<username> ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat

Após essa alteração, em execução sudo ss -tnap e sudo netstat -tnap deve ser executado sem solicitar uma senha

A coleção de rede foi executada sem sudo

Se você ver o seguinte aviso na página Inventário descoberto:


Network collection ran without sudo. Process-level connection data may be missing.

Esse aviso indica que a conta de usuário SSH não tem acesso sudo no servidor de destino. Sem o sudo, a ferramenta de descoberta ainda pode coletar dados de conexão de rede, mas não pode determinar qual processo possui cada conexão. Para coletar dados completos de conexão em nível de processo, certifique-se de que o usuário SSH tenha acesso sudo no servidor de destino.

Erros de coleta de métricas do sistema operacional

UUID de servidor ausente para servidores Linux

Se a ferramenta de descoberta não conseguir coletar o UUID do servidor (exibido como vazio ou ausente) para servidores Linux, verifique se as credenciais SSH configuradas para esses servidores têm privilégios sudo. A ferramenta usa dmidecode para ler o UUID do servidor. Se não dmidecode estiver instalada, a ferramenta volta à leitura/sys/class/dmi/id/product_uuid, o que também requer acesso sudo. Sem o sudo, nenhum método pode recuperar o UUID.

Resolução: Certifique-se de que a conta de usuário SSH fornecida à ferramenta de descoberta tenha acesso sudo nos servidores Linux de destino.

Problemas de acesso no inventário descoberto

Se você ver uma mensagem no status da coleção do servidor, como Credenciais ausentes ou Acesso negado:

Selecione o servidor na tabela de servidores descobertos.
Escolha Gerenciar credencial de acesso Você pode optar por:
1. Selecione credenciais alternativas no menu suspenso Selecionar credenciais.
2. Selecione Usar novas credenciais e fornecer novas credenciais.
Save (Salvar).

A ferramenta de descoberta tenta novamente a conexão depois que você salva suas alterações.

Solução de problemas de autenticação com chave SSH

Testando a conectividade da chave SSH a partir da ferramenta de descoberta

Se a autenticação da chave SSH falhar, verifique a conectividade da ferramenta de descoberta com o servidor de destino:

Faça login na ferramenta de descoberta (via console vSphere ou SSH no host Linux).

Teste a conectividade SSH usando sua chave privada:


ssh -i /path/to/private_key -o StrictHostKeyChecking=no <username>@<target_ip>

Se a conexão for bem-sucedida, o problema é como a chave foi carregada na ferramenta de descoberta. Re-upload insira a chave e verifique se o nome de usuário corresponde.
Se a conexão falhar, verifique a mensagem de erro na tabela a seguir.

Mensagem de erro	Causa	Resolução
`Permission denied (publickey)`	A chave pública não está no `authorized_keys` arquivo do servidor de destino ou o nome de usuário está errado.	Adicione a chave pública ao `~/.ssh/authorized_keys` servidor de destino para o usuário correto. Verifique as permissões do arquivo:`chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys`.
`Connection timed out after 20s`	A porta 22 não pode ser acessada pela ferramenta de descoberta.	Verifique se a porta 22 está aberta entre a ferramenta de descoberta e o servidor de destino. Verifique firewalls e grupos de segurança.
`Connection refused`	O serviço SSH não está sendo executado no servidor de destino.	Inicie o serviço SSH:`sudo systemctl start sshd`.
`Invalid SSH key for credential 'name'`	O formato da chave não é suportado, os dados da chave estão corrompidos ou a frase secreta está ausente ou está incorreta.	Verifique se o formato da chave é RSA, ECDSA ou Ed25519 no formato PEM, OpenSSH ou PKCS #8. Se a chave estiver criptografada, verifique se a senha está correta.

Solução de problemas do instalador Linux

A porta 5000 já está em uso

Sintoma: O serviço da ferramenta de descoberta falha ao iniciar após a instalação.

Resolução: identifique e interrompa o processo usando a porta 5000:


sudo ss -tlnp | grep :5000

Pare o processo conflitante e reinicie a ferramenta de descoberta:


sudo ./AWS-Transform-discovery-tool.sh start

Mensagens de erro comuns

Esta tabela descreve mensagens de erro comuns e suas explicações:

Mensagem	Local	Explicação
Uma senha já foi criada	Criar página de senha	Condição de corrida quando dois usuários criam senhas ao mesmo tempo; atualizar
Falha na exportação	Página de inventário	Tente novamente ou envie registros
Uma coleta sob demanda já está em andamento	Página de inventário	Condição de corrida quando dois usuários iniciam as coletas manuais ao mesmo tempo; tente novamente após a conclusão da coleta manual atual
`Command timed out after 60s`	Status da coleção do servidor	Um comando no servidor de destino não foi concluído em 60 segundos. Isso pode ocorrer em servidores muito carregados. Repita a coleta ou investigue a carga do servidor de destino.
Uma ou mais credenciais contêm UUIDs desconhecidos	Página de acesso ao sistema operacional	Condição de corrida quando dois usuários editam as credenciais do sistema operacional ao mesmo tempo; tente novamente
Senha inválida	Sign-in página	Senha incorreta para fazer login; entre em contato com o administrador ou entre em contato
Sua sessão expirou. Por favor, faça login novamente.	Sign-in página	A sessão expirou, é necessário fazer login novamente
Ocorreu um erro interno	Várias páginas	Tente novamente ou envie registros

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Considerações sobre segurança

Notas da versão