Você está na página 1de 44

CENTRO DE INFORMÁTICA

GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

NATANAEL SOUZA DOS SANTOS

Avaliação de ferramentas de monitoramento de exceções e
eventos de logging para aplicações java

MONOGRAFIA

Recife
2017
NATANAEL SOUZA DOS SANTOS

Avaliação de ferramentas de monitoramento de exceções e
eventos de logging para aplicações java

Trabalho de graduação apresentado ao pro-
grama de graduação em Ciência da Compu-
tação da Universidade Federal de Pernam-
buco, como parte dos requisitos parciais ne-
cessários à obtenção do título de Bacharel
em Ciência da Computação.

Orientador: Vinicius Garcia
Coorientador: Josino Rodrigues Neto

Recife
2017
Natanael Souza dos Santos
Avaliação de ferramentas de monitoramento de exceções e eventos de logging para aplica-
ções java/ Natanael Souza dos Santos. – Recife, 2017-
43 p. : il. (algumas color.) ; 30 cm.

Orientador: Vinicius Garcia

Monografia – CENTRO DE INFORMÁTICA
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO , 2017.
IMPORTANTE: ESSE É APENAS UM TEXTO DE EXEMPLO DE FICHA CATALOGRÁFICA.
VOCÊ DEVERÁ SOLICITAR UMA FICHA CATALOGRÁFICA PARA SEU TRABALHO NA
BILBIOTECA DA SUA INSTITUIÇÃO (OU DEPARTAMENTO).
Natanael Souza dos Santos

Avaliação de ferramentas de monitoramento de exceções e eventos de logging
para aplicações java

IMPORTANTE: ESSE É APENAS UM
TEXTO DE EXEMPLO DE FOLHA DE
APROVAÇÃO. VOCÊ DEVERÁ SOLICITAR
UMA FOLHA DE APROVAÇÃO PARA SEU
TRABALHO NA SECRETARIA DO SEU
CURSO (OU DEPARTAMENTO).

Trabalho aprovado. Recife, DATA DA APROVAÇÃO:

Vinicius Garcia
Orientador

Professor
Convidado 1

Professor
Convidado 2

Recife
2017
A minha mãe Severina Maria de Souza e meu Pai José Paulino dos Santos que
nunca deixaram de acreditar na minha capacidade, sem vocês eu não teria conseguido.
Agradecimentos

Sou grato a minha noiva Maria Ferreira, aquela que me deu o maior dos presen-
tes, minha filha Ivanete Natalie, pelo apoio e confiança na minha jornada.
Ao professores Vinicius Garcia, Leandro Marques e Josino Neto pela ajuda e
confiança que me ajudaram a finalizar esse arduo caminho.
Aos amigos da gradução, que me inspiraram e me ajudaram nessa jornada.
A todos que de alguma forma fizeram parte dessa experiência de se graduar
em Ciência da Computação no Centro de Informática.
A todos vocês, muito obrigado.
All we have to decide is what to do with the
time that is given us. (J. R. R. Tolkien)
Resumo

Com o advento da computação em nuvem, os sistemas passaram a executar
totalmente nesses ambientes de produção, fora da infraestrutura de desenvolvimento,
impondo um limite ao desenvolvedor no controle da infraestrutura de produção. Esse
comportamento impulsionou o desenvolvimentos de ferramentas de monitoramento
de erros e logs para diversos ambientes e tecnologias de programação. Este trabalho
tem como objetivo apresentar essas ferramentas, denotando seus objetivos e apontar
as vantagens de uso das mesmas, além fazer uma avaliação entre esses serviços de
monitoramento de exceções para linguagem de programação Java, executando suas
integrações e analisando alguns parâmetros que influenciam a escolha e utilização
desses serviços pelos desenvolvedores a fim de facilitar a escolha e utilização dessas
ferramentas.

Palavras chave: Logging, Exceptions, Java, Monitoring Tools
Abstract

With the advent of cloud computing, applications have been fully executed
in these production environments, outside the development infrastructure, Imposing
a limit to the developer in control of the production infrastructure. This behavior has
boosted the development of error and logs monitoring tools for various environments and
programming technologies. This academic work aims to present these tools, denoting
its goals and expose its advantages, in addition to making an appraisal of these error
monitoring tools for Java programming language, performing their integration and
analyzing some parameters that influence the choice and use of these services by
developers to facilitate the choice and use of these tools.

Keywords: Logging, Exceptions, Java, Monitoring Tools
Lista de ilustrações

Figura 1 – Usando altitude como analogia, essa figura ilustra a estrutura em
Saas em vários níveis de detalhes. . . . . . . . . . . . . . . . . . . . 14
Figura 2 – Aba de overview da aplicação Airbrake . . . . . . . . . . . . . . . . 26
Figura 3 – Aba de occurrences da aplicação Airbrake . . . . . . . . . . . . . . . 26
Figura 4 – Dashboard da aplicação Raygun . . . . . . . . . . . . . . . . . . . . 29
Figura 5 – Aba de environment da visão do erro RollbackException . . . . . . . 29
Figura 6 – Aba de itens da aplicação Rollbar . . . . . . . . . . . . . . . . . . . 32
Figura 7 – Aba de community solutions relacionada a um erro na aplicação Rollbar 32
Figura 8 – Aba de issues da aplicação Rollbar . . . . . . . . . . . . . . . . . . . 34
Figura 9 – Visão relacionada a um erro na aplicação Sentry . . . . . . . . . . . 35
Figura 10 – Overops Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 11 – Aba de all events da aplicação Overops . . . . . . . . . . . . . . . . 37
Figura 12 – Visão relacionada ao erro SQL Error na aplicação Overops . . . . . 38
Lista de tabelas

Tabela 1 – Tabela I: Serviços de Monitoramento de Erro . . . . . . . . . . . . . 18
Tabela 2 – Resultados: Instalação . . . . . . . . . . . . . . . . . . . . . . . . . 39
Tabela 3 – Resultados: Modificabilidade de Código . . . . . . . . . . . . . . . . 39
Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Conceitos e Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Software as a Service (Saas) . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Localizar o bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Monitoramento de exceção . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Benefícios de uma ferramenta de monitoramento de exceções . 16
2.5.1 Clientes Felizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2 Tempo é dinheiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 Serviços de monitoramento de exceções e eventos de logging avaliados 17
2.6 Considerações do capítulo . . . . . . . . . . . . . . . . . . . . . . . 19

3 Ambiente de avaliação . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Detalhes do Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Configurações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Airbrake (AIRBRAKE, 2017) . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Raygun (RAYGUN, 2017) . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Rollbar (ROLLBAR, 2017) . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 Sentry (SENTRY, 2017) . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.5 Overops (KNOW. . . , 2017) . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Conclusão e trabalhos futuros . . . . . . . . . . . . . . . . . . . . . 41

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12

1 Introdução

O paradigma de computação em nuvem tem sido adotado amplamente para
desenvolver serviços através da internet. Isso se deve às características técnicas e
econômicas que o paradigma garante entregar, incluindo: elasticidade, flexibilidade,
esquema de serviço on-demand, otimização de recursos de hardware e software. Se
por um lado os benefícios são muitos, do outro há um aumento na complexidade
de infraestrutura. Esse aumento de complexidade criou uma demanda por serviços
de monitoramento remoto, dentre eles: monitoramento de capacidade e recursos;
gerenciamento de datacenters; gerenciamento de SLA (do inglês, Acordo de nível de
Serviço), gerenciamento de billing, gerenciamento de performance e gerenciamento de
segurança (ACETO et al., 2013).
Essa mudança de Paradigma também teve reflexo nos ambientes de desenvolvi-
mento de software. Com a facilidade e barateamento proporcionada pelos ambientes
de computação em nuvem, desenvolvedores de software passaram a usar ambientes
remotos como ambiente de produção, resultando em um pouco de perda de controle
do ambiente de produção (CHARAN; RAO; SRINIVAS, 2011; ZHANG, 2013). Esse
comportamento, assim como no gerenciamento de nuvens, resultou na criação de
ferramentas que garantissem mais controle no gerenciamento de aplicações remotas,
essas ferramentas são conhecidas como Application Performance Monitoring (APM),
responsáveis por monitorar a execução e disponibilidade de aplicações em produ-
ção através da internet. Algumas ferramentas APM que suportam a linguagem Java
são: New Relic, AppDynamics, Dynatrace e Pinpoint (AHMED et al., 2016). O tipo de
ferramenta de monitoramento em nuvem de aplicações abordado neste trabalho é o
monitoramento de exceções ou eventos de log. Com esse serviço é possível fazer o
monitoramento de logs ou erros de sistemas em produção em tempo real, e em alguns
casos é até possível checar o estado do programa, visualizando o código do programa
e o estado da variáveis no momento do lançamento do erro. Esse modelo de ferramenta
é relativamente novo no mercado e sofre com a falta de conteúdo de nível técnico ou
acadêmico. Motivado pela necessidade de explorar mais esse nicho, esse estudo tem
a intenção apresentar algumas ferramentas convencionais de monitoramento de erros
e fazer uma avaliação entre as suas principais características.
O objetivo deste trabalho é apresentar de forma concisa o conceito de ferramen-
tas de monitoramento de exceção, apresentar algumas destas ferramentas e fazer uma
avaliação de cada uma delas, analisando o processo de configuração e integração
destas ferramentas de acordo com a modificabilidade de código e instalação, em um
ambiente de programação utilizando linguagem Java.
Capítulo 1. Introdução 13

No capítulo 2 discutiremos sobre os conceitos e ferramentas abordados nesse
trabalho. Nesse capítulo é discutido sobre os conceitos de Saas, debugging, logging,
monitoramento de exceções e apresentação das ferramentas selecionadas para esse
trabalho. No capítulo 3 exploraremos o ambiente de teste, as configurações e depen-
dências necessárias para fazer a integração entre as ferramentas e o código, além de
avaliar cada ferramenta utilizada. No capítulo 4 concluímos o trabalho e fazemos uma
classificação das ferramentas buscando relacionar cada uma com um tipo de projeto
especificado e discutiremos alguns desafios para trabalhos futuros.
14

2 Conceitos e Ferramentas

Este capítulo é responsável por apresentar os conceitos que são requisitos para
o entendimento deste trabalho, e as ferramentas que são usadas durante as avaliações.
Se o leitor dominar os conceitos descritos nessa sessão, não é obrigatório sua leitura,
no entanto pode ser útil para revisão de literatura.

2.1 Software as a Service (Saas)

Serviço de monitoramento de erros em aplicações é um Software as a Service
(SaaS), ou seja é um serviço oferecido via internet onde o fornecedor do software
disponibiliza uma estrutura completa e suficiente para dar suporte ao serviço por um
preço correspondente à quantidade de recursos utilizados(NAZIR, 2012).

O modelo de software as a service dá a possibilidade de desdobramento
na utilização dos serviços, onde o cliente pode ceder o software locado
para uso de terceiros, aos quais iremos nomeá-los de usuários finais.
Portanto o cliente pode desenvolver diversas relações de negócios
com usuários finais, podendo utilizar os meios de cobranças como:
assinatura mensal ou anual, volumes de serviços pela utilização de
software e serviço disponibilizado gratuitamente (LIMA, 2012)

Figura 1 – Usando altitude como analogia, essa figura ilustra a estrutura em Saas em vários
níveis de detalhes.

Fonte: Armando Fox;David Patterson, 2012 p. 61.
Capítulo 2. Conceitos e Ferramentas 15

O Saas está inserido no contexto da web, logo ele utiliza o padrão cliente-
servidor para oferecer um serviço distribuído, e faz uso de todos os protocolos e
tecnologias, não sendo necessário instalação local. Uma aplicação SAAS WEB é
um exemplo do padrão arquitetural cliente-servidor, onde o software cliente atua na
interação com o usuário e faz requisições para o servidor, enquanto que o software no
servidor atua processamento dos dados e atendendo as requisições do cliente. (FOX;
PATTERSON, 2012)

2.2 Debugging

A definição popular descreve debugging como um processo metódico de encon-
trar e reparar uma quantidade de bugs ou defeitos em um programa de computador. Em
termos simplificados, quando o código não faz o que era esperado pelo desenvolvedor,
se configura um bug, e consequentemente esse bug deverá ser encontrado e corrigido.
O processo de debugging é dividido em quatro etapas: localizar o bug; classificar o
bug; entender o bug; e por fim reparar o bug. (ADRAGNA, 2008)

2.2.1 Localizar o bug

Desenvolvedores inexperientes tendem a achar que localizar um bug é uma
tarefa trivial, isso se deve por confiarem em saber o que o código deveria fazer. Um
bug nasce da premissa de que algo pensado em ser correto, na verdade está errado.
Para ajudar nesse processo de localizar um bug, existem alguns métodos padrões
usados por desenvolvedores. Segundo (SPINELLIS, 2006), a estratégia bottom-up é
dos métodos mais eficientes, pois começa do sintoma e procura pela causa. Um
sintoma pode ser um acesso à uma variável não inicializada pelo programa ou até
mesmo um loop infinito. O debugger normalmente mostra uma captura do momento
em que o sintoma ocorreu, e através das chamadas de código após o momento do
sintoma é possível chegar na causa do erro. Além dessa técnica, é possível fazer o
debugging da aplicação usando o auxílio de algum IDLE, como o Eclipse, através da
funcionalidade de debugging interativo.

2.3 Logging

Logs são eventos que proporcionam uma visão de determinado estado em
um sistema de software e pode ser salvos em arquivos ou escritos em consoles.
Logs geralmente são compostos por mensagens curtas, e seu conteúdo pode variar
dependendo da aplicação ou sistema. Um sistema web pode gerar logs indicando quais
e quando páginas foram requisitadas, enquanto que um drive de impressora pode gerar
logs indicando que ocorreu algum problema ao conectar com a impressora (OLINER;
GANAPATHI; XU, 2011).
Capítulo 2. Conceitos e Ferramentas 16

No ambiente de programação, logging é uma prática comumente usada para
salvar informações pertinentes relacionadas à execução do software. Essa prática é
feita adicionando declarações em trechos do código que consistem em funções que
recebem parâmetros como mensagens de texto explicando o ocorrido, variáveis e o
nível de verbosidade que indica o nível de gravidade do log (Fatal, error, warning, debug,
info, etc) (FU1 et al., 2014).
O logging é usado para facilitar o debugging de uma aplicação. Desenvolvedores
ainda fazem uso do logging usando o comando de print, seja para o console ou para o
disco. Se o programa de software falhar, o desenvolvedor pode filtrar por mensagens
relacionadas com o erro lançado. Se o desenvolvedor acreditar que o sistema de
software falhou porque houve uma queda de conexão com a internet, ele pode procurar
pela frase “connection error ” e capturar informações relacionadas com a execução no
momento da falha (OLINER; GANAPATHI; XU, 2011).

2.4 Monitoramento de exceção

Monitorar uma exceção ou um evento de log é o processo de capturar, reportar
e gerenciar dados de exceções que ocorrem em software. O objetivo é aumentar a
produtividade e qualidade do software, usando o monitoramento de exceções é possível
checar em tempo real as exceções que são lançadas pela aplicação e gerenciar as
mesmas para que a equipe de desenvolvimento conserte as mesmas. Quando uma
exceção ocorre, uma ferramenta de monitoramento de exceções captura informações
importantes como ambiente, sistema operacional, endereço remoto do ambiente de
produção e até o número de usuários afetados pelo erro. Também é possível visualizar
os gráficos que marcam a frequência de ocorrências de exceções, integração com
serviços de gerenciamento de software e comunicação. (JANÁK, 2009; WHAT. . . , 2017)

2.5 Benefícios de uma ferramenta de monitoramento de exceções

Esta sessão aponta alguns benefícios que resultam da utilização destas ferra-
mentas para monitoramento de software em produção, tanto da perspectiva do cliente,
como da perspectiva dos responsáveis pelo software.

2.5.1 Clientes Felizes

Em um cenário onde uma aplicação esteja em produção, o sistema está suscetí-
vel a diversos comportamentos que podem ou não terem sido previstos no ambiente
de desenvolvimento ou no ambiente de testes. Esses comportamentos podem ser
rastreados e gravados em arquivos que registram eventos do sistema para possíveis
auditorias e diagnósticos do sistema, esses arquivos são conhecidos como arquivos
Capítulo 2. Conceitos e Ferramentas 17

de log. Quando esses comportamentos se refletem em uma falha na aplicação, é de
fundamental importância que os responsáveis pela aplicação se adiantem para analisar
o log, e consequentemente encontrar a raiz que provocou o erro no sistema para que
posteriormente os responsáveis possam corrigir essa exceção.
Quando esses erros ocorrem e os desenvolvedores não têm acesso a eles, é
necessário que os usuários do sistema em questão relatem o ocorrido para que os
desenvolvedores possam reproduzir e posteriormente corrigir o erro. O problema surge
quando o usuário não tem conhecimento técnico suficiente para relatar o problema ou
quando o problema passa despercebido pelo mesmo. Comportamentos não previstos
pelo sistema podem impactar negativamente a experiência de uso da aplicação e o
processo de manutenção do software. (WHAT. . . , 2008)
Mas esse cenário de problemas pode ser corrigido se a aplicação estiver sendo
monitorada por um serviço de monitoramento de erros. Com esse serviço, os respon-
sáveis pelo software serão informados por cada erro notificado pelo sistema através de
várias interfaces de comunicação, como e-mail, chats ou serviços de gerenciamentos
de software. Ter o conhecimento prévio desses erros previnem que os desenvolvedores
interroguem os clientes com o objetivo de ter conhecimento sobre o comportamento
que produziu o erro.

2.5.2 Tempo é dinheiro

Depurar um erro ou exceção em uma aplicação é um processo custoso e pode
ser executado de várias formas, como depuração interativa, estruturas de controle,
análise de código fonte, análise de logs entre diversos outros.
O uso de serviços de monitoramento impede o desperdício de tempo que é
gasto revendo o código fonte ou lendo intermináveis arquivos de logs que são muitas
vezes não estruturados e extensos. O SaaS notifica a ocorrência desse erro, expondo
a causa do erro, e dependendo da aplicação exibir o estado dos objetos no momento
que aconteceu o erro.

2.5.3 Serviços de monitoramento de exceções e eventos de logging avaliados

Com a finalidade de escolher as ferramentas para serem estudadas nesse
trabalho, foram usados alguns parâmetros para escolha:

• integração com linguagem java. O Java foi a linguagem escolhida para fazer a
integração com as ferramentas de monitoramento de exceções.

• Comunidade ativa ou ter atualizações recentes. As ferramentas elegidas neste
trabalho foram atualizadas no mínimo durante os últimos cinco anos. As atua-
Capítulo 2. Conceitos e Ferramentas 18

lizações foram confirmadas de acordo com os repositórios oficiais no GitHub,
nas ferramentas open sources, ou em suas próprias páginas.

As ferramentas escolhidas foram: Airbrake, Overops, Raygun, Rollbar e Sentry.
Todas essas ferramentas obedeceram os parâmetros de escolha, e foram selecionados
através de pesquisas realizadas no buscador Google. Alguns desses serviços também
foram referenciadas em (ZHITNITSKY, 2014).

Tabela 1 – Tabela I: Serviços de Monitoramento de Erro

Linguagem Versão Atualizado Código Aberto

Airbrake Multi 2.2.8 06/2013 Sim

Overops Multi* 4.8.12 07/2017 Não

Raygun Multi 2.2.0 12/2016 Sim

Rollbar Multi 0.5.4 05/2017 Sim

Sentry Multi 8.18.0 07/2017 Sim

Airbrake: Airbrake (AIRBRAKE, 2017) é uma ferramenta online que permite o
monitoramento de erros. A ferramenta suporta as principais linguagens de programação
e frameworks. O software possui planos pagos e gratuitos e da suporte a integração com
diversas ferramentas de gerenciamento: GitHub, Trello, Slack, HipChat, JIRA, Pivotal
Tracker, GitHub Enterprise, GitLab, GitLab CE/EE, Bitbucket, Lighthouse, Flowdock,
Campfire, Assembla e outros. O Airbrake é licenciado sob as condições do Apache
License 2.0, apesar de sua última atualização ter ocorrido no final de 2013, seu último
commit ocorreu em dezembro de 2016(AIRBRAKE-JAVA, 2017). O Airbrake oferece 14
dias gratuítos para teste, após esse período, o serviço passa a cobrar a partir de US$
49,00 mensais.
Overops: Overops (KNOW. . . , 2017)é uma ferramenta que monitora erros
que ocorrem no ambiente de produção. Ela suporta apenas linguagens baseadas na
máquina virtual java: Java, Scala e Clojure, porém é a única ferramenta que permite
visualizar o código e o estado das variáveis que se relacionam com o erro ocorrido. O
serviço também oferece integração com serviços como o AppDynamics, CloudWatch,
DataDog, Grafana, Graphite, HipChat, Librato, New Relic, PagerDuty, Slack, Zabbix.
Este é o único serviço que não possui código aberto, no entanto sua escolha se deu
necessária devido a exclusividade de ser a única ferramenta que atua no nível da
máquina virtual java.
Raygun: Raygun (RAYGUN, 2017) é uma ferramenta que além de apresentar
o monitoramento de erros e integração com serviços de gerenciamento de projetos;
Capítulo 2. Conceitos e Ferramentas 19

plataformas de hospedagem de código para controle de versão e colaboração e fer-
ramentas de colaboração, tem um foco especial no usuário final do software a ser
monitorado, a ferramenta promete identificar esses usuários finais e saber quando o
mesmo for afetado por comportamento inesperado. Esse serviço suporta integração
com as seguintes ferramentas de gerenciamento e notificação: HipChat, Campfire,
YouTrack, GitHub, FogBugz, Trello, Sprintly, JIRA, JIRA OAuth, Bitbucket, PivotalTracker,
Webhook, Slack, Flowdock, BugHerd, Visual Studio Team Services, Lighthouse, Asana,
Zendesk, Moxtra, VictorOps, CA Agile CentralAssembla, PagerDuty, GitLab, Target-
process, Amazon SQS, Azure Service Bus. O Raygun é licenciado sob as restrições
do MIT License e seu último commit ocorreu em fevereiro de 2017 (RAYGUN4JAVA,
2017). O Raygun oferece apenas 14 dias gratuitos para teste, possuindo planos a partir
de US$ 199,00 mensais.
Rollbar: Rollbar (ROLLBAR, 2017) é uma ferramenta que propõe fazer monito-
ramento de erros, possui integração com as principais linguagens de desenvolvimento
e frameworks. A ferramenta possui um agrupamento inteligente de erros e promete
acompanhar o impacto de cada implantação de código no ambiente de produção. O
Rollbar oferece uma API para acesso dos dados e integração com outros serviços, além
do Rollbar Query Language, que fornece uma rica interface de consulta para os dados
do serviço. O Rollbar também permite enviar eventos para softwares de gerenciameno
ou noficação: HipChat, Campfire, GitHub, Trello, Sprintly, JIRA, Bitbucket, PivotalTracker,
Webhook, Slack, Flowdock, Asana, VictorOps, PagerDuty, GitLab. Licenciado sob o MIT
Liscense, seu último commit foi em maio de 2017 (ROLLBAR-JAVA, 2017). O serviço
possui um plano gratuito com eventos limitados, e planos a partir US$ 49,00 mensais.
Sentry: Sentry (SENTRY, 2017) é uma ferramenta que faz o monitoramento
de exceções e possui integração com as principais linguagens e seus frameworks.
A ferramenta oferece uma interface simples, porém intuitiva e possui integração com
os principais serviços de gerenciamento de projetos, plataformas para hospedagem
de código para controle de versão e ferramentas de colaboração. Licenciado sob
as restrições do BSD 3-clause “New” or “Revised” License, o Sentry possui uma
comunidade bastante ativa e tem commits semanais (SENTRY, 2017). O serviço
oferece um plano gratuito e planos a partir de US$ 26,00 mensais ou planos on-
demand.

2.6 Considerações do capítulo

Este capítulo expôs os principais conceitos que compõe as ferramentas de
monitoramento de exceções e eventos de log. Apresentou o conceito de Software as a
Service, que é a maneira que as ferramentas utilizam para entregarem o serviço para
os desenvolvedores, também foram expostos os conceitos de logging e debugging ,
Capítulo 2. Conceitos e Ferramentas 20

tal como a prática de monitorar exceções, sendo esses os conceitos que motivam
o uso dessas ferramentas de monitoramento de exceções. Por fim, as ferramentas
que serão avaliadas são apresentadas. Todos os princípios explorados neste capítulo
são necessários para melhor entendimento e compreensão das avaliações que serão
realizadss no próximo capítulo.
21

3 Ambiente de avaliação

O objetivo deste capítulo é explicar a configuração do ambiente de teste, assim
como as tecnologias usadas ao decorrer deste trabalho, detalhes da implementação,
dependências necessárias para replicação desses exemplos e por fim, na sessão
3.2, um passo a passo de como configurar cada ferramentas de monitoramento de
exceções e eventos de logs descritas no capítulo anterior.
Esta sessão é importante pois ela faz uma avaliação das nuâncias de cada
ferramenta, ou seja, como cada ferramenta se diferencia no momento de se fazer
a integração com aplicação, seja por dependências de bibliotecas externas ou por
modificação de código.

3.1 Detalhes do Ambiente

O ambiente de teste é construído em uma computador da fabricante Acer,
Aspire E 15, E5-573-54ZV, com processador Intel® Core™ i5-5200U, memória 8GB
DDR3 L, armazenamento de 1000 GB HDD. O sistema operacional é o Fedora 23 com
configuração padrão de de internet. A versão do JDK usada é o OpenJDK Runtime
Environment (build 1.8.0_111-b16). A IDE usada é o Eclipse, versão Neon.1a Release
(4.6.1).
Com a finalidade de utilizar todo o potencial de cada serviço de monitoramento,
e fazer uma comparação mais justa, suas configurações foram implementadas de
acordo com os guias dos seus respectivos websites.

3.1.1 Código

Para seguirmos o foco deste trabalho, iremos utilizar uma aplicação trivial em
java que consiste apenas em consultas a um banco de dados, onde faremos inserção
de objetos. O levantamento de exceções se dará pelo desligamento do banco de
dados no meio a uma consulta ao mesmo. O Hibernate versão 5.2.10 foi utilizado para
facilitar o mapeamento objeto relacional, o uso do framework se faz necessário para
que apenas possamos focar nas configurações dos serviços de monitoramento. Para
o gerenciamento de dependências do projeto foi utilizado o Maven, uma ferramenta
de integração de projetos, dado a grande adoção da ferramenta no ambiente de
desenvolvimento java.
O seguinte Código 3.1 descreve a entidade Person, que será utilizada para ser
persistida no banco de dados. A implementação da classe Person é trivial, possuindo
apenas dois atributos, id e name. Com auxílio das classes do pacote javax.persistence,
Capítulo 3. Ambiente de avaliação 22

foi usado alguns java annotations para fazer o mapeamento objeto-relacional. Mapea-
mento objeto-relacional é uma técnica que abstrai o modelo relacional, usado em banco
de dados, para o o modelo orientado a objetos, essa técnica é importante pois permite
que o desenvolvedor não escreva código para banco de dados, melhorando a produtivi-
dade e diminuindo o tempo de desenvolvimento da aplicação. (CANDIDO NETO et al.,
2016) A anotação @Entity na linha 6 configura que a classe Person é uma entidade do
mapeamento objeto-relacional. As anotações das linhas 9 e 10 respectivamente con-
figura que o atribute id é o identificador da entidade Person e que o valor é gerado
automaticamente. A linhas 13 descreve que o atribute name é uma coluna da entidade
da Person.

Código 3.1 – Person.java
1 import j a v a x . p e r s i s t e n c e . Column ;
2 import javax . persistence . E n t i t y ;
3 import j a v a x . p e r s i s t e n c e . GeneratedValue ;
4 import javax . persistence . Id ;
5
6 @Entity
7 p u b l i c c l a s s Person {
8
9 @Id
10 @GeneratedValue
11 p r i v a t e long i d ;
12
13 @Column ( n u l l a b l e = f a l s e , unique= f a l s e )
14 p r i v a t e S t r i n g name ;
15
16 p u b l i c S t r i n g getName ( ) {
17 r e t u r n name ;
18 }
19 p u b l i c v o i d setName ( S t r i n g name ) {
20 t h i s . name = name ;
21 }
22 }

O código 3.2 é a implementação da classe App, onde é executada todas as avali-
ações e descritas neste trabalho. A linha 1 até a linha 3 são feitos os imports das classes
necessárias para implementação do JPA (Java Persistence Aplication) (HIBERNATE-
JPA-2. . . , 2013) na nossa classe App. O JPA é uma padrão da plataforma java para
persistência de dados, e é implementada pelo Hibernate, que o framework usado nesse
trabalho para fazer o mapeamento objeto-relacional (BALDUINO; RUFINO, 2014). Na
linha 11 é criado uma instância da classe EntityManagerFactory, essa classe é res-
ponsável por fazer a ligação com o arquivo de configuração e com a entidade Person
(Código 3.1). Para fazer comunicação com o JPA, é criada uma instância da classe
EntityManager através da instância já conhecida criada na linha 11. Da linha 17 até a
Capítulo 3. Ambiente de avaliação 23

linha 26 é feita um loop onde um objeto da entidade Person é persistido a cada iteração
do loop. Esse é o alicerce de onde será lançada as exceções e os logs de eventos
que serão capturados pelas ferramentas de monitoramento de exceções e logs citadas
neste trabalho. A exceção será lançada quando a conexão com o banco de dados for
encerrada, impedindo a persistência da nossa entidade no banco de dados.

Código 3.2 – App.java
1 i m p o r t j a v a x . p e r s i s t e n c e . EntityManager ;
2 import javax . persistence . EntityManagerFactory ;
3 import javax . persistence . Persistence ;
4
5 i m p o r t t g . n a t a n a e l . e n t i t y . Person ;
6
7 p u b l i c c l a s s App {
8
9 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] args ) {
10
11 EntityManagerFactory f a c t o r y = Persistence .
c r e a t e E n t i t y M a n a g e r F a c t o r y ( " mariaDB " ) ;
12 EntityManager manager = f a c t o r y .
createEntityManager ( ) ;
13
14 Person person = new Person ( ) ;
15 person . setName ( " Jhon " ) ;
16
17 f o r ( i n t i = 0 ; i < 100000; i ++) {
18 try {
19 manager . g e t T r a n s a c t i o n ( ) . begin
() ;
20 manager . p e r s i s t ( person ) ;
21 manager . g e t T r a n s a c t i o n ( ) . commit
() ;
22
23 } c a t c h ( E x c e p ti o n e ) {
24 e . printStackTrace ( ) ;
25 }
26 }
27
28 manager . c l o s e ( ) ;
29 f a c t o r y . close ( ) ;
30 }
31 }

3.1.2 Dependencias

O arquivo pom.xml (Código 3.3) é responsável pela declaração de todas as
dependências usadas no código base da aplicação. O arquivo pom.xml é o principal
arquivo de configuração usado pelo maven. Da linha 10 á linha 14 é declarado a
dependência da biblioteca org.hibernate verão 5.2.10, e da linha 17 até a linha 21 é
Capítulo 3. Ambiente de avaliação 24

declarada a dependência do pacote org.mariadb.jdbc, esse pacote é responsável por
fazer a ligação da nossa aplicação com o banco de dados MariaDB.

Código 3.3 – pom.xml
1 < p r o j e c t xmlns= " h t t p : / / maven . apache . org /POM/ 4 . 0 . 0 " x m l n s : x s i = "
h t t p : / / www. w3 . org / 2 0 0 1 /XMLSchema−i n s t a n c e "
x s i : s c h e m a L o c a t i o n = " h t t p : / / maven . apache . org /POM/ 4 . 0 . 0 h t t p :
/ / maven . apache . org / xsd / maven − 4 . 0 . 0 . xsd " >
2 <modelVersion> 4 . 0 . 0 < / modelVersion>
3 <groupId>tg . natanael< / groupId>
4 < a r t i f a c t I d >ErrorTrackingTest< / a r t i f a c t I d >
5 < v e r s i o n >0.0.1 −SNAPSHOT< / v e r s i o n >
6 <name> E r r o r T r a c k i n g T e s t < / name>
7
8 <dependencies>
9 < !−− h t t p s : / / m v n r e p o s i t o r y . com / a r t i f a c t / org . h i b e r n a t e /
h i b e r n a t e −core −−>
10 <dependency>
11 < g r o u p I d >org . h i b e r n a t e < / g r o u p I d >
12 < a r t i f a c t I d > h i b e r n a t e −core < / a r t i f a c t I d >
13 <version>5.2.10. Final< / version>
14 < / dependency>
15
16 < !−− h t t p s : / / m v n r e p o s i t o r y . com / a r t i f a c t / org . mariadb .
j d b c / mariadb−java−c l i e n t −−>
17 <dependency>
18 < g r o u p I d >org . mariadb . j d b c < / g r o u p I d >
19 < a r t i f a c t I d >mariadb−java−c l i e n t < / a r t i f a c t I d >
20 <version>1.1.7< / version>
21 < / dependency>
22 < / dependencies>
23
24 < / p r o j e c t >

3.2 Configurações

Usaremos como referência a documentação oficial de cada serviço de monitora-
mento que será tratado neste trabalho. Essa é uma forma de garantir uma comparação
justa, impedindo a interferência de facilitadores de terceiros.

3.2.1 Airbrake (AIRBRAKE, 2017)

O Airbrake oferece suporte para repositórios Maven e funciona com uma inte-
gração com o framework de logging, Log4J 1.2, através de appenders. Appenders são
classes Java que implementam a interface Appender e são responsáveis por entregar
os logs de eventos no destino, e esse destino pode ser em um simples console, escre-
ver em arquivos, banco de dados ou até enviar através do método POST do serviço
REST (APPENDERS, ). No entanto o framework log4j já se encontra descontinuado
Capítulo 3. Ambiente de avaliação 25

desde agosto de 2015, a versão mais atual é nomeada log4j2 e já se encontra na
versão 2.8.2.
O Airbrake é configurado através do arquivo de propriedades do log4j, onde
são fornecidos a chave de acesso além de informações relacionadas ao appender
do log4j. Para que o framework passe a enviar as mensagens de log para o servidor,
é necessário utilizar a classe Logger do log4j. Como o objetivo do trabalho não é
explicar o funcionamento do log4j, não entraremos em mais detalhes sobre o seu
funcionamento.

Código 3.4 – Dependencias do Airbreak
<dependency>
<groupId> l o g 4 j < / groupId>
< a r t i f a c t I d >log4j</ a r t i f a c t I d >
<version>1.2.17< / version>
< / dependency>

<dependency>
<groupId> i o . a i r b r a k e < / groupId>
< a r t i f a c t I d > a i r b r a k e −j a v a < / a r t i f a c t I d >
<version>2.2.8< / version>
< / dependency>

Código 3.5 – log4j.properties
l o g 4 j . r o o t L o g g e r =INFO , s t d o u t , a i r b r a k e

l o g 4 j . appender . s t d o u t =org . apache . l o g 4 j . ConsoleAppender
l o g 4 j . appender . s t d o u t . l a y o u t =org . apache . l o g 4 j . P a t t e r n L a y o u t
l o g 4 j . appender . s t d o u t . l a y o u t . C o n v e r s i o n P a t t e r n =[%d,%p ] [%c { 1 } . %
M:%L ] %m%n

l o g 4 j . appender . a i r b r a k e = a i r b r a k e . AirbrakeAppender
l o g 4 j . appender . a i r b r a k e . api_key =YOUR_KEY_HERE
l o g 4 j . appender . a i r b r a k e . env=development
/ / l o g 4 j . appender . a i r b r a k e . env= p r o d u c t i o n
/ / l o g 4 j . appender . a i r b r a k e . env= t e s t
l o g 4 j . appender . a i r b r a k e . enabled= t r u e
l o g 4 j . appender . a i r b r a k e . u r l = h t t p : / / a p i . a i r b r a k e . i o / n o t i f i e r _ a p i
/ v2 / n o t i c e s
Capítulo 3. Ambiente de avaliação 26

Figura 2 – Aba de overview da aplicação Airbrake

Fonte: print screen do painel de controle do Airbrake

Figura 3 – Aba de occurrences da aplicação Airbrake

Fonte: print screen tirada do dashboard do Airbrake

O dashboard do Airbrake se apresenta de forma simples e intuitiva, nele é
possível verificar informações pertinentes ao erro como quando aconteceu, a mensa-
gem passada, o endereço remoto do servidor onde ocorreu o erro, além do backtrace
Capítulo 3. Ambiente de avaliação 27

da ocorrência. Algumas dessas características podem ser visualizadas na Figura 1 e
Figura 2. A principal vantagem do Airbrake é a facilidade de configuração quando a
aplicação já faz uso do framework log4j, dessa forma o custo de alteração de código é
mínimo. Em contrapartida o log4j não recebe mais suporte da comunidade, pondo em
risco a manutenibilidade do código.

3.2.2 Raygun (RAYGUN, 2017)

As dependências do Raygun também estão disponíveis no repositório Maven,
simplificando bastante a instalação. Diferentemente do Airbrake, o Raygun não utiliza
nenhum framework de logging como dependência, ele utiliza uma instancia da inter-
face java Thread.UncaughtExceptionHandler, que é invocada quando uma thread é
terminada abruptamente devido a um uncaught exception (INTERFACE. . . , ). No nosso
código, implementamos uma instância da interface Thread.UncaughtExceptionHandler,
e na implementação do método uncaughtException é criada uma instância do Ray-
gunClient, essa instância é responsável por enviar as exceções não capturadas para
o Raygun (Código 3.5, 33 - 39). Para fazer o rastreio das exceções não capturadas
no nosso método main, é necessário passar como parâmetro a nossa instância do
Thread.UncaughtExceptionHandler para o método estático setDefaultUncaughtExcepti-
onHandler da classe Thread (Código 3.5, 13).

Código 3.6 – App.java
1 i m p o r t j a v a x . p e r s i s t e n c e . EntityManager ;
2 import javax . persistence . EntityManagerFactory ;
3 import javax . persistence . Persistence ;
4
5 i m p o r t com . mindscapehq . raygun4java . core . RaygunClient ;
6
7 i m p o r t t g . n a t a n a e l . e n t i t y . Person ;
8
9 p u b l i c c l a s s App {
10
11 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] args ) throws Throwable
{
12
13 Thread . s e t D e f a u l t U n c a u g h t E x c e p t i o n H a n d l e r ( new
MyExceptionHandler ( ) ) ;
14
15 EntityManagerFactory f a c t o r y = Persistence .
c r e a t e E n t i t y M a n a g e r F a c t o r y ( " maria " ) ;
16 EntityManager manager = f a c t o r y .
createEntityManager ( ) ;
17
18 Person person = new Person ( ) ;
19 person . setName ( " Jhon " ) ;
20
Capítulo 3. Ambiente de avaliação 28

21 f o r ( i n t i = 0 ; i < 100000; i ++) {
22
23 manager . g e t T r a n s a c t i o n ( ) . begin ( ) ;
24 manager . p e r s i s t ( person ) ;
25 manager . g e t T r a n s a c t i o n ( ) . commit ( ) ;
26 }
27
28 manager . c l o s e ( ) ;
29 f a c t o r y . close ( ) ;
30 }
31 }
32
33 c l a s s MyExceptionHandler implements Thread .
UncaughtExceptionHandler
34 {
35 p u b l i c v o i d uncaughtException ( Thread t , Throwable e ) {
36 RaygunClient c l i e n t = new RaygunClient ( "
nQH7dhoBpU / Zc4ltm5Y / sA== " ) ;
37 c l i e n t . Send ( e ) ;
38 }
39 }

Como visto no código anterior, a configuração desse framework tem um impacto
mínimo no código, visto que só é necessário algumas inserções de linhas de código.
Essa abordagem é bastante vantajosa porque não é necessário se preocupar com o
lançamento das exceções. Fazendo um paralelo com o Airbrake, usando o primeiro
framework só é possível capturar os eventos que foram capturados via o log4j, enquanto
que aqui só capturado as exceções que não esperadas pelos desenvolvedores. Essa
abordagem dá a vantagem de usar o Raygun em conjunto com outro serviço de
rastreamento de erro justamente por capturar eventos que outras ferramentas não são
capazes de capturar.
Capítulo 3. Ambiente de avaliação 29

Figura 4 – Dashboard da aplicação Raygun

Fonte: print screen capturado da aplicação Raygun

Figura 5 – Aba de environment da visão do erro RollbackException

Fonte: print screen capturado da aplicação Raygun

O painel de controle do Raygun se apresenta repleta de opções para o usuário,
porém aqui serão tratados apenas as opções que concernem com o propósito do
trabalho. O framework oferece opções para gerenciar os erros capturados, nele é
Capítulo 3. Ambiente de avaliação 30

possível agrupar os erros em categorias e atribuir a cada erro um usuário específico
para ficar responsável com o tratamento deste erro. Outro aspecto importante é que é
possível analisar algumas métricas relacionadas ao servidor de produção que podem
ser importante para entender o contexto que originou o erro, dentre essas métricas
estão: memória virtual disponível, memória virtual total e contador de processador.
Além dessas características, o framework cumpre bem ações como notificação por
e-mail e criar integração com outras ferramentas. Tudo isto pode ser visualizado na
Figura 3 e Figura 4.

3.2.3 Rollbar (ROLLBAR, 2017)

As dependências do Rollbar também são disponíveis via Maven, e sua configura-
ção é bastante semelhante as configurações do Raygun, porém com uma diferença, ele
utiliza uma instância própria da classe Rollbar, além de poder capturar manualmente
os eventos que são lançados na aplicação, esses eventos são classificados em error,
critical, warning, log, debug e info e são capturados usando os métodos com os res-
pectivos nomes da classe Rollbar. Essas implementações serão melhores explicadas
com o código adiante. A integração com o código é executada criando uma instância
da classe Rollbar, é mandatório passar como parâmetro to token de acesso à conta,
que pode ser encontrado nas configurações da interface web do Rollbar (Código 3.7,
11). Após a criação da instância da classe Rollbar, já é possível lançar os eventos
manualmente (Código 3.7, 31) ou lançar as exceções não tratadas chamando o método
handleUncaughtErrors() (Código 3.7, 15).

Código 3.7 – Main.java
1 i m p o r t j a v a x . p e r s i s t e n c e . EntityManager ;
2 import javax . persistence . EntityManagerFactory ;
3 import javax . persistence . Persistence ;
4
5 i m p o r t com . r o l l b a r . R o l l b a r ;
6
7 i m p o r t t g . n a t a n a e l . e n t i t y . Person ;
8
9 p u b l i c c l a s s App {
10
11 p u b l i c s t a t i c f i n a l R o l l b a r r o l l b a r = new R o l l b a r ( " 3
f6b5d9ab319423db0b4cdf2f49dbe11 " , " p r o d u c t i o n " ) ;
12
13 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] args ) throws Throwable
{
14
15 r o l l b a r . handleUncaughtErrors ( ) ;
16
17 EntityManagerFactory f a c t o r y = Persistence .
c r e a t e E n t i t y M a n a g e r F a c t o r y ( " maria " ) ;
Capítulo 3. Ambiente de avaliação 31

18 EntityManager manager = f a c t o r y .
createEntityManager ( ) ;
19
20 Person person = new Person ( ) ;
21 person . setName ( " Jhon " ) ;
22
23 f o r ( i n t i = 0 ; i < 100000; i ++) {
24 try {
25 manager . g e t T r a n s a c t i o n ( ) . begin
() ;
26 manager . p e r s i s t ( person ) ;
27 manager . g e t T r a n s a c t i o n ( ) . commit
() ;
28
29 } c a t c h ( E x c e p ti o n e ) {
30 e . printStackTrace ( ) ;
31 rollbar . error (e) ;
32 }
33 }
34
35 manager . c l o s e ( ) ;
36 f a c t o r y . close ( ) ;
37
38 }
39 }

Como visto no código anterior, as modificações no código fonte são mínimas
dependendo do nível de captura de eventos desejável pelo usuário. Se o objetivo for
capturar exceções não tratadas no código, só é necessário adicionar duas linhas de
código como visto nas linhas 11 e 15 do código 3.7 - App.java acima. Se o objetivo
também for tratar individualmente cada evento, é exigido o lançamento do devido evento,
como visto na linha 31 do código 3.7.
Essa abordagem é bastante vantajosa pois possibilita para o desenvolvedor
escolher a melhor forma de integrar o framework com a aplicação. Se a integração
for feita desde o início da implementação do código, pode ser pertinente o uso através
de lançamentos de eventos manuais, enquanto que a integração for feito no meio do
ciclo de vida do código, pode ser mais viável capturar apenas os erros não tratados,
mas nada impede o uso dos dois tratamentos. Se algum outro framework já seja
responsável pelo lançamento manual desses eventos, e o objetivo de se integrar o
rollbar é capturar os eventos inesperados, pode ser viável utilizar apenas o Rollbar
para ambos tratamento, se por um lado vai existir um custo com modificação de código,
por outro haverá uma vantagem de custo financeiro e gerenciamento, pois apenas um
framework será usado na aplicação.
Capítulo 3. Ambiente de avaliação 32

Figura 6 – Aba de itens da aplicação Rollbar

Fonte: print screen tirada da aplicação Rollbar

Figura 7 – Aba de community solutions relacionada a um erro na aplicação Rollbar

Fonte: print screen tirada da aplicação Rollbar

A interface do usuário do Rollbar apresenta uma funcionalidade de filtrar eventos
baseada nos tipos de eventos lançados na aplicação pelos desenvolvedores, esses
eventos são: Critial, Error, Warning, Infor e Debug. Essa funcionalidade pode ser
Capítulo 3. Ambiente de avaliação 33

visualizada na Figura 5. Utilizando a configuração padrão fornecida pelo site do Rollbar
não foi possível visualizar informações relacionadas ao ambiente de produção, como
o ip do servidor ou alguma informação padrão como o nome do sistema operacional.
Uma caraterística exclusiva que não foram vistas nos error trackers até agora é a
possibilidade de encontrar soluções de erros específicos fornecidas pela comunidade
do Rollbar, essa particularidade pode ser utilizada pelos desenvolvedores para acelerar
o processo de correção dos erros relatados, essa funcionalidade pode ser visualizada
na Figura 6.

3.2.4 Sentry (SENTRY, 2017)

O Sentry concede duas formas de lançamentos de eventos utilizando a lingua-
gem java, a primeira reporta eventos manualmente utilizando a classe SentryClient, a
segunda se baseia na integração com frameworks de logging. Neste trabalho iremos
utilizar a segunda forma de reportar eventos pelos seguintes motivos: Não ser necessá-
rio aprender uma biblioteca nova, além de aumentar o nível de modificação do código
e por já existir um modo de levantar logs maduro e adotado pela comunidade.
A configuração do Sentry utilizando um framework de logging é bastante seme-
lhante com a configuração do Airbrake. Diferente do seu semelhante, o Sentry suporta
o Log4j2, que é licenciada sob os termos do Apache License 2.0; o Logback, licenciado
sob os termos do Eclipse Public License v1.0 e GNU Lesser General Public License
version 2.1, além da classe Logging que faz parte do pacote Util do java.

Código 3.8 – Sentry - log4j2.xml
1 <?xml v e r s i o n = " 1 . 0 " encoding= "UTF−8" ?>
2 < c o n f i g u r a t i o n s t a t u s = " warn " packages= " org . apache . l o g g i n g . l o g 4 j
. core , i o . s e n t r y . l o g 4 j 2 " >
3 <appenders>
4 <Console name= " Console " t a r g e t = "SYSTEM_OUT" >
5 < P a t t e r n L a y o u t p a t t e r n = "%d { HH:mm:ss . SSS} [% t ] %−5
l e v e l %l o g g e r { 3 6 } − %msg%n " / >
6 < / Console>
7
8 < S e n t r y name= " S e n t r y " / >
9 < / appenders>
10
11 <loggers>
12 < r o o t l e v e l = " INFO " >
13 <appender−r e f r e f = " Console " / >
14 < !−− Note t h a t t h e S e n t r y l o g g i n g t h r e s h o l d i s
o v e r r i d d e n t o t h e WARN l e v e l −−>
15 <appender−r e f r e f = " S e n t r y " l e v e l = "WARN" / >
16 </ root>
17 < / loggers>
18 < / c o n f i g u r a t i o n >
Capítulo 3. Ambiente de avaliação 34

Por simplicidade e por já termos usado o log4j na configuração do Airbrake,
iremos utilizar o log4j2 para fazer a integração com o Sentry. O uso é bastante inteligível,
sendo necessário apenas configurar o arquivo log4j2.xml, adicionando o appender que
referencia o Sentry, o exemplo dessa configuração pode ser visualizada no código 3.8
acima, e inicializar o sentry no método main da classe App, passando como parâmetro
o DSN(Data Source Name). A configuração do DSN é a primeira e mais importante
tarefa a se concluir, pois ela diz ao SDK para onde os eventos devem ser enviados,
o DSN pode ser encontrado nas configurações do projeto dentro da interface web do
Sentry. O exemplo da inicialização do Sentry pode ser visto no código 3.9.

Código 3.9 – Sentry - App.java
1 S e n t r y . i n i t ( " h t t p s : / / p u b l i c : private@host : p o r t / 1 " ) ;

A interface web do Sentry não oferece muitas novidades. A estrutura é bastante
simples entregando uma lista de eventos lançados agrupados pela quantidade de lan-
çamentos. O Sentry também pode ser usado como uma ferramenta de gerenciamento
de tarefas para desenvolvedores, já que é possível atribuir usuários específicos para
tratarem determinados erros. Informações como o stacktrace ou detalhes do ambiente,
como quando o evento ocorreu ou o nome do servidor também estão presentes, assim
como nos demais frameworks. Algumas dessas informações podem ser confirmadas
na Figura 7 e Figura 8.

Figura 8 – Aba de issues da aplicação Rollbar

Fonte: print screen tirada da aplicação Sentry
Capítulo 3. Ambiente de avaliação 35

Figura 9 – Visão relacionada a um erro na aplicação Sentry

Fonte: print screen tirada da aplicação Sentry

3.2.5 Overops (KNOW. . . , 2017)

Diferente de todas as ferramentas vistas agora, o Overops se destaca por agir no
nível da máquina virtual java (JVM), ou seja, não é necessário a inserção de nenhuma
linha de código ou uso de framework de logging. Esse comportamento possibilita que
a ferramenta colete dados relacionados com o estado das variáveis e o código atual
que é executado no instante do erro, além de detectar caught/uncaught exceptions e
logs de erro. Todas essas funcionalidades não funcionam como mágica, tudo isso é
possível porque o Overops executa no servidor como um micro-agent Java(cada um
por JVM), e um coletor daemon, quando combinado os dois, o Overops detecta todos
os eventos citado no início deste parágrafo.
Capítulo 3. Ambiente de avaliação 36

Figura 10 – Overops Workflow

http://blog.takipi.com/why-is-takipi-made-for-production/

Para instalar e configurar o Overops, é mandatório fazer o download e instalar o
pacote Overops. A ferramenta provê suporte para diversas distribuições Linux, desde
que não sejam 32-bits, macOS (10.6+) e Windows Server 2008/Windows Vista ou
novas versões desde que não sejam 32-bits. Como o sistema operacional usado nesse
projeto é o Fedora 23, iremos instalar o Overops utilizando um comando shell que faz
o download do pacote e executa o script de instalação. É mandatório trocar o MyKey
pela chave de instalação que pode ser gerada nas configurações da interface web do
Overops:

Código 3.10 – Script de instalação do Overops
wget −O − −o / dev / n u l l h t t p : / / g e t . t a k i p i . com | sudo bash / dev /
s t d i n − i −−sk=<MyKey>

Em seguida é necessário conectar o Overops Agent como argumento da JVM.
Isto pode ser feito adicionando este valor como argumento da JVM:
-agentlib:TakipiAgent
Se o eclipse for utilizado, esse argumento pode ser adicionado na aba de
VM arguments que pode ser alcançado acessando o menu Debug Configuration ->
Arguments Tab. Após essas etapas, o Overops já está pronto para começar a receber
os dados da aplicação.
A interface web do Overops é bastante intuitiva. A ferramenta tem uma carac-
Capítulo 3. Ambiente de avaliação 37

terística de classificar os eventos em categorias, JVM errors; Logged errors; Logged
warnings; Uncaught exceptions; DB errors; Network errors. Essa funcionalidade sim-
plifica bastante a busca por determinados eventos. Além das categorias, o Overops
oferece uma funcionalidade de classificar os eventos em labels, Critical; High priority;
Low priority; Archive; Resolved e Resurfaced, seus nomes são auto explicativos. Na
interface relacionada a um evento, é possível visualizar o código fonte do programa
no momento da ocorrência do evento, além do estados de todas a variáveis que de
alguma forma se relaciona com o evento, além disso é também possível visualizar
as mensagens de logging que foram lançadas no processo e também as métricas
relacionadas à JVM, sendo elas: Memory; Garbage Collection; JVM Process; Class
Loading; JIT Compilation; Operating System; Environment Variables; System Properties
e Active Threads. Estas são particularidades que fazem o Overops se distanciar das
outras ferramentas se o nível de detalhamento dos eventos exigido for superior. Boa
parte do que foi discutido aqui pode ser visualizado na Figura 10 e Figura 11.

Figura 11 – Aba de all events da aplicação Overops

Fonte: print screen tirada da aplicação Overops
Capítulo 3. Ambiente de avaliação 38

Figura 12 – Visão relacionada ao erro SQL Error na aplicação Overops

Fonte: print screen tirada da aplicação Overops

3.3 Resultados

Como síntese das avaliações vistas neste capítulo, iremos colocar as ferramen-
tas lado a lado e fazer uma comparação entre os dois parâmetros que mais foram
abordados neste trabalho: Instalação e Modificabilidade de código.

• Instalação - É o nível de facilidade que um framework tem de ser integrado com
o código fonte da aplicação a ser monitorada. Aqui será abordado a necessidade
de dependências por parte do framework.

• Modificabilidade de código - É o nível do quanto o código precisa ser modifi-
cado para que a integração com o framework funcione corretamente.

Os parâmetros serão classificados em uma escala de três níveis: Atende;
Atende Parcialmente e Não Atende. A instalação atende quando não é necessário
nenhuma outra dependência em relação à própria ferramenta, ou seja, apenas com
a biblioteca da ferramenta é possível concluir a instalação. A instalação atende parci-
almente quando é exigido o uso de algum outro framework, como por exemplo o uso
de uma biblioteca de logging como o log4j. E por fim, a instalação não atende quando
não é possível realizar a integração. Neste trabalho conseguimos fazer a integração
com êxito de todas as ferramentas, logo todas as ferramentas pelo menos atenderam
parcialmente no parâmetro de instalação. A modificabilidade de código atende quando
Capítulo 3. Ambiente de avaliação 39

não é necessário fazer alterações no código, nem que seja uma única linha. A modifi-
cabilidade de código atende parcialmente quando é exigido que o lançamentos dos
eventos sejam feitas manualmente, via uso de framework de logging ou não. E por
fim, a modificabilidade de código não atende quando a estrutura do código precisa ser
modificada totalmente.
Tabela 2 – Resultados: Instalação

Exception Tracker Instalação

Airbrake Atende Parcialmente

Raygun Atende

Rollbar Atende

Sentry Atende Parcialmente

Overops Atende

Tabela 3 – Resultados: Modificabilidade de Código

Exception Tracker Modificabilidade de Código

Airbrake Atende Parcialmente

Raygun Atende Parcialmente

Rollbar Atende Parcialmente

Sentry Atende Parcialmente

Overops Atende

Como síntese destas avaliações, as ferramentas foram qualificadas de acordo
com os dois parâmetros escolhidos pelo autor no começo deste capítulo. Na Tabela 2 é
possível ver os resultados das ferramentas qualificadas no quesito instalação, enquanto
que na Tabela 3 é possível ver os resultados das ferramentas qualificadas no quesito
de modificabilidade de código.
É compreensível que as ferramentas que utilizam frameworks de logging atende-
ram parcialmente o parâmetro de instalação devido a esta dependência. Já no quesito
de modificabilidade de código, com exceção do Overops, todas atenderam parcialmente
pela necessidade de implementação de código. É importante mencionar que estes
resultados foram obtidos baseados pela avaliação do autor deste trabalho, e que os
parâmetros, tais como suas escalas foram descritos de acordo com o ponto de vista
do mesmo. Também é considerável deixar claro que a escolha de uma ferramenta de
Capítulo 3. Ambiente de avaliação 40

monitoramento de exceções baseada nas avaliações exploradas neste trabalho não
garantem exatidão nesta escolha, se um software é escrito sem o uso de um framework
de logging, nada impede que o desenvolvedor do código dê preferência pelo uso do
Airbrake ou Sentry que dependem desses frameworks para se integrar com a aplicação.
41

4 Conclusão e trabalhos futuros

Neste trabalho introduzimos o conceito de serviço de monitoramento de erros
passando por seus objetivos e motivações de uso. Apresentamos as cinco principais
ferramentas de monitoramento de erros para linguagem java e discutimos a integração
de cada uma das ferramentas com o sistema a ser monitorado. Os exemplos de códigos
e ferramentas foram descritos de forma a serem facilmente reproduzidos e testados.
Da comparação entre as ferramentas, o Overops foi o que obteve melhor êxito,
desde que essa solução atua no nível da JVM, não é necessário nenhuma alteração no
código, consequentemente é possível que essa solução seja integrada a qualquer sis-
tema em produção que já esteja sendo executado. Enquanto que as outras ferramentas
exigem pelo menos que os eventos sejam lançados manualmente, mesmo que sejam
via framework de logging. Para quem já utiliza algum framework de logging como o
log4j, pode ser vantajoso usar o Airbrake ou Sentry. Se o objetivo for apenas capturar
eventos que não são esperados pelo sistema, o Raygun ou Rollbar pode ser a melhor
opção.
As avaliações concluídas aqui foram baseadas apenas na capacidade dessas
ferramentas se integrarem com o código, outros parâmetros como capacidade de
captura de erros, capacidade de notificação, capacidade de integração com outras
ferramentas de gerenciamento ou até mesmo uma análise de UX design podem ser
feitas em outros trabalhos futuros para aumentar o escopo de classificação dessas
ferramentas.
Realizar testes mais robustos é essencial para uma avaliação mais técnica
dessas ferramentas. Expor as ferramentas avaliadas neste trabalho a testes de desem-
penho usando grandes quantidades de exceções para observar como as ferramentas
se comportam diante de um cenário de estresse é importante para uma análise mais
técnica. Outra vertente que também pode ser explorada é a execução de uma análise
dos algoritmos usados no código fonte das ferramentas open sources avaliadas neste
trabalho para pode otimizar seus resultados ou estudar a criação de uma ferramenta de
monitoramento de exceções e eventos de log otimizada de acordo com as ferramentas
analisadas. Todos esses experimentos são desafios que poderão ser explorados em
trabalhos futuros.
42

Referências

ACETO, G. et al. Cloud monitoring: A survey. Computer Networks, n. 57, p. 2093 –
2115, 2013.

ADRAGNA, P. Software debugging techniques. 2008.

AHMED, T. M. et al. Studying the Effectiveness of Application Performance Management
(APM) Tools for Detecting Performance Regressions for Web Applications: An
Experience Report. In: 13TH WORKING CONFERENCE ON MINING SOFTWARE
REPOSITORIES, 2016. [S.l.], 2016.

AIRBRAKE. 2017. Disponível em: <https://airbrake.io/>. Acesso em: 30/06/2017.

AIRBRAKE-JAVA. 2017. Disponível em: <https://github.com/airbrake/airbrake-java>.
Acesso em: 12/07/2017.

APPENDERS. Disponível em: <https://logging.apache.org/log4j/2.x/manual/appenders.
html>. Acesso em: 29/06/2017.

BALDUINO, T. H. G. da S.; RUFINO, R. R. ALTO DESEMPENHO UTILIZANDO
FRAMEWORK HIBERNATE E PADRÃO JAVA PERSISTENCE API. Paranavaí, 2014.

CANDIDO NETO, A. A. et al. HIBERNATE E JPA: CONCEITOS PARA UTILIZAÇÃO. In:
. [S.l.: s.n.], 2016.

CHARAN, N. R. G.; RAO, S. T.; SRINIVAS, D. P. Deploying an Application on the Cloud.
(IJACSA) International Journal of Advanced Computer Science and Applications, v. 2,
n. 5, p. 119 – 125, 2011.

FOX, A.; PATTERSON, D. Engineering Long-Lasting Software: An Agile Approach
Using SaaS and Cloud Computing Beta Edition 0.9.0. 0.9.0. ed. [S.l.]: Strawberry
Canyon LLC, 2012.

FU1, Q. et al. Where Do Developers Log? An Empirical Study on Logging Practices in
Industry. ICSE Companion’14, p. 24 – 33, 2014.

HIBERNATE-JPA-2.1-API 1.0.0.Final API. 2013. Disponível em: <http://docs.jboss.org/
hibernate/jpa/2.1/api/>. Acesso em: 17/07/2017.

INTERFACE Thread.UncaughtExceptionHandler. Disponível em: <https://docs.oracle.
com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html>. Acesso em:
29/06/2017.

JANÁK, J. Issue Tracking Systems. 2009 — MASARYK UNIVERSITY FACULTY OF
INFORMATICS. Acesso em: 20/07/2017.

KNOW When and Why Code Breaks in Production. 2017. Disponível em:
<https://www.overops.com/>. Acesso em: 07/07/2017.

LIMA, C. A. C. de. Um modelo de gerenciamento de identidade para segurança de
aplicativos SAAS. 2012 — C.E.S.A.R.
Referências 43

NAZIR, M. Cloud Computing: Overview & Current Research Challenges. IOSR Journal
of Computer Engineering, v. 8, p. 14 – 22, Dezembro 2012. Acesso em: 10/07/2017.

OLINER, A.; GANAPATHI, A.; XU, W. Advances and Challenges in Log Analysis. Acm
Queue, ACM, 2011.

RAYGUN. 2017. Disponível em: <https://raygun.com/>. Acesso em: 30/06/2017.

RAYGUN4JAVA. 2017. Disponível em: <https://github.com/MindscapeHQ/raygun4java>.
Acesso em: 12/07/2017.

ROLLBAR. 2017. Disponível em: <https://rollbar.com/?dr>. Acesso em: 07/07/2017.

ROLLBAR-JAVA. 2017. Disponível em: <https://github.com/rollbar/rollbar-java>. Acesso
em: 12/07/2017.

SENTRY. 2017. Disponível em: <https://sentry.io/welcome/>. Acesso em: 07/07/2017.

SENTRY. 2017. Disponível em: <https://github.com/getsentry/sentry>. Acesso em:
12/07/2017.

SPINELLIS, D. Debuggers and Logging Frameworks. IEEE SOFTWARE, IEE Computer
Society, p. 98 – 99, 2006. Acesso em: 18/07/2017.

WHAT is Bug Tracking? 2017. Disponível em: <https://airbrake.io/what-is-bug-tracking>.
Acesso em: 20/07/2017.

WHAT IS ISSUE TRACKING? 2008. Disponível em: <https://sifterapp.com/academy/
overview/why/>. Acesso em: 2017.

ZHANG, Y. Automatic software deployment using user-level virtualization for
cloud-computing. 2013.

ZHITNITSKY, A. 5 Error Tracking Tools Java Developers Should Know. 2014. White
Paper.