Esta página tem por objetivo apresentar objetivo apresentar as ferramentas de análise de erros CriticalLog, ErrorReportView e Sentinela.

      1. Critical Log

     Esta ferramenta busca facilitar a identificação de erros críticos como por exemplo perdas momentâneas de conectividade com o banco, timeout de banco de dados e falha ao registrar algum host entre outros.

     O log exibe as as seguintes informações: Usuário conectado, nome da máquina , aplicação, informações do erro, stack trace e data do ocorrido.

     Para visualizar este log, basta acessar o diagnóstico do sistema, na aba Erros Críticos.

     Criamos algumas regras para classificar um erro como crítico e alimentamos à tabela GCRITICALLOG para posterior análise, são elas:

1 – Regra com mecanismo de identificar quando o host é interrompido inesperadamente. Nesta regra quando o host é reiniciado verificamos se o mesmo seguiu o fluxo de desligamento por completo, e caso negativo geramos um registro na GCRITICALLOG com seu respectivo arquivo de dump.
2- Regra com mecanismo de identificar queries lentas sendo executadas, sejam elas, consultas SQL ou queries de produto. Nesta regra verificamos queries que levam mais de 2 minutos para executar e geramos um registro na GCRITICALLOG.
3 – Regra para verificar estouro de pool de conexões com o banco de dados. Nesta regra temos uma lógica de programação para identificar qual foi o processo vilão que estourou o pool de conexões, pois na maioria dos caso não é o processo que o erro foi apresentado que é o causador do problema, com isso geramos um registro na GCRITICALLOG.
4 – Regra para identificar erros no Job Server. Nesta regra temos pontos estratégicos no fonte mapeado pelo know-how de erros para identificar configurações erradas de afinidade, de usuários do Alias, e desserialização da classe de processo, etc. Para cada erro é gerado um registro na GCRITICALLOG.
5 – Regra para identificar sem os devidos tratamentos. Nesta regra capturamos exceções levantadas na aplicação e geramos registros na GCRITCALLOG.
6 – Regra para calcular a recorrência. Nesta regra identificamos quais erros possuem as mesmas características e incrementamos a recorrência do mesmo.
7 – Regra para identificar o produto. Nesta regra avaliamos o stackTrace do erro na ordem da execução e o primeiro produto encontrado é definido como o responsável pelo erro.

     Demais regras podem e serão adicionadas para que cada vez mais consigamos identificar de forma rápida erros críticos.

      2. Snowden

O Snowden é para onde todas as informações de critical log de clientes sobem e são compiladas de uma forma que nos permite avaliar incidentes similares de forma geral, podendo analisar os impactos em diferentes versões e em diferentes clientes.

O Endereço do Snowden é: https://snowden.totvs.com.br/app/incidents.

Dados para acesso:

Usuário: seuusuario@[email protected] (ex.: [email protected]@totvs.com)
Senha: senha de rede da TOTVS.

      3. RMDbg (RM Debugger)

       O RMDbg é uma ferramenta de análise de dump de serviços RM que nos permite fazer um diagnóstico completo do processo no momento em que o dump foi extraído. Com essa ferramenta podemos analisar eventuais vazamentos de memória, eventuais crashes de processos (crash dump), consultas com grande volumes de dados, relatórios com problemas e também uma série de outros fatores que podem estar comprometendo a saúde da aplicação.

      Um dump pode ser criado a qualquer momento, inclusive no ambiente de produção do cliente. Basta solicitar o time de TI do cliente, time de atendimento ou o time de Cloud de TOTVS. O material com instruções de uso e executável está no drive compartilhado.

Segue exemplo de criação de dump:

      4. ErrorReportView

     Com o novo recurso do relatório de erros da MDI, diversas informações que antes eram solicitadas ao cliente agora poderão ser coletadas com um único clique. Através de um novo botão disponível na janela de erros padrão, é possível para o usuário gerar um relatório contendo informações do ambiente utilizado junto a outros dados como print da tela onde o erro foi apresentado, arquivos do sistema como rm.exe. config e _Broker.dat entre outras informações padrões.

      5. Sentinela

     O Sentinela é uma ferramenta de Monitoramento de Ambientes criada para que o usuário possa identificar possíveis ofensores de performance. Para acessar a ferramenta, basta pesquisa-la no menu "Executar" ou acessar "Serviços Globais | Administração | Sentinela":

Image Removed

          5.1. Checagem Rápida de Ambiente

              Aqui o usuário pode executar um checklist de itens relacionados a configurações do ambiente CorporeRM e também relacionados ao SGBD com a finalidade de apresentar pontos de melhoria em suas configurações:

                      Image Removed

          5.2. Tarefas de execução agendada

                 Neste grupo de ferramentas o usuário pode executar alguns processos agendados de manutenção do banco de dados, análise de suas consultas sql, habilitar ou desabilitar fórmulas visuais, habilitar ou desabilitar triggers, testes de fórmulas .Net e geração do arquivo NGEN.

          5.3. Ferramentas de Análise

     Image Removed

                     5.3.1. Conversor de Sentenças Sql Server para Oracle

            Image Removed

          Este recurso é destinado ao cliente que migra seu banco de dados à partir do SGBD Sql Server para o Oracle. O processo ajusta o cálculo do controle(CRC) da tabela que armazena as consultas sql do produto, este CRC garante a manipulações das informações continas na linha, sendo geridas pela própria aplicação. Na maioria das migrações do Sql Server para o Oracle tais controles podem ficar errados, se faz necessário executar este processo para ajustar o controle e devolver a funcionalidade do cadastro de consultas.

           Além de garantir o valor do controle correto em relação ao banco de dados Oracle, este processo também aplica alguns ajustes nas consultas contidas no cadastro, retirando o hint 'NOLOCK' bem como ajustando o uso de apelidos nas tabelas das consultas.

           Esta ferramenta não faz uma migração completa das consultas T-Sql para PL-Sql, sua intenção principal é apresentar ao usuário um diagnóstico dos itens a serem tratados.

Abaixo a tela do processo sendo executado:

Image Removed

Após finalizar é gerada a lista das consultas com os erros da interpretação das sentenças pelo SGBD. Como foi dito anteriormente fica a cargo do usuário analisar e aplicar tais ajustes após sua migração entre bancos:

Image RemovedMaiores informações acesse Sentinela.

Vídeo:

A seguir um vídeo demonstrativo das ferramentas apresentadas: