Eu configurei uma nova prova de conceito do sistema logstash
CentOS 6.6 (on Vmware 5.5) - single CPU VM with 12G RAM allocated
Elasticsearch e Logstash instalados a partir de RPMs…
# rpm -q elasticsearch logstash
elasticsearch-1.7.1-1.noarch
logstash-1.5.3-1.noarch
JVM: 1.8.0_51
Os dados que estou alimentando são registros simples do formulário…
M1234 z123 2015-01-31 23:28:09.417 8.55373
(os campos são nome da máquina, ID do usuário, data, hora, hora de logon - tudo é simples US-ASCII)
Configuração do Logstash abaixo (esses dados são provenientes de um banco de dados MSSQL e, no momento, estou exportando para o arquivo de texto e transferindo o arquivo para o servidor logstash).
Isso funcionou bem para um dia inteiro de logs (registros de 11K), mas quando tento processar o backlog a partir desse ano, ele "trava".
Os sintomas disso são
- o elasticsearch ainda é responsivo - as pesquisas e o acesso à configuração ainda são excelentes
- o número de documentos nos índices pára de subir
- o sistema torna-se essencial inativo - apenas a atividade do disco em segundo plano e o uso mínimo da CPU
- se eu tentar parar o processo logstash (que ainda está em execução), ele só morrerá com
kill -9 .
Isso parece acontecer em cerca de 200 mil documentos. Não é afetado pelo número de índices - comecei com índices diários e depois mudei para semanal - ele ainda para em torno de 200 mil documentos.
Como essa é uma prova de conceito em execução em uma única máquina, reduzi a contagem de réplicas para 0 e os shards para 1 - não acho que isso deva fazer alguma diferença para esse problema.
Não vejo nenhum erro nos logs logstash ou elasticsearch, apesar de ter tornado a verbosidade em ambos.
Eu não acho que o sistema esteja ficando sem memória, espaço em disco, descritores de arquivos.
Não sei mais o que ver. Isso parece um problema trivial (para a ELK) e não vejo esse problema em uma configuração existente da ELK que lida com nossos logs de e-mail (embora isso esteja executando versões anteriores e tenha vários nós de armazenamento elasticsearch)
Embora eu tenha certeza de que não há sequências de byte ímpar nos arquivos de entrada, eu declarei explicitamente a entrada como US_ASCII com charset => "US-ASCII" na sub-rotina do plugin file input. Não espero que isso faça alguma diferença (o teste ainda está em execução).
Atualização: Embora não houvesse nada de interessante nos logs quando a importação parou, as linhas registradas quando logstash foi solicitado a desligar foram interessantes…
{:timestamp=>"2015-08-03T10:17:39.104000+0100", :message=>["INFLIGHT_EVENTS_REPORT", "2015-08-03T10:17:39+01:00", {"input_to_filter"=>20, "filter_to_output"=>0, "outputs"=>[]}], :level=>:warn}
Implica em mim que o problema está no estágio de filtragem e não na saída para elasticsearch . Confirmei isso primeiro livrando-se da saída elasticsearch e tendo apenas stdout . Isso mostrou o mesmo comportamento - importou depois de um tempo.
Colocar a saída elasticsearch de volta, mas limpar tudo na seção filter me deu uma importação de dados completa e bem-sucedida.
Agora eu tenho uma correção para isso - detalhes em resposta.
input {
file {
path => "/var/lib/clusters/*"
type => "clusterF"
start_position => "beginning"
}
}
filter {
mutate {
remove_field => [ "path", "host" ]
}
# 13COMP014 nabcteam 2015-07-29 11:09:21.353 153.493
if [type] == "clusterF" {
grok {
match => { "message" => "%{NOTSPACE:client} +%{WORD:userid} +%{TIMESTAMP_ISO8601:datestamp} +%{BASE10NUM:elapsed:float}" }
}
}
if [elapsed] < 0 {
drop {}
}
if [elapsed] > 1000.0 {
drop {}
}
if [userid] =~ "[a-z][0-9]{7}" {
mutate {
add_field => [ "userClass", "student" ]
}
} else if [userid] =~ "n[a-z].*" {
mutate {
add_field => [ "userClass", "staff" ]
}
} else {
mutate {
add_field => [ "userClass", "other" ]
}
}
date {
match => [ "datestamp", "ISO8601" ]
}
mutate {
remove_field => [ "message" ]
}
}
output {
elasticsearch {
bind_host => "clog01.ncl.ac.uk"
protocol => "http"
cluster => "elasticsearch"
flush_size => 10
index => "clusters-%{+xxxx.ww}"
}
}