2 Gerenciamento de Log 2.1 Definições básicas



Documentos relacionados
UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Projuris Enterprise Visão Geral da Arquitetura do Sistema

Disciplina de Redes de Computadores Estudo Dirigido para a Prova II Professor Dr Windson Viana de Carvalho

2 Fundamentação Conceitual

Manual de Instalação PIMSConnector em Windows

Aula 03-04: Modelos de Sistemas Distribuídos

Redes de Computadores II

UNICE Ensino Superior Linguagem de Programação Ambiente Cliente Servidor.

ITIL v3 - Operação de Serviço - Parte 1

SISTEMA LOGS May 20 11:37:47 felipe-virtualbox sudo: pam_unix(sudo:session): session opened for user root by felipe(uid=0)

Pró-Reitoria de Administração - PRAd Assessoria de Informática - AI SISTEMA DE PUBLICAÇÃO DE LICITAÇÕES. Manual de Procedimentos

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Resolução da lista de exercícios de casos de uso

Integração de livros fiscais com o Microsoft Dynamics AX 2009

Permitir a troca de mensagens de texto entre os dois alunos; Permitir que um aluno enviasse para o outro uma cópia de prova;

Programando em PHP. Conceitos Básicos

PLATAFORMA DE DESENVOLVIMENTO PINHÃO PARANÁ TABELIÃO INTERFACE ADMINISTRATIVA MANUAL DE PRODUÇÃO

Redes de Computadores. 1 Questões de múltipla escolha. TE090 - Prof. Pedroso. 17 de junho de 2015

Submissão Autenticada de Ficheiros ao SIGEX

REDES DE COMPUTADORES

Casos de uso Objetivo:

O Processo de Engenharia de Requisitos

Gerenciamento do ciclo de vida de um documento Simone de Abreu

Sistemas de Arquivos NTFS, FAT16, FAT32, EXT2 e EXT3

MODELAGEM E SIMULAÇÃO

INSTALANDO UM SERVIDOR WINDOWS SERVER 2012 R2 SERVER CORE

Manual de Instalação PIMSConnector em Linux

MINISTÉRIO DA EDUCAÇÃO

APERFEIÇOAMENTO DE PROCEDIMENTOS ESTATÍSTICOS PARA AVALIAÇÃO INSTITUCIONAL ONLINE: IMPLANTAÇÃO DE RELATÓRIOS ARMAZENÁVEIS

Parâmetros de Utilização e Manutenção das Mensagens do Informa Online Maio 2007

Java NET: Interaja com a Internet. Ricardo Terra (rterrabh [at] gmail.com) Java NET: Interaja com a Internet Maio,

Camada de Aplicação. Prof. Eduardo

Projetos I Resumo de TCC. Luiz Rogério Batista De Pieri Mat:

REDES DE COMPUTADORES E TELECOMUNICAÇÕES MÓDULO 12

Manual do Usuário do Produto EmiteNF-e. Manual do Usuário

Boletim Eletrônico de Recolhimento Manual do Sistema. Boletim Eletrônico de Recolhimento. Manual do Sistema

NOTA TÉCNICA Nº. 002/2013- VERSÃO 2.0 SNGPC

Resolução de Problemas de Rede. Disciplina: Suporte Remoto Prof. Etelvira Leite

Terminal de Consulta de Preço. Linha Vader. Modelo TT300 e TT1000i

MINISTÉRIO DA SAÚDE. Secretária de Gestão Estratégica e Participativa da Saúde SGEP. Coordenação de Desenvolvimento dos Sistemas de Saúde - CDESS

Introdução à Camada de Aplicação. Prof. Eduardo

Conceitos Básicos de Rede. Um manual para empresas com até 75 computadores

Prática em Banco de Dados MER Sistema SIGEM. Grupo: Marcos Felipe Paes Pessoa Renan do Carmo Reis

Professor: Macêdo Firmino Disciplina: Sistemas Operacionais de Rede

Usando o Conference Manager do Microsoft Outlook

O Sistema foi inteiramente desenvolvido em PHP+Javascript com banco de dados em MySQL.

PORTABILIDADE NUMÉRICA UMA SOLUÇÃO ORIENTADA PELA SIMPLICIDADE, QUALIDADE E BAIXO CUSTO

Satélite. Manual de instalação e configuração. CENPECT Informática cenpect@cenpect.com.br

DIRETORIA DE TECNOLOGIA DA INFORMAÇÃO SETOR DE ESTÚDIO E SUPORTE MANUAL DE UTILIZAÇÃO DO WEBMAIL DA FTC EAD

Oracle WebLogic Server 11g: Conceitos Básicos de Administração

JavaServer Faces. Parte 2

FAZEMOS MONOGRAFIA PARA TODO BRASIL, QUALQUER TEMA! ENTRE EM CONTATO CONOSCO!

Ferramenta para Comunicação Empresarial: Estudo de Caso Marluvas

Tópicos Avançados em Banco de Dados Gerenciamento de Transações em Banco de Dados. Prof. Hugo Souza

Política Gestão de Configuração e Mudança

ADMINISTRAÇÃO DE BANCOS DE DADOS MÓDULO 13

Como estudar o SIPIA CT

Manual do Teclado de Satisfação Online WebOpinião

Medidor Powersave V2 USB

TUTORIAL AMBIENTE WEB PORTUGOL

ANEXO V Edital nº 03508/2008

2. Conceitos e Arquitetura de Bancos de Dados

MANUAL SICCL SQL SRTVS 701 Bloco O Ed. MultiEmpresarial Sala 804 Brasília/DF CEP Fone/Fax: (061) implanta@conselhos.com.

Introdução a Banco de Dados Aula 03. Prof. Silvestri

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Manual MQS. Logo após colocar essas informações abrirá a página inicial do sistema:

Universidade Federal de Santa Catarina Departamento de Informática e Estatística Bacharelado em Sistemas de Informação

Diagrama lógico da rede da empresa Fácil Credito

Sistemas Operacionais. Curso Técnico Integrado Profa: Michelle Nery

1. Explicando Roteamento um exemplo prático. Através da análise de uns exemplos simples será possível compreender como o roteamento funciona.

Entendendo como funciona o NAT

Capítulo 2. Processos de Software Pearson Prentice Hall. Todos os direitos reservados. slide 1

SISTEMAS DISTRIBUIDOS


GBD PROF. ANDREZA S. AREÃO

13/03/ :24 Leite Júnior

No projeto das primeiras redes de computadores, o hardware foi a principal preocupação e o software ficou em segundo plano.

PROCEDIMENTOS DE AUDITORIA INTERNA

Diretrizes para determinação de intervalos de comprovação para equipamentos de medição.

Requisitos de Software

4 Desenvolvimento da ferramenta

Redes de Computadores

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança

RELATÓRIOS QUE PODEM FUNDAMENTAR A IMPLANTAÇÃO DE PEDAGOGIAS GERENCIÁVEIS A PARTIR DO SISTEMA CUSTOMIZADO EDUEAD MOODLE

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar

Catálogo de Padrões de Dados

Agência Nacional de Energia Elétrica ANEEL

Engenharia de Software II

CATÁLOGO DE SERVIÇOS DIRETORIA DE SUPORTE COMPUTACIONAL VERSÃO 1.0

Transcrição:

2 Gerenciamento de Log 2.1 Definições básicas Os logs são fontes riquíssimas de informação e são gerados pelos servidores e pelas aplicações conforme eventos significativos acontecem. Em [1], log é definido como um conjunto de registros com marcação temporal, que suporta apenas inserção, e que representa eventos que aconteceram em um computador ou equipamento de rede. Estes registros constituem a fonte básica de informação tanto para a detecção e resolução de problemas quanto para informações de negócio, como métricas de acesso e comportamento de usuários. O conjunto de atividades desempenhadas na operação de logs, como visualização, armazenamento, compactação, e assim por diante, pode ser denominado de processo de gerenciamento de logs. A importância deste processo é evidenciada por publicações que orientam como as atividades deste processo devem ser conduzidas [1,3]. A seção 2.4 deste capítulo detalha as atividades envolvidas em um sistema que tem como objetivo suportar o processo de gerenciamento de logs. No contexto de uma empresa de Internet, como é o caso da Globo.com, os logs das aplicações são usados tanto para extrair informações de negócio, quanto para identificar e resolver problemas. Estas duas necessidades básicas de logs, informação de negócio e administração de aplicações, se tornam um desafio quando a realidade dos negócios na Internet impõe que as informações de acesso sejam geradas em tempo real e que o parque de servidores, cada vez maior para atender a crescente demanda, seja mais bem administrado. Nesse sentido, sob o ponto de vista da administração de sistemas, quando o volume de acesso aumenta nas aplicações, o número de servidores tende a crescer também, e, com isso, o volume de log não só aumenta, mas como também passa a estar distribuído pelos servidores. Esta distribuição de logs é uma realidade em diversas aplicações que utilizam desde dezenas de

Gerenciamento de Log 16 servidores, como é o caso da Globo.com, até milhares de servidores, como é o caso do Google 4. Desta forma, é importante notar que, ao mesmo tempo em que os desafios técnicos em gerenciar um crescente e distribuído volume de logs se tornam evidentes, as demandas de negócio pressionam por informações em tempo real e por uma administração mais eficiente das aplicações que garanta sempre a disponibilidade. 2.2 Logs como um fluxo de eventos Um dos pontos importantes desta tese é olhar os logs sob um ponto de vista diferente, ou seja, tratar os arquivos de logs de uma aplicação como um fluxo de eventos, para então aplicar técnicas de correlação de eventos baseadas em regras e consultas, que serão abordadas no Capítulo 3. Um evento é definido 12 simplesmente como a ocorrência de uma atividade, ou, no contexto de sistemas de computação, definido como uma representação de uma atividade que acontece em um sistema de computação. Desta forma, cada linha gerada em um arquivo de log corresponde a um evento e a seqüência destes eventos corresponde a um fluxo de eventos. Sobre estes fluxos podem então ser definidas regras e consultas para análise em tempo real. A figura a seguir ilustra esta idéia:

Gerenciamento de Log 17 Figura 1 - Logs como fluxos de eventos 2.3 Caracterização e padrões de logs Dado o grande conjunto de aplicações existentes, é inviável haver um padrão único para todas as mensagens de log. Cada tipo de aplicação distinta possui um formato diferente para seus registros de logs. Contudo existem informações básicas que estão presentes na maioria destes registros 5: Marcação temporal (timestamp): contém a informação de data e hora em que o registro de log foi gerado. É muito importante para que se possa comparar a ocorrência de um evento com outros registros de log no tempo e, assim, correlacioná-los. Severidade: caracteriza o quão importante é aquele registro tendo em vista a integridade do sistema. A severidade é determinada sobre uma escala gradativa que se inicia com mensagens informativas e termina em mensagens que caracterizam uma falha grave no sistema. A tabela a seguir descreve esta escala:

Gerenciamento de Log 18 Nível Descrição Debug ou trace Informações sobre o fluxo de execução do sistema, muito utilizadas em fase de desenvolvimento para correção de erros na aplicação. Info ou notice Caracteriza um evento meramente informacional. Warn Caracteriza um evento sobre o qual se deva ter uma maior atenção e, possivelmente, uma ação pró-ativa para prevenção de erro. Contudo, um erro no sistema não foi caracterizado. Error Caracteriza um evento de erro no sistema. Fatal Caracteriza um evento de erro grave, ou seja, que pode ocasionar degradação ou indisponibilidade de um sistema. Tabela 1 Níveis de severidade para eventos de log Quando a estrutura de gerenciamento de logs é centralizada, outra informação importante e presente nos eventos de log é a fonte. Esta informação identifica que servidor, ou aplicação, gerou aquele evento de log. Felizmente existem hoje diferentes padrões de log estabelecidos. Como esta dissertação está inserida no contexto de gerenciamento de aplicações, serão abordados dois padrões muito utilizados em servidores Web e em aplicações Java 6. Para os servidores Web, como o caso do Apache 7, foi estabelecido um padrão para os logs de acesso, o Common Logfile Format 8, que possui um conjunto de informações fixas a serem registradas a cada evento de log. A Tabela 2 indica a seqüência das informações em uma única linha do Common Logfile Format. A Figura 2 mostra um exemplo de mensagem de log para este padrão.

Informação Descrição Remotehost Nome ou endereço IP do computador que realizou o acesso RFC931 O nome identificador do usuário remoto Authuser O nome de usuário com o qual o usuário se autenticou Date Data e hora da requisição Request A linha de requisição exatamente como gerada pelo cliente Status O código 1 HTTP9 retornado Bytes O tamanho do conteúdo do documento transferido Tabela 2 Descrição de campos do Common Logfile Format 127.0.0.1 - frank [10/Oct/2000:13:55:36-0700] "GET /apache_pb.gif http/1.0" 200 2326 Figura 2 Exemplo de registro de evento de log no padrão Common Logfile Format Para aplicações escritas em Java e servidores de aplicação como o Jboss Web 11, a biblioteca log4j 10 é hoje bastante utilizada, podendo considerá-la um padrão para geração de logs. Contudo, esta biblioteca permite especificar os arquivos e o formato das linhas de log a serem geradas e, sendo assim, as mensagens geradas podem variar de acordo com o que foi configurado. A Tabela 3 traz um exemplo de mensagens de log em diferentes formatos geradas pelo log4j: referência 9. 1 Uma listagem completa com os códigos HTTP podem ser encontrada na

Gerenciamento de Log 20 Mensagem de log em formato de texto simples: INFO [main] (MyApp2.java:12) - Entering application. Mensagem de log em formato XML: <log4j:event logger="org.apache.log4j.xml.xmllayouttestcase" timestamp="mon Aug 10 21:07:25 CEST 2006" sequencenumber="145" level="debug" thread="main"> <log4j:message><![cdata[hi]]></log4j:message> <log4j:throwable><![cdata[java.lang.exception at org.apache.log4j.xml.xmllayouttestcase.testnull(x) at java.lang.reflect.method.invoke(x) [..] ]]></log4j:throwable> </log4j:event> Tabela 3 Diferentes formatos de mensagens de log com log4j Takada e Koike 13 propõem um formato genérico para linhas de logs bastante simples. O General Log Format, formato utilizado pela aplicação de visualização de logs apresentada no artigo, contém quatro campos, sendo dois pré-fixados e dois livres. Os campos fixos são a marcação temporal e o campo mensagem. Existem outros dois campos nomeados como tag 1 e tag 2 que podem ser utilizados para outras informações, por exemplo, a severidade e a identificação de quem originou a requisição. Outra iniciativa de proposta de formato de log é encontrada em 24, que propõe um padrão baseado em XML para Bibliotecas Digitais. Baseando-se neste estudo sobre os padrões e nas principais informações de um evento de log e considerando os requisitos que serão expostos no Capítulo 4, um padrão será proposto nesta dissertação, também no Capítulo 4, para representar os eventos de log.

Gerenciamento de Log 21 2.4 Sistema de gerenciamento de logs O gerenciamento de logs sob o ponto de vista de um sistema envolve um conjunto amplo de atividades. Baseando-se em [1, 3, 5], esta dissertação lista as seguintes atividades relacionadas ao gerenciamento de logs: Análise léxica e transformação: é o processo que,analisa,as linhas de mensagens de log e produzir uma saída formatada em um padrão mais adequado para futuro processamento. Transmissão e recepção: é o processo que transmite os eventos de logs para um servidor central, em conjunto com o processo que recebe as mensagens de log no servidor. Análise sobre eventos de log: é o processo que, através de algoritmos, regras ou consultas extrai informação relevante sobre mensagens de log. Compactação: é o processo que, reduz o tamanho de uma informação através de algoritmos de compactação de texto. Como exemplo, pode-se citar os algoritmos baseados no algoritmo de Lempel-Ziv-Welch. Armazenamento: é o processo que compreende em guardar os registros de log por um tempo determinado. Este processo é necessário muitas vezes para fins legais e, também, desejado para que se possa ter um histórico. Indexação e Busca: é o processo responsável por estruturar os registros de logs de forma que sejam posteriormente pesquisados. Visualização: é o processo que permite a visualização dos registros de log, sejam eles em tempo real ou dos registros já armazenados. Para realizar estas atividades, uma nova classe de sistema foi criada e chamada de Sistemas de Gerenciamento de Log (Log Management Systems - LMS). Sah 1 propõe uma arquitetura completa de um sistema de gerenciamento de logs, voltada para sistemas com grande volume de acesso e distribuídos. Vale ressaltar que o sistema de gerenciamento de logs apresentado é um sistema proprietário. A arquitetura proposta compõe-se de três serviços principais o Master Service, o Parsing Service e o Storage Service. O Master Service recebe requisições HTTP contendo linhas de logs em um formato XML. Cada requisição é passada então em paralelo para o Parsing Service, que irá através de expressões regulares retirar informações das linhas de log, e para o Storage

Gerenciamento de Log 22 Service que irá indexar, compactar e armazenar os logs. A análise dos logs é feita sobre a forma de consultas SQL sobre uma base de dados modificada. Quanto à visualização, não foi claramente especificada como esta acontece no sistema. Fischer 5 divide a arquitetura de sistemas de gerenciamento de log em três camadas: entrada, processamento e saída. Em sua tese, propõe o uso do protocolo XMPP 14 como método de transmissão e recepção de mensagens de logs, tendo como vantagens a interoperabilidade, segurança, independência de plataforma, confiabilidade e já atual grande adoção do protocolo XMPP. Sobre as atividades de um LMS listadas anteriormente, a atividade de análise de logs é a que talvez tenha mais atraído o interesse de pesquisas. Existe uma literatura ampla sobre algoritmos de análise de logs. Como exemplos, pode-se citar: Adeva e Atxa 19 que propuseram um algoritmo baseado em técnicas de text-mining capaz de diferenciar comportamentos normais de maliciosos com base nos logs do servidor de aplicação. Vaarandi [17, 18] que publicou dois artigos sobre identificação de padrões freqüentes em logs. Algoritmos capazes de minerar arquivos logs e identificar perfis de usuários 19, períodos interessantes para o negócio 20, e algoritmos que conseguem descobrir estes padrões em tempo real 21. Algoritmos capazes de inferir regras sobre o comportamento de uma aplicação sobre um conjunto de logs [22, 23]. Além destes algoritmos, existem também os componentes que possibilitam uma forma mais simples de correlação de eventos de log, atividade que será definida no Capítulo 3, capaz de produzir resultados e responder aos eventos em tempo real. Estes componentes se baseiam em regras pré-determinadas para correlação de eventos e em consultas do tipo SQL que podem ser criadas e executadas continuamente sobre um fluxo de eventos. Esses componentes serão detalhados no Capítulo 3 desta dissertação. Sobre a atividade de visualização de logs, 13 apresenta o Mielog, um sistema desenvolvido em C++ que propõe uma interface interativa para visualização e navegação sobre mensagens de log. Ainda sobre atividades de gerenciamento de logs, é importante ressaltar que centralizar os logs não é uma tarefa simples. Quando se está lidando com volumes altíssimos de logs, estas mensagens tem que ser transmitidas, e isto

Gerenciamento de Log 23 pode representar um tráfego alto na rede. Na Globo.com, por exemplo, um único servidor Web chega a gerar logs com mais de 2 GB por dia. Schlossnagle 15 propõe algumas arquiteturas para a centralização dos logs, entre elas, o uso de comunicação de grupo (multicast) para tentar diminuir o tráfego na rede quando as mensagens são transmitidas para mais de um destino.