ElasticSearch Server pára aleatoriamente o trabalho

6

Eu tenho 2 servidores ES sendo alimentados por 1 servidor logstash e visualizando os logs em Kibana. Este é um POC para resolver quaisquer problemas antes de entrar em produção. O sistema funcionou por ~ 1 mês e a cada poucos dias, o Kibana irá parar de mostrar logs em algum momento aleatório no meio da noite. Ontem à noite, a última entrada de log que recebi em Kibana foi por volta das 18:30. Quando eu chequei nos servidores ES, ele mostrava o mestre rodando e o secundário não rodando (do status / sbin / service elasticsearch), mas eu consegui fazer uma curva no localhost e ele retornou a informação. Então não tenho certeza o que está acontecendo com isso. De qualquer forma, quando eu faço um status no nó mestre, eu entendo isso:

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
{
  "cluster_name" : "gis-elasticsearch",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 6,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 186,
  "active_shards" : 194,
  "relocating_shards" : 0,
  "initializing_shards" : 7,
  "unassigned_shards" : 249
}

Quando eu vejo os índices, através de "ls ... nós / 0 / indeces /" ele mostra todos os índices que estão sendo modificados hoje por algum motivo e há novos arquivos para a data de hoje.Então eu acho que estou começando a pegar backup depois que eu reiniciei os dois servidores, mas não tenho certeza por que ele falhou em primeiro lugar. Quando olho para os logs do mestre, só vejo quatro erros de aviso às 18:57 e depois o segundo sai do cluster. Eu não vejo nenhum registro no secundário (Pistola) sobre por que ele parou de funcionar ou o que realmente aconteceu.

[2014-03-06 18:57:04,121][WARN ][transport                ] [ElasticSearch Server1] Transport response handler not found of id [64147630]
[2014-03-06 18:57:04,124][WARN ][transport                ] [ElasticSearch Server1] Transport response handler not found of id [64147717]
[2014-03-06 18:57:04,124][WARN ][transport                ] [ElasticSearch Server1] Transport response handler not found of id [64147718]
[2014-03-06 18:57:04,124][WARN ][transport                ] [ElasticSearch Server1] Transport response handler not found of id [64147721]

[2014-03-06 19:56:08,467][INFO ][cluster.service ] [ElasticSearch Server1] removed {[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.1.1.10:9301]]{client=true, data=false},}, reason: zen-disco-node_failed([Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.13.3.46:9301]]{client=true, data=false}), reason failed to ping, tried [3] times, each with maximum [30s] timeout [2014-03-06 19:56:12,304][INFO ][cluster.service ] [ElasticSearch Server1] added {[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.1.1.10:9301]]{client=true, data=false},}, reason: zen-disco-receive(join from node[[Pistol][sIAMHNj6TMCmrMJGW7u97A][inet[/10.13.3.46:9301]]{client=true, data=false}])

Alguma ideia de registro ou solução de problemas adicionais que eu possa ativar para evitar que isso aconteça no futuro? Como os shards não são capturados, agora estou vendo muito mensagens de depuração que não foram analisadas. Suponho que isso será corrigido assim que as detectarmos.

[2014-03-07 10:06:52,235][DEBUG][action.search.type ] [ElasticSearch Server1] All shards failed for phase: [query] [2014-03-07 10:06:52,223][DEBUG][action.search.type ] [ElasticSearch Server1] [windows-2014.03.07][3], node[W6aEFbimR5G712ddG_G5yQ], [P], s[STARTED]: Failed to execute [org.elasticsearch.action.search.SearchRequest@74ecbbc6] lastShard [true] org.elasticsearch.search.SearchParseException: [windows-2014.03.07][3]: from[-1],size[-1]: Parse Failure [Failed to parse source [{"facets":{"0":{"date_histogram":{"field":"@timestamp","interval":"10m"},"global":true,"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"(ASA AND Deny)"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1394118412373,"to":"now"}}}]}}}}}}}},"size":0}]]

    
por Eric 10.03.2014 / 13:19

1 resposta

2

Suspeitos comuns para ES com Kibana são:

  • * Quantidade muito pequena de memória disponível para o ES ** (que você pode investigar com qualquer sistema de detecção, como o Marvel, ou algo que enviará dados da JVM para fora da VM para monitoramento)
  • Durações longas do GC (ative o log do GC e veja se eles não acontecem quando o ES parar de responder)

Além disso, a configuração "usual" para ES é 3 servidores para permitir melhor redundância quando um servidor está inativo. Mas YMMV.

Você também pode tentar o novo coletor de lixo G1 , que tem (no meu caso) um comportamento muito melhor do que o CMS no meu Kibana ES.

O problema de duração do GC geralmente é o que acontece quando você está procurando em outro lugar e normalmente leva a uma perda de dados porque o ES pára de responder.

Boa sorte com estes:)

    
por 10.03.2014 / 17:03