Investigação – Como Identificar a Causa de um Problema no Openstack

Uma coisa que meus alunos me pediram muito durante o ultimo curso de Openstack foi uma lista de como eu faço para identificar um problema dentro de um ambiente. Obviamente não consigo criar um artigo contendo todos os problemas, porém consigo criar um simples artigo que mostre uma linha de raciocínio de como seria feito para identificar a causa raiz de uma determinada falha.

A ideia desse artigo é auxiliar qualquer um em executar troubleshoot dentro da plataforma Openstack de forma fácil e descomplicada. Claro que ainda parte do trabalho será feita por você, que terá que identificar o que cada mensagem significa, porém pense nesse artigo mais como se fosse um mapa da ordem em que deverá ler os logs.

Tudo Começa no Compute

Todo analista de Openstack irá lhe dizer que 90% dos problemas é o Neutron, porém jamais iremos começar nossa análise no Neutron. O primeiro arquivo que iremos ler é o nova-compute da máquina hospedeira de nossa instância. Lá tem informações sobre tudo que ocorre com as instâncias, desde anexar novos volumes, a até criar novas interfaces de rede. Tudo esta lá, então nosso primeiro passo é ler seu conteúdo.

# less /var/log/nova/nova-compute.log

Esse arquivo é localizado dentro de /var/log/nova/nova-compute.log, e se a causa de seu problema não estiver lá, um indicativo do próximo arquivo a ser lido pelo menos estará lá. Caso o log realmente informe que o problema seja no Neutron, então o próximo passo é olhar o arquivo neutron-<service>-agent.log, sendo <service> o nome do serviço que usa em conjunto com ele. Para fins didático iremos usar nesse ambiente o linuxbridge, logo para ler o arquivo o comando seria:

# less /var/log/neutron/neutron-linuxbridge-agent.log

Nesse arquivo irá falar o motivo do porque não foi possível criar uma interface de rede, ou anexar um IP flutuante na instância, entre outros motivos.

Outro arquivo interessante de se olhar é o log do seu virtualizador, caso o problema não seja o Neutron. No caso do Libvirt, seu arquivo de log é um pouco mais complicado de ser lido, visto que ele fica dentro de /var/log/libvirt/qemu/instance-XXXXX.log, sendo XXXXX o ID da instância que deseja ler (ID do KVM). Para saber qual é o arquivo correto que deve ser lido, primeiramente, como admin, execute o comando openstack server show com o nome da sua instância, isso irá retornar algumas informações importantes:

# openstack server show instancia-1
+-------------------------------------+------------------------+
| Field                               | Value                  |
+-------------------------------------+------------------------+
| OS-DCF:diskConfig                   | MANUAL                 |
| OS-EXT-AZ:availability_zone         | nova                   |
| OS-EXT-SRV-ATTR:host                | compute1               |
| OS-EXT-SRV-ATTR:hypervisor_hostname | compute1.dexter.com.br |
| OS-EXT-SRV-ATTR:instance_name       | instance-00000001      |
+-------------------------------------+------------------------+

No campo OS-EXT-SRV-ATTR:instance_name temos o nome dessa instância dentro do nosso virtualizador, bastando agora rodar o comando abaixo com essa informação para termos acesso ao log dela:

# less /var/log/libvirt/qemu/instance-00000001.log

Proximo Passo: Controller

Se nosso problema não for detectado somente olhando os logs das computes, nosso próximo passo é olhar os logs da máquina que elegemos como controller de nosso ambiente. Algums arquivos de logs interessantes que podemos começar a olhar são:

  • /var/log/keystone/keystone-wsgi-public.log: Requisições via API do Keystone – requisições públicas;
  • /var/log/keystone/keystone-wsgi-admin.log: Requisições via API do Keystone – requisições privadas;
  • /var/log/nova/nova-api.log: Requisições via API do Nova.

Esses três arquivos são os principais que devemos conferir em caso de problema, sendo o nova-api.log o principal. Nesse arquivo irá conter informações sobre todas as requisições a API do Nova, então provavelmente se sua requisição não for atendida o motivo deve encontra-se arqui. No caso do keystone-wsgi-*.log ficará os logs de erro se em algum momento a API do Openstack recusou a autenticação fornecida pelo Keystone.

Outros arquivos que pode consultar, porém mais específicos, são os logs de cada serviço da ferramenta, sendo alguns deles:

  • /var/log/nova/nova-conductor.log: Log de informações quando o Openstack tenta criar a instância em alguma compute;
  • /var/log/nova/nova-consoleauth.log: Log de informações sobre o acesso ao VNC das instâncias;
  • /var/log/neutron/neutron-server.log: Log de informações relacionado ao serviço do Neutron Server;
  • /var/log/neutron/neutron-dhcp-agent.log: Log de informações do agente de DHCP;
  • /var/log/glance/glance-api.log: Log da API do glance;
  • /var/log/glance/glance-registry.log: Log do serviço responsável por armazenar e extrair as imagens;
  • /var/log/cinder/volume.log: Log do serviço do Cinder de criação, remoção, anexação e desanexação de volumes.

Fique Atento aos Warnings

É meio obvio dizer isso, mas problemas dentro do Openstack são armazenados dentro do log com a mensagem de ERROR, como no exemplo abaixo:

2018-06-23 15:41:33.827 15276 ERROR neutron.service DBNonExistentTable: (sqlite3.OperationalError) no such table: ml2_geneve_allocations [SQL: u'SELECT ml2_geneve_allocations.geneve_vni AS ml2_geneve_allocations_geneve_vni, ml2_geneve_allocations.allocated AS ml2_geneve_allocations_allocated \nFROM ml2_geneve_allocations']

A informação do log é sempre dividida em data e hora em que a mensagem foi exibida, PID do serviço, e um Traceback do Python contendo a origem do erro no código e o motivo do porque o erro ocorreu. No exemplo acima fica claro que o erro ocorreu porque uma tabela não existia dentro do banco de dados (no caso geneve_allocations). Essa mensagem de erro, que é o que nos interessa na maioria das vezes, fica localizada no final do Stacktrace.

Porém não é de mensagens de ERROR que uma investigação se resume: mensagens de Warning também devem ser analisadas sempre, pois elas podem informar uma pequena falha que pode acabar se tornando um incômodo futuro. Por exemplo a mensagem abaixo:

2018-06-23 13:20:28.476 7115 WARNING keystonemiddleware.auth_token [req-f278d2ee-f204-46bf-b1cf-787d81ae2dff - - - - -] AuthToken middleware is set with keystone_authtoken.service_token_roles_required set to False. This is backwards compatible but deprecated behaviour. Please set this to True.

Na mensagem acima estamos com um Warning informando que a opção keystone_authtoken.service_token_roles_required está marcada como False, porém no futuro isso será alterado para True e você deve já se preparar para essa alteração. Esse tipo de mensagem nos informa que nesse momento nosso ambiente está 100% operacional, porém caso desejamos atualizar tudo no futuro será possível que o ambiente não volte ao ar até corrigirmos esse Warning, que terá se tornado um ERROR no futuro.

Modo Debug

Caso o problema não seja identificado com os logs atuais do Openstack, talvez seja interessante ativar o modo Debug de cada ferramenta. Para quem não conhece, o modo debug é criado para que uma aplicação mostre dentro dos logs todas as operações que está executando, em algums casos até o que está processando.

Isso é usado muito por desenvolvedores, porém para quem já é bem familiarizado com o Openstack é uma mão na roda durante troubleshoots de problemas que aparentemente não tem soluções. Para ativar, abra o arquivo /etc/<app>/<app>.conf, sendo app o nome da ferramenta que deseja ativar o modo debug, e então inclua a linha abaixo dentro do arquivo:

# vim /etc/<app>/<app>.conf
debug = True

Com o arquivo alterado, reinicie a aplicação que ativou o modo debug para que a opção passe a funcionar. Vale ressaltar que isso deve ser ativo somente como ultima opção, visto que o modo debug facilmente pode encher seu disco com informação desnecessária. Após a conclusão da análise, desative o modo debug para normalizar o crescimento do arquivo de log.

Não Achou? Olhe a Launchpad

Se o problema que você está tendo não consegue encontrar a causa, talvez o Launchpad seja a sua melhor alternativa. Obviamente uma busca no Google pode te ajudar, mas existe uma enorme chance do que você está sofrendo ser na verdade um bug da ferramenta e que já possui um ticket aberto. Por isso aconselho sempre a olhar esse fórum primeiro antes de começar a buscar no Google adoidado pela solução/causa.

Vale lembrar que existe um Launchpad para cada serviço do Openstack, então consulte ele também além do principal. O link para cada launchpad específico fica dentro da própria página do Launchpad do Openstack.

E isso é tudo que conheço por experiência em análise do ambiente do Openstack. Espero que o post tenha sido útil e que possa colaborar também com outras dicas nos comentários. Abaixo segue alguns links uteis relacionado ao conteúdo do post:

  • https://launchpad.net/openstack
  • https://docs.openstack.org/nova/pike/admin/manage-logs.html

1 comentário

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *