BIG DATA: ANALISANDO DADOS COM O SPLUNK …monografias.poli.ufrj.br/monografias/monopoli10024511.pdf · i BIG DATA: ANALISANDO DADOS COM O SPLUNK ENTERPRISE Maria Bianca Monteiro
Post on 08-Jun-2018
245 Views
Preview:
Transcript
i
BIG DATA: ANALISANDO DADOS COM O SPLUNK ENTERPRISE
Maria Bianca Monteiro Irace
Projeto de Graduação apresentado ao Curso de
Engenharia Eletrônica e de Computação da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessários à
obtenção do título de Engenheiro.
Orientadores:
Alexandre de Assis Bento Lima
Flávio Luis de Mello
Rio de Janeiro
Março de 2018
iv
Ao meu pai
v
AGRADECIMENTOS
Gostaria de agradecer primeiramente ao meu pai, que sempre me mostrou a
importância da educação. Desde pequena ele me incentivou a acreditar que a matemática
era uma brincadeira. Cresci ouvindo que eu seria a “contadora do papai”. Os anos se
passaram e descobri que eu queria fazer engenharia. Não era contabilidade, mas com a
influência que tive do meu pai não tinha como não ser um curso de exatas! Papai sempre
falava que minha primeira missão era obter meu diploma, que ele chamava de “passaporte
pra vida”. Ele me viu entrar na faculdade mas infelizmente faleceu sem poder me
parabenizar na formatura com seu carinhoso beijo em minha testa. Merci papazito.
Em segundo lugar, gostaria de agradecer à minha mãe, que além de cuidar de mim
fazendo da nossa casa um lar e cozinhando um feijão maravilhoso, torcia por mim antes
de todas as provas. Mesmo sem saber do que se tratava, ela decorava o nome de todas as
minhas matérias para poder pedir em suas rezas que tudo corresse bem. Obrigada pela
torcida e por ter um coração tão bonito.
Agradecimento especial aos meus orientadores, Alexandre de Assis e Flávio de
Mello, pela disposição e por todas as sugestões que me auxiliaram a transformar meus
rascunhos neste projeto de graduação.
RESUMO
Este projeto de graduação consiste no estudo de caso sobre a utilização de uma
ferramenta de Big Data, Splunk Enterprise, para a captura e análise de dados gerados
por uma grande empresa de telecomunicações. Uma amostra do monitoramento feito
nos dados da empresa é descrita. Explica-se como o uso do Splunk Enterprise auxiliou a
empresa em sua tomada de decisão e a levou a reduzir o uso de seus recursos e obter um
maior retorno sobre investimento. O monitoramento pelo Splunk Enterprise de
indicadores como uso de CPU, espaço em disco e outros, fez com que a empresa
diminuísse em 80% a utilização dos discos de seus servidores, entre outras melhorias.
Palavras-chave: Big Data, Splunk, Splunk Enterprise, SPL.
vi
ABSTRACT
This graduation project consists in the case study of the use of a Big Data tool,
Splunk Enterprise, for capturing and analyzing data generated by a large
telecommunications company. A sample of the monitoring done on the company data is
described. This work explains how the use of Splunk Enterprise helped the company in
its decision making and led it to reduce the use of its resources and obtain a greater
return on investment. Splunk Enterprise's monitoring of indicators such as CPU usage,
disk space and others, led the company to reduce its server disks usage by 80%, among
other improvements.
Key-words: Big Data, Splunk, Splunk Enterprise, SPL.
vii
viii
Sumário
Capítulo 1 – Introdução ............................................................................................... 1
1.1 – Tema .......................................................................................................... 1
1.2 – Delimitação ................................................................................................ 1
1.3 – Justificativa ................................................................................................ 1
1.4 – Objetivo ..................................................................................................... 2
1.5 – Metodologia ............................................................................................... 2
1.6 – Organização do texto.................................................................................. 3
Capítulo 2 - Dados: processamento e armazenagem ................................................. 4
2.1 – Dados e informação ................................................................................... 4
2.2 – Classificação dos dados quanto a sua estrutura ......................................... 5
2.2.1 – Dados estruturados....................................................................... 5
2.2.2 – Dados não estruturados................................................................ 5
2.2.3 – Dados semiestruturados .............................................................. 6
2.3 – Banco de dados e SGBD............................................................................ 7
2.3.1 – Modelo de dados Relacional ....................................................... 8
2.3.2 – SQL.............................................................................................. 9
2.3.3 – Transações ACID.........................................................................10
2.3.4 – NoSQL.........................................................................................11
2.4 – Inteligência de negócios, Analytics e Big Data .........................................12
2.4.1 – Características de Big Data: os 5 Vs ..........................................13
2.4.2 – Fases da análise de Big Data ......................................................16
2.4.3 – Desafios de Big Data ..................................................................17
ix
Capítulo 3 - A ferramenta Splunk Enterprise ...........................................................18
3.1 – Arquitetura e armazenamento ....................................................................18
3.2 – SPL .............................................................................................................20
3.3 – Alertas ....................................................................................................... 26
3.4 – Dashboards ............................................................................................... 26
Capítulo 4 – Estudo de caso ........................................................................................ 28
4.1 – A empresa Telex e seus produtos .............................................................. 28
4.2 – Funcionamento geral ................................................................................. 28
4.3 – Problema e solução ................................................................................... 29
4.4 – O uso do Splunk Enterprise na Telex ........................................................ 29
4.4.1 – Alerta: Espaço em disco ............................................................. 31
4.4.2 – Alerta: Uso de CPU ................................................................... 32
4.4.3 – Dashboard: Infraestrutura .......................................................... 33
4.4.4 – Dashboard: Técnicos – Informações Mobile ............................. 33
4.4.5 – Alerta: Visitas Improdutivas ...................................................... 34
4.4.6 – Dashboard: Mapa – Atribuições de Técnicos ............................ 35
Capítulo 5 – Conclusão ................................................................................................ 37
Referências ................................................................................................................... 38
x
Lista de Figuras
Figura 1 – Exemplo de XML [9] .................................................................................... 7
Figura 2 – Gráfico do crescimento de dados gerados ao longo dos anos [20] .............. 13
Figura 3 – O que acontece na Internet em um minuto? [21] ......................................... 15
Figura 4 – Entrada de dados de diferentes fontes no servidor Splunk [24] ................... 18
Figura 5 – Exemplo básico de cluster com fator de réplica igual a 3 [25] .................... 19
Figura 6 – Exemplo de pesquisa em SPL ...................................................................... 21
Figura 7 – Exemplo do comando chart ......................................................................... 24
Figura 8 – Exemplo do comando timechart .................................................................. 25
Figura 9 – Exemplo de dashboard no Splunk Enterprise .............................................. 27
Figura 10 – Arquitetura para uso do Splunk Enterprise (adaptada de [25]) .................. 30
Figura 11 – E-mail enviado após disparo do alerta de espaço em disco ....................... 32
Figura 12 – E-mail enviado após disparo do alerta de uso de CPU .............................. 32
Figura 13 – Dashboard de Infraestrutura ...................................................................... 33
Figura 14 – Dashboard dos Técnicos e informações mobile ........................................ 34
Figura 15 – E-mail de monitoramento de visitas improdutivas ..................................... 35
Figura 16 – Dashboard de atribuição de técnicos aos agendamentos ........................... 36
xi
Lista de Tabelas
Tabela 2.1 – Comparação entre dados estruturados e semiestruturados [8] ............... 6
Tabela 2.2 – Exemplo de dados estruturados representados em um modelo
relacional: uma agenda telefônica........................................................ 9
¹ O programa está disponível em <https://www.splunk.com>.
Capítulo 1
Introdução
1.1 – Tema
O tema do trabalho é o estudo de Big Data, seus desafios, aplicações e
ferramentas. Neste sentido é descrita a aplicação de uma ferramenta para tratamento de
Big Data, o Splunk Enterprise¹ para capturar e analisar a enorme quantidade de dados
complexos de uma empresa da área de telecomunicações.
1.2 – Delimitação
O objeto de estudo é o conjunto de dados gerados por aplicações de um sistema
de agendamento de atendimentos de uma grande empresa de telecomunicações. Todos os
dados apresentados são reais, embora o nome da empresa e outras informações
confidenciais tenham sido omitidas. Para facilitar as nomeações ao longo deste trabalho,
esta empresa é referenciada através do nome fictício de Telex e a empresa de consultoria
contratada por esta é denominada Consultex (nome também fictício).
Estratégias semelhantes poderiam ser aplicadas em qualquer outro projeto cujo
objetivo fosse analisar um grande conjunto de dados.
1.3 – Justificativa
Em pesquisas dos últimos anos, observa-se que a quantidade de dados gerados
tem crescido exponencialmente. Isso se deve principalmente à evolução tecnológica, com
a criação cada vez maior de dispositivos que geram saídas. Há estudos que dizem que, a
cada 40 meses, duplica-se o espaço necessário para armazenar todos esses dados [1].
2
Além da grande quantidade de dados tornar um desafio seu armazenamento e
análise, o fato de terem origem em fontes diferentes os tornam também heterogêneos, ou
seja, os dados são volumosos e variados [2]. O conceito de Big Data surgiu com a
intenção de atender à demanda do desenvolvimento de ferramentas que tornassem a
manipulação desses dados possível.
Neste sentido, o presente projeto é um estudo geral de uma das ferramentas de Big
Data: o Splunk Enterprise, com foco na aplicação e análise de um caso real: a Telex. A
contribuição do projeto se deve ao fato de Big Data ser um assunto recente e, como
consequência, haver divergência entre conceitos teóricos que ainda não foram
definitivamente definidos.
1.4 – Objetivo
O objetivo geral é descrever o estudo de caso que mostra a utilização de uma
ferramenta de Big Data, Splunk Enterprise, para a captura e análise dos dados gerados
diariamente pela Telex de forma a extrair o máximo de informações úteis para que a
empresa otimize seu sistema de agendamento de atendimentos. Sendo assim, os objetivos
específicos são: (1) apresentar as operações disponíveis no Splunk Enterprise; (2)
descrever a situação da Telex; (3) elencar as informações de interesse da Telex; (4) usando
o Splunk Enterprise na Telex, analisar os dados da empresa com a ferramenta.
1.5 – Metodologia
O uso do Splunk Enterprise se deve principalmente a uma parceria da Consultex
com a Splunk, além de ser uma tecnologia adequada para o caso. A Telex apresentava
outras ferramentas em uso para o processamento de seus dados. O Splunk Enterprise foi
configurado de forma a não interferir no funcionamento destas.
Os dados da Telex provindos de diversas aplicações foram coletados em uma etapa
chamada de aquisição dos dados. Muitos dos dados coletados não são realmente úteis
para futuras análises, por isso são segregados da massa de dados original.
Informações heterogêneas foram transformadas e inseridas todo dia em índices do
Splunk. Cada aplicação tem o tempo certo para fazer a inserção de seus dados nos
3
servidores da ferramenta de acordo com a quantidade de dados gerados e seu período de
funcionamento. Trata-se da integração dos dados.
Com o conhecimento da Telex e com as funções disponíveis no Splunk Enterprise,
gráficos, dashboards, relatórios e outros foram produzidos pela autora deste projeto e sua
equipe da Consultex para análise desses dados, assim como a implantação de toda a
arquitetura necessária para tal.
O produto deste trabalho de conclusão de curso está relacionado ao
monitoramento para pleno funcionamento e otimização das aplicações que formam o
sistema de agendamento de atendimentos da Telex graças ao uso do Splunk Enterprise.
1.6 – Organização do texto
O texto está organizado como a seguir.
O capítulo 2 é focado em dados e sua análise. Os seguintes tópicos são abordados:
dados e informação, banco de dados, Sistemas de Gerenciamento de Banco de Dados,
inteligência de negócios, Analytics e Big Data.
No capítulo 3, a ferramenta de Big Data utilizada no projeto, Splunk Enterprise, é
apresentada junto com sua linguagem de pesquisa, a SPL (Splunk Search Processing
Language).
O capítulo 4 descreve o estudo de caso. A situação atual da Telex é discutida e
mostra-se como seus objetivos foram alcançados com o uso da ferramenta.
O capítulo 5 conclui o projeto.
4
Capítulo 2
Dados: processamento e armazenagem
Neste capítulo, na seção 2.1, é apresentada a diferença entre dado e informação.
Na seção 2.2, a classificação dos dados quanto a sua estrutura é descrita. A seção 2.3 tem
como tema principal bancos de dados e seus sistemas gerenciadores. Tópicos
relacionados como o modelo relacional, a linguagem SQL, entre outros também são
abordados. Finalmente, na seção 2.4 fala-se sobre inteligência de negócios, analytics e
Big Data. As características de Big Data, suas fases de análise e seus desafios também
são expostos.
2.1 – Dados e informação
Somasundaram e Shrivastava, atualmente diretores da EMC Global Services,
definem dados como um “conjunto de fatos em estado bruto” [3], isto é, aqueles retirados
diretamente de suas fontes e que não tenham passado por nenhum tipo de tratamento.
Uma letra, um número, ou até mesmo uma imagem ou um vídeo podem ser considerados
dados.
Segundo Luciano Floridi [4], italiano pioneiro no campo da Filosofia da
Informação, dados podem ser considerados uma informação se eles satisfizerem alguns
critérios:
“A definição geral de informação (GDI): σ é uma instância de informação,
entendida como conteúdo semântico, se e somente se:
1) σ consiste em um ou mais dados;
2) os dados em σ são bem formados;
3) os dados bem formados em σ têm significado.”
[4]
Informação requer então uma análise para se obter uma compreensão do dado
correspondente. Um dado passa a ser uma informação a partir do momento em que faz
sentido para seu receptor. A palavra “laranja”, por exemplo, é um dado, mas quando
5
inserida na situação “Maria está usando uma camisa laranja”, se torna uma informação.
O entendimento sobre o sentido de uma informação depende do contexto onde o dado é
inserido, como por exemplo na sentença “Maria está comendo uma laranja”. Uma
informação é resultado de um ou mais dados processados em um determinado contexto.
Conclui-se então que toda informação é um dado, mas nem todo dado é uma
informação. Dado é algo mais abstrato que possui inicialmente diversas possibilidades de
significado, enquanto informação é algo mais concreto, possui um contexto e dá
materialidade ao dado provendo um único significado.
Embora a diferenciação de ambos os termos seja do campo da filosofia, que não
é o foco deste projeto, suas definições são necessárias para que não haja confusão entre
eles, visto que são frequente e erroneamente usados como sinônimos.
2.2 – Classificação dos dados quanto a sua estrutura
Os dados podem ser categorizados segundo diversos critérios. Nesta seção, será
apresentada a classificação em dados estruturados, não-estruturados e semiestruturados.
2.2.1 – Dados estruturados
Segundo Rathinasamy, dados estruturados são definidos como dados que podem
ser facilmente organizados [5]. São pares de campo e valor armazenados em tabelas, ou
seja, em linhas e colunas. Apresentam uma estrutura fixa a partir de um modelo
previamente projetado e são gerenciados por Sistemas Gerenciadores de Banco de Dados.
Estes últimos são abordados em 2.3.
2.2.2 – Dados não estruturados
Rathinasamy define dados não estruturados como dados que se referem a
informações que não possuem um modelo de dados predefinido e/ou não estão
organizadas de forma predefinida [5]. Estes dados não podem então ser alocados em uma
tabela, já que não são organizados em pares de campo e valor. Imagens, vídeos, textos e
áudios são exemplos de dados não estruturados.
6
Pesquisas de diversas empresas da área de TI apontam que cerca de 80% a 85%
dos dados produzidos por uma empresa são não estruturados. Entretanto, uma enquete
feita pela TDWI Research obteve como resultado 47% de dados estruturados, 31% de não
estruturados e 22% de dados semiestruturados [6]. Embora haja uma grande discrepância
entre os valores das pesquisas, não há dúvidas que os dados não estruturados e
semiestruturados representam a maioria dos dados gerados.
2.2.3 – Dados semiestruturados
Há um terceiro tipo de dados, os dados semiestruturados, embora nem todos os
autores o mencionem em seus textos.
Segundo a definição, esta categoria agruparia dados com uma estrutura irregular
ou vagamente definida. Os dados semiestruturados não necessitam de esquemas
previamente definidos e são menos restritos que os dados estruturados [7]. Sua estrutura
é descritiva e não prescritiva. Os dados semiestruturados são ditos autodescritivos, pois
sua estrutura é inserida junto a eles. Observe a tabela comparativa entre dados
estruturados e semiestruturados a seguir.
Tabela 2.1 – Comparação entre dados estruturados e semiestruturados (extraída de [8])
Dados estruturados Dados semiestruturados
Esquema predefinido Nem sempre há um esquema predefinido
Estrutura regular Estrutura irregular
Estrutura independente dos dados Estrutura embutida no dado
Estrutura reduzida Estrutura extensa
Estrutura fracamente evolutiva Estrutura fortemente evolutiva
Estrutura prescritiva Estrutura descritiva
Distinção entre estrutura e dado é clara Distinção entre estrutura e dado não é
clara
A estrutura de dados semiestruturados pode ser extensa em consequência da
heterogeneidade destes. Ela também é considerada fortemente evolutiva pois é
modificada frequentemente para manter seus dados atualizados.
7
Dados semiestruturados podem ser logs de servidores e aplicações, arquivos na
linguagem de marcação XML, elementos no formato JSON, entre outros. Veja a seguir
um exemplo de um arquivo em XML representando um menu de café da manhã.
Figura 1 – Exemplo de XML (extraída de [9])
2.3 – Banco de dados e SGBD
Um banco de dados é uma coleção de dados relacionados que são organizados e
armazenados em uma estrutura lógica, fazendo então com que sejam facilmente
acessados, gerenciados e atualizados. [10]
8
Os Sistemas de Gerenciamento de Banco de Dados (SGBD) são softwares
responsáveis pela interação entre o usuário, o banco e facultativamente outras aplicações.
Ou seja, os SGBD possibilitam a comunicação entre o usuário e o armazenamento físico
dos dados [11].
Suas principais funções são armazenar, excluir, atualizar e extrair informações de
um banco de dados. Além disso, precisam garantir a consistência dos dados e que estes
não serão perdidos. Para tal, o SGBD pode criar cópias dos dados em discos ou fitas para
casos de falhas (backup). Com o objetivo de oferecer ao usuário rápido acesso às
informações, o sistema copia os dados mais acessados para a memória. Também é papel
do sistema controlar quem tem acesso aos dados e manter eles seguros (controle de
acesso, encriptação, etc.).
Nas seções a seguir, os seguintes temas são abordados: (1) modelo Relacional,
que é o modelo mais comum de banco de dados hoje em dia; (2) SQL, que é a linguagem
de pesquisa padrão nos SGBD relacionais; (3) transações ACID, cujas propriedades são
fundamentais para operações em bancos de dados; e (4) NoSQL, onde o assunto de banco
de dados não relacionais é discutido.
2.3.1 – Modelo de dados Relacional
Há diversos modelos de dados. O mais conhecido é o modelo Relacional. Este foi
desenvolvido pelo matemático Edgar Frank Codd a partir de estudos sobre representações
de relacionamentos de dados e a teoria dos conjuntos. Suas pesquisas foram publicadas
em 1970. [11]
O modelo Relacional organiza os dados em relações que podem ser dispostas em
linhas e colunas, sendo popularmente denominadas de tabelas. As colunas representam
os atributos dos dados. Cada linha é uma instância da relação entre eles. Instâncias
também são chamadas de tuplas. Nenhuma tupla pode ser completamente igual a outra.
Para isso, existe o conceito de chave primária. Consiste em um valor único e não nulo.
Cada tupla deve conter uma chave primária para diferenciá-la das demais. [12]
9
Tabelas podem ser referenciadas por um atributo comum. Isto ocorre quando uma
chave primária de uma tabela está presente em outra tabela, sendo denominada chave
estrangeira desta. [12]
Bancos de dados relacionais podem ser utilizados para armazenar dados
estruturados. O Sistema Gerenciador de Banco de Dados Relacional (SGBDR) é um
software que possibilita a criação e a gerência de um banco de dados relacional. Segue
um exemplo de uma agenda telefônica:
Tabela 2.2 – Exemplo de dados estruturados representados em um modelo relacional:
uma agenda telefônica.
ID Nome Sobrenome Telefone
001 Alexandre Assis +55 22 91234-5678
002 Flávio Mello +55 21 98231-7568
003 Maria Bianca Irace +55 21 99601-2847
Este exemplo apresenta três tuplas representadas com quatro atributos: ID, nome,
sobrenome e telefone. O número de identificação ID é a chave primária da tabela.
Percebe-se que nenhuma linha contém ID nulo ou repetido.
2.3.2 – SQL
A Linguagem de Consulta Estruturada (SQL – Structured Query Language)
surgiu em 1974 em um projeto experimental de um Centro de Pesquisas da IBM, com o
objetivo de implementar o modelo relacional proposto por Codd em 1970.
É uma linguagem declarativa para definição, manipulação e consulta de dados.
Linguagens procedurais necessitam que o programador especifique o passo a passo das
operações, já em linguagens declarativas isto não é necessário. Além disso, possui
facilidades para criação de visões no banco de dados, para especificar segurança e
autorização, especificar controles de transação, etc [12].
A linguagem SQL é formada pelo seu núcleo principal e suas extensões, para
aplicações específicas. Todos os SGBD relacionais que fazem uso da SQL apresentam o
10
mesmo núcleo da linguagem. Isto faz com que a migração entre sistemas relacionais seja
muito mais fácil, se forem compatíveis com a SQL. [12]
Por causa de todas essas vantagens, a linguagem SQL se tornou a linguagem
padrão dos SGBD relacionais.
2.3.3 – Transações ACID
O conceito de transação é um ponto chave para aplicações de gestão de dados. Em
1981, Jim Gray definiu uma transação como "uma transformação de estado que possui
propriedades de atomicidade, durabilidade e consistência" [13]. Uma transação é então
um conjunto de operações de consultas e alterações de dados que respeita propriedades
que são discutidas mais adiante nesta seção.
Uma das principais funções na armazenagem de dados é manter os dados
confiáveis para eventuais consultas. De que adiantaria armazenar dados falsos? Ou perder
parte deles? Imagine uma situação em que um usuário faz uma transferência de dinheiro
para uma outra conta bancária. Caso haja qualquer tipo de problema durante a operação,
é necessário garantir que o dinheiro não desapareça da conta do usuário e deixe de ser
creditado na outra conta, por exemplo. Para evitar este tipo de problema fala-se das
transações ACID. Para uma transação ser considerada uma transação ACID, ela deve
possuir as seguintes propriedades:
• Atomicidade
Transações atômicas são executadas por completo ou não são executadas.
Se uma parte da transação falhar, a transação inteira é abortada e o banco
de dados não é modificado.
• Consistência
Esta propriedade garante que após a execução de uma transação, o banco
passa de um estado válido para outro estado válido [14]. Isto quer dizer
que todas as relações respeitam todas as regras e restrições.
11
• Isolamento
Uma transação não é afetada por outra transação em progresso. Ou seja,
múltiplas transações podem ser executadas por um ou mais usuários ao
mesmo tempo, sem que interfira no resultado da outra. [14]
• Durabilidade
Os resultados de transações são armazenados permanentemente
independente de falhas no sistema ou no hardware. [14]
Estas propriedades devem ser garantidas por qualquer SGBD destinado a
operações com forte controle de consistência.
2.3.4 – NoSQL
No início dos anos 2000, com o crescimento da Web, percebeu-se que, para
algumas aplicações, os bancos de dados relacionais não eram adequados, pois era
necessário o processamento de grandes volumes de dados em alta velocidade. Inovações
foram então necessárias. [14]
O termo NoSQL apareceu pela primeira vez em 1998, quando Carlo Strozzi se
referia ao seu banco de dados acessado via shell scripts, e não por comandos na linguagem
SQL. NoSQL vem do inglês “Not Only SQL”, que significa “Não somente SQL”. Desde
então, outras alternativas a comandos longos e complexos em SQL foram desenvolvidas.
O diferencial destas em relação ao uso da SQL é que o desenvolvedor executa funções
em objetos sem a necessidade do total conhecimento da estrutura do banco de dados. [15]
Vários bancos de dados NoSQL foram criados, cada um com características
específicas de acordo com a necessidade. Isso resultou em diferentes definições do termo
NoSQL. Entretanto, todas concordam que um banco de dados NoSQL tem as seguintes
propriedades [15]:
• A definição prévia dos dados e de sua estrutura não é necessária.
12
• As informações são não relacionais e armazenadas por completo,
contrariamente ao modelo relacional que interliga as informações por
meio de relações entre tabelas.
• É distribuído e seu hardware não precisa ser especializado. Servidores
baratos podem ser usados. Caso haja a necessidade de processar mais
dados, é facilmente escalável.
Graças a essas características, os bancos de dados NoSQL são a solução para o
armazenamento e processamento da grande massa de dados não estruturados e
semiestruturados gerada atualmente.
2.4 – Inteligência de negócios, Analytics e Big Data
Ao longo dos anos, diversos termos foram criados para falar sobre a extração de
informações dos dados. Ainda não há um consenso sobre as definições dos mais
modernos. Alguns autores, por exemplo, tratam analytics como um subconjunto da
inteligência de negócios, já outros as tratam como duas coisas distintas.
Boris Evelson, atualmente vice-presidente da Forrester e trabalhando há mais de
20 anos com inteligência de negócios, a define como “um conjunto de metodologias,
processos, arquiteturas e tecnologias que transformam dados brutos em informações
úteis” [16]. A inteligência de negócios permite a tomada de decisão em uma empresa
através de seus dados.
Analytics tem foco em análise matemática e estatística [17]. Trata-se da
descoberta, interpretação e conexão entre padrões significativos dos dados [18]. Evelson
e muitos outros autores consideram analytics como parte da inteligência de negócios.
Nos últimos anos, com o crescimento exponencial dos dados, um novo termo foi
criado: Big Data, que é o foco deste trabalho. Não se sabe ao certo quando o termo foi
usado pela primeira vez. Estudos feitos pela Google apontam um aumento no número de
pesquisas por Big Data a partir de 2012, indicando sua popularização. Por ser algo
recente, uma única definição ainda não foi estabelecida.
Um artigo do International Journal of Internet Science diz que Big Data “são
conjuntos de dados grandes e complexos cujas ferramentas tradicionais não são
13
adequadas para sua manipulação”. As novas ferramentas devem capturar, supervisionar,
gerenciar e processar esses dados dentro de uma faixa de tempo tolerável. [19]
Para ilustrar a grande quantidade de dados gerados, veja o gráfico feito em 2016
pela Gartner, empresa líder mundial em pesquisa e consultoria, com estatísticas do
crescimento de dados gerados em anos anteriores e previsão para os anos futuros (Figura
2).
Figura 2 – Gráfico do crescimento de dados gerados ao longo dos anos (extraída
de [20])
Quando se fala em Big Data Analytics, refere-se ao uso de ferramentas que
realizam análises matemáticas e estatísticas sobre dados grandes e complexos com o
objetivo de auxiliar a tomada de decisão de uma organização.
Nas seções a seguir, são discutidos os seguintes tópicos: (1) as características de
Big Data, (2) os passos para sua análise e (3) seus desafios.
2.4.1 – Características de Big Data: os 5 Vs
Big Data pode ser descrito através de cinco características que são conhecidas
como os 5Vs. São elas:
14
• Volume
Se refere à grande quantidade de dados gerados.
• Velocidade
A grande quantidade de dados é gerada e consumida de forma muito
rápida.
• Variedade
Os dados têm origem em diversas fontes e são de diferentes tipos.
• Veracidade
A qualidade do dado obtido deve ser verificada, pois se for duvidosa pode
afetar a análise.
• Valor
Os dados devem agregar valor ao negócio.
Para se ter noção do fluxo de dados, veja a seguir na figura 3 um comparativo de
2016 e 2017 com alguns números do que acontece na internet em um minuto. É claro que
alguns desses dados também refletem a popularidade da aplicação escolhida para a
análise, mas independente disto e de outros fatores, não há dúvidas que no geral houve
um aumento de fluxo em somente um ano. Repare por exemplo que a média de envio de
e-mails por minuto passou de 150 milhões em 2016 para 156 milhões em 2017. Fazendo
as contas, dá um aumento de e-mails enviados de mais de 3 trilhões!
15
Figura 3 – Comparativo de 2016 e 2017: O que acontece na internet em um
minuto? (extraída de [21])
Para entender a variedade dos dados, imagine a situação onde um hospital cuida
de um paciente doente. O hospital recolhe informações de pressão, batimento cardíaco,
faz exames de sangue, de urina, entre outros, e precisa analisar todos esses dados distintos
provindos de diversos aparelhos para poder tratá-lo.
Devido ao grande fluxo e a fontes duvidosas, os dados não são totalmente
confiáveis. Na situação anterior, por exemplo, o hospital podia estar recolhendo a pressão
do paciente ao longo do dia por meio de aparelhos automatizados e o sensor sofrer algum
tipo de interferência e obter uma medida de pressão errada. Este erro pode afetar a análise
caso não seja eliminado. Daí a importância da veracidade.
Tratando-se de Big Data, a quantidade de dados é tão grande que alguns valores
errados não vão afetar a média. Em alguns casos, o valor errado pode ser tão discrepante
que é facilmente excluído. Em outros, esses valores diferentes podem ser o objeto foco
do estudo. Tudo vai depender da aplicação.
Para extrair valor de Big Data, é necessário seguir alguns passos que são
discutidos no tópico a seguir.
16
2.4.2 – Fases da análise de Big Data
A análise de Big Data é composta por cinco fases essenciais para seu sucesso:
aquisição de dados, extração de informação e limpeza, integração dos dados,
modelagem e análise, e interpretação [2]. A descrição de cada uma é dada a seguir.
1. Aquisição de dados
Trata-se do registro de uma atividade de interesse. Grandes massas de
dados são produzidas a todo momento pelos numerosos instrumentos que se
tem hoje em dia. O desafio é justamente conseguir filtrar as informações úteis,
já que não se pode armazenar algo tão voluminoso. [2]
2. Extração de Informação e limpeza
A informação coletada pode não estar em um formato pronto para a
análise. A extração de informação consiste nesta formatação e depende
fortemente da aplicação de Big Data da qual se deseja fazer a análise.
Técnicas de limpeza devem ser empregadas para eliminar informações
falsas, tais como medidas incorretas, opiniões tendenciosas no caso de
pesquisas com pessoas, entre outras. [2]
3. Integração dos dados
Os dados heterogêneos vindos de diversas fontes devem ser transformados
e integrados por meio de ferramentas que os manipulam de forma a torná-los
interpretáveis e analisáveis.
4. Modelagem e análise
Modelar amostras pequenas de dados no modelo relacional é demonstrar
sua estrutura, dizer como estão organizadas e quais são as suas relações. Em
Big Data, os dados podem ser modelados após o armazenamento, de acordo
com a necessidade [22].
A análise trata da observação desses dados para sua compreensão. Embora
possa haver uma certa quantidade de dados errôneos em uma aplicação de Big
Data, estes são facilmente excluídos por métodos estatísticos [2].
17
5. Interpretação
A fase de interpretação também depende fortemente da aplicação de Big
Data. Trata-se da formulação de opiniões que explicam os dados obtidos.
Baseando-se nessas suposições, outras análises podem ser feitas com o
objetivo de auxiliar a tomada de decisão.
2.4.3 – Desafios de Big Data
Devido às características de Big Data, há desafios para sua análise.
Por se tratar de dados heterogêneos, os algoritmos de análise são dificultados,
visto que trabalham com dados homogêneos. Para contornar este problema, é necessário
manter as informações sobre a proveniência e as características dos dados. [2]
Dispositivos coletores de dados são incertos, pois podem capturar dados errôneos
ou incompletos. Estes erros precisam ser gerenciados.
Por se tratar de uma grande quantidade de dados, o desafio que no passado era
aumentar a frequência de clock dos processadores, passou a ser como arquitetar o
hardware da melhor forma para suprir as necessidades de processamento.
Técnicas de armazenamento devem ser empregadas para a eficiência da análise
em tempo real. Os dados costumam ser separados por índices, agilizando assim a pesquisa
por itens específicos. [2]
A privacidade e a posse de dados representam um desafio sociológico de Big Data.
Informações de localização de um indivíduo, por exemplo, são facilmente relacionadas a
características pessoais, além de padrões de deslocamento serem facilmente descobertos
[2]. Este tema renderia boas discussões, mas as ciências humanas não são foco deste
projeto.
18
Capítulo 3
A ferramenta Splunk Enterprise
A empresa Splunk é uma multinacional americana fundada em 2003. Ela produz
software para pesquisa, monitoramento e análise de Big Data através de uma interface
Web. Dentre seus produtos está o Splunk Enterprise, ferramenta usada neste projeto.
O Splunk Enterprise captura, indexa e correlaciona dados em tempo real. A partir
de seu repositório é possível gerar gráficos, relatórios, alertas, dashboards e outros. Tudo
isso é feito por meio de pesquisas nos dados indexados, fazendo o uso da Search
Processing Language (SPL), ou em português, Linguagem de Processamento de Busca.
O principal objetivo da ferramenta é auxiliar atividades envolvendo inteligência
de negócios, fornecendo métricas e recursos para visualização dos dados, identificando
padrões, diagnosticando problemas, etc.
Todos esses temas são abordados neste capítulo, que foi escrito usando como
principal referência a documentação oficial [23] fornecida pela Splunk.
3.1 – Arquitetura e armazenamento
O Splunk Enterprise indexa qualquer tipo de dado textual proveniente de qualquer
que seja a fonte: computadores, sensores, bases de dados, máquinas virtuais e outros
dispositivos (ver ilustração da figura 4). É então adequado para a variedade de Big Data.
Figura 4 – Entrada de dados de diferentes fontes no servidor Splunk [24]
19
A arquitetura básica de um cluster para o Splunk Enterprise é composta por três
tipos de instâncias: nó mestre, nó peer e search head. Essas instâncias também são
chamadas de indexadores, que têm como função indexar dados. Um cluster indexador é
um grupo de indexadores (ou nós) que possui réplicas dos dados. O fator de réplica
especifica a quantidade de cópias dos dados que o cluster mantem. Isto serve para a
prevenção de perda de dados, promovendo a disponibilidade deles para pesquisa. [25]
O nó mestre gerencia o cluster, coordenando as atividades dos nós peer e
informando ao search head aonde se encontram os dados. Os nós peer recebem e indexam
os dados. A quantidade de nós peer deve ser igual ou superior ao fator de réplica. O search
head gerencia as pesquisas nos nós peer. Veja na figura 5 um exemplo de um cluster com
fator de réplica igual a 3. As flechas vermelhas representam os dados pesquisados, as
verdes os dados encaminhados e as azuis os dados replicados.
Figura 5 – Exemplo básico de cluster com fator de réplica igual a 3 (adaptada de
[25])
Para os dados chegarem às instâncias do Splunk Enterprise, um outro programa
disponibilizado pela própria empresa deve ser instalado e configurado nas máquinas onde
se deseja capturar os dados, os forwarders.
20
Configurar um cluster no Splunk Enterprise é uma tarefa simples que consiste em
designar na ferramenta o tipo de cada instância. É necessário ao menos um nó mestre e
um search head. As demais instâncias são os nós peer. Esta arquitetura é facilmente
escalável. Para expandir o cluster é só adicionar mais nós peer. [25]
Os repositórios do Splunk Enterprise são chamados de índices. A ferramenta
possui três índices por padrão, mas outros também podem ser facilmente criados pelos
administradores da ferramenta, que devem pré-definir seu tamanho de acordo com a
aplicação.
Os índices separam os dados pelo tempo em diretórios chamados de buckets. É na
fase de indexação que os dados recebidos são transformados em eventos e são marcados
com a informação do horário em que foram coletados. Pesquisas com filtros de tempo
adequados são então executadas de forma rápida, uma característica muito importante
para a manipulação de Big Data.
Os dados são indexados com três campos por padrão, denominados pela
ferramenta de host, source e sourcetype. O campo que determina o tempo da coleta é
chamado de _time ou timestamp.
3.2 – SPL
Como o Splunk Enterprise trabalha com dados estruturados e não estruturados, o
uso da linguagem SQL não é adequado para a ferramenta. Consequentemente, foi
necessária a criação de uma linguagem própria para a utilização dos dados, a Linguagem
de Processamento de Busca (SPL, do inglês Search Processing Language). Ela foi
desenvolvida pela empresa Splunk e engloba comandos de pesquisa com suas funções e
argumentos. Sua sintaxe foi originalmente baseada nos processos de Unix e na linguagem
SQL. Com o uso da SPL o usuário tem a liberdade de manipular os dados capturados para
obter a melhor forma de visualização e/ou uso destes. Veja na figura 6 uma simples
pesquisa em SPL.
Repare que todos os eventos retornados pela pesquisa possuem como host a
máquina “splpx01”. Trata-se do nome dado a um servidor do Splunk nesta aplicação. Os
21
eventos deste exemplo contêm pares de chave-valor, que facilitam a identificação de
possíveis campos interessantes (interesting fields) pela ferramenta, que são listados à
esquerda. O usuário tem a possibilidade de filtrar seus eventos pelo tempo, selecionando
um período específico através do timepicker, situado à direita da barra de pesquisa ou da
linha do tempo, situada abaixo da mesma.
Figura 6 – Exemplo de pesquisa em SPL
Para auxiliar na transformação dos dados indexados em algo útil, a linguagem
SPL possui um conjunto de comandos. Estes são usados na barra de pesquisa e separados
por barras verticais ( | ). Os comandos em SPL são categorizados segundo sua função em
comandos de filtragem (search, where, dedup, head, tail, ...), agrupamento (transaction,
...), informação (top, rare, stats, chart, timechart, ...) e modificação (fields, replace, eval,
rex, lookup, ...). Alguns mais usados são listados a seguir.
Search
Comando mais básico da SPL, chamado implicitamente em todas as pesquisas
antes da primeira barra vertical. Quando não é o primeiro comando da pesquisa, serve
para filtrar os resultados anteriores. Funciona com expressões e booleanos.
22
Table
Serve para mostrar os dados brutos em formato de uma tabela. Seus argumentos
devem ser campos existentes identificados pela ferramenta ou extraídos pelo usuário.
Exemplo:
index=vendas source=oracle sourcetype=pizzas
| table _time sabor tamanho valor
| search (sabor = ”quatro queijos” OR sabor = ”calabresa”) valor > 15
Neste exemplo, os eventos são um conjunto de dados brutos que contêm
informações de quais pizzas foram vendidas em um estabelecimento. Os campos
extraídos e tabelados foram o horário em que a pizza foi vendida, seu sabor, tamanho e
valor. O segundo comando search, já que há um search implícito por padrão no início de
qualquer pesquisa, filtra os dados da tabela selecionando apenas as vendas de pizza de
sabor igual a “quatro queijos” ou “calabresa”, e cujo valor seja superior a 15 reais. O
operador lógico AND é implícito entre pesquisas.
Where
Também é um comando que serve para filtrar a pesquisa. A diferença entre o
where e o search é que o where é usado para comparações entre campos.
Se no exemplo anterior tivéssemos por exemplo dois campos de valores,
referentes aos preços das pizzas em duas lojas diferentes, poderíamos fazer:
index=vendas source=oracle sourcetype=pizzas
| where valor_lojaA < valor_lojaB
Esta pesquisa retornaria somente os eventos cujas pizzas são mais baratas na loja
A.
23
Sort
Ordena pelo campo especificado.
... | sort + nome_campo
Ordena o “nome_campo” de forma crescente.
... | sort - nome_campo
Ordena o “nome_campo” de forma decrescente.
Top/Rare
Retorna a ocorrência mais/menos frequente dos campos listados, junto com sua
contagem e percentual do total de eventos.
Eval
Este comando calcula uma expressão e insere seu valor em um campo, podendo
ser um campo utilizado na própria expressão, que neste caso será sobrescrita.
Exemplos:
... | eval velocidade = deslocamento/tempo
Sendo "deslocamento" e "tempo" dois campos com valores conhecidos, o novo
campo "velocidade" é criado com os valores da divisão correspondente.
... | eval total = “R$ ” + total
O operador “+” funciona como um concatenador neste exemplo. O total, que antes
poderia ser o número “9,99”, por exemplo, passou a ser a string “R$ 9,99”. A lista
completa de operadores e funções se encontra na documentação em [26].
Stats
24
Calcula estatísticas em um conjunto de dados. Apresenta a seguinte lista de
funções:
- avg(X): faz a média dos valores do campo X.
- count(X): faz a contagem total de eventos do campo X.
- dc(X): faz a contagem de eventos distintos do campo X.
- max(X): retorna o valor máximo de X.
- min(X): retorna o valor mínimo de X.
O comando stats apresenta outras funções que podem ser facilmente encontradas
na documentação em [27].
Chart
Comando que gera uma visualização dos dados em um gráfico. A variável que
fica no eixo x pode ser especificada usando over ou by.
Exemplo:
... | chart max(valor) by sabor
Tendo como contexto o nosso exemplo das pizzas, esta pesquisa retorna um
gráfico com o preço máximo da pizza no eixo y e os sabores das pizzas no eixo x (figura
7).
25
Figura 7 – Exemplo do comando chart
O comando chart apresenta diversas opções de gráficos padrão, tais como:
gráficos de linha, área, barra, coluna, de setores, entre outros. O desenvolvedor pode
facilmente selecionar o formato desejado através da opção na interface gráfica
denominada “formato de visualização”.
Timechart
Comando que gera uma visualização por meio de um gráfico cujo eixo x é
obrigatoriamente o tempo.
Exemplo:
... | timechart count AS “Qtd pizzas vendidas”
Dentro de um contexto onde os eventos são as pizzas vendidas, esta pesquisa exibe
um gráfico da quantidade de pizzas vendidas pelo tempo. Veja o gráfico na figura 8.
Figura 8 – Exemplo do comando timechart
A linguagem SPL possui muitos outros comandos. Caso seja interesse do leitor,
todos estão listados na documentação oficial em [28].
26
3.3 – Alertas
Um alerta é "uma pesquisa que é executada periodicamente com uma condição
avaliada nos resultados da própria pesquisa" [29]. Quando a condição coincide, algumas
ações são executadas. Uma das ações disponíveis e muito utilizada na ferramenta é a
possibilidade de envio de e-mails quando um alerta é disparado.
Para criar uma alerta, as seguintes informações são necessárias: a pesquisa base,
os dias e horários que essa pesquisa será feita, o intervalo de tempo de dados que a
pesquisa levará em conta, as condições para seu disparo, assim como as ações que serão
executadas após tal acontecimento.
A ação de envio de e-mail também é facilmente configurada. O desenvolvedor
precisa inserir os e-mails dos destinatários, escrever o assunto e o corpo do e-mail, além
de escolher se deseja acrescentar os resultados da pesquisa, gráficos, entre outras
informações no e-mail.
Outras ações também podem ser executadas após um disparo de um alerta. Se as
disponíveis não forem suficientes, o desenvolvedor tem a possibilidade de baixar
aplicativos na base do Splunk [30] para complementar a ferramenta.
3.4 – Dashboards
Os dashboards são um conjunto de painéis com várias visualizações de dados.
Eles devem conter informações de forma organizada sobre um cenário da organização
monitorada, com o objetivo de facilitar a compreensão do problema e permitir uma
análise rápida para a tomada de decisão. [31]
27
Figura 9 – Exemplo de dashboard no Splunk Enterprise
A figura 9 é um exemplo de dashboard criado no Splunk Enterprise. Ele contém
quatro painéis: um do tipo valor único, um gráfico de linha, um gráfico de coluna e uma
tabela. O desenvolvedor tem uma interface que permite fácil organização dos painéis no
dashboard.
28
Capítulo 4
Estudo de Caso
Neste capítulo são discutidas as informações gerais da Telex, os produtos e
serviços que ela oferece e o básico funcionamento de um de seus sistemas. Este sistema
é o responsável pelo agendamento de atendimentos da empresa e é a fonte principal da
análise deste projeto. Além disso, é apresentado o motivo da contratação da Consultex,
como a aplicação da ferramenta Splunk Enterprise para solução do problema da Telex.
Os nomes fictícios Telex e Consultex foram usados para manter sigilo de
informações confidenciais, entretanto, os dados apresentados são todos reais.
4.1 – A empresa Telex e seus produtos
A Telex é uma grande empresa de telecomunicações sediada no Brasil que atende
a mais de 100 milhões de clientes ao redor do mundo.
Como a maioria das empresas de telecomunicações de hoje em dia, ela oferece o
fornecimento de Internet, telefone fixo e canais fechados de televisão. O cliente pode
solicitar um só produto, como uma combinação deles. Além disso, pode escolher
especificações para cada produto, como a velocidade da Internet contratada, quantos
minutos de conversa terá seu plano de telefone e quais canais serão liberados para ele
assistir.
Para atender a esta demanda e instalar os aparelhos necessários para o
funcionamento dos serviços contratados pelo cliente, a Telex possui técnicos e um sistema
de agendamento de atendimentos cujo fluxo é explicado no tópico a seguir.
4.2 – Funcionamento geral
Quando um cliente liga para a central de atendimento da Telex, um bilhete de
atendimento é aberto no sistema com um número de identificação único, chamado de BA.
Nele, constam informações sobre o cliente, como nome, telefone, entre outras, que são
completadas ao longo do atendimento.
29
Caso seja um novo cliente, este pode ligar solicitando a instalação de algum
produto. Para isso, o sistema precisa verificar se há técnicos disponíveis para o endereço
solicitado, além de analisar os horários livres para o cliente aceitar um deles para
confirmação do agendamento. Para quem já é cliente da Telex, solicitações de mudança
de endereço ou de reparos nas instalações geram procedimentos similares no sistema.
4.3 – Problema e solução
O sistema de atendimento da Telex gera diariamente um volume de dados da
ordem de terabytes. A empresa possui mais de 200 servidores para gerenciar este enorme
fluxo de dados. Juntos, estes servidores são capazes de armazenar mais de dez petabytes
de informação. Eles apresentam um total de quatro terabytes de memória RAM e utilizam
o Windows Server como sistema operacional.
Com esta enorme quantidade de dados gerada diariamente, não há dúvidas de que
a aplicação apresenta dois Vs de Big Data: volume e velocidade. A variedade também
está presente pelo fato dos dados serem provindos de diversas fontes: bases de dados, log
de servidores, etc. Estas fontes são confiáveis, então há veracidade. O conjunto das
informações agrega valor ao negócio, pois representa o funcionamento do maior sistema
da Telex. A aplicação possui então os 5 Vs de Big Data.
Para garantir o pleno funcionamento do sistema de agendamento de atendimentos,
a Telex contratou os serviços da Consultex, uma grande empresa multinacional de
consultoria voltada para a tecnologia da informação.
Para a resolução do problema de Big Data da Telex, a Consultex decidiu analisar
os dados gerados pelo sistema, fazendo uso de uma das ferramentas fornecidas pela
empresa Splunk, a Splunk Enterprise. O uso de um SGBD relacional tradicional não seria
adequado, pois os dados gerados pela empresa são em sua maioria semiestruturados.
4.4 – O uso do Splunk Enterprise na Telex
Como não é possível armazenar toda a massa de informação gerada pelo sistema,
o primeiro passo da Consultex foi obter o completo conhecimento do sistema para filtrar
o que realmente poderia ser útil para análise por meio da ferramenta escolhida.
30
A infraestrutura disponível para o monitoramento através do Splunk Enterprise é
composta de 4 servidores, sendo um o search head, que tem como função a distribuição
das demandas entre os diversos índices contidos nos demais servidores, além da
consolidação dos resultados. Os servidores da Telex cujos dados são encaminhados aos
servidores do Splunk são chamados de forwarders. O esquema da arquitetura pode ser
visto na figura 10.
Figura 10 – Arquitetura para uso do Splunk Enterprise (adaptada de [25])
Como os índices possuem um tamanho limitado e a quantidade de dados a serem
armazenados é crescente, nem tudo pode ser guardado para sempre. Quando um índice
está cheio, os dados mais antigos são deletados para dar espaço aos mais recentes. O
tamanho dos índices é calculado de forma a manter os indicadores disponíveis por no
mínimo 30 dias, que é o tempo mínimo necessário para um monitoramento satisfatório.
A licença paga para o uso do Splunk Enterprise permite que até 50GB de dados
sejam adicionados diariamente em seus servidores. Não há limitações na quantidade de
dashboards nem alertas criados. Em um ano de atuação, a Consultex criou mais de 200
alertas e mais 60 dashboards para o monitoramento do sistema da Telex. Alguns são
apresentados a seguir.
31
4.4.1 – Alerta: Espaço em disco
Como já foi dito anteriormente, os servidores da Telex têm como sistema
operacional o Windows Server, que apresenta um log de dados que serve para registrar
todos os eventos ocorridos no sistema, sejam eles informações de uso de memória, de
disco, de CPU e muitas outras. Elas servem para reconstruir os estados passados da
máquina e permitem o diagnóstico de problemas. Os arquivos de log de todos os
servidores da Telex são encaminhados para os servidores do Splunk para análise. A
frequência de ingestão dessas informações ocorre a cada três minutos.
Um dos alertas criados é o de espaço em disco. Este alerta verifica se a
porcentagem de espaço livre nos servidores é inferior a 15%. Ele possui uma pesquisa em
SPL que verifica a cada três minutos os dados do log do Windows de todos os servidores.
Caso algum deles atinja o espaço livre em memória inferior a 15%, o alerta é disparado e
um e-mail é enviado aos responsáveis da Telex. Veja a pesquisa do alerta a seguir:
1 index="performance" source="discologico" counter="% Free Space"
2 | stats avg(Value) as Valor by host
3 | eval Valor = round(Valor,2)
4 | where Valor < 15
5 | table host Valor
6 | rename host as Servidor, Valor as “% Espaço Livre”
Todos os dados de log são armazenados no índice “performance”. Os dados
referentes às informações de disco lógico são categorizados no source “discologico”. Um
dos campos presentes no arquivo de log é o counter, que descreve qual informação está
disponível no campo Value. Neste caso, o counter “% Free Space” representa a
porcentagem de espaço livre em disco. A segunda linha da pesquisa calcula a média desta
porcentagem por host (servidor) para o intervalo de tempo de dados configurado no alerta
e nomeia esta variável de “Valor”. Na terceira linha, o campo “Valor” é arredondado para
duas casas decimais. Na quarta linha, os resultados são filtrados para exibir somente os
que contiverem porcentagem inferior a 15. Na linha cinco, uma tabela é formada com as
colunas “host” e “Valor”. Na última linha, o campo “host” é renomeado para “Servidor”
e o campo “Valor” para “% Espaço Livre”. Um exemplo de um e-mail enviado após um
disparo deste alerta é mostrado na figura 11.
32
Figura 11 – E-mail enviado após disparo do alerta de espaço em disco
A falta de espaço em disco gera lentidões nas aplicações da Telex. Assim, graças
ao disparo deste alerta e envio do e-mail aos responsáveis, estes podem tomar
providências antes que ocorra algum problema.
4.4.2 – Alerta: Uso de CPU
O arquivo de log dos servidores também apresenta informações de uso de CPU.
Um alerta para monitorar esta variável apresenta a seguinte pesquisa em SPL:
1 index="performance" source="processador" counter="% Processor Time"
2 | stats avg(Value) as Valor by host
3 | eval Valor = round(Valor,2)
4 | where Valor > 90
5 | table host Valor
6 | rename host as Servidor, Valor as “% Uso de CPU”
No mesmo índice de “performance” são inseridos os dados relativos ao
processador. Nesta pesquisa o counter “% Processor Time” é usado, pois apresenta os
valores de porcentagem de uso da CPU. Há um filtro na pesquisa que seleciona somente
os eventos cuja porcentagem seja superior a 90%. Este alerta também envia um e-mail
caso a pesquisa retorne algum resultado. O e-mail é mostrado na figura 12.
Figura 12 – E-mail enviado após disparo do alerta de uso de CPU
33
4.4.3 – Dashboard: Infraestrutura
Para o monitoramento geral da infraestrutura do sistema, um dashboard foi criado
e é mostrado na figura 13.
Figura 13 – Dashboard de Infraestrutura
Os servidores da Telex foram agrupados em camadas dependendo de sua função,
com o objetivo de identificar mais facilmente qual parte do sistema poderia ser afetada
caso um dos indicadores apresentasse valores alarmantes.
Neste dashboard, o total de servidores é exibido por camada. Ele presenta a
quantidade de servidores ativos, e se as médias de uso de CPU, memória e disco estão
dentro dos intervalos para um bom funcionamento. Caso um desses indicadores ultrapasse
o limite da normalidade, o semáforo fica vermelho.
Com a criação deste dashboard, a Telex passou a identificar imediatamente os
problemas relacionados à infraestrutura de seu sistema, podendo então tomar medidas
antes de sofrer maiores impactos.
4.4.4 – Dashboard: Técnicos – Informações Mobile
Todos os técnicos da Telex apresentam um aplicativo para celular para terem
acesso às informações necessárias para a execução de suas tarefas, tais como uma agenda
com seus horários com agendamento, endereço e contato dos clientes, passo a passo de
cada procedimento que fazem, entre outras. Para o bom funcionamento da aplicação, é
necessário que os técnicos permaneçam conectados (“logados”) para poderem receber
34
atualizações de informações, além de esvaziar diariamente a memória cache de seus
aparelhos.
Figura 14 – Dashboard dos Técnicos e informações mobile
Para ter controle da proporção de técnicos que realizam as boas práticas, parte do
dashboard de informações mobile é mostrado na figura 14.
4.4.5 – Alerta: Visitas Improdutivas
Cada visita agendada de um técnico apresenta um status. As visitas podem ser
categorizadas como “Sucesso”, caso o técnico tenha conseguido fazer as instalações ou
reparos previstos, ou como “Improdutivas”, caso contrário. Os possíveis problemas para
uma visita improdutiva são pendências do técnico, tais como falta de material, pendências
do cliente (como estar ausente no dia do agendamento ou não possuir um telefone fixo ou
uma televisão no dia da instalação dos serviços), e cancelamento de agendamento.
Um alerta diário foi criado para o monitoramento destas métricas. Parte do e-mail
enviado pelo alerta pode ser visto na figura 15.
35
Figura 15 – E-mail de monitoramento de visitas improdutivas
4.4.6 – Dashboard: Mapa – Atribuições de Técnicos
Toda noite, após o agendamento de visitas ao longo do dia, o sistema faz a
atribuição de técnicos aos agendamentos. Para isto, ele verifica as opções de técnicos que
trabalham na região correspondente ao endereço do bilhete de atendimento, examina
marcações em regiões próximas e atribui os atendimentos aos técnicos de forma
otimizada.
O legado não é perfeito, então pode ocorrer de ter tarefas sem técnico designado
e técnicos com horários sem atendimento. Isto que faz com que a Telex tenha mão de obra
ociosa mesmo tendo atendimentos cujo técnico não foi atribuído pelo sistema.
Um dashboard com um mapa (figura 16) exibe a porcentagem de visitas não
atribuídas por estado. Um valor muito elevado deste indicador alarma a necessidade de
uma intervenção pela Telex. Para solucionar este problema, os bilhetes de atendimento
são alterados manualmente por um funcionário, que atribui técnicos aos agendamentos.
As regiões também são divididas em setores de atendimento. Neste mesmo
dashboard, há um gráfico de barras que mostra a quantidade de setores com porcentagem
de atribuição muito baixa por estado. Assim fica mais fácil identificar quais áreas poderão
ser afetadas por falhas de agendamento.
36
Figura 16 – Dashboard de atribuição de técnicos aos agendamentos
37
Capítulo 5
Conclusão
Com a implementação do Splunk Enterprise para a análise dos dados gerados pelo
sistema de agendamento de bilhetes de atendimento da Telex, a empresa conseguiu fazer
um melhor monitoramento dos dados de sua aplicação. O uso da ferramenta auxiliou sua
tomada de decisão, trazendo um alto retorno sobre investimento.
Estatísticas apontam que esta solução fez com que a Telex diminuísse em 80% a
utilização dos discos de seus servidores e reduzisse seu consumo de recursos em cerca de
40%.
Conclui-se então, que a escolha da ferramenta Splunk Enterprise para a resolução
do problema de Big Data da Telex, assim como seu uso foram pertinentes.
38
Referências
[1] HILBERT, Martin; LÓPEZ, Priscila. "The World's Technological Capacity to Store,
Communicate, and Compute Information". Science v. 332, n. 6025, pp. 60–65, Abril
2011.
[2] JAGADISH, H.V.; GEHRKE,Johannes; LABRINIDIS, Alexandros;
PAPAKONSTANTINOU, Yannis; PATEL, Jignish; RAMAKRISHNAN, Raghu;
SHAHABI, Cyrus. "Exploring the inherent technical challenges in realizing the
potential of Big Data", Communications of the ACM v.57, n.7, pp. 86-94, 2014.
[3] SOMASUNDARAM, G.; SHRIVASTAVA, A; EMC Education Services,
Armazenamento e Gerenciamento de Informações: Como armazenar, gerenciar e
proteger informações digitais. 1 ed. Porto Alegre, Bookman, 2009.
[4] FLORIDI, Luciano. Semantic Conceptions of Information. The Stanford
Encyclopedia of Philosophy, 2005. Disponível em:
<https://plato.stanford.edu/archives/spr2017/entries/information-semantic/>. Acessado
em 02/09/2017.
[5] RATHINASAMY, Shankar, Unstructured Data: Growth and Challenges. 1 ed.
EMC², 2015.
[6] RUSSOM, Philip. BI Search and text analytics - New Additions to the BI
Technology Stack. The Data Warehousing Institute, 2007. Disponível em: <
http://download.101com.com/pub/tdwi/Files/TDWI_RRQ207_lo.pdf >. Acessado em:
03/09/2017.
[7] DEUTSCH, A., Semistructured data and XML. Penn DB Engineering, 1998.
Disponível em <http://db.cis.upenn.edu/research/SS_XML.html>. Acessado em:
03/09/2017.
[8] MELLO, Ronaldo; et al. Dados Semi-Estruturados. Instituto de Matemática e
Estatística, 2017. Disponível em: <https://www.ime.usp.br/~jef/semi-estruturado.pdf>.
Acessado em: 03/09/2017.
39
[9] W3SCHOOLS. XML example. Disponível em:
<https://www.w3schools.com/xml/simple.xml>. Acessado em 03/09/2017.
[10] ROUSE, Margaret. Database (DB). Techtarget, 2017. Disponível em:
<http://searchsqlserver.techtarget.com/definition/database>. Acessado em: 07/09/2017.
[11] E. F. Codd. 1970. “A relational model of data for large shared data banks”.
Commun. ACM v. 13, n. 6, pp. 377-387, junho 1970.
[12] ELMASRI, Ramez; NAVATHE, Shamkant. Fundamentals of Database Systems.6
ed. Boston, Addison-Wesley, 2011.
[13] GRAY, Jim. The Transaction Concept: Virtues and Limitations. Azure, 1981.
Disponível em: < http://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf >.
Acessado em: 16/01/2018.
[14] HARRISON, Guy. Next Generation Databases: NoSQL, NewSQL, and Big
Data. 1 ed. New York, Apress, 2015.
[15] FOWLER, Adam. NoSQL For Dummies. 1 ed. New Jersey, John Wiley & Sons,
2015.
[16] EVELSON, Boris. Topic Overview: Business Intelligence. Forrester, 2008.
Disponível em
<https://www.forrester.com/report/Topic+Overview+Business+Intelligence/-/E-
RES39218>. Acessado em: 16/01/2018.
[17] DAVENPORT, Thomas. Big Data at Work. 1 ed. Boston, Harvard Business
School Publishing, 2014.
[18] FOGLI, John; HERKENHOFF Linda. Analytics Boot Camp: Basic Analytics for
Business Students and Professionals. 1 ed. New York, Business Expert Press, 2017.
[19] SNIJDERS, C.; MATZAT, U.; REIPS, U. Big Data: Big gaps of knowledge in the
field of Internet. International Journal of Internet Science, 2012. Disponível em:
<http://www.ijis.net/ijis7_1/ijis7_1_editorial.pdf>.
40
[20] INFRAGISTICS. Big Data and the Internet of Things. Infragistics, 2015.
Disponível em:
<https://www.infragistics.com/community/blogs/b/mobileman/posts/big-data-and-the-
internet-of-things>. Acessado em 24/01/2018.
[21] LEBOEUF, Kelly. What happens in an Internet minute?. Excelacom, 2016.
Disponível em <http://www.excelacom.com/resources/blog/2016-update-what-happens-
in-one-internet-minute>. Acessado em 25/01/2018.
[22] SWOYER, Steve. You Still Need a Model! Data Modeling for Big Data and
NoSQL. The Data Warehousing Institute, 2017. Disponível em:
<https://tdwi.org/articles/2017/03/22/data-modeling-for-big-data-and-nosql.aspx>.
Acessado em 30/01/2018.
[23] SPLUNK, Splunk Documentation. Splunk, 2018. Disponível em:
<docs.splunk.com>. Acessado em 02/2018.
[24] SPLUNK, Using Splunk 6.3. 1 ed. Splunk, 2016.
[25] SPLUNK, About clusters. Splunk Documentation, 2017. Disponível em:
<http://docs.splunk.com/Documentation/Splunk/7.0.2/Indexer/Aboutclusters>.
Acessado em 01/03/2018.
[26] SPLUNK, Eval command. Splunk Documentation, 2017. Disponível em: <
http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Eval >. Acessado
em 28/02/2018.
[27] SPLUNK, Stats command. Splunk Documentation, 2017. Disponível em: <
http://docs.splunk.com/Documentation/Splunk/7.0.2/SearchReference/Stats>. Acessado
em 28/02/2018.
[28] SPLUNK, Commands by category. Splunk Documentation, 2017. Disponível em:
<http://docs.splunk.com/Documentation/Splunk/7.0.2/SearchReference/Commandsbyca
tegory>. Acessado em 28/02/2018.
[29] CARASSO, David. Exploring Splunk. 1 ed. New York, CITO Research, 2012.
41
[30] SPLUNK, SplunkBase. Splunk, 2018. Disponível em:
<https://splunkbase.splunk.com>. Acessado em: 20/02/2018.
[31] OPSERVICES, Entenda a importância dos dashboards para as empresas de
tecnologia. OPServices, 2015. Disponível em:
<https://www.opservices.com.br/dashboards-empresas-de-tecnologia/>. Acessado em:
20/02/2018.
top related