Histórico da Página
O objetivo desta página é descrever as diversas técnicas e ferramentas que estão à disposição para o monitoramento, suporte e resolução de problemas do Smart eSocialFiscal. A ordem escolhida para apresentar os itens aqui descritos remete à linha do tempo da resolução de um problema.
...
O acesso aos serviços aqui descritos devem ser solicitados à area de Segurança da Informação de Cloud.
Visão Geral
O Smart eSocial Fiscal é disponibilizado através de um cluster de Kubernetes 1.10. O cluster é único para todos os clientes. Ao conjunto de recursos destinados à um cliente damos o nome de topologia. Cada cliente do serviço possui um código chamado organization id, ou simplesmente código do cliente, que identifica a topologia nos diversos serviços que apresentaremos aqui. Problemas relacionado ao cluster em si devem ser destinados ao TOTVS Cloud. Mais detalhes técnicos da arquitetura da solução estão disponíveis em Arquitetura do Smart eSocialFiscal.
Resolução de Problemas
Monitoramento - UptimeRobot
A instalação do Smart eSocial Fiscal possui um processo de auto-cura que resolve alguns problemas nas topologias de maneira automática. No entanto é possível que por problemas ainda não mapeados, a topologia fique fora do ar. Para identificar as topologias com problemas, utilizamos um serviço chamado UptimeRobotm, que deve ser acessado na URL:
...
O Kubernetic (https://kubernetic.com/) é uma ferramenta desktop que ajuda na gestão do cluster de Kubernetes. Caso alguma topologia apresente instabilidade ou mesmo algum monitor esteja alarmado, o primeiro passo é verificar o estado desta topologia no Kubernetic.
Ao abrir o aplicativo, diversas informações referentes ao cluster são exibidas. No entanto, para a resolução de problemas, a opção mais utilizada é o menu Pods, localizado na barra lateral de menu. Ao clicar nesta opção, digite o código do cliente no combo-box localizado no topo da tela. Uma tela conforme a imagem adiante será exibida.
Esta tela apresenta todos os processos (ou containers) da topologia do cliente selecionado. As colunas da lista estão descritas adiante.
- NAME: é o nome do pod associado ao container do processo em questão. O prefixo do nome do pod será sempre o nome do serviço mais um valor hash que varia conforme os pods são reiniciados ou recriados.
- TYPE: para esta tela sempre será do tipo pod.
- READY: exibe se o pod está pronto para receber requisições ou não.
- STATUS: mostra a situação do pod. Qualquer valor diferente de Running indica um problema com o pod. Note que ao lado do status é exibida também a quantidade de restarts do container. Um container pode ser reiniciado automaticamente pelo Kubernetes caso ele fique irresponsivo de acordo com regras de healthcheck do Protheus.
- AGE: mostra o tempo de vida deste pod.
Para ver mais detalhes de um pod, clique sobre seu nome. Uma tela conforme a imagem adiante será exibida.
A partir desta tela é possível realizar várias ações, mas o que nos interessa são duas especificamente.
No link Logs é possível visualizar os logs recentes de um pod. Para logs mais detalhados ou até mesmo para filtros mais complexos de logs, verifique a seção logs deste documento.
No botão Delete é possível deletar o pod. Eventualmente se faz necessário reiniciar um processo da topologia. No Kubernetes isso é feito deletando o pod em questão, pois após a deleção, o Kubernetes irá providenciar a criação de um novo pod automaticamente.
Ai licar no link Pods localizado no topo da tela, retornamos à tela que lista todos os processos da topologia. Note que é possível reiniciar a topologia inteira, selecionando todos os pods e clicando no botão Delete nesta tela, conforme imagem adiante.
Logs - logdna
O logdna é um serviço de armazenamento e consulta de logs. Todos os processos da topologia do Smart Fiscal enviam seus logs para este serviço. Acesse-o através da URL:
https://app.logdna.com/ce391081e7/logs/view?q=namespace:XXXXXX
Substituindo XXXXXX pelo código do cliente. Uma tela como a imagem adiante deve ser apresentada.
Ao entrar no seriviço pela URL descrita anteriormente, visualizamos os logs de todos os processos da topologia. É possível filtrar somente um processo, como por exemplo, o dbaccess. Para isso, devemos clicar no menu All Apps, localizado na barra de menu na parte superior da tela. O menu deve ser exibido conforme imagem adiante.
Faça a busca por dbaccess e marque o checkbox do container retornado, conforme imagem adiante.
Clique na tela na região dos logs e aguarde o recarregamento da página. A partir deste momento, somente os logs do dbaccess serão exibidos.
Com um olhar mais atento podemos verificar que após a aplicação do filtro a url mudou, conforme imagem adiante.
Isso significa que para facilitar o processo, basta substituir o parâmetro de consulta apps da URL e recarregar a página para exibir o log desejado. Os parâmetros podem variar de acordo com os containers e podem assumir os seguintes valores:
- protheus-appserver-homolog
- protheus-appserver-prod
- protheus-dbaccess
- protheus-license
- protheus-lockserver
- protheus-status
- protheus-tss
- protheus-webservice-homolog
- protheus-webservice-prod
Existem diversas funcionalidades no painel web do logdna. Para mais detalhes sobre buscas, filtros e afins, consulte a documentação https://docs.logdna.com/docs/getting-started.
Gerenciamento por Linha de Comando - kubectl
Eventualmente será necessário ir mais a fundo na investigação de algum problema. Para isso lançamos mão do kubectl, que é a ferramenta oficial do Kubernetes para realizar qualquer operação no cluster. No entanto o acesso ao cluster via kubectl está limitado à algumas máquinas, sendo assim é necessário solicitar acesso ao host:
Quando estiver dentro deste host, poderá executar kubectl e realizar qualquer operação no cluster.
Através da documentação https://kubernetes.io/docs/reference/kubectl/overview/ podemos observar que para listar os pods de um cliente, devemos executar o seguinte comando:
kubectl -n CODIGO_CLIENTE get pods
O resultado é similar ao obtido no Kubernetic.
Comunicação - Slack
Existe um slack disponível para o time do Smart Fiscal no endpoint adiante.
O objetivo deste slack é a comunicação dos times envolvidos na operação do serviço.
Além disso, utilizamos o slack como endpoint para alguns filtros de log que são complementares ao serviço de monitoramento descrito anteriormente. Existe um canal neste slack chamdo #monitoring que recebe mensagens do logdna quando um determinado log é gerado. Desta maneira é possível agir proativamente antes do serviço ficar comprometido. Estes filtros ainda devem ser evoluidos e construidos junto com a operação e engenharia do produto.
Problemas Conhecidos
Acesse a página Problemas Conhecidos e Soluções Aplicáveis para mais detalhes.