Realizar um protótipo para validar a integração do Gerar com o ELK com a intenção de substituir as consultas via API do Zabbix.
Objetivos
Mapear quais funcionalidades mais importantes para serem substituídas, levantando assim quais métricas tem que ser expurgadas para o ElasticSearch.
Estudar e adotar medida estratégica para indexação de dados no ElasticSearch, para que dashboards do Kibana comportem-se da forma esperada, para consultas performáticas, e para expurgo de dados simples.
Validar a capacidade de transferência de dados Mysql -> Logstash -> ElasticSearch, por exemplo se ele é capaz de transferir cem mil de registros por minuto, do banco do Zabbix para o ElasticSearch, para que as base estejam sempre sincronizadas.
Verificar se informações estão íntegras e consistentes.
Montar dashboards para apresentação da POC, mostrando o que pode ser estruturado e visualizado através do kibana.
Conceitos
Zabbix
Zabbix é uma ferramenta de monitoramento de redes que oferece uma interface web para administração e exibição de dados. Ou seja, esta ferramenta coleta métricas (CPU, memória, trafego de rede, etc) vindas de qualquer tipo de equipamento que se comunique via snmp, jmx, trap entre várias outras opções. Dadas estas métricas coletadas e armazenadas para fins de histórico é possível configurar alarmes e actions sobre estas para alertar situações emergenciais, seja via e-mail, sms ou mesmo pela própria interface.
Logstash
Logstash é um ferramenta de processamento de dados, este busca informações de uma infinidade de fontes, que podem ser de um simples arquivo de log, até um banco de dados relacional. Após sua busca é possível filtrar/processar e indexa-los da forma que melhor lhe atender no ElasticSearch (obs: logstash não tem como output apenas o ElasticSearch).
Basicamente refere-se a capacidade de um sistema aumentar a sua produção total sob o aumento de carga quando os recursos (normalmente de hardware) são adicionados. Um sistema cujo desempenho aumenta com o acréscimo de hardware, proporcionalmente à capacidade acrescida, é chamado de “sistema escalável”. Existem dois tipos de escalabilidade:
Horizontal → significa adicionar mais nós ao sistema, tais como um novo computador com aplicação para clusterizar o software.EscalabilidadeHorizontal.gifEscalabilidadeHorizontal.gif
Vertical → significa adicionar recursos em um único nó do sistema, o que pode ser CPU, memória ou storage.EscalabilidadeVertical.gifEscalabilidadeVertical.gif
Banco não relacional
O movimento mais conhecido como NoSql tem como motivação resolver o problema de escalabilidade dos bancos tradicionais, pois pode ser muito caro ou/e complexo escalar um banco SQL. Diferentemente dos bancos SQL não existe um esquema forte, ou seja, a estrutura de dados é maleável e pode ser definida dinamicamente e através da própria aplicação, e isto facilita a distribuição de dados.
ElasticSearch
ElasticSearch é um servidor voltado para pesquisa de alta performance baseado no Lucene Apache. Em outras palavras é um banco de dados não relacional voltado a aplicações que utilizam buscas por string e/ou substrings com um feedback muito grande e que exigem tempo de resposta muito baixo. ElasticSearch trabalha bem na realidade de sistemas distribuídos e oferece vários recursos para facilitar seu trabalho nesse sentido. É acessível a partir da interface de serviço web RESTful e usa do JSON (JavaScript Object Notation) para operações em seus dados armazenados. Construído em Java, o que permite ElasticSearch rodar em diferentes plataformas.
Inverted index
O segredo do ElasticSearch basicamente está na forma do armazenamento dele que permite sua alta performance em buscas. Este armazenamento usa de um conceito chamado inverted index, basicamente no caso do Elastic para cada tipo string que chegar no banco ele irá separar por palavras (ou token como eles chamam) e logo após criará uma tabela na qual dirá em qual documento o tal termo aparece. Resultará em algo do tipo :
Term Doc_1 Doc_2 ------------------------------------ brown | X | X dog | X | X fox | X | X in | | X jump | X | X lazy | X | X over | X | X quick | X | X summer | | X the | X | X ------------------------------------
O modo que o inverted index irá trabalhar está diretamente relacionado com os Analysers, este será explicado na seção de características.
Kibana
Kibana é basicamente um front-end para o ElasticSearch, onde o usuário pode ter visualizações gráficas do que está chegando em seu banco, ou até mesmo aplicar métricas sobre os dados armazenados para conseguir relatórios com baixo tempo de resposta para uma considerável quantidade de dados. Para fazer a busca no Elastic o Kibana utiliza de um padrão chamado Lucene query.
Lucene query
Como o ElasticSearch é baseado no Apache Lucene, ele trabalha com um tipo de consulta chamada Lucene Query, e esta é a base fundamental para buscar informações do ElasticSearch seja pelo Kibana, Grafana ou qualquer tipo de ferramenta gráfica. Ficará o link de estudo para Lucene queries nas referências.
Enquadramento
Pesquisa Aplicada
Desafio
Desafio é conseguir centralizar todos os bancos de informação dos Zabbix que existem hoje para a gerência em um só banco (ElasticSearch neste caso), dado que não é possível ter todos equipamentos da rede em um Zabbix só pois existem mais de dez mil, e expurgar realmente todas as métricas que estão sendo coletadas para este banco alternativo sem perda de informação e garantindo integridade. Como bônus seria de grande ajuda se a ferramenta oferece-se melhor performance em busca dados, visto que temos relatórios hoje que demoram mais de 8 horas para serem gerados, e possível cruzamento de dados de gerência com negócio.
Características
Projeto Gerar - Gerência de Redes
Projeto Gerar utiliza o Zabbix como ferramenta de monitoramento da rede.
Os principais módulos do Zabbix
O zabbix tem quatro estruturas fundamentais para seu funcionamento:
Zabbix Server: Administra as métricas, ou seja, recebe dados dos proxys e os armazena, além disso administra consultas de dados através da API.
Zabbix web: Interface com o usuário. Visualização de dados coletados, configurações do Zabbix e centralização.
Banco de Dados: Armazena todas as informações de configuração do Zabbix, inclusive todos os dados coletados do monitoramento e o histórico. (este banco pode ser Postgre, Mysql ou Oracle).
Zabbix proxy: O Zabbix proxy coleta as informações de uma parte do parque monitorado e repassa para o Zabbix server.
Detalhe importante é que cada Zabbix tem apenas um banco de dados, um server, e pode ter vários proxys.
No cenário atual existem mais de dez mil equipamentos para serem monitorados, e apenas um Zabbix não suporta tal carga, devido a quantidade de dados que chegam por segundo (mais ou menos 15 mil dados por segundo), como o Zabbix suporta apenas crescimento vertical e não horizontal foi proposta e implementada uma solução usando mais de um Zabbix para suportar toda a rede, cada estrutura Zabbix será chamado agora de zBox.
A arquitetura do projeto Gerar, conforme pode ser vista na figura acima, está dividida em duas partes: a parte inferior corresponde aos elementos responsáveis pelo monitoramento em si, enquanto que na parte superior as aplicações fazem a consolidação do monitoramento e disponibilizam interfaces para visualização e interação com a gerência.
Na arquitetura na parte inferior o monitoramento foi dividido em várias estruturas de Zabbix (zabbix server, zabbix web, banco de dados e pollers), inicialmente tem os seguintes ambientes: Ambiente Telecom, Ambiente Clientes, Ambiente Plataformas e Ambiente Gerências Proprietárias.
A solução para o crescimento horizontal consiste basicamente em: toda vez que as zBox chegarem ao seu limite de equipamentos suportados, cria-se uma nova zBox de tal forma que as integrações existentes com estas sejam capazes de automaticamente detectarem esta nova zBox sendo de um mesmo ambiente (telecom, plataformas, clientes, cloud, gerências propietárias ...) para estarem sempre sincronizadas. Para a extração centralizada de alarmes das mais de 10 zBox temos no Gerar a tela de alarmes, que através da API, busca todos os alarmes de todos ambientes, mas como a API não tem alta performance muitas vezes ocorrem falhas, por isso são disparadas cinco requisições para garantir a integridade de todos os dados na tela do Gerar.
Além do Portal Gerar, o projeto configurou uma ferramenta para extração de relatórios chamada Grafana, para a visualização de histórico e status atual das métricas coletadas no Zabbix. O Grafana não é performático para relatórios extensos, como pegar o tráfego de todas as portas da última semana de um Backbone com mil interfaces, além disso ele não consegue cruzar dados de múltiplos zBox em um gráfico só, o que pode prejudicar a visualização de alguns usuários que buscam relatórios de equipamentos agregados (como relatório de anéis). No Grafana a configuração é feita diretamente com cada Zabbix ou zBox, assim para configurar um dashboard é necessário escolher o datasource primeiro, ou seja, o zBox.
Logstash
Modo de operação
Para se usar o logstash é necessário configurar um arquivo especificando qual será o input (de onde os dados viram), filter ( opcional, tratamento e filtro de dados) e output (para onde os dados vão). Existem mais de 100 plugins de input/output e cada um conta com uma sintaxe diferente para busca de dados (ex: para busca em um banco mysql você especifica um select, já para arquivos de log você passa um regex para indicar onde começa e termina cada informação deste).
Plugin jdbc
Este plugin foi criado para buscar dados de qualquer base de dados com um interface JDBC, você pode schedular as requisições com a sintaxe de uma cron ou roda-lo apenas uma vez e carregar todos os seus dados para o Logstash. Cada linha que for buscada será tratada como um evento, e as colunas são transformadas para campos desse evento.
Modo de uso:
Para usa-lo temos que atribuir algumas variáveis de orientação fundamentais:
jdbc_driver_library : um caminho para um driver JDBC o qual será usado pelo Logstash
jdbc_driver_class: O tipo de banco que irá conectar (Mysql, Oracle, Postgree, etc...)
jdbc_connection_string: é basicamente uma URL de comunicação com o banco
jdbc_user : usuário do banco
jdbc_password(Opcional): senha do usuário se houver
schedule(Opcional): tempo em que sera executada e rexecutada a query
statement: query que será executada no banco de dados
As características gerais do ElasticSearch são as seguintes:
É escalável até petabytes de dados estruturados e não estruturados.
Usa desnormalização para melhorar o desempenho da pesquisa.
É um dos motores de busca da empresa populares, que atualmente está sendo usado por muitas grandes organizações como a Wikipedia, The Guardian, StackOverflow, GitHub etc.
É de código aberto e disponível.
Os conceitos básicos e importantes para compreensão do ElasticSearch são as seguintes:
Document - É uma coleção de campos, definida no formato JSON. Cada documento pertence a um type e reside dentro de um index. Cada documento está associado com um único identificador, chamado o UID.
Type/Mapping - É uma coleção de documents que compartilham um conjunto de campos comuns presentes no mesmo índice.
Index - É uma coleção de diferentes tipos de documents e propriedades do document. A escolha de um bom index influencia diretamente na performance.
Shard - Os índices são horizontalmente subdivididos em shards, ou seja posso ter um index em duas máquinas diferentes (para casos de indexes muito grandes), porém em um momento de busca, ele irá buscar em ambas as máquinas automaticamente. Tecnicamente isso significa que cada shard contém todos os metadados do document, porém não contém todos os registros.
Replicas - ElasticSearch permite que um usuário para criar réplicas de seus índexes e shards. Replicação não só ajuda a aumentar a disponibilidade de dados em caso de falha, como também melhora o desempenho da pesquisa através da realização de uma operação de busca paralela nestas réplicas.
Node - Refere-se a uma única instância em execução do ElasticSearch. Um servidor físico ou virtual pode acomodar vários nodes, dependendo da capacidade dos seus recursos físicos, como RAM, armazenamento e poder de processamento.
Cluster - É uma coleção de um ou mais nós. Cluster fornece recursos de indexação e busca coletiva em todos os nodes.
Analyzers
Analyzers é uma propriedade de cada campo de um document, essa propriedade interfere em como será estruturada a tabela do inverted index (afetando assim a busca) e no quanto de storage consumirá o ElasticSearch. O trabalho do analyser é separar uma string em substrings apartir de caracteres especiais as quais seram indexadas e/ou associadas a sinônimos, por exemplo com analyser padrão da ferramenta a string "ifInOctets[GigabitEthernet0/0]" seria dividida em "ifInOctets", "GigabitEthernet0", "0". Existem vários tipos de analysers e você mesmo pode criar o seu, assim como não é obrigado utilizar analysers nos campos, porém por default eles vem ativados, para mais informações consulte a documentação do ElasticSearch: https://www.elastic.co/guide/en/elasticsearch/guide/current/analysis-intro.html
_ALL
_All é um type que por padrão vem ativo em todos os indexes, este lhe permite fazer uma busca em todos os campos de todos os types de um index de uma vez, por exemplo: quero buscar "Pedro" em uma realidade onde existem os campos nome e usuário, em um banco relacional normalmente teríamos que fazer um 'where nome = "PEDRO" or usuário = "PEDRO"', se existissem 10 campos para a busca teria que fazer o 10 vezes a mesma expressão pra cada campo, no caso do ElasticSearch ele faz a busca em todos os campos, sem precisar passar um por um, apenas dizendo "busque isso". É importante se atentar quanto ao _ALL pois ele causa um consumo maior de storage, por isso é bom sempre analisar se sua aplicação depende mesmo ou não desta funcionalidade. Para mais informações : https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-all-field.html
Fase II - Exemplo de Caso de Negócio
Benefício para a Algar Telecom
Rapidez na produção de relatórios
Espaço do armazenamento de histórico é reduzido
Centralização de informações em um só banco
Escalabilidade Horizontal
Benefícios para o cliente
Rapidez ao conseguir informações
Conseguir cruzar informações entre diferentes fontes de dados
Informações mais precisas levando vários componentes de rede em conta de uma vez
Direcionadores chave
Melhores relatórios preveem melhor possíveis desastres futuros
Escalabilidade proporciona que a quantidade de informações cresça sem afetar performance
Cliente independente
Aumento da satisfação do cliente dada a rapidez
Redução de custo em storage
Elemento inovador
A rapidez em consultas sendo proposta juntamente com a centralização de dados de gerência e possível junção com dados de negócio.
Possíveis modelos de negócios
Imagine que proporá essa implantação na Algar Telecom. O que sugere que façamos? Por exemplo, com quantos usuários pretende testar, qual será o escopo, objetivo e resultados a serem alcançados.
Business Case
É muito comum achar casos em que o ELK é usado para armazenamento e administração de log de aplicação (Aqui dentro da empresa ja existem várias iniciativas e aplicações que utilizam, o próprio Gerar irá utilizar deste recurso futuramente), além disso também achamos alguns casos mais famosos para aplicações que dependem de busca em muitos textos como Wikipédia, Github, Facebook. Porém não achei nada parecido até então em minhas pesquisas com o que está sendo proposto, afinal é uma particularidade bem especifica do projeto gerar que precisa ser sanada.
Fase III - Protótipo orientado ao Negócio
Escopo
A POC tem o objetivo de migrar os dados dos bancos de dados do Zabbix já em produção Ips: 172.20.0.52 e 172.20.0.25, os quais são respectivamente o menor e o maior banco, utilizando o logstash com o plugin jdbc e nesta parte avaliar quantos dados ele é capaz de copiar por minuto.
Feito essa análise e migração já podemos trabalhar em cima do ElasticSearch verificando a Integridade e Consistência dos dados, e desenvolver um método para expurgo de dados esporádico, ex de 1 em 1 semana ou de 1 em 1 mês deletar os dados antigos para garantir a saúde do SO. Além disso dirigir um estudo para verificar qual será o melhor esquema de indexação para o caso do expurgo de dados do zabbix.
Com o backend preparado analisaremos se o Kibana nos atende como ferramenta de relatórios, se existe alguma ferramenta no mercado que substitua o Kibana, ou se é necessário esforço interno para o desenvolvimento de uma ferramenta que nos atenda em 100% dos casos.
Limitações
Não é possível testar as verdadeiras capacidades de busca do ElasticSearch com consultas "full" pois a máquina que tenho disponível tem apenas 8GB de ram, e devido a grande carga de dados é possível testar algumas consultas mais simples, porém estas já nos dão uma estimativa de quão potente será.
Não é possível dizer ao certo quanto de memória é necessário para o ElasticSearch no nosso caso, o recomendado é 64GB por node para manter uma performance boa sem dúvidas, porém existem alternativas como utilizar de vários shards (varias máquinas) para paralelizar a busca tornando a carga de dados menor.
PoC
A PoC consistiu em 4 partes:
Construção do arquivo de configuração do logstash
Análise de como estruturar o ElasticSearch em termos de index, campos com ou sem analyzers etc.
Análise de front-end
Análise de recursos necessários
Logstash
A primeira parte e mais importante da construção do arquivo de configuração, é fazer uma consulta boa (em termos de performance e de carga de dados) para o banco de dados, de forma que consiga se manter sincronizado com os zabbix (perceba que existe uma diferença entre sincronização e tempo real, sincronização pode ser diária, horária, já tempo real é no mesmo momento). A realidade é que no menor dos ambientes chegam aproximadamente 20 mil dados (apenas do tipo inteiro, tambem temos tipo string, float e text) em um minuto, já no maior temos aproximadamente 100 mil dados por minuto.
A primeira tentativa foi simplesmente fazer uma consulta geral cruzando as tabelas. Obviamente não da certo primeiro que nem se fizermos a consulta no banco de dados direto via sql conseguiriamos conseguiremos algo rapidamente.
A segunda tentativa foi dado um timestamp x colete todo o histórico deste ponto pra frente e mantenha sempre sincronizado a partir daí, é possível fazer? Não consegui na PoC, dado um tempo x comecei a rodar o logstash no mesmo tempo x, este começou a sincronização, porem por alguma razão ,a qual não descobri, 5 horas depois ele parou. A vantagem dessa abordagem é que uma vez sincronizado, o logstash tem um artificio que dada uma query ele sabe onde parou da ultima vez, então não ficará repetindo registros a cada execução apenas pegará novos, outro ponto é que se o zabbix cair ou o elastic/logstash, ele sempre saberá de onde parou e nunca "perderá coleta de histórico". A desvantagem é o grande payload de dados que exige recursos da máquina, e a incerteza se realmente da certo.
A terceira e última tentativa foi dado que irei ter uma execução por minuto, busque o ultimo minuto de registros. Simplesmente deu certo, dado o select que consta nos arquivos de configuração [L1] e [L2] consigo buscar em menos de um minuto o ultimo minuto de registros, assim garanto o sincronismo das bases, caso esse select executar em mais de um minuto posso ter um efeito avalanche, encavalando consultas e podendo nunca mais voltar ao sincronismo automaticamente. A vantagem é, pequeno payload, garante quase um tempo real, permite o sincronismo. Já a desvantagem é se o banco do zabbix cair, perderei as coletas daquele tempo em que ele não esteve respondendo.
ElasticSearch
A questão a respeito do ElasticSearch se divide em propriedades dos documentos e estrutura dos indexes. Primeiramente vamos abordar a questão dos indexes, o ponto é que o index, pode melhorar ou piorar a busca, facilitar ou não o expurgo temporário de dados, e por fim pode ajudar ou não na visualização gráfica pelo Kibana.
Desta forma em relação aos indexes, tivemos duas opções, na primeira o index seria o nome do equipamento, de forma que cada um teria o histórico de todos itens de um equipamento. A segunda abordagem seria o index ser a data (dia, mes e ano) em que foi feito a coleta. Ambas abordagens foram testadas e dão certo, o que difere as duas é que a primeira torna mais fácil o trabalho de visualização de informações pelo Kibana, já a segunda torna o trabalho esporádico de deleção de histórico mais fácil de ser realizado.
Quanto a propriedade dos documentos é preciso se atentar primeiramente ao quesito de analyzers. Caso deixe-os ativados temos 2 pontos negativos em nosso cenário, primeiramente ele faz com que tenhamos mais gasto de storage( falarei mais a respeito nas próximas seções), segundamente ele atrapalha a busca "concreta" da string, isso quer dizer que quando deseja-se fazer uma query buscando determinado equipamento que chama, por exemplo, "a-me-sw-teste" ele buscará por "a", "me", "sw", "teste" assim fará gráficos a respeito de cada uma das substrings e não do string em si, ou seja, ele estaria fazendo um gráfico de equipamentos que contem "sw" no nome, outro para equipamentos que tem "me" e assim por adiante, porem oque buscamos é para o equipamento em si "a-me-sw-teste", desta forma apenas desativar os analyzers já resolve nosso problema, foi feito através do arquivo [L3].
Kibana
Ao fazer as cofigurações básicas do kibana é possível observar na aba "Discover" o volume de dados os quais estão chegando em um intervalo de 30 min.
O Kibana corresponde as expectativas quanto a extração de dados para relatórios básicos e apresentação de gráficos. Porém para que seja visível como a área cliente deseja, ou que seja relacionado equipamento, ip, e coleta é necessário para cada coleta ter também no mesmo documento, equipamento, ip, interface, etc... Se formos pensar, obviamente ele gastará mais storage desta forma pois teremos um monte de informação repetida a mais ou menos cada 5 minutos (tempo minimo de coleta de um item no Zabbix para a realidade de Telecom).
Recursos
Nesse quesito devemos nos atentar principalmente em 2 pontos, primeiramente storage, qual seriam as melhores configurações para minimizar o gasto de storage? Segundo um tutorial disponibilizado pela própria empresa do elastic (o link está nas referencias) a melhor configuração para documentos é desativar analyzers, o _ALL e os doc values, isso foi feito através do arquivo [L3]. Testei ambas realidade pior e melhor caso e a diferença foi uma economia de aproximadamente 40% de storage por index. A outro fator que não consegui testar que pode influenciar também na questão do storage é a versão do ElasticSearch, quanto mais atual melhor.
Outro quesito é a memória, segundo tutorial disponibilizado pela própria empresa do elastic (o link está nas referencias) o mínimo para se garantir performance é 32gb de memória ram. Quanto a esse ponto foi apenas possível constatar que os 8gb disponibilizados na maquina em que fiz a PoC realmente não atendem em uma busca mais complexas, podendo até engargalar o elasticSearch tendo assim que reinicia-lo e assim perdendo coletas.
Extras e conclusões
Ponto principal
É possível centralizar todos os bancos de informação dos Zabbix que existem hoje para a gerência em um só banco?
Sim é possível e para isso podemos fazer de duas maneira:
a) Instalamos o conjunto ELK em uma maquina só, assim um único Logstash ficará responsável por coletar as informações das N máquinas.
b) Instalamos ELK em uma máquina X e um Logstash em cada máquina que contem banco de dados, assim ficaram N Logstash em N maquinas mandando informação para um logstash que sera responsavel apenas em estruturar a informação para o ElasticSearch. Algo desse tipo:
Particularmente gosto mais da segunda opção, pois distribui-se a carga de processamento entre as máquinas.
Quanto a expurgar realmente todas as métricas que estão sendo coletadas para este banco alternativo sem perda de informação e garantindo integridade temos um problema, pois da forma que foi feita na PoC se a conecção entre as máquinas falhar ele perderá histórico daquele momento.
Extras
Utilizando o Plugin do elasticSearch para o Grafana (front-end atual de relatorios da empresa) consegui as mesmas funcionalidades que o Kibana fornece e até mais alguns "enfeites" a mais. Porém aparentemente o Grafana tem uma tendencia de fazer o elasticSearch dar problema de memória mais fácil do que o Kibana (não descobri o por que).
Utilizando o ElasticSearch temos um aumento significativo na busca por informações, por exemplo buscar todas os dados coletados de mil equipamentos dos últimos 15 minutos em menos de 1 minuto.
É possível ter informações de negócio cruzadas com gerencia, porém meio inviável, pois teríamos que ter um arquivo de configuração para cada interface de cada equipamento.
A melhor abordagem é ter um index para info de negócio, outros para coletas, e outro para informações gerenciais do equipamento, desta forma economiza-se storage e melhora performance. Porem seria necessário o desenvolvimento de um front-end próprio para extração das informações.
Por razões vivenciadas no projeto Gerar em termos de relatórios e requisitos, na minha visão o melhor para a empresa é desenvolver um front-end próprio, customizado para suas necessidades, onde vá atender a todos, e utilizar de um back-end como o ElasticSearch com respostas rápidas, para alimentar esse front-end. Com um front-end próprio seria possível a centralização de dados de gerência e negócio gastando menos storage, com mais performance e que atenda todas as áreas.
Detalhe Técnico
Arquivos de Configuração
Logstash
Estes arquivos estavam localizados no seguinte caminho "/etc/logstash/conf.d/"
[L1]
Arquivo para expurgo de dados do menor banco de dados 172.20.0.52 (menor banco).
<source lang="c">input {
jdbc {
jdbc_connection_string => "jdbc:mysql://172.20.0.52:3306/zabbix"
jdbc_user => "logstash"
jdbc_password => "El@st1cse@rch"
jdbc_driver_library => "/etc/logstash/conf.d/mysql-connector-java-5.1.40-bin.jar"
jdbc_driver_class => "com.mysql.jdbc.Driver"
#Por default ja eh true, porem por desincargo de consciencia...
record_last_run => true
#Todo minuto roda buscando os registros do ultimo minuto
schedule => "* * * * *"
statement => "select host, ip, key_ , (clock*1000) as clock, value from interface i, items it, hosts h, (select * from history_uint where (UNIX_TIMESTAMP(NOW())-60) <= clock) hi where it.hostid = h.hostid and h.hostid = i.hostid and hi.itemid = it.itemid"
}
}
output {
#Fins de Debug
stdout {
codec => rubydebug {
metadata => true
}
}
#Saida Elastic
elasticsearch {
index => "history-%{+YYYY.MM.dd}"
document_type => "Inteiro"
template => "/etc/logstash/conf.d/map_int.json" #mapa para campos do index
template_overwrite => "true" #index dinâmico
hosts => "10.32.255.168:9200"
}
}</source>
[L2]
Arquivo para expurgo de dados do maior banco de dados 172.20.0.22 (maior banco).
<source lang="c">input {
jdbc {
jdbc_connection_string => "jdbc:mysql://172.20.0.22:3306/zabbix"
jdbc_user => "logstash"
jdbc_password => "El@st1cse@rch"
jdbc_driver_library => "/etc/logstash/conf.d/mysql-connector-java-5.1.40-bin.jar"
jdbc_driver_class => "com.mysql.jdbc.Driver"
record_last_run => true
schedule => "* * * * *"
statement => "select host, ip, key_ , (clock*1000) as clock, value from interface i, items it, hosts h, (select * from history_uint where (UNIX_TIMESTAMP(NOW())-60) <= clock) hi where it.hostid = h.hostid and h.hostid = i.hostid and hi.itemid = it.itemid"
}
Para executar esse script primeiramente é necessário a instalação do módulo do elasticsearch para o python com :
pip install elasticsearch
<source lang="python">from datetime import date
import sys
from elasticsearch import Elasticsearch
hj = date.today()
passado = date.fromordinal(hj.toordinal()-int(sys.argv[1]))
index = str(passado.year)+"."+str(passado.month)+"."+str(passado.day)
print index
es = Elasticsearch()
es.indices.delete(index='history-'+index, ignore=[400, 404])</source>
Comandos importantes
Logstash
/opt/logstash/bin/logstash -f history_int_10.conf -- starta o processo do logstash para busca de informações passando L1 como parametro de configuração para a busca)
