Histórico da Página
...
| title | Solução de Problemas |
|---|
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
...
SmartERP. A ordem escolhida para apresentar os itens aqui descritos, remete à linha do tempo da resolução de um problema.
| Índice | ||
|---|---|---|
|
Acesso aos Serviços
O acesso aos serviços aqui descritos devem ser solicitados à área de Segurança da Informação de Cloud.
Visão Geral
O
...
SmartERP Protheus é disponibilizado através de um cluster de Kubernetes.
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
...
devem ser destinados ao TOTVS Cloud. Mais detalhes técnicos da arquitetura da solução estão disponíveis em Arquitetura do Smart
...
ERP.
Resolução de Problemas
Monitoramento - UptimeRobot
A instalação do
...
SmartERP Protheus 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 UptimeRobot, que deve ser acessado na URL:
...
https://uptimerobot.com/dashboard.php#mainDashboard
A tela apresentada deve ser conforme a seguinte imagem
...
:
À esquerda da tela, uma lista com todos os monitores é exibida. Lembrando, que cada cliente possui dois monitores, um para o environment de homologação, outro para o environment de produção. Ambos apontam para a mesma topologia
...
. No entanto, possuem alguns processos separados. O nome dos monitores é formado pelo código do cliente mais o nome do environment.
Gerenciamento
...
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.
dos Ambientes dos clientes
Para realizarmos o gerenciamento dos ambientes dos clientes, utilizaremos a ferramenta Rancher.
O Rancher é um painel que permite criar, apagar, alterar, escalar containers, fazer load balancer, gerenciar volumes e a rede no Docker.
Fonte: http://rancher.com
Principais funcionalidades do Rancher
- Logs de auditoria: Sempre que necessário é possível verificar qual usuário executou uma ação e todos os dados relativos à esta ação. O log de auditoria permite que, além da visibilidade sobre tudo que acontece no cluster, você tenha dados suficientes para eventuais auditorias HIPAA ou PCI DSS, por exemplo.
- API de gerenciamento e webhooks: Tudo falado até aqui e todas outras funcionalidades não faladas, são possíveis de serem executados através da API do Rancher. Via API, é possível escalar seus hosts, serviços, iniciar processos de upgrade (deploy), efetivá-los ou fazer rollback, obter métricas de environments, hosts, stacks, etc. Também é possível configurar URL de webhook para fazer o upgrade de serviços, escalonamento de hosts e serviços.
- Acesso ao Contêiner: Diretamente pela interface você pode acessar os logs do container (ao invés de entrar host e executar o comando
docker logs XXX -f) ou até mesmo acessar o bash do container (ao invés dedocker exec -it XXX bash), deixando essa interação bastante dinâmica. Para ter cuidado com os acessos e com chaves secretas, o Rancher tem uma área específica durante a criação de um serviço para a inserção de dados sensíveis como secrets dentro do container.
A ferramenta esta disponível no endereço: https://rancher.gcp.tks.sh/login. Para ter acesso, solicitar ao time SRE Protheus.
Após acesso à ferramenta, será exibido a tela dos clusters disponíveis:
Após selecionar o cluster serão demonstradas todas as suas métricas (disponível somente para os administradores).
Entrando no espaço de trabalho, podemos filtrar um ambiente de cliente e verificar todos os serviços sendo executados para o mesmo:
Caso seja necessário realizar um troubleshoot no ambiente, basta entrar em um dos serviços:
No POD, clique na caixa contendo os 3 pontos (à direita da tela):
Será exibida a tela contendo o Shell. Para acessar o POD (conhecimento em bash linux é exigido) e os logs que estão sendo gerados pelo serviço.
Além disto, poderá ser deletado o POD que será recriado instantaneamente.
Tome muito cuidado com esta opção, pois se deletado o POD, todos os processos que dependem dele também estarão inativos.
Logs - logdna (Em análise)
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.
...
O logdna é um serviço de armazenamento e consulta de logs. Todos os processos da topologia do
...
SmartERP Protheus enviam seus logs para este serviço.
Acesse-o através da URL:
...
https://app.logdna.com/ce391081e7/logs/view?q=namespace:XXXXXX
...
Substitua XXXXXX pelo código do cliente. Uma tela como a seguinte imagem
...
será apresentada
...
:
Ao
...
acessar a 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,
...
clique no menu All Apps, localizado na barra de menu na parte superior da tela.
O menu
...
é exibido conforme a seguinte imagem
...
:
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
...
, verifique 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-prod
- protheus-dbaccess
- protheus-license
- protheus-lockserver
- protheus-status
- protheus-tss
- 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 time de cloud e SRE.
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 podsO resultado é similar ao obtido no Kubernetic.
Comunicação - Slack
Existe um slack disponível para o time do
...
SmartERP, consulte o time de SRE para o envio do link da comunidade.
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 chamado #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 evoluídos e construídos junto com a operação e engenharia do produto.
Problemas Conhecidos
| Problema | Detalhamento | Possíveis Ações |
|---|---|---|
| A página do smartclient html do cliente ou o webservice retorna erro relacionado ao Kong. | O Kong é um servidor web baseado no nginx que é utilizado como proxy reverso para os serviços do Smart |
...
| ERP. Existe apenas uma instalação de Kong para todo o cluster. Normalmente, esse erro ocorre quando o serviço em questão está fora do ar, sendo assim o Kong não consegue alcançar o endpoint para fazer o proxy. | Utilizar o Kubernetic ou o kubectl para verificar o estado dos pods da topologia em questão. Possivelmente um ou mais pods estarão comprometidos (não Running). Identificar via logs (logdna) o motivo do ocorrido e se for o caso reiniciar o(s) pod(s). |
| O smartclient html do cliente exibe mensagem de falha de conexão na tela. | O |
...
| SmartERP Protheus utiliza a infraestrutura da AWS/GCP, mais especificamente o datacenter de |
...
| SP. A latência para este datacenter gira |
...
| em torno de |
...
| 50ms. Eventualmente, o problema relatado pode ocorrer se a rede do cliente tiver com um problema adicional de conectividade. | Realizar testes na rede do cliente para comprovar o diagnóstico descrito em detalhamento. | |
| Foi identificado que os containers de uma topologia estão executando restarts sucessivos. | O kubernetes pode reiniciar os containers de uma topologia por conta de alguns problemas. Um deles é que o healthcheck do produto retornou erro. | Verificar junto ao time de produto, com logs obtidos no logdna em mãos, o motivo dos healthchecks terem falhado. |
| O kubernetes pode reiniciar os containers porque o processo em questão está utilizando mais memória do que foi configurado para ele. Quando isso ocorre, o OOMKiller do Linux mata o processo. | Verificar junto ao time de produto, com logs obtidos no logdna em mãos, o porque do consumo excessivo de memória. Eventualmente, a quantidade de memória destinada ao processo em questão pode ser aumentada através da alteração do deployment via Kubernetic ou kubectl. |
| HTML |
|---|
<script>
function linksToBlank(){
var links = document.getElementsByTagName("a");
var l = 0;
for (var i = 0, l = links.length; i < l; i++) {
links[i].target = "_blank";
}
}
window.onload = linksToBlank;
</script> |
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas