Versões comparadas
Chave
- Esta linha foi adicionada.
- Esta linha foi removida.
- A formatação mudou.
Esta página tem por objetivo apresentar as ferramentas de análise de erros CriticalLog, ErrorReportView e Sentinela.
Índice
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.
Aviso | ||
---|---|---|
| ||
O Critical Log faz expurgo dos dados à cada 2 dias. Os registros, datados em 15 dias anteriores à data de expurgo, são excluídos da tabela GCRITICALLOG. |
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":
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:
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
5.3.1. Conversor de Sentenças Sql Server para Oracle
Image Modified
Image Modified
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ção das informações contidas 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:
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:
Aviso | ||
---|---|---|
| ||
As ferramentas apresentadas são captadoras de diferentes não conformidades, exceções e possíveis ofensores à performance do sistema. Os dados coletados e os relatórios gerados, devem ser enviados à Totvs para que o time responsável possa analisar esses dados e relatórios e possa oferecer o suporte necessário para que as não conformidades, exceções e ofensores à performance evidenciadas sejam devidamente sanadas. Os dados das tabelas referentes à cada uma dessas funcionalidades por si só, não garantem uma análise eficiente de quaisquer problemas que possam estar ocorrendo no software ou no ambiente ao qual o software está instalado. |
Vídeo:
A seguir um vídeo demonstrativo das ferramentas apresentadas:
Conector de Widget | ||
---|---|---|
|
Informações | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
Informações | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
|
...