ENRIQUECIMENTO SEMÂNTICO DE LOGS COMO AUXÍLIO NO
PROCESSO DE GESTÃO E TOMADA DE DECISÕES
UNIVERSIDADE FEDERAL DE PERNAMBUCO [email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE 2018
ENRIQUECIMENTO SEMÂNTICO DE LOGS COMO AUXÍLIO NO
PROCESSO DE GESTÃO E TOMADA DE DECISÕES
Trabalho apresentado ao Programa de Pós-Graduação em Ciência da Computação do Departamento de Informática da UNIVERSIDADE FEDERAL DE PERNAMBUCO como re-quisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Prof. Dr. José Gilson de Almeida Teixeira Filho
RECIFE 2018
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
B277e Barros, Dante Aurélio Dantas de Menezes
Enriquecimento semântico de logs como auxílio no processo de gestão e tomada de decisões / Dante Aurélio Dantas de Menezes Barros. – 2018.
92 f.: il., fig., tab.
Orientador: José Gilson de Almeida Teixeira Filho.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2018.
Inclui referências e apêndices.
1. Ciência da computação. 2. Ontologia. 3. Enriquecimento semântico. I. Teixeira Filho, José Gilson de Almeida (orientador). II. Título.
004 CDD (23. ed.) UFPE- MEI 2018-061
ENRIQUECIMENTO SEMÂNTICO DE LOGS COMO AUXÍLIO NO
PROCESSO DE GESTÃO E TOMADA DE DECISÕES
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 04 de janeiro de 2018
Aprovado em: 04/01/2018
BANCA EXAMINADORA
———————————————————————– Prof. Dr. Hermano Perrelli de Moura / UFPE
———————————————————————– Prof. Dr. Ivaldir Honorio de Farias Junior
SOFTEX/RECIFE
———————————————————————– Prof. Dr. José Gilson de Almeida Teixeira Filho / UFPE
Primeiramente a Deus por me dar forças e inspiração. A meu professor orientador, Dr. José Gilson de Almeida Teixeira Filho, por ter aceitado esse desafio, por sua compreensão e parceria durante a orientação deste trabalho e pelas palavras de incentivo. Aos meus pais, a meu tio Reginaldo Barros pelo acolhimento e a toda minha família por todo apoio e esforço que fizeram para que eu conseguisse chegar até aqui. Ao Instituto Federal da Bahia - IFBA, pelo apoio e disponibilidade para realizar a pesquisa, em especial à equipe da DGTI que disponibilizaram seu tempo com a realização das entrevistas, seminários e reuniões. À Laise, minha namorada, pelo apoio e por dividir os momentos que temos juntos com o computador. Á Edna Matos, pelo apoio e incentivo em toda essa jornada. Aos colegas de mestrado, pela convivência e parceria. Muito obrigado a vocês e a todos os outros que participaram da minha vida acadêmica ou não e me ajudaram nessa conquista.
Resumo
A utilização de uma abordagem semântica para logs de eventos traz muitos benefícios para a melhoria de processos e da gestão do conhecimento, podendo minimizar os esforços necessários para implementação de um registro de eventos estruturado, contendo informações semanticamente úteis, além de possibilitar a obtenção de dados não acessíveis por meios dos sistemas de informações convencionais. Entretanto ainda é um desafio torna essas informações relevantes e acessíveis de forma operacional e estratégica, de acordo com a função ou cargo que o interessado desempenha na instituição, e apresenta-las de forma elegante e transparente para a gestão, facilitando a sua interpretação e como consequência, um processo de tomada de decisões mais eficientes. Neste contexto, este trabalho tem como objetivo principal demonstrar como o enriquecimento semântico de logs pode ser utilizado nos processos de tomada de decisões gerenciais e/ou técnicas no Instituto Federal da Bahia. Para isso, foi desenvolvida uma ontologia com objetivo de auxiliar no enriquecimento semântico e extração de conhecimentos dos logs, permitindo que esses dados possam ser conectados e combinados com outros dados para melhorar ainda mais a identificação e compreensão dos mesmos, assim como a utilização de regras em gráficos RDF para cálculo das métricas, a serem utilizadas no apoio à gestão, contribuindo para detecção, exploração e definição de problemas e oportunidades em tempo hábil. A abordagem proposta neste trabalho foi avaliada através um painel gerencial com informações das principais métricas e KPIs dos serviços selecionados, mostrando-se adequada como auxilio no processo de gestão e tomada de decisões.
The use of a semantic approach to event logs has many benefits for improving processes and knowledge management, and can minimize the efforts required to implement a structured event log containing semantically useful information, as well as making it possible to obtain data not accessible by means of conventional information systems. However, it is still a challenge to make this information relevant and accessible in an operational and strategic way, according to the function or position that the person performs in the institution, and presents them in an elegant and transparent way for the management, facilitating their interpretation and a more efficient decision-making process. In this context, this paper has as main objective to demonstrate how the semantic enrichment of logs can be used in the processes of managerial and / or technical decision making in the Federal Institute of Bahia. For this, an ontology was developed with the purpose of helping in the semantic enrichment and extraction of knowledge of the logs, allowing that data can be connected and combined with other data to further improve their identification and understanding, as well as the use of rules in RDF charts to calculate metrics, to be used in management support, contributing to the detection, exploration and definition of problems and opportunities in a timely manner. The approach proposed in this work was evaluated through a managerial panel with information of the main metrics and KPIs of the selected services, proving adequate as an aid in the management and decision making process.
Lista de Figuras
2.1 Pilha de tecnologias da Web Semântica. . . 22
2.2 Um gráfico RDF com dois nós (Sujeito e Objeto) conectando-se por um (Predicado). 23 2.3 Ciclo de vida de acordo com o modelo ITIL. . . 30
3.1 Ciclo da Pesquisa-Ação. . . 38
4.1 Processo de desenvolvimento da ontologia. . . 48
4.2 Classes principais e seus relacionamentos. . . 51
4.3 Classes e relações dos logs gerados por serviço de hospedagem web. . . 54
4.4 Classes e relações dos logs gerados por serviço de correio eletrônico. . . 56
4.5 Relações da classe Métrica. . . 57
4.6 Software utilizado na construção da ontologia. . . 58
5.1 Exemplo de um painel de monitoramento de desempenho dos serviços. . . 65
5.2 Arquitetura. . . 66
5.3 Disponibilidade dos sites institucionais (MET04). . . 71
5.4 Acessos suspeitos aos sites (MET08). . . 72
5.5 Métricas operacionais do serviço de correio eletrônico (MET10, MET11). . . . 72
5.6 Efetividade no envio de e-mails (MET14). . . 73
2.1 Exemplos declarações RDF. . . 23
2.2 Usando IRIs para nomear recursos RDF. . . 24
2.3 Exemplos de prefixos e namespaces . . . 25
2.4 Trabalhos relacionados. . . 34
3.1 Priorização das ações e seu respectivo ciclo. . . 45
4.1 Questões de competência. . . 48
4.2 Principais serviços ofertados pela instituição. . . 49
4.3 Arquivos de logs das aplicações. . . 50
4.4 Métricas da ontologia. . . 59
4.5 Análise questões de competência. . . 60
5.1 Métricas referentes aos serviços de Hospedagem de site web e Correio eletrônico. 64 5.2 Exemplos de Alvo para os indicadores-chave de desempenho (KPI) . . . 65
Lista de Códigos de Programas
2.1 Exemplo de logs de Syslog. . . 19
2.2 Exemplo de logs de Nginx. . . 19
2.3 Exemplo de separação utilizando caractere especial (/n) em logs de Syslog. . . 20
2.4 Exemplo de log de eventos utilizando XML. . . 20
2.5 Exemplo de log syslog em formato estruturado. . . 20
2.6 Exemplo de log syslog em formato não estruturado. . . 21
2.7 Exemplo de log apache solr em formato semi-estruturado. . . 21
2.8 Exemplo de subclasses , subpropriedades utilizando a sintaxe funciona. . . 27
5.1 Mapeamento de axiomas. . . 68
5.2 Exemplo de log de acesso em um servidor Web Apache. . . 68
5.3 Representação em RDF extraída desse evento com base na ontologia. . . 69
5.4 Código com regra de inferência utilizando SHACL. . . 69
5.5 Método responsável por adicionar tuplas no repositório. . . 70
KPI Key Performance Indicator
RDF Resource Description Framework . . . 23
RDFS RDF Schema XML Extensible Markup Language . . . 20
W3C World Wide Web Consortium . . . 21
OWL Web Ontology Language . . . 22
RIF Rule Interchange Format . . . 22
SPARQL Protocol and RDF Query Language . . . 22
IRI Internationalized Resource Identifier . . . 24
URI Uniform Resource Identifier . . . 24
JSON JavaScript Object Notation . . . 28
CSV Comma Separated Values . . . 28
TSV Tab Separated Values . . . 28
ITIL IT Infrastructure Library . . . 29
ITSM Gerenciamento de Serviços de TI . . . 29
IFBA Instituto Federal de Educação, Ciência e Tecnologia da Bahia . . . 17
DGTI Diretoria Sistêmica de Gestão de Tecnologia da Informação . . . 41
DRT Departamento de Redes e Telecomunicações . . . 42
PETI Plano Estratégico de Tecnologia da Informação . . . 44
PDTI Plano Diretor de Tecnologia da Informação . . . 41
PDI Plano de Desenvolvimento Institucional ICAS Integrated Cyber Analysis System . . . 49
FOAF Friend of a Friend vocabulary . . . 51
IP Internet Protocol TCP Transmission Control Protocol JENA Jena Semantic Web Java . . . 69
CEFET-BA Centro Federal de Educação Tecnológica da Bahia . . . 41
GDSS Sistemas de suporte de decisão de grupo . . . 33 GSS Sistemas de Suporte de Grupo . . . 33 MSS Sistemas de Suporte de Gerenciamento . . . 33
1 INTRODUÇÃO 15 1.1 Motivação . . . . . . . 15 1.2 Objetivos . . . 17 1.2.1 Objetivo geral . . . . . 17 1.2.2 Objetivos específicos . . . .. . . 18 1.3 Estrutura da Dissertação . . . 18 2 FUNDAMENTAÇÃO TEÓRICA 19 2.1 Logs . . . . . . 19 2.2 Web semântica . . . . . . . . . . . . .. . . 21
2.2.1 Resource Description Framework – RDF . . . 23
2.2.2 RDF Schema (RDFS) . . . .. . . . 25
2.2.3 Web Ontology Language (OWL) 2 . . . .. . . 26
2.2.4 SPARQL . . . .. . . .28
2.2.5 Linked Data . . . . . . 28
2.3 Gerenciamento de Serviços de TI . . . 29
2.3.1 ITIL . . . . . . 29
2.3.1.1 Operação de Serviço . . . .. . . 31
2.3.1.2 Melhoria Contínua do Serviço . . . 31
2.4 Processo de gestão e tomada de decisão . . . 32
2.4.1 Sistemas de Suporte à Decisão . . . 32
2.4.1.1 Componentes dos sistemas de suporte à decisão . . . 33
2.5 Trabalhos Relacionado . . . .34
2.6 Considerações sobre o capítulo . . . ..36
3 METODOLOGIA 37
3.1 Fase exploratória . . . 40
3.2 Seminário . . . .40
3.3 Coleta de dados . . . 40
3.4 Analise documental . . . 41
3.5 Aplicando o método de Pesquisa-ação . . . 41
3.5.3 Reconhecimento dos fatos sobre o problema . . . 43
3.5.4 Planejamento . . . .. . . 45
3.6 Considerações sobre o capítulo . . . 45
4 CAPTURA DO CONHECIMENTO E REPRESENTAÇÃO DO DOMÍNIO 46
4.1 Implantação . . . 46
4.1.1 Uma ontologia para logs de eventos . . . 46
4.1.2 Especificando . . . 48 4.1.3 Conceitualização . . . 49 4.1.4 Formalização . . . 52 4.2 Implementação . . . 58 4.3 Monitoramento . . . 58 4.4 Avaliação . . . 60 4.5 Aperfeiçoamento . . . 61
4.6 Considerações sobre o capítulo . . . 61
5 PAINEL GERENCIAL 62
5.1 Implantação . . . .. . . 62
5.1.1 O painel gerencial . . . 62
5.1.1.1 Avaliar e definir métricas importantes para o negócio . . . .63
5.1.1.2 Definir o painel de TI por área e mapear as métricas associadas para cada área . . . .. 64
5.1.1.3 Definir o alvo de desempenho de cada métrica . . . .. . . 64
5.1.1.4 Desenvolver um painel resumo de TI . . . 65
5.1.1.5 Desenvolver processos para coleta, análise, síntese e relatório de dados . . . . . . 65
5.1.1.6 Reavaliação regular do programa e ajustar metas, métricas e processos quando necessário . . . 66
5.1.2 A arquitetura . . . 66 5.1.3 Processo de extração . . . 67 5.1.3.1 Seleção de dados . . . .67 5.1.3.2 Mapeamento . . . 67 5.1.3.3 Conversão RDF . . . 68 5.1.4 O enriquecimento semântico . . . 68 5.1.5 Armazenamento . . . 69 5.1.6 Processamento . . . 70 5.1.7 Visualização . . . .71
5.4 Aperfeiçoamento . . . . . . 76
5.5 Considerações sobre o capítulo . . . 76
6 CONCLUSÃO 77
REFERÊNCIAS 80
APÊNDICE A - Termo de Livre Consentimento assinado pelos d participantes da entrevista . . . 86
APÊNDICE B - Roteiro para entrevista . . . . . . .87
APÊNDICE C - Detalhamento das métricas . . . 88
APÊNDICE D - Questionário de avaliação do painel de gestão e d ontologia . . . . . . .92
1
INTRODUÇÃO
Este capítulo faz uma introdução e apresenta de sucinta e objetiva a pesquisa, fornecendo informações sobre sua razão e importância, contexto em que está inserida e seus objetivos. Este capítulo é composto pelas seguintes seções: Motivação (1.1), Objetivos (1.2) e Estrutura da Dissertação (1.3).
1.1
Motivação
A grande maioria das aplicações, serviços ou equipamento de rede geram registro de eventos (logs), estes podem ser utilizado para diagnosticar acontecimentos imprevistos, como por exemplo a falta de recursos na infraestrutura em que um sistema está hospedado, ou falha na autenticação de um usuário. Logs também são úteis para armazenar e rastrear o fluxo de aplicações ou equipamento de rede durante a sua execução, possibilitando futuras investigações e monitoramento (ABNT NBR ISO/IEC 27001:2013). Esses registros podem ser armazenados localmente ou de modo remoto, onde no último caso, as mensagens de notificação de eventos são transmitidas através da rede, podendo ou não ser agrupadas em um repositório único.
Conforme a norma ABNT NBR ISO/IEC 27001:2013 convém que os logs produzidos sejam analisados criticamente e em intervalos regulares, porém, essa tarefa não é simples, devido a sua heterogeneidade, os logs produzidos são estruturados e compostos em diversos formatos, de acordo com a função desempenhada pelo sistema ou equipamento que os gerou, o que segundo
NIMBALKAR et al.(2016) pode ser um desafio, dificultando a compreensão desses registros
quando em um formato desconhecido.
Segundo NASCIMENTO; FERRAZ; ASSAD (2011) a análise de logs a procura de
informações sobre eventos, consiste em uma atividade necessária e corriqueira, porém essas informações de logs estão distribuídas entre os sistemas e equipamentos de rede, dificultando a sua coleta e integração (ILIE et al.,2010) e tornando a sua análise mais complexa.
A grande quantidade de informações produzidas pode ser apontada como outro fator que dificulta a análise dos registros de atividades, tornando-se inviável examiná-los manualmente. Uma solução proposta pelo World Wide Web Consortium (W3C) é a utilização de metadados
para descrever os dados, e o fato desses metadados serem compreensíveis por máquina, permite o processamento automático dos recursos relacionados (YU,2014).
No entanto, esses registros são gerados em formato de texto e de forma não estruturada. Portanto, a necessidade em converter esses logs para eventos estruturados, mais compreensíveis por usuários humanos. Agrupam-se em três, as principais soluções presentes na literatura para a conversão desses logs: baseadas em log-parser (TANG; LI; PERNG,2011;HE et al.,2016); baseadas em classificação (GASPARY et al.,2004;FAZZINGA et al.,2017) e baseadas em
cluster (VAARANDI; KONT; PIHELGAS,2016;ZHUGE; VAARANDI,2017).
SegundoLI et al.(2017) embora existam alguns formatos comuns de logs, encontrar uma boa maneira de adapta-los através de um analisador ainda é uma questão desafiadora, para isso, técnicas de mineração de eventos foram utilizadas visando a obtenção de padrões ocultos, tendências ou relacionamentos entre os eventos, essas técnicas têm relação estreita com muitas outras áreas de pesquisa, como mineração de dados, banco de dados, aprendizado de máquinas e estatísticas.
De acordo comNASCIMENTO; FERRAZ; ASSAD(2011) este cenário torna-se ainda
mais complexo quando existe a necessidade de realizar correlações de eventos, identificar quais foram as operações de um determinado usuário em um período específico, ou se a quantidade de erros de uma aplicação está relacionada a uma falha na rede. Um evento de acordo com
FILHO(2011a) pode ser descrito como “qualquer ocorrência detectável ou discernível que seja
significativa para a gestão da infraestrutura de TI, ou para a entrega do serviço de TI, incluindo a avaliação do impacto que um desvio pode causar aos serviços”.
Ainda de segundo FILHO (2011a), para uma melhor gestão desses serviços e por
reconhecer a importância do monitoramento dos eventos, a IT Infrastructure Library (ITIL), por meio de sua biblioteca de boas práticas em gerenciamento de serviços de TI, definiu o processo para gerenciamento de eventos, onde provê a capacidade de detectar eventos, analisá-los e determinar ações de controle apropriadas.
A utilização de uma abordagem semântica para logs de eventos traz muitos benefícios para a melhoria de processos e da gestão do conhecimento, podendo minimizar os esforços necessários para implementação de um registro de eventos estruturado, contendo informações semanticamente úteis (DETRO et al., 2016), além de possibilitar a obtenção de dados não acessíveis por meios dos sistemas de informações convencionais.
Segundo (PEARLSON; SAUNDERS; GALLETTA,2012) para ser relevante e ter um
propósito, a informação deve ser considerada dentro do contexto que é recebida, porém para que esta seja analisada criticamente, é necessário combinar e agregar informações para torna-las coletivamente úteis (YU, 2014), utilizando a tecnologia para melhorar os processos de gerenciamento (ISOTANI et al.,2015).
No entanto, devido ao volume de dados gerados pelos diferentes serviços organizacionais é possível observar dois desafios: como tornar essas informações relevantes e acessíveis de forma operacional e estratégica, de acordo com a função ou cargo que o interessado desempenha na
instituição e como apresenta-las de forma elegante e transparente para a gestão, facilitando a sua interpretação e como consequência, um processo de tomada de decisões mais eficientes.
O processo de tomada de decisão pode ser definido como "a detecção, exploração e definição de problemas e oportunidades, bem como a geração, avaliação e seleção de solu-ções"(MORA et al.,2005). Os padrões de eventos descobertos podem ser usados na tomada de decisões, entretanto existem peculiaridades em como esses padrões podem ser úteis. Enquanto que os administradores de sistemas geralmente têm mais interesse nas informações capazes de prever situações indesejáveis, como interrupções de serviços ou incidentes de segurança, um gestor possui interesse em outros tipos de informações ou em uma granularidade diferente.
De acordo comTURBAN; ARONSON; LIANG(2004) o processamento de informações
manualmente ao tomar decisões está se tornando cada vez mais difícil. Uma possível abordagem para resolver esse problema é a utilização de um conjunto de indicadores de desempenho chave (KPIs) aplicados aos serviços, implementados usando raciocínio baseado em regras sobre a ontologia. Possibilitando a coleta de informações e monitoramento em tempo hábil.
Partindo desse cenário, esta pesquisa tem como questão norteadora identificar de que maneira os dados gerados através dos logs de eventos, podem, com o auxílio enriquecimento semântico e ontologias, contribuir para a extração de conhecimentos úteis nos processos de tomada de decisões gerenciais.
Nesta pesquisa, será adotado como cenário de experimentação os sistemas e equipa-mentos que compõem o datacenter do Instituto Federal de Educação, Ciência e Tecnologia da Bahia (IFBA), fisicamente localizado no campus Salvador. Tal escolha está baseada no fato que nele está concentrado a maioria dos sistemas da instituição, e em decorrência disso, uma grande quantidade de logs são gerados diariamente. O IFBA é uma instituição federal de ensino, que de acordo com seu regimento geral (BRASIL,2013a) tem estrutura administrativa descentralizada, com unidade central está a reitoria, que é composta por pró-reitorias, diretorias sistêmicas, departamentos e etc.
1.2
Objetivos
Nas subseções abaixo estão descritos os objetivos gerais e específicos do presente trabalho.
1.2.1
Objetivo geral
Este trabalho objetiva demonstrar como o enriquecimento semântico de logs pode ser utilizado nos processos de tomada de decisões gerenciais e/ou técnicas.
1.2.2
Objetivos específicos
O objetivo geral do trabalho pode ser alcançado através da obtenção dos seguintes objetivos específicos:
Identificar e selecionar os dados existentes nos logs de diferentes serviços do IFBA e
mapear informações úteis para a tomada de decisão;
Criação de uma ontologia para apoio à gestão que se utiliza dos logs como fonte de
informação;
Capturar as mensagens de notificação de eventos e enriquecê-las semanticamente
utilizando a ontologia, tornando-as adequadas à manipulação por máquinas e usuários humanos;
Demonstração da aplicabilidade da proposta através de um painel gerencial.
1.3
Estrutura da Dissertação
Este trabalho é organizado da seguinte forma: no capitulo 2 será apresentada a fundamen-tação teórica com os conceitos básico para melhor entendimento deste trabalho, apresentando uma revisão da literatura contemplando a estrutura dos Logs, os padrões básicos e componente da Web Semântica, Gerenciamento de Serviços de TI e Processo de gestão e tomada de decisão, assim como discute alguns trabalhos relacionados, comparando com a proposta neste trabalho. Em seguida, no capítulo 3, será apresentada a metodologia, dá qual se deriva os dois capítulos posteriores contendo o detalhamento dos ciclos de pesquisa-ação realizados por esse trabalho. No capítulo 4 é descrito a confecção da ontologia, demonstrando o potencial que as ontologias têm em ajudar na extração de dados semânticos e como a semântica formal em ontologias pode ser adicionado no processo de mineração de logs, enquanto que o capitulo 5 é composto pela construção de um painel gerencial que se utiliza dos resultados do primeiro ciclo, e tem como objetivo avaliar a ontologia e demonstrar a aplicabilidade da proposta desta pesquisa. Por fim, serão apresentadas algumas conclusões, incluindo as contribuições e limitações deste trabalho, além de possíveis trabalhos futuros.
2
FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, é apresentada uma revisão bibliográfica com os conceitos básico para melhor entendimento deste trabalho.
2.1
Logs
Os arquivos de log são compostos por entradas que registram eventos associados a sistemas operacionais, aplicativos em execução ou dispositivos de rede (NIMBALKAR et al.,
2016). Cada dispositivo computadorizado é uma potencial fonte de eventos. SegundoAZODI
et al.(2013) a manipulação de arquivos de logs fornecem um desafio no sentido de que, muitas
vezes, não existe nenhuma estrutura definida, como também, não são comuns entre diferentes fontes de eventos .
De acordo com AZODI et al.(2013) existem diferentes maneiras para separação de eventos em um arquivo, com o intuito de que seja possível a inclusão de múltiplos logs em um único arquivo, eles precisam ser separados de tal forma que o usuário possa identificá-lo com eventos individuais. Existe uma série de estratégias que implementam essa separação.
Separação por linha: A maneira mais comum para separar evento, em que cada registro ocupa uma linha do arquivo. Podendo ser observado em logs de Syslog1(Código 2.1) ou do Nginx2(Código 2.2).
Código 2.1: Exemplo de logs de Syslog.
1 Apr 5 2 1 : 1 7 : 0 1 V i r t u a l B o x CRON[ 2 1 8 6 3 ] : ( r o o t ) CMD ( cd / && r u n −p a r t s −− r e p o r t / e t c / c r o n . h o u r l y )
2 Apr 5 2 1 : 3 9 : 0 1 V i r t u a l B o x CRON[ 2 2 1 1 9 ] : ( r o o t ) CMD ( [ −x / u s r / l i b / php / s e s s i o n c l e a n ] &&/ u s r / l i b / php / s e s s i o n c l e a n )
Fonte: (O autor).
Código 2.2: Exemplo de logs de Nginx.
1 2 0 1 7 / 0 4 / 1 0 1 6 : 4 1 : 1 4 [ emerg ] 7 6 0 3 # 0 : b i n d ( ) t o 0 . 0 . 0 . 0 : 8 0 f a i l e d ( 9 8 : A d d r e s s a l r e a d y i n u s e ) 2 2 0 1 7 / 0 4 / 1 0 1 6 : 4 1 : 1 4 [ emerg ] 7 6 0 3 # 0 : s t i l l c o u l d n o t b i n d ( )
Fonte: (O autor).
1https://tools.ietf.org/html/rfc5424/
Separação por um delimitador: É utilizado um delimitador para a separação entre eventos. Para evitar erros, o delimitador deve ser um caractere que não esteja presente nos eventos de log. O caractere especial nova linha (/n) é comumente utilizado para esse fim. Como ilustrado no (Código 2.3).
Código 2.3: Exemplo de separação utilizando caractere especial (/n) em logs de Syslog.
1 Apr 22 1 3 : 5 8 : 0 2 V i r t u a l B o x d h c l i e n t [ 2 2 7 6 6 ] : No w o r k i n g l e a s e s i n p e r s i s t e n t d a t a b a s e − s l e e p i n g . \ n
2 Apr 22 1 3 : 5 8 : 0 2 V i r t u a l B o x Ne t w o rk M a n ag e r [ 7 2 6 ] : < i n f o > [ 1 4 9 2 8 8 0 2 8 2 . 1 8 3 5 ] d h c p 4 ( e n p 0 s 3 ) : s t a t e c h a n g e d unknown − > f a i l \ n 3 Apr 22 1 3 : 5 8 : 0 2 V i r t u a l B o x k e r n e l : [ 3 2 4 8 1 . 3 ] i n p u t : V i r t u a l B o x USB T a b l e t a s / d e v i c e s / p c i / u s b 1 / 1 − 1 / 1 − 1 : 1 . 0 / i n p u t / i n p u t 1 1 \ n
Fonte: (O autor).
Através de estruturas: Utiliza-se de estruturas para incorporar vários eventos, como exemplo, a utilização de um esquema Extensible Markup Language (XML), implementado pela infraestrutura de log da Microsoft3(Código 2.4).
Código 2.4: Exemplo de log de eventos utilizando XML.
1 < E v e n t x m l n s =" h t t p : / / s c h e m a s . m i c r o s o f t . com / win / 2 0 0 4 / 0 8 / e v e n t s / e v e n t " > 2 − <System > 3 < P r o v i d e r Name=" E v e n t L o g " / > 4 < E v e n t I D Q u a l i f i e r s = " 3 2 7 6 8 " > 6 0 1 3 < / E v e n t I D > 5 < L e v e l >4 </ L e v e l > 6 <Task >0 </ Task > 7 <Keywords >0 x80000000000000 < / Keywords > 8 < T i m e C r e a t e d SystemTime ="2017 −04 −21 T15 : 0 0 : 0 0 . 7 5 9 4 7 0 5 0 0 Z " / > 9 < E v e n t R e c o r d I D > 376 84 </ E v e n t R e c o r d I D > 10 < C h a n n e l > System < / C h a n n e l > 11 < Computer >LAPTOP< / Computer > 12 < S e c u r i t y / >
13 </ System >− 14 </ E v e n t >
Fonte: (O autor).
A qualidade da informação extraída de um evento depende muito, se não inteiramente, do formato do evento. Um log de eventos pode ser em qualquer formato, mas podem ser definidas normas para melhorar a interoperabilidade e simplificar o processamento automatizado de arquivos de log. Independentemente desses padrões, ainda existem fontes de registro que usam seu próprio formato para um log de eventos. Geralmente, existem três categorias de eventos: Estruturado: Em um formato de log estruturado, cada informação tem uma localização clara e
significado. Cada peça de informação tem um valor legível por máquina e especificamente sem frases em linguagem natural, como mostrado no exemplo do (Código 2.5).
Código 2.5: Exemplo de log syslog em formato estruturado.
1 Apr 30 0 8 : 1 0 : 0 1 r e p o r t e r −01 CROND[ 4 3 0 9 6 ] : ( r o o t ) CMD ( / u s r / l i b 6 4 / s a / s a 1 1 1 )
Fonte: (O autor).
Ter logs em um formato estruturado pode ser considerado o melhor caso, uma vez que não exige analisar e permite extrair informações rapidamente e com eficiência.
Não estruturado: Em um formato de log não estruturado, a informação não é organizada em campos dedicados, mas é escrita como frases em linguagem natural, como mostrado no (Código 2.6). Esse formato de log pode ser encontrado em logs de aplicativos, onde não há muita atenção a legibilidade por máquina de arquivos de log, mas sim para fins informativos para o usuário. Um exemplo para informações de log não estruturadas é o campo “msg” em Syslog. Syslog é um protocolo de log e escreve mensagens em um formato estruturado, mas seu campo de mensagem pode conter informações arbitrárias. Observa-se como um exemplo disso a Figura 6, onde a aplicação está passando texto não estruturado como parte do campo “msg”.
Código 2.6: Exemplo de log syslog em formato não estruturado.
1 Apr 24 1 1 : 2 0 : 5 6 V i r t u a l B o x k e r n e l : [ 1 0 . 5 4 7 9 4 2 ] NET : R e g i s t e r e d p r o t o c o l f a m i l y 10 2 Apr 24 1 1 : 2 0 : 5 6 V i r t u a l B o x k e r n e l : [ 1 0 . 5 4 9 0 5 6 ] M o b i l e I P v 6 3 Apr 24 1 1 : 2 0 : 5 6 V i r t u a l B o x k e r n e l : [ 1 0 . 5 4 9 0 5 9 ] NET : R e g i s t e r e d p r o t o c o l f a m i l y 17 4 Apr 24 1 1 : 2 0 : 5 6 V i r t u a l B o x k e r n e l : [ 1 0 . 5 4 9 0 6 6 ] R e g i s t e r i n g t h e d n s _ r e s o l v e r key t y p e 5 Apr 24 1 1 : 2 0 : 5 6 V i r t u a l B o x k e r n e l : [ 1 0 . 5 4 9 5 2 9 ] r e g i s t e r e d t a s k s t a t s v e r s i o n 1 Fonte: (O autor).
Semi-estruturado: Um formato de log semi-estruturado contém informações estruturadas e informações não estruturadas. Basicamente, as informações no formatos semi-estruturados são organizadas em campos dedicados, mas alguns campos não contêm dados estruturados. Como no exemplo de log do apache solr4(Código 2.7).
Código 2.7: Exemplo de log apache solr em formato semi-estruturado.
1 Abr 2 6 , 2017 1 2 : 5 7 : 0 6 AM o r g . a p a c h e . s o l r . u p d a t e . D i r e c t U p d a t e H a n d l e r 2 commit 2 INFO : s t a r t commit 3 f l a g s = 0 , _ v e r s i o n _ = 0 , o p t i m i z e = f a l s e , o p e n S e a r c h e r = f a l s e , w a i t S e a r c h e r = t r u e , e x p u n g e D e l e t e s = f a l s e , s o f t C o m m i t = f a l s e Abr 2 6 , 2017 1 2 : 5 7 : 0 6 AM o r g . a p a c h e . s o l r . s e a r c h . S o l r I n d e x S e a r c h e r < i n i t > 4 INFO : O p e n i n g S e a r c h e r @ 6 2 4 9 f e 7 2 main Fonte: (O autor).
Como observado, existem várias formas de estruturar um log de evento. De acordo com
AZODI et al.(2013), a natureza desses formatos e as diferenças entre eles tornam a normalização
uma tarefa desafiadora, pois cada formato de log pode possuir níveis de detalhes diferentes, ser parcialmente ou completamente desestruturados, dificultando o mapeamento direto dos campos de eventos, e mesmo quando as informações são completamente estruturado, um evento isolado frequentemente não fornecer informações suficientes para serem interpretadas corretamente.
2.2
Web semântica
O termo "Web Semântica"foi originalmente criado pelo World Wide Web Consortium (W3C), como uma extensão da atual Web, na qual é dado às informações um significado bem
definido, permitindo que os computadores e as pessoas trabalhem em cooperação
BERNERS-LEE; HENDLER; LASSILA(2001). A Web Semântica pode ser vista como um conjunto de
normas e tecnologias permitindo que máquinas possam compreender o significado (semântica) de informações na Web. Ela representa uma nova visão sobre como a Web deve ser construído de modo que a informação pode ser processada automaticamente por máquinas em grande escala
YU(2014).
Entende-se a Web Semântica como uma coleção de tecnologias e padrões, na Figura 2.1 encontra-se uma visão mais atualizada sobre a pilha de tecnologias da Web Semântica, mostrando toda a complexidade.
Figura 2.1: Pilha de tecnologias da Web Semântica. Fonte: (NOWACK,2009)
Na versão atual da pilha de tecnologias pode ser verificada as especificações que se torna-ram padrões W3C, e implementadas nas diferentes camadas: Web Ontology Language (OWL), Rule Interchange Format (RIF), Protocol and RDF Query Language (SPARQL) (linguagem de consulta para RDF). Nessa versão em 3D, criada porNOWACK(2009) foi acrescentada um im-portante elemento na pilha de tecnologias semânticas, o linked data5, componente extremamente importantes para o sucesso da Web Semântica, pois sem dados vinculados (coleção de conjuntos de dados inter-relacionados e muitas vezes disponíveis publicamente), nenhum mecanismo de raciocínio terá sucesso (KOMENTARZ,2010).
2.2.1
Resource Description Framework - RDF
Nesta seção são abordados os aspectos principais do Resource Description Framework (RDF), incluindo seu conceito, seu modelo abstrato, sua semântica, suas construções e caracte-rísticas de linguagem.
O RDF foi originalmente criado no início de 1999 pela W3C como padrão para a
codificação de metadados. De acordoKLYNE GRAHAM; CARROLL(2004) o RDF fornece
interoperabilidade entre aplicativos que trocam informações compreensíveis por máquina na Web, permitindo o processamento automatizado de recursos da Web e podendo ser usado em uma variedade de aplicações, com por exemplo, fornece informações sobre recursos da Web e os sistemas que os utilizam.
O RDF não é usado apenas para codificar metadados sobre recursos da Web, mas também para descrever quaisquer recursos e suas relações existentes no mundo real. Esses recursos são descritos por triplas RDF, formadas por sentenças com Sujeito, Predicado e Objeto (CYGANIAK;
WOOD; LANTHALER,2014).
Figura 2.2: Um gráfico RDF com dois nós (Sujeito e Objeto) conectando-se por um (Predicado). Fonte: (O Autor).
Como princípio básico o RDF usa o modelo abstrato da Figura 2.2 para decompor informações e conhecimento, com regras simples sobre o significado de cada uma desses segmentos. De acordo comYU(2014) o objetivo é fornecer um método geral que seja simples e flexível o suficiente para expressar qualquer fato, mas suficientemente estruturado para que as aplicações de computador podem usar e processá-lo de forma escalável.
O conhecimento (ou informação) é expresso como uma lista de declarações, onde cada instrução assume a forma de Sujeito, Predicado e Objeto, e esta ordem nunca deve ser alterada (YU,2014).
Tabela 2.1: Exemplos declarações RDF.
Sujeito Predicado Objeto
lenovo-g50-80 type Notebook
lenovo-g50-80 manufacturer Lenovo
lenovo-g50-80 label “Lenovo G50-80”
Lenovo foundedBy Liu Chuanzhi
Fonte: (O autor).
Observa-se na Tabela 2.1 que a identificação do objeto na declaração é chamada de sujeito (recurso), a identificação para uma propriedade ou uma característica de um recurso é
chamada de predicado (propriedade), enquanto que o valor de uma propriedade é chamado de objeto (valor de propriedade). Por exemplo, na transcrição de uma das declarações contidas a Tabela 2.1 para o português teremos: “lenovo-g50-80 é fabricado por Lenovo ”.
Todas as coisas que estão sendo descritas por expressões /acrdf são chamadas de recursos, incluindo coisas físicas, documentos, conceitos abstratos, números e palavras (CYGANIAK;
WOOD; LANTHALER,2014). De acordo comoSCHREIBER G.; RAIMOND(2014) para
identificar de maneira única um recurso são utilizados Internationalized Resource Identifier (IRI)s6, que é uma generalização de Uniform Resource Identifier (URI)7, o que propicia um conjunto maior de caracteres Unicode. Portanto, um IRI pode ser criado para identificar e descrever informações sobre qualquer domínio que possa ser recuperado da Web, assim como pode ser utilizado para representar um sujeito, predicado ou objeto em uma declaração RDF.
Na Tabela 2.2 pode ser observado que todos os recursos listados anteriormente na Tabela 2.1 podem ser nomeados usando IRIs, com exceção dos valores literais que representam sequências de caracteres, números e datas, por exemplo: “Lenovo G50-80” é o nome pelo qual o Notebook é conhecido.
Tabela 2.2: Usando IRIs para nomear recursos RDF.
Sujeito Predicado Objeto
http://ex.com.br/Lenovo_G50_80 http://dbpedia.org/ontology/type http://dbpedia.org/resource/Notebook http://ex.com.br/Lenovo_G50_8 http://dbpedia.org/ontology/manufacture http://dbpedia.org/resource/Lenovo http://ex.com.br/Lenovo_G50_80 http://xmlns.com/foaf/0.1/name “Lenovo G50-80”
http://dbpedia.org/resource/Lenovo http://dbpedia.org/ontology/foundedBy http://dbpedia.org/resource/Liu_Chuanzhi
Fonte: (O autor).
A maioria das IRIs listadas da Tabela 2.2 já existem, elas pertencem ao projeto DBpedia8 (projeto com objetivo de extrair informação estruturadas da Wikipedia9), de acordo comYU
(2014) é recomendado a reutilização de IRIs existentes sempre que for possível.
A identificação de recursos através de IRIs dão origem nomes bastante longos,
tornando-os pouco legíveis e de difícil compreensão. Como soluçãoCYGANIAK; WOOD; LANTHALER
(2014) propõe a utilização da parte comum do identificador como namespace e a sua associação por convenção a um nome curto (prefixo). Porém, essas abreviações não são IRIs válidos e não devem ser utilizados em contextos onde IRIs são esperados. Na Tabela 2.3 observa-se exemplos de utilização de namespaces.
6RFC3987:https://www.ietf.org/rfc/rfc3987.txt
7RFC3986:https://www.ietf.org/rfc/rfc3986.txt
8http://dbpedia.org
Tabela 2.3: Exemplos de prefixos e namespaces. prefixo namespace ex http://ex.com.br dbo http://dbpedia.org/ontology/ foaf http://xmlns.com/foaf/0.1/ rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs http://www.w3.org/2000/01/rdf-schema# Fonte: (O autor).
Agora, por exemplo, o IRI http://xmlns.com/foaf/0.1/name pode ser escrito como foaf:name, tornando-o mais legível. Além disso, RDF refere-se a um conjunto de IRIs (muitas vezes criado para um propósito específico) como um vocabulário.
Outros dois componentes importantes do modelo RDF são: nó em branco e literais. Como dito anteriormente, um recurso pode ser nomeado utilizando IRI’s, porém quando este não é representado por um IRI, é denominado de um nó em branco. Já os literais são dados de texto simples, usados para valores como seqüências de caracteres, números e datas. Um valor literal, pode ter uma identificação de idioma, indicando em qual idioma o texto foi escrito, também pode possuir uma IRI que indica seu tipo de dado, essas informações de tipo de dado, auxiliam a sua
interpretação por um analisador de documentos RDF (CYGANIAK; WOOD; LANTHALER,
2014).
O modelo de dados RDF fornece uma estrutura abstrata e conceitual para descrever os recursos de uma maneira que as máquinas podem processar. Porém existem diversas formas como eles podem ser apresentados ou serializado, facilitando a troca de modelos RDF entre
aplicações.GANDON; SCHREIBER (2014) define uma sintaxe XML para esta finalidade,
denominado de RDF/XML, usado para representar um gráfico RDF como um documento XML. RDF/XML não é a única sintaxe de serialização que está sendo adotada. Existem outros formatos de serialização RDF, como por exemplo: o Turtle e N-Triples. O Turtle é uma sintaxe
baseada em texto para serialização do modelo RDF (PRUD’HOMMEAUX E.; CAROTHERS,
2014), enquanto que o N-Triples é mais simples e intuitivo do que o Turtle, oferecendo outra alternativa de serialização (CAROTHERS G.; SEABORNE,2014).
2.2.2
RDF Schema (RDFS)
RDFS ou RDF Schema é uma recomendação do W3C, de acordo comBRICKLEY D.; GUHA
(2014) é uma linguagem de representação de conhecimento extensível que pode ser usada para criar um vocabulário para descrever classes, subclasses e propriedades de recursos RDF. Com essa definição, o RDFS pode ser entendido como a linguagem de descrição de vocabulário do RDF dentro de um domínio de aplicativo específico. Seu vocabulário básico é identificado pelo IRI <ttp://www.w3.org/2000/01/rdf-schema#>, e por convenção associado ao prefixo RDFS.
chamados classes. Os membros de uma classe são conhecidos como instâncias da classe. Eles são frequentemente identificados por IRIs, enquanto que as propriedades permitem expressar relações entre classes e suas instâncias ou superclasses.
Porém RDFS não permite a expressão de relações mais complexas entre classes e restrições mais precisas sobre classes e propriedades específicas, para suprir essa necessidade foi criado uma nova linguagem chamada Web Ontology Language (OWL), que será discutida na próxima seção.
2.2.3
OWL 2
A ontologia desempenha um papel crítico para a Web Semântica, portanto é necessário compreender a ontologia para entender plenamente a idéia da Web Semântica (YU,2014). Para
GROUP(2014) ontologias são vocabulários formalizados de termos, muitas vezes cobrindo um
domínio específico e compartilhado por uma comunidade de usuários. OWL 2 é uma extensão
e revisão do OWL Web Ontology Language (OWL)10, desenvolvido pelo W3C Web Ontology
Working Group11 e publicado em 2004, (posteriormente referenciado como "OWL 1").
Assim com OWL 1, o OWL 2 foi projetado para facilitar o desenvolvimento e compar-tilhamento de ontologias pela Web, com o objetivo final de tornar o conteúdo da Web mais acessível às máquinas.
SegundoMOTIK B.; PARSIA(2012a) os vocábulos da OWL (nas suas duas versões,
OWL 1 e OWL 2) são identificados pelo IRI <http://www.w3.org/2002/07/owl#>, e por conven-ção associados ao prefixo owl, e geralmente usados em documentos RDF/XML.
Para uma melhor compreensão da OWL 2,HITZLER P.; KRÖTZSCH(2012) defende
que é primordial o entendimento de algumas noções fundamentais. Essas noções básicas são: Axiomas: as afirmações básicas que uma ontologia OWL expressa, qualquer ontologia OWL
pode ser vista como uma coleção de axiomas e essa ontologia afirma que todos os seus axiomas são verdadeiros;
item Entidades: elementos usados para se referir-se a objetos do mundo real, onde uma entidade individual é chamada de objeto, uma entidade de classe é chamada de categoria e entidade de propriedade é chamada de relação;
Expressões: combinações de entidades para formar descrições complexas, sendo responsável por tornar a linguagem OWL muito mais expressiva, se comparada como o RDFS; Existem várias formas de serialização disponíveis para OWL 2: a Functional-Style12 (estilo funcional) foi projetada para traduzir a especificação estrutural para várias outras
10https://www.w3.org/TR/2004/REC-owl-features-20040210/
11http://www.w3.org/2007/OWL/
sintaxes e fornecer uma base para a implementação de ferramentas OWL 2; a RDF/XML13, já mencionada anteriormente, é a única sintaxe que é obrigatória para ser suportada por todas as ferramentas OWL 2; Manchester14, representação textual para ontologias
OWL fácil de ler e escrever; e a XML/OWL15 sintaxe XML para OWL definida por um
esquema XML, porém sua análise pode ser feita mais facilmente do que em RDF/XML
(HITZLER P.; KRÖTZSCH,2012).
Observa-se no exemplo acima que a descrição de uma classe (<Notebook>) tem uma instância <Lenovo_G50_80>, a classe (<Company>) tem uma instância <Lenovo>, e a relação entre essas duas instâncias utilizando a propriedade (<manufacture>). Outra característica presente em OWL é a possibilidade de gerar hierarquias de classes e propriedades. As hie-rarquias são definidas mediante a especificação dos axiomas subclasses (owl: SubClassOf) e subpropriedades (owl:SubObjectPropertyOf e owl:SubDataPropertyOf). Como exemplo desses conceitos no Código 2.8 (HITZLER P.; KRÖTZSCH,2012).
Código 2.8: Exemplo de subclasses , subpropriedades utilizando a sintaxe funciona.
1 S u b C l a s s O f ( : Notbook : Computer ) 2 S u b P r o p e r t y O f ( : m a n u f a c t u r e : p r o v i d e r )
Fonte: (O autor).
SegundoYU(2014) uma questão importante ao projetar uma linguagem de ontologia é a escolha entre priorizar a sua expressividade, ou a eficiência do processo de raciocínio, pois quanto mais rica a linguagem é, mais complexo e demorado é o raciocínio, podendo torná-lo, em casos extremos, computacionalmente impossíveis. O objetivo, portanto, é projetar uma linguagem que tenha expressividade suficiente e que seja também bastante simples para ser apoiada por motores de raciocínio razoavelmente eficientes. Para solucionar esse dilema entre a eficiência de raciocínio e a expressividadeMOTIK B.; PARSIA (2012b) define diferentes subconjuntos de OWL 2 (perfis), chamados de OWL 2 EL, OWL 2 QL e OWL 2 RL. Para garantir uma capacidade de raciocínio escalonável, cada um desses perfis tem suas próprias limitações quanto à sua expressividade.
OWL 2 EL é projetado para sistemas de alta complexidade e com necessidade de maior poder de expressividade, normalmente possuem um grande número de classes e descrições estruturais complexas.
OWL 2 QL é projetado para aquelas aplicações que envolvem bancos de dados clássicos e que também precisam trabalhar com ontologias OWL 2. Para essas aplicações, a interoperabili-dade da OWL 2 com as tecnologias de banco de dados torna-se sua principal preocupação, pois as ontologias usadas nessas aplicações são frequentemente usadas para consultar grandes conjuntos de indivíduos.
13http://www.w3.org/TR/owl2-xml-serialization/
14http://www.w3.org/TR/owl2-manchester-syntax/
OWL 2 RL é projetado para aquelas aplicações que exigem o raciocínio escalável sem sacrificar a expressividade, é o perfil ideal para o enriquecimento de dados especificados e conectados via RDF, pois suporta tanto a semântica direta quanto a semântica baseada em RDF.
2.2.4
SPARQL
SPARQL é uma linguagem de consulta RDF e protocolo de acesso a dados para a Web Semântica. Seu nome é um acrônimo de SPARQL Protocol and RDF Query Language
(PRUD’HOMMEAUX E.; SEABORNE,2008).
SegundoJACYNTHO(2012) com o advento do RDF, em especial associado ao
movi-mento da Web semântica, começaram a surgir os bancos de dados RDF, também conhecidos como RDF Data Store ou Triple Store. Bancos de dados RDF são similares aos bancos de dados tradicionais, onde pode ser armazenado RDF statements (ou triplas) e recuperá-los depois usando uma linguagem de consulta, em geral, SPARQL.
Consultas SPARQL são realizadas em um banco de dados RDF por meio de um SPARQL endpoint. De acordo comYU(2014) um SPARQL endpoint pode ser entendido como uma inter-face em que os usuários (humanos ou aplicativos) podem acessar para consultar um conjunto de dados RDF usando a linguagem de consulta SPARQL, podendo ser configurado para retornar re-sultados em vários formatos, como por exemplo: XML16, JavaScript Object Notation (JSON)17, Comma Separated Values (CSV)18, Tab Separated Values (TSV)19(GROUP,2014).
2.2.5
Linked Data
Linked Dataé um conceito intimamente relacionado com o conceito da Web Semântica, após publicar dados legíveis por máquina, como documentos RDF, o próximo passo é de alguma forma torná-los conectados entre si. O conceito de Linked Data foi originalmente proposto por por Tim Berners-Lee (BERNERS-LEE,2006), e refere-se a dados publicado na Web de tal forma que é legível por máquina, e ligados a outros conjuntos de dados externos e, por sua vez, pode ser ligado a partir de conjuntos de dados externos também. Conceitualmente, Linked Data refere-se a um conjunto de melhores práticas para publicar e conectar dados estruturados na Web.
De acordo comYU(2014) a conexão entre Linked Data e a Web Semântica é bastante óbvia: publicar e consumir dados legíveis por máquina é central para ambos os conceitos. De fato, nos últimos anos, Linked Data e a Web Semântica tornaram-se dois conceitos que são intercambiáveis. Portanto a ideia básica de Linked Data é bastante direta e pode ser resumida em usar o modelo de dados RDF para publicar dados estruturados na Web e links RDF para interligar dados de diferentes fontes de dados.
16http://www.w3.org/TR/rdf-sparql-XMLres/
17http://www.w3.org/TR/sparql11-results-json/
18http://www.w3.org/TR/sparql11-results-csv-tsv/
A aplicação destes dois princípios simples constrói-se uma Web de Dados em que máquinas podem ler e compreender, portanto, a Web Semântica é criada pelos dados estruturados e vinculados na Web, ou seja, a Web Semântica é a meta, e Linked Data fornece os meios para alcançar o objetivo.
Tim Berners-Lee (BERNERS-LEE, 2006) propõe quatro regras básicas para publicar e interligar dados RDF na Web. São elas:
1. Use URIs para identificar as coisas;
2. Use HTTP URIs para que pessoas ou máquina possam acessar estes nomes na Web; 3. Servir informações úteis na web através de URI;
4. Incluir links para outros URIs, necessário para conectar os dados e possibilitar que clientes encontrem mais coisas.
2.3
Gerenciamento de Serviços de TI
O Gerenciamento de Serviços de TI (ITSM) é o instrumento onde adota-se uma postura proativa em relação ao atendimento das necessidades da organização, contribuindo para eviden-ciar a sua participação na geração de valor, alocando adequadamente os recursos disponíveis e
gerenciando de forma integrada (FILHO,2011b). SegundoMELENDEZ; DÁVILA; PESSOA
(2016) nos últimos anos, modelos de processo para ITSM e sua aplicação em organizações cres-ceram de forma significativa. Existem vários modelos e padrões que representam as melhores práticas para Gerenciamento de Serviços de TI (ITSM), como a IT Infrastructure Library (ITIL).
2.3.1
ITIL
A biblioteca ITIL propõe um conjunto de melhores práticas no gerenciamento de serviços de TI. O ITIL é utilizado por organizações em todo o mundo para estabelecer e melhorar as capacidades no gerenciamento de serviços. O ISO/IEC 20000 fornece um padrão formal e universal para as organizações que procuram ter suas capacidades de gerenciamento de serviços auditadas e certificadas. Embora o ISO/IEC 20000 seja um padrão a ser alcançado e mantido, a ITIL oferece um conjunto de conhecimentos úteis para alcançar o padrão (TSO,2011a). A biblioteca ITIL possui os seguintes componentes (TSO,2011a):
O acitil Core: orientação de melhores práticas aplicável a todos os tipos de
organiza-ções que prestam serviços a uma empresa.
A Guia Complementar de ITIL: um conjunto complementar de publicações com
ori-entação específica para setores da indústria, tipos de organização, operação modelos e arquiteturas de tecnologia.
De acordo comFILHO (2011b) a ITIL Core é constituída por cinco publicações: a estratégia de serviço como o núcleo do ciclo de vida de serviço; o projeto, transição e operação de serviço como estágios do ciclo de vida orbitando o núcleo, sendo este conjunto ancorado pela melhoria contínua do serviço.
Estratégia de serviço: prevê e conceitua um conjunto de serviços que ajuda o negócio
a alcançar os seus objetivos. Aqui são tomadas as decisões estratégicas relacionadas aos serviços que serão desenvolvidos.
Projeto de serviço: desenha ou projeta os serviços tendo em vista os objetivos de
utilidade e garantia. Basicamente projeta o que a estratégia decidiu.
Transição de serviço: move os serviços para o ambiente de produção. Os serviços
são desenvolvidos, testados e liberados de forma controlada.
Operação de serviço: gerencia os serviços em produção para assegurar que sejam
alcançados os seus objetivos de utilidade e garantia. Aqui estão os processos do dia a dia, que mantêm os serviços funcionando.
Melhoria contínua de serviço: avalia os serviços e identifica a formas de melhorar
sua utilidade e garantia no suporte aos objetivos do negócio. A Figura 2.3 fornece uma visão detalhada do ciclo de vida do ITIL.
Figura 2.3: Ciclo de vida de acordo com o modelo ITIL. Fonte: (FILHO(2011b)).
Para um melhor entendimento e devido ao escopo desta pesquisa, selecionamos apenas uma parte da biblioteca ITIL: o processo de Gerenciamento de Eventos que integra a etapa Operação de Serviço, por entendermos que está intimamente ligado ao objeto de estudo desta pesquisa e a etapa Melhoria Contínua do Serviço, que tem como objetivo avaliar e melhorar a qualidade de serviços, além de aprimorar o gerenciamento de serviço de TI dentro de uma organização, e para isso, precisa ter acesso a vários tipos de informações, incluído as informações advindas do processo de Gerenciamento de Eventos.
2.3.1.1 Operação de Serviço
O objetivo da operação de serviço é coordenar e realizar as atividades e processos de operações de serviço, orientando sobre a efetividade e eficiência na entrega e suporte de serviços, de modo a garantir o valor para o cliente e para o provedor de serviços (TSO,2011a).
Entre os cinco processos que integram a operação de serviço a gestão de eventos é encarregado de construir uma base para a monitoração e controle operacional, detectando eventos, determinando como um evento faz sentido em relação ao outro e determinando a ação de controle apropriada (FILHO,2011a), a fim de garantir o bom funcionamento dos serviços de TI.
SegundoFILHO(2011a, p. 152) uma operação de serviço eficiente depende do conhe-cimento da situação da infraestrutura e da detecção de qualquer desvio da operação normal ou esperada. As ferramentas de monitoramento, que são usadas para detectar eventos, podem ser divididas em duas classes: as ferramentas ativas avaliam itens chave de configuração para determinar sua situação e disponibilidade, alertando qualquer exceção para uma ação corretiva apropriada e as ferramentas passivas que detectam e correlacionam alertas operacionais ou comunicações geradas por itens de configuração.
No contexto dessa pesquisa os dados provenientes dos logs de eventos enriquecidos semanticamente darão suporte a outros processos da etapa de melhoria contínua do serviço, detalhada a seguir.
2.3.1.2 Melhoria Contínua do Serviço
Segundo FILHO (2011a, p. 204) a Melhoria Contínua de Serviço é a fase que une
todos os outros elementos do ciclo de vida de serviço, garantindo que tanto os serviços como a capacidade para provimento dos serviços melhorem e amadureçam.
Por esse motivo não pode ser entendida como uma fase separada, suas atividades devem ser executadas para todo o ciclo de vida. Esta etapa deve focar em aumentar a eficiência, maximizar a efetividade e otimizar o custo dos serviços. A única maneira de fazer isto, é assegurando que as oportunidades sejam identificadas durante todo o ciclo de vida do serviço. Dentre os processos que fazem parte dessa etapa destacamos:
Elaboração de Relatório: responsável pela geração e fornecimento de relatórios sobre
os resultados alcançados e o desenvolvimento nos níveis de serviçoFILHO(2011a, p. 205);
Medição de Serviço: a medição do nível de componente é necessária e importante,
mas a medição de serviço deve ir além do nível de componente. A medição de serviço requer a tomada de medidas individuais e as combine para prover uma visão da realidade do serviço.
Esses dois processos foram selecionados por entendermos que através da Medição de Serviço e com base em dados reais, pessoas podem ser orientadas a mudar o comportamento e tomada de ações corretivas sobre as oportunidades de melhoria identificadas, mas para isso, essas informações devem ser reportadas em relatórios simples, efetivos, automatizados e adequados ao usuário finalFILHO(2011a, p. 206).
2.4
Processo de gestão e tomada de decisão
O processo de tomada de decisão pode ser definido como "a detecção, exploração e defini-ção de problemas e oportunidades, bem como a geradefini-ção, avaliadefini-ção e seledefini-ção de soluções"(MORA
et al.,2005). De acordo comTURBAN et al.(2001) o processamento de informações
manual-mente ao tomar decisões está se tornando cada vez mais difícil devido às seguintes razões:
Avanços na comunicação, acessibilidade aos mercados globais, o uso da Internet e o
comércio eletrônico aumenta o número de alternativas envolvidas em uma decisão;
Muitas decisões precisam ser feitas dentro de uma restrição de tempo: processar as
informações necessárias de forma eficiente e eficaz não é possível se feito manual-mente;
A tecnologia da informação e a análise sofisticada que ela fornece torna-se um fator
em fazendo uma boa decisão, e
Acesso rápido a informações remotas, como especialistas em consultoria ou
forneci-mento de uma decisão de grupo a reunião é muitas vezes necessária.
2.4.1
Sistemas de Suporte à Decisão
A tomada de decisões é um processo que pode envolver muitas etapas, como uma das ferramentas adotadas por gestores para que as suas decisões sejam mais precisas e adequadas está a utilização de Sistemas de Suporte à Decisão (DSS). Os Sistemas de Suporte à Decisão surgiram com o intuito de automatizar várias tarefas do processo de tomada de decisão e apoiar decisões gerenciais em situações de decisão semi-estruturada, onde deveria ser um complemento aos decisores para ampliar suas capacidades, mas não para substituir seu julgamento (TURBAN;
ARONSON; LIANG,2004), de acordo com HOLSAPPLE; JOSHI(2002) é uma tecnologia
baseada em computador que visa obter o conhecimento correto, na forma correta, para as pessoas certas e no momento certo, para que eles possam tomar decisões melhores. SegundoTURBAN
et al.(2001), quatro tecnologias de informação foram usadas com sucesso para apoiar gerentes
ou tomadores de decisão:
Sistemas de Suporte à Decisão que suporta principalmente tipos analíticos e
Sistemas de informação executiva (EIS), que fornecem informações e ultimamente
foram expandidos para incluir ferramentas de análise e comunicação para os deciso-res;
Sistemas de suporte de decisão de grupo (GDSS) ou Sistemas de Suporte de Grupo
(GSS) para grupo apoio à decisão, e
Sistemas de suporte inteligentes que fornecem conhecimentos especializados através
de um componente especializado para otimize uma decisão.
Coletivamente, os sistemas acima mencionados são conhecidos como Sistemas de Su-porte de Gerenciamento (MSS) e podem ser usados independentemente ou combinados, cada um fornecendo uma capacidade diferente.
2.4.1.1 Componentes dos sistemas de suporte à decisão
SegundoTURBAN; ARONSON; LIANG(2004) um aplicativo DSS pode ser composto
pelos subsistemas descritos abaixo:
Gerenciamento de dados. inclui um banco de dados que obtém dados relevantes para a situa-ção, podendo ser interligado com o data warehouse corporativo, para compor os dados relevantes para a tomada de decisões;
Gerenciamento de modelos. inclui recursos financeiros, estatística, ciência de gestão ou outros modelos quantitativos que fornecem o sistema capacidades analíticas do tem e gerencia-mento de software apropriado.
Interface de usuário. O usuário se comunica e comanda o DSS através deste subsistema. O usuário é considerado parte do sistema. O navegador da Web fornece uma estrutura de interface gráfica familiar e consistente para a maioria dos DSS.
Gerenciamento baseado no conhecimento. Este subsistema pode suportar qualquer um dos outros subsistemas ou atuam como um componente independente. Ele fornece inteligência para aumentar o próprio tomador de decisão. Pode ser interligado com o repositório de conhecimento da organização (parte de um sistema de gerenciamento de conhecimento), que às vezes é chamado de base de conhecimento organizacional.
Por definição, um DSS deve incluir os três primeiros componentes listados acima, o subsistema de gerenciamento baseado no conhecimento é opcional, mas pode fornecer muitos benefícios, fornecendo inteligência em e para os três principais componentes. Como em qualquer sistema de informação de gerenciamento, o usuário pode ser considerado um componente do
2.5
Trabalhos Relacionados
Na literatura, é possível encontrar diversos trabalhos sobre o enriquecimento semântico de logs utilizando ontologias e tomada de decisão na gestão de serviços de TI. Entretanto entre os estudos encontrados, não foram evidenciados casos em que o enriquecimento semântico de logs foi utilizado no processo de tomada de decisão.
Na Tabela 2.4 listamos as principais abordagens e discussões mais representativas nesta área, realizando uma comparação com este trabalho.
Tabela 2.4: Trabalhos relacionados.
Título Contexto Mineração
de eventos
Enriquecimento
semântico Ontologia Gestão
Tomada de decisão Semantic Interpretation
of Structured Log Files. (NIMBALKAR et al.,2016)
Logs/
Ontologia X X X
Semantic data mining: A survey of ontology-based approaches
(DOU; WANG; LIU,2015)
Logs/
Ontologia X X
OWL-based intelligent security audit.
(KUMAR VASANTHA; FEROZ,2014)
Logs/
Ontologia X X X
OntoLog: using web semantic and ontology for security log analysis.
(NASCIMENTO; FERRAZ; ASSAD,2011)
Logs/
Ontologia X X X
Using security logs for collecting and reporting technical security metrics. (VAARANDI; PIHELGAS,2014)
Logs/
Ontologia X X
Calculation of COBIT metrics using a formal ontology. (TEXTOR; GEIHS,2015) Gestão X X X An Intelligent Approach to Increase Efficiency of IT-Service Management Systems : University Case-Study.
(TKACHUK; SOKOL; GLUKHOVTSOVA,2013)
Gestão X X X Applying an ontology approach to IT service management for business-IT integration.
(VALIENTE; BARRIOCANAL; SICILIA,2012)
Gestão X X X
DSS Based IT Service Support Process Reengineering Using ITIL: A Case Study. (VALVERDE; TALLA,2014) Gestão/ Tomada de decisão X X X Improving IT Service Management with Decision-Making Support Systems. (MORA et al.,2014) Gestão/ Tomada de decisão X X A Visualização de Informação e a Transparência de Dados Públicos. (PAULA et al.,2011) Visualização de informações X X
VisPublica: uma proposta para aprimorar a transparência de dados públicos. (RIBEIRO et al.,2012) Visualização de informações X X Enriquecimento semântico de logs como auxílio no processo de gestão e tomada de decisões
- X X X X X
Fonte: (O autor).
NIMBALKAR et al.(2016) propõe a inferência da estrutura e esquema do arquivo de
log, e usa esse esquema para gerar uma representação semântica do conteúdo do arquivo de log. Com base nos valores em cada coluna, mapeia as colunas a uma classe semântica e cada
par de colunas a uma relação semântica de uma determinada ontologia. Esse mapeamento é utilizado para gerar um conjunto de triplas RDF a partir do conteúdo do arquivo de log. Estes triplas RDF pode ser integrado com outras fontes de dados para raciocinar e detectar potenciais vulnerabilidades de segurança.
O processo de mineração de dados semântico incorpora sistematicamente o conhecimento
do domínio, DOU; WANG; LIU(2015) em seu trabalho, apresentam os conceitos gerais de
mineração de dados semântico, investigando por que a ontologia tem potencial para ajudar a extração de dados semânticos e como a semântica formal em ontologias pode ser incorporada no processo de mineração de dados. A utilização de ontologias como facilitador na análise de logs é
defendida porKUMAR VASANTHA; FEROZ(2014), este descreve um sistema que objetiva
facilitar a auditoria inteligente de registros de segurança. Para isso um conjunto de políticas de segurança são convertidos em ontologias (OWL), ao mesmo tempo que, os registros de atividades também são convertidos num formato baseado em OWL e com base nestas ontologias o sistema
aplica as regras no firewall. NASCIMENTO; FERRAZ; ASSAD (2011) também propõe a
utilização de ontologias para análise dos logs de segurança, comprovando através de teste que houve melhorias na interpretação e análise de logs, permitindo a realização de mais consultas complexas e a implementação da correlação de eventos de forma muito eficaz.
Em outro estudo,VAARANDI; PIHELGAS(2014) discutem o uso de técnicas de análise de log para coletar métricas de segurança a partir de registros de segurança de tipos comuns (registros de alarme IDS de rede, registros de estação de trabalho e conjuntos de dados Netflow), revisando uma série de cenários de coleta de métricas para log de segurança, além descreverem a estrutura de coleta baseada em tecnologias de gerenciamento de registro de código aberto.
TEXTOR; GEIHS(2015) apresentam em sua pesquisa uma abordagem para conectar o modelo
abstrato COBIT com valores métricos calculados criando uma ontologia COBIT formal e um sistema de tempo de execução que acompanha, com as relações entre entidades, como processos, metas e métricas, são tornadas explícitas e legíveis por máquina. Todos os elementos da ontologia são identificados através de URI, permitindo o alinhamento dos elementos COBIT com outras ontologias (gerenciais, como ITIL) mas também o uso do modelo em regras de automação e consultas de agregação.
Uma abordagem inteligente para aumentar a eficiência dos sistemas de gerenciamento
de serviços de TI (ITSMS) é proposta em (TKACHUK; SOKOL; GLUKHOVTSOVA,2013),
enquanto que (VALVERDE; TALLA,2014) investigam como a implementação das diretrizes
ITIL nos níveis operacional e tático podem ser usadas para avaliar o processo de suporte de serviço de TI, através de um conjunto de Indicadores Chave de Desempenho (KPI), que são monitorados por um sistema de suporte à decisão (DSS).MORA et al.(2014) demonstra como a gestão de serviços de TI (ITSM) se beneficia da utilização dos sistemas de apoio à tomada de decisões, através da descrição e análise do processo de tomada de decisão para ITSM.
Com objetivos correlatos (VALIENTE; BARRIOCANAL; SICILIA,2012) apresentam uma
seus modelos de processo de gerenciamento de serviços.
No contexto da visualização de informações, (PAULA et al.,2011) desenvolveu um estudo com objetivo de investigar as técnicas de visualização de informação (InfoVis) e sua aplicação no contexto governamental, buscado quais técnicas são mais apropriadas para apoiar a tomada de decisão nos setores públicos e a comunicação com a sociedade. Dando seguimento a pesquisaRIBEIRO et al.(2012) também faz uma análise de técnicas para visualização que facilitem a interpretação de dados públicos, objetivando a transparência, na pesquisa os autores concluem que a utilização das técnicas requer um esforço considerável de análise para garantir sua adequação ao dado a ser visualizado.
Diante dos trabalhos mencionados, pode-se observar que a utilização de uma abordagem semântica para logs de eventos traz muitos benefícios para a melhoria de processos e da gestão do conhecimento, podendo minimizar os esforços necessários para implementação de um registro de eventos estruturado, contendo informações semanticamente úteis. Entretanto torna-la relevantes e acessíveis ainda é um desafio. Dispor-se a preencher essa lacuna, este trabalho buscou apresentar uma abordagem para tornar essas informações relevantes e acessíveis, de acordo com a função ou cargo que o interessado desempenha na instituição, e apresenta-las de forma elegante e transparente para a gestão, facilitando a sua interpretação e como consequência, um processo de tomada de decisões mais eficientes.
2.6
Considerações sobre o capítulo
Neste capítulo foi apresentada a fundamentação teórica e conceitos que serviram como base desta dissertação, norteando as atividades desenvolvidas na pesquisa. Na seção 2.1 que aborda sobre Logs, podemos observar suas características, estruturação e separação, de acordo com as diferentes fontes dos eventos. Na seção 2.2 apresentamos uma visão geral sobre Web Semântica e seu conjunto de normas e tecnologias, permitindo a compreensão de significados (semântica) por máquinas. Na seção 2.3 alguns conceitos sobre Gerenciamento de Serviços de TI são apresentados. Na seção 2.4 é abordado conceitos sobre o Processo de Gestão e Tomada de Decisão, especificamente dos Sistemas de Suporte à Decisão (DDS). E por fim, foram listados trabalhos relacionados a esta pesquisa.
3
METODOLOGIA
Este trabalho trata-se de uma pesquisa aplicada, com abordagem qualitativa, que utiliza como estratégia a pesquisa-ação, definida porTHIOLLENT(2011, p. 20) como “um tipo de pesquisa social com base empírica que é concebida e realizada em estreita associação com uma ação ou com a resolução de um problema coletivo e no qual os pesquisadores e os participantes representativos da situação ou do problema estão envolvidos de modo cooperativo”. O fato do autor desta pesquisa está trabalhando como Analista de TI no IFBA, ambiente onde a pesquisa se realizará, foi um dos motivadores para escolha desse método. Dessa forma, será possível unir pesquisa e ação em um único processo, possibilitando aos sujeitos da pesquisa, participantes e pesquisadores, os meios para conseguirem responder aos problemas que vivenciam, buscando e experimentando soluções em situações reais (THIOLLENT,2011, p. 21,97).
Além disso, THIOLLENT (2011, p. 22) destaca alguns dos principais aspectos da
pesquisa-ação como uma estratégia metodológica em pesquisas sociais:
a) há uma ampla e explícita interação entre pesquisadores e pessoas implicadas na situação investigada;
b) desta interação resulta a ordem de prioridade dos problemas a serem pesquisados e das soluções a serem encaminhadas sob forma de ação concreta;
c) o objeto de investigação não é constituído pelas pessoas e sim pela situação social e pelos problemas de diferentes naturezas encontrados nesta situação;
d) o objetivo da pesquisa-ação consiste em resolver ou, pelo menos, em esclarecer os problemas da situação observada;
e) há, durante o processo, um acompanhamento das decisões, das ações e de toda a atividade intencional dos atores da situação:
f) pesquisa não se limita a uma forma de ação (risco de ativismo): pretende-se aumentar o conhecimento dos pesquisadores e o conhecimento ou o "nível de consciência"das pessoas e grupos considerados.
