Problema

Os sistemas geram logs muito volumosos, de difícil análise e administração, tornando complexa a gestão por parte do cliente.

Para contornar limitações de espaço em disco, normalmente o cliente adota uma destas soluções:

• configura os logs com nível mínimo de detalhes, para que os arquivos fiquem pequenos;
• rotaciona e elimina os logs com alta frequência;

Estas soluções levam à perda de informações importantes no momento de análise de um problema.

Cenário comum:

• o cliente abre chamado reportando um problema, porém não tem o log em nível detalhado, ou então possui log detalhado apenas das últimas horas e não do momento do erro;
• com isso recebe orientação para aumentar o nível de log e provocar o problema novamente, e isso nem sempre é factível, especialmente em problemas mais graves, como queda de serviços;
• muitas vezes não é possível reproduzir no ambiente de homologação o problema exato que ocorreu na produção;
• como consequência, a atuação do suporte fica prejudicada, aumentando o tempo de atendimento, a quantidade de iterações e esforço de investigação, para todos os envolvidos.

Precisamos de uma forma mais robusta de armazenar e consultar logs recentes sem comprometer a operação e minimizando impactos ao usuário final.

Solução proposta

Definir uma configuração para possibilitar gerenciamento ativo dos logs gerados pelo sistema, que possa ser implantado pelo próprio cliente na sua estrutura e utilizado para agilizar análises, consultorias, atendimentos de suporte e situações relacionadas.

Escopo

Esta documentação cobre um método para gerenciamento dos logs do Progress 12 PASOE que já utilizamos internamente e recomendamos aos clientes.

A mesma tecnologia pode ser utilizada para qualquer outro tipo de log, como Progress Clientlog, Tomcat, Apache, etc.

Reforçamos que esta não é a única solução que existe, e nem a única forma de fazer. Aqui tivemos a intenção de definir uma solução simples e 100% utilizando software livre. O cliente pode ficar à vontade para experimentar outros tipos de ferramentas.

• A TOTVS não se compromete com suporte a este serviço (bugs da ferramenta, atualização futura, etc).

O setup que propomos utiliza 3 ferramentas que fazem parte do Elastic Stack para coletar, armazenar e consultar os logs:

• Filebeat - agente que monitora os logs do Datasul e envia continuamente para o banco de dados;
• Elasticsearch - o banco de dados propriamente dito - coração de todo o stack;
• Kibana - interface gráfica para aplicar queries sobre o banco e mostrar os resultados;

• O Elastic Stack possui outras ferramentas, inclusive de Machine Learning, mas neste escopo estamos adotando apenas soluções mais simples e sem custo.

Impacto na estrutura

A única alteração prevista para as máquinas já existentes é garantir que o log do PASOE esteja sendo gerado com alto nível de detalhes, e rotacionado dentro de um tempo adequado para impedir risco de estouro de disco.

Já para o Elastic Stack, recomendamos a criação de uma nova Virtual Machine, para concentrar todas as configurações e isolar todos os processos, evitando qualquer risco de desestabilização dos sistemas já existentes.

Configurar nível de log do PASOE

&&&

Rotacionamento dos logs do PASOE

Na máquina onde roda o PASOE, garanta que existe uma rotina (exemplos completos mais abaixo) para executar periodicamente o comando de rotacionamento do log, que pode ser:

Para apenas apagar os logs:

/<instalacao_pasoe>/bin/tcman.(sh|bat) clean

Para rotacionar os logs salvando histórico:

/<instalacao_pasoe>/bin/tcman.(sh|bat) clean -A

Abaixo seguem exemplos dos scripts que utilizamos internamente na Totvs, que podem ser customizados conforme a sua necessidade. O que essa versão faz:

• Rotacionar os logs PASOE quando excederem o tamanho de 20 MB
• Eliminar o histórico de logs rotacionados quando atingir 60 minutos sem alteração

Requisitos de hardware para a nova VM do Elastic Stack

Descrevemos aqui a configuração que estamos utilizando internamente para os ambientes de desenvolvimento. Cenários de produção dos clientes podem demandar de configurações diferentes, especialmente no quesito Disco, dependendo do volume de logs e quantidade de tempo que desejar armazená-los.

Recomendamos criar uma nova Virtual Machine exclusiva para este setup, para isolar os processos e garantir que as demais máquinas utilizadas para o sistema não sejam afetadas.

• Sistema Operacional: Oracle Linux 8 (pode ser outro. Utilizamos este por ser homologado para uso internamente na Totvs).
• Disco: 500 GB (hoje estamos gerenciando logs de 10 ambientes e mantendo histórico por 7 dias. 500 GB está se mostrando suficiente).
• Memória: 8 GB (dependendo da quantidade de logs a administrar e usuários que realizarão consultas, pode ser interessante mais memória, para otimizar a performance).
• Processadores: 4 núcleos (dependendo da quantidade de logs a administrar e usuários que realizarão consultas, pode ser interessante mais núcleos, para otimizar a performance).

Passo a passo para a instalação

Elasticsearch

Instalação

&&& tratar os passos para criar a senha forte do elasticsearch e também os usuários para kibana_admin e filebeat. validar se precisará editar 2x o elasticsearch.yml (primeiro sem segurança para criar os usuários e depois elevar a segurança em outro passo). &&&

Vamos começar pelo banco de dados, que é a parte mais importante de todo o stack. Inicialmente faremos a instalação padrão conforme a documentação da ferramenta:

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
sudo yum install elasticsearch

Configuração

Após instalado, vamos editar as configurações no arquivo /etc/elasticsearch/elasticsearch.yml:

Utilize este arquivo em anexo como modelo:  elasticsearch.yml

Atenção especial para estes campos:

• path.data: /elasticsearch # é neste diretório que os dados serão armazenados, portanto aponte para uma pasta (ou volume) com ao menos 500 GB disponíveis.
• path.logs: /var/log/elasticsearch # os logs do elasticsearch serão fundamentais para mitigar quaisquer problemas durante a configuração
• Os campos abaixo precisam ser adicionados para que a interface gráfica (veremos a seguir) exija login e senha. Sem estes campos o acesso fica aberto:
  • xpack.security.enabled: true
    xpack.security.authc.realms.native.native1.enabled: true
    xpack.security.authc.realms.native.native1.order: 0
    xpack.security.transport.ssl.enabled: false
    xpack.security.http.ssl.enabled: false

A porta default do Elasticsearch é 9200. Se necessário, altere diretamente no arquivo.

Kibana

Instalação

Agora vamos instalar a interface gráfica, pois através dela será mais simples realizar as demais configurações do Elasticsearch.

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
sudo yum install kibana

Configuração

Após instalado, vamos editar as configurações no arquivo /etc/kibana/kibana.yml:

Utilize este arquivo como modelo: kibana.yml

Atenção especial para estes campos:

• server.port: 8080 # por default a porta do Kibana é 5601. Aqui internamente optamos por utilizar a 8080 por ser mais adequada ao nosso modelo de redes e segurança.
• server.host: "0.0.0.0" # fizemos esta configuração para permitir acesso à interface gráfica à partir de qualquer ponto da rede. Restrinja de acordo com a sua necessidade. #
• elasticsearch.username: "kibana_user" # usuário que foi criado na etapa anterior para permitir que o Kibana faça login no Elasticsearch para realizar queries e aplicar alterações de configurações.
• elasticsearch.password: "elastic" # este setup permite que a senha fique legível no arquivo. Por ser algo controlado na rede interna, isso nos atende. Mas você pode optar por utilizar um formato mais robusto, seguindo a documentação oficial do Kibana, que não vamos tratar nesta documentação.