Splunk: Monitorando o ambiente de TI – Parte 1 - Revista Infra Magazine 10

São muitos os controles e métricas que normalmente são criados para monitorar os elementos críticos que compõem o ambiente de TI de pequenas, médias e grandes empresas. Tais elementos fazem parte de um grande stack de suporte às operações de negócio: sistemas OLTP, bancos de dados, sistemas de entrada e saída de dados e aqueles de apoio e suporte à decisão.

Obviamente, esses são elementos básicos, mas ainda podemos abrir o leque ou mesmo fazer um drill-down e abordar os servidores de aplicação como o WebSphere, servidores web como o Apache e/ou Tomcat, ou ainda bancos de dados como Oracle, MySQL, SQL Server e sistemas desenvolvidos em Java, .NET e qualquer outra linguagem. Outros elementos compõem o que é tido como serviço networking, que é composto por vários outros pedaços como firewall, roteadores e switches, além dos vários servidores que são controladores de domínio, DNS, servidores de impressão e vários outros que precisam ser monitorados em tempo real para, por exemplo, saber se estão online e servindo aos funcionários.

A grande questão é que todos estes pontos têm os seus controles e, na maioria das vezes, as práticas não permitem uma análise real do que está acontecendo por debaixo de todos aqueles aparatos, uma análise completa no que diz respeito à saúde dos serviços de TI que suportam o negócio.

Na maioria das vezes, quando um problema acontece, ele passa por todos os profissionais do departamento de TI e acaba no conhecido jogo de empurra entre as áreas – isso realmente acontece. Infelizmente não existe uma ferramenta gráfica que colete a informação para que se possa fazer uma análise mais detalhada sem que essa situação aconteça.

Por causa disso, geralmente acontece o seguinte: alguém nota alguma instabilidade no ambiente e a comunica. É quando o gerente de área toma conhecimento da situação e aciona, além de pessoal interno, uma consultoria ou mesmo uma auditoria de sistemas para dar conta do problema. Nestes casos e em muitos outros, o tempo dos profissionais envolvidos na resolução reativa dos problemas toma grande parte dos recursos que a empresa poderia empregar para tornar a TI mais proativa e menos reativa. Reagir a um problema é trabalhar para colocar um sistema de volta às operações normais após um crash de algum dos elementos de TI já citados; ou seja, o problema já aconteceu e nesse momento a empresa parou de oferecer determinado serviço para o seu cliente.

Rotineiramente, o profissional precisa analisar vários logs utilizando um editor de textos, ou mesmo via terminal em tela preta, e tomar nota dos vários registros após consultar vários arquivos. Este processo de investigação de informação ou busca pela ocorrência de um evento em vários arquivos de log pode consumir muito tempo e pessoal dedicado a realizar esse tipo de trabalho, que acaba por obter um resultado mais por inferência do que algo que realmente seja uma verdade com fatos a serem exibidos. Tais arquivos de log fazem parte de um conceito que é muito discutido nos dias atuais, que é o Big Data, dados que as empresas só descobrem que possuem quando precisam acessá-los, na maioria das vezes, em momentos de downtime dos sistemas (o conceito de Big Data será discutido em uma próxima oportunidade).

No entanto, hoje as empresas já estão mais atentas em relação a estes tipos de dados, procurando utilizá-los em prol da criação ou da extração de inteligência operacional e, assim, saltar em competitividade na frente de seus concorrentes. Dessa forma, alcançam mais visibilidade nos negócios e obtêm serviços com mais uptime e com equipes mais resilientes, podendo escalar menos os problemas que ocorrem no dia a dia.

Considerando o citado cenário, vamos apresentar neste artigo uma ferramenta que está revolucionando a maneira de monitorar em tempo real a TI e os negócios e ainda relacionar os dados de máquinas (ver Nota DevMan 1) gerados por devices (routers e switches), sistemas operacionais, serviços de network e vários outros pontos com dados obtidos dos negócios.

O Splunk é uma Plataforma Universal de Dados de Máquina desenvolvida por uma empresa de nome Splunk, Inc., localizada na cidade de São Francisco, no estado da Califórnia, EUA, que fez o IPO (veja Nota DevMan 2) há pouco tempo (Abril de 2012) e que se mantém em um crescimento enorme a cada ano. O conceito do produto é fácil de entender: basta que você adicione todas as fontes de dados – como logs de aplicações/softwares, logs de segurança, de sistemas operacionais, logs de operações de billing, logs de acesso a servidor web, logs de bancos de dados, logs gerados por roteadores e/ou switches e várias outras fontes de dados, não importa onde elas estejam –, e inicie a coleta e a indexação de tal informação.

Com as fontes de dados configuradas, os dados serão indexados de forma contínua, e sobre estes dados o administrador de sistemas, DBA, analista de sistemas e/ou gestor de área poderão facilmente criar alertas e gráficos para monitoramento em tempo real dos elementos do ambiente de TI. A granularidade do monitoramento vai da necessidade dos profissionais envolvidos, pois o Splunk é capaz desde meramente monitorar um arquivo de log de forma contínua, até mesmo pesquisar toda a movimentação de um usuário por todos os elementos da TI, correlacionando os vários eventos por vários arquivos de log.

A ideia é justamente obter em minutos o que é feito normalmente em horas, baseando-se em pesquisa textual, centralização da informação e dados de máquina, sendo que ainda é possível contar com uma arquitetura de escala linear, o que veremos no próximo tópico.

Conhecendo o Splunk

O Splunk é o mecanismo de coleta, indexação e reconhecimento automático de padrões de informação considerada como dado de máquina. Dado de máquina é tudo aquilo que é gerado para manter os serviços que são oferecidos pela TI de uma organização funcionando satisfatoriamente. Qualquer arquivo de log, seja ele um log gerado por um firewall IronPort, um BlueCoat, ou mesmo um log de alerta do Oracle ou o log de erro do MySQL, ou ainda os logs de acesso e erros do Apache, todos estes também contêm dados de máquina que podem ser coletados e indexados de forma contínua pelo Splunk para fornecer análise do ambiente em tempo real. A Figura 1 mostra alguns exemplos de fontes de dados.

Figura 1. Fontes de dados.

O Splunk não utiliza conectores, não utiliza qualquer tipo de bancos de dados por trás e nem impõe limite em relação ao volume de coleta e indexação de informação, já que estamos falando de uma ferramenta de Big Data. Você não precisa se preocupar em desenvolver conectores para coletar e indexar determinados tipos de informação ou mesmo desenvolver um novo pedaço de software sempre que um novo padrão de informação chegar ao mercado. O Splunk reconhece os padrões de um arquivo de log automaticamente, faz a sua indexação e armazena a informação organizada em disco com 50% de taxa de compressão. Os dados são armazenados no formato key/value e são gerenciados pelo próprio Splunk, que desde a versão 4 tem uma versão otimizada do MapReduce (ver Nota DevMan 3) com várias melhorias em relação ao release do Google de 200

Toda informação é armazenada em buckets, que são a menor porção de dados dentro da estrutura de armazenamento de informação. Tais buckets são então amarrados a índices, que por sua vez são gerenciados e também mantidos pelo Splunk em disco. O mais interessante é que você poderá criar índices sempre que um novo tipo de informação for adicionado para ser coletado e indexado automaticamente pelo Splunk.

Os buckets podem ser ainda dos tipos hot, warm, cold e frozen (veja o subtópico a seguir). Os dados vão se movendo internamente nessa estrutura de acordo com a quantidade e a idade da informação armazenada. Tal estrutura é própria do Splunk e por isso o usuário não precisa se preocupar em ter um banco de dados para armazenar os dados coletados pela ferramenta, visto que muitas ferramentas no mercado ainda precisam ter um Oracle, SQL Server ou MySQL. No Splunk os dados vão sendo coletados e sua arquitetura acontece em tempo real, de forma que o esquema de dados é desenhado de acordo com a identificação dos padrões nos eventos dos arquivos configurados.

O Splunk coleta e indexa a informação que o usuário deseja e, assim, reconhece os padrões dentro dos eventos armazenados em arquivos de logs ou até mesmo, gerados por devices como roteadores e switches. Essa informação, considerada como dados de máquina, é coletada, indexada e armazenada pelo próprio Splunk em um conjunto de arquivos que contém essencialmente dois tipos:

· Arquivos contendo dados de máquina em forma comprimida, conhecidos também como “rawdata”;

· Arquivos de índices que apontam para os arquivos de dados – rawdata – e arquivos de metadados.

Tais arquivos juntos formam os índices no Splunk, que referenciam um determinado tipo de dado de máquina coletado/indexado e que pode ser utilizado na Search App para busca e análise. Todos os dados indexados são organizados em buckets, e estes, são classificados em cinco formas diferentes, com base na idade dos dados. São elas:

· Hot: Aqui são armazenados os eventos mais recentes. Estes buckets estão abertos para escrita e os novos dados são sempre escritos neles. Para sistemas 32 bits, hot buckets podem ter até 1GB de tamanho, ao passo que para sistemas 64 bits, podem ter até 10GB de tamanho antes que virem Warm buckets. Por padrão, os hot buckets podem ser encontrados em $SPLUNK_HOME/var/lib/splunk/defaultdb/db/*. Tal localização pode ser configurada para que cada tipo de bucket seja armazenado em um disco separado, o que é considerada uma boa prática. Caso um Hot bucket não atinja 1/10GB, em 90 dias ele será migrado para Warm com base na sua idade;

· Warm: Dentro deste tipo de informação estão todos os dados que pertencem a buckets maiores que 1/10GB que passaram do estágio de Hot para Warm, processo reconhecido como “rolled data”. A cada bucket que é migrado do estágio Hot para o Warm, um novo diretório é criado (em uma instalação padrão) em $SPLUNK_HOME/var/lib/splunk/defaultdb/db/*, seguindo uma convenção especial de nomenclatura. Uma instalação padrão do Splunk poderá contar com até 300 Warm buckets. Quando for criado o Warm bucket número 301, o mais antigo bucket deste estágio será migrado para Cold;

· Cold: Armazena os buckets que foram migrados de Warm, sendo que podem chegar até 500 GB antes de serem migrados para Frozen. O aspecto da idade dos dados também está presente neste estágio, sendo que, quando determinados buckets atingirem seis anos, eles serão migrados para Frozen;

· Frozen: por padrão, o Splunk exclui permanentemente todos os buckets de dados que são migrados de Cold para Frozen; os dados são removidos do índice nesse momento. Caso seja necessário arquivar os dados que são movidos para este estágio, edite o arquivo indexes.conf localizado em $SPLUNK_HOME/etc/system/default e configure o parâmetro coldToFrozenDir para arquivar os novos Frozen buckets, como exibido na Listagem 1.

Listagem 1. Editando o arquivo inputs.conf para configurar o coldToFrozen.

# edição do arquivo $SPLUNK_HOME/etc/system/default/inputs.conf
  [<nome_índice>]</nome_índice>
  coldToFrozenDir = “/frozenPartition”

Também no arquivo indexes.conf, utilize o parâmetro coldToFrozenScript para executar um script que normalmente é chamado para fazer o arquivamento dos dados e alguma outra tarefa que pode ser executada por meio de scripts, o que dá a possibilidade de utilizar a criatividade de forma livre. Veja como fazer esta configuração na Listagem 2.

Listagem 2. Adicionando a parâmetro coldToFrozenScript ao arquivo inputs.conf.

# edição do arquivo $SPLUNK_HOME/etc/system/default/inputs.conf
  [<nome_índice>]</nome_índice>
  coldToFrozenScript = [$SPLUNK_HOME/bin/] “coldToFrozenExample.py”

Por padrão, o script especificado na Listagem 2, chamado coldToFrozenExample.py, está pronto para ser utilizado e está localizado em $SPLUNK_HOME/bin. O parâmetro coldToFrozenDir tem precedência sobre o coldToFrozenScript, portanto cuidado ao colocar as duas funcionalidades ao mesmo tempo;

· Thawed: Se o usuário traduzir para o Português a palavra Thawed, vai perceber algo até engraçado e que, nesse contexto, faz todo sentido. Literalmente, este estágio trata do descongelamento dos dados ou buckets que foram congelados, ou seja, antes de serem arquivados, eles estavam em um formato de Frozen buckets e agora serão posicionados no diretório de Thawed buckets, localizado em $SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb. Após colocar os Frozen buckets como “descongelados” no diretório citado, eles podem ficar lá o tempo que for necessário, e quando não os quiser mais, basta excluí-los. Uma boa estratégia é criar um script para mover os Frozen buckets para Thawed buckets e eliminá-los de acordo com uma política defendida em um script no nível do SO.

Por padrão, o Splunk realizará buscas somente nos Hot/Warm/Cold buckets, uma vez que os Frozen buckets são excluídos por padrão. O usuário poderá ainda arquivar os Frozen buckets em um disco para fazer o seu restore, caso seja necessário. O comportamento ou política para que buckets sejam considerados antigos e assim passem de um estágio para outro, ou mesmo, as práticas de arquivamento de Frozen buckets, poderão ser reconfigurados de acordo com os interesses da organização por meio do arquivo indexes.conf. Neste arquivo, o administrador do Splunk especificará variáveis para configuração de políticas de retenção de eventos indexados. Veja mais sobre o assunto em http://tinyurl.com/aatf2gr.

Cada evento é indexado a partir do seu timestamp e as partes que compõem o evento são identificadas e adicionadas abaixo de estruturas denominadas fields. Os fields são estruturas que nomeiam a informação identificada em meio aos eventos e que podem ser utilizados para efetuar buscas por meio do aplicativo padrão do Splunk, a Search App. Neste aplicativo, ou no aplicativo de busca, é onde o usuário poderá escrever suas próprias consultas para extrair a informação mais valiosa para sua organização, aquela que responde a perguntas estratégicas.

A Search App é considerada como o Google do lado interno da sua organização, pois com ela você pode buscar por termos como “error” ou “fail” e tem a possibilidade de percorrer todos os logs adicionados ao Splunk e saber exatamente o que está acontecendo com a sua TI. Além disso, o Splunk possui uma linguagem própria de consulta aos dados de máquina indexados denominada SPL, ou Search Processing Language.

Além de armazenar os dados sem precisar de um banco de dados, não necessitar de conectores, lidar com qualquer volume de dados e ainda possuir um aplicativo que possibilita manipular dados com uma linguagem própria, o Splunk possibilita que o usuário crie os seus próprios relatórios baseados em vários tipos de gráficos (column, line, area, bar, pie, scatter, radial, filter e marker), que podem ser criados a partir da Search App e assim serem salvos em um painel que poderá conter vários gráficos relacionados com um departamento específico. Além dos gráficos, alertas sobre consulta a dados também podem ser criados e dentro destes alertas, o usuário poderá definir o envio de e-mails e a execução de scripts para realizar ilimitadas ações de correção para um problema identificado.

Com isso, o Splunk entrega o que tem defendido como sua missão, que é “tornar os dados de máquina acessíveis, utilizáveis e valorizados por todos”. Com apenas quatro passos, você conseguirá extrair informação inteligente de um emaranhado de dados, nos quais, a olhos nus, o usuário ou uma equipe não teria tanta facilidade em fazer. Os quatros passos são:

1. Configurar a fonte de dados;

2. Consultar a informação com a Search App;

3. Criar relatórios com vários tipos de gráficos;

4. Criar alertas sobre a informação retornada pelas consultas.

O Splunk ainda oferece a facilidade de poder facilmente ser integrado com vários outros sistemas. Um exemplo é a integração que pode ser feita com sistemas de controle de SLA (Service Level Agreement ou Acordo de Nível de Serviço), para determinar quais tickets estão para vencer, quais já venceram e quão efetivo é o departamento em não deixar SLAs vencerem. Integrar o Splunk com portais de e-commerce também é uma tarefa simples. O administrador de sistemas poderia facilmente saber quais produtos estão sendo abandonados no carrinho de compras, ou até mesmo o tempo de entrega de uma requisição de usuário, correlacionando logs de Apache, WebSphere e MySQL.

Os sistemas operacionais suportados são os seguintes:

· Solaris 9, 10 (x86, SPARC);

· Linux Kernel versão 2.6.x e superiores (x86: 32 e 64-bit);

· FreeBSD 6.1 (x86: 32-bit), 6.2, 7.x, 8.x (x86: 32 e 64-bit);

· Windows Server 2003/2003 R2;

· Windows Server 2008/2008 R2;

· Windows XP (32-bit);

· Windows Vista (32-bit, 64-bit);

· Windows 7 (32-bit, 64-bit);

· Mac OS X 10.5 e 10.6;

· AIX 5.2, 5.3, e 6.1;

· HP-UX.

Além disso, o Splunk tem como característica ser escalável desde o seu laptop até máquinas maiores em um Data Center. Sendo assim, o administrador Splunk poderá iniciar os testes em laptops e depois migrar aquele ambiente para máquinas maiores. Uma ressalva interessante é que a empresa não precisará adotar máquinas muito grandes para rodar o Splunk, já que o produto tem escalabilidade horizontal ou linear, ou seja, pode operar bem com várias máquinas pequenas (hardware commodity). E é aí que entram alguns novos conceitos: as três funções básicas do Splunk, que é a de coletar, indexar e consultar dados de máquina, funções estas que podem ser facilmente divididas entre várias máquinas.

A máquina que servirá para busca de informação (utilizando a Search App) passará a ser chamada de Search Head; as máquinas que recebem as informações e as armazenam em disco passam a ser chamadas de Indexers; e aquelas que enviam as informações para os Indexers passam a contar com um pequeno agente, que é um software Splunk denominado Universal Forwarder. Este Universal Forwarder, ou somente Forwarder, coletará a informação de interesse nas máquinas onde rodam, por exemplo, o Apache, o Linux e o Oracle, e enviará aquelas informações para os Indexers para serem indexadas e, assim, estarem disponíveis para os Search Heads, onde o usuário entra com as consultas (ufa!). Para vermos melhor como funciona essa arquitetura, observe a Figura 2.

Figura 2. Splunk em três camadas, dividindo funções.

Para fazer a instalação do Splunk é necessário acessar o site splunk.com e fazer um pequeno cadastro. Assim, além de fazer o download de acordo com a sua plataforma, o usuário já contará com um perfil para acessar o fórum oficial de usuários Splunk, conhecido por Splunk Answers, e também baixar aplicativos no Splunkbase, onde a própria Splunk disponibiliza vários aplicativos desenvolvidos por eles e também aplicativos de terceiros (uma boa oportunidade para quem deseja vender aplicativos para Splunk).

Tais aplicativos podem ser baixados de dentro da sua instalação do Splunk e são como inteligência empacotada para resolver determinado problema de monitoramento. Com um aplicativo, ou somente “app”, como são chamados, o usuário conseguirá monitorar um IronPort, BigIP e servidores Unix/Linux e Windows em 10 minutos. Saiba mais detalhes sobre a documentação do Splunk na Nota DevMan 4.

Conclusão

Neste artigo vimos algumas características do funcionamento do Splunk, que é uma plataforma universal de dados de máquina que possibilita que a organização não só aprenda mais com os dados que já possui, como com os dados que produz no dia a dia de suas operações. Uma vez coletados os dados, o Splunk os armazenará em disco, em buckets, como vimos, e utilizará mecanismos de indexação destes dados para que informações sejam recuperadas com muita rapidez e facilidade. A partir de tais dados armazenados, será possível utilizar a Search App para então consolidar relatórios e gráficos para que os membros de cada time dos vários departamentos de uma empresa possam acompanhar a operação em tempo real, o que é o mais interessante.

No próximo artigo, você terá a oportunidade de aprofundar um pouco mais no Splunk, ao realizarmos uma exploração mais prática passando pelos principais tópicos como coleta de informação, análise, consulta e implementação de relatórios e gráficos.