Elasticsearch muore quando Logstash tenta di scrivere dati


9

Ho una configurazione di Raspberry Pi 2 (ultima Raspbian dell'aprile 2015) che la scorsa settimana eseguiva sia ElasticSearch che Logstash su una rete di test (non una configurazione semplice, ma era stabile per oltre una settimana!). Ho riavviato la mia macchina oggi e ho avuto davvero delle difficoltà a far funzionare di nuovo le cose; ES e LS funzioneranno in modo indipendente, ma quando provo a spingere l'uscita LS in ES l'istanza di ES muore senza spiegazioni. Il mio obiettivo è quello di ottenere sia i dati di funzionamento che quelli di pompaggio LS in ES tramite il plug-in di output standard.

ElasticSearch [v1.5.0]

Credo che questo sia il problema principale. ES può avviarsi tramite service elasticsearch starte rimane in esecuzione, è accessibile tramite richieste HTTP alla porta 9200 e tutti i segni della vita sembrano sani. Non appena qualcosa (qualsiasi cosa, per quanto posso dire) tenta di scrivere i dati in un indice, il processo si interrompe e il debug dei registri @ / var / log / elasticsearch / * non contiene nulla relativo a guasti del servizio. Ho provato a inserire tramite logstash (vedi sotto) e con arricciatura, entrambi i quali terminano il processo ES. Il comando curl che sto eseguendo è curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ \"type\" : \"specialRecord\" }".

Logstash [v1.4.2]

Attualmente sto correndo con questa semplice configurazione:

input {
    stdin { }
}

output {
        stdout { codec => rubydebug }
        elasticsearch {
                host => '127.0.0.1'
                cluster => 'elasticsearch'
        }
}

Altre note

Alcune cose che ho provato:

  • Ho provato ad aumentare i livelli di registrazione per ElasticSearch su DEBUG / TRACE e l'output è straordinariamente poco interessante. Felice di fornire i registri se sarebbe utile.

  • Ho provato a fornire ES 256 MB e 512 MB di spazio heap, che non sembra influenzare nulla. Ho anche visto l'utilizzo della memoria durante tutto questo e l'esaurimento della memoria non sembra essere un problema.

  • Ho provato a disabilitare il multicast per provare a eliminare un mucchio di variabili di rete, ma questo non sembra fare la differenza.

  • Mi sono assicurato che la directory di dati per ES disponga di molto spazio, autorizzazioni di scrittura, ecc. ES crea sottodirectory nella path.datadirectory quando viene caricata ma non credo che venga aggiunto nulla da quando riavvio il processo di ES le statistiche dell'indice suggeriscono che il numero totale di documenti è zero.

Sono piuttosto sconcertato ora e deluso dal fatto che nulla di cui ho bisogno (o almeno sono in grado di trovare) venga registrato. Qualche idea su cosa potrebbe succedere qui?


Se non stai ottenendo nulla di utile dai registri, l'unica opzione (diversa dalla compilazione dal sorgente e dall'aggiunta di più istruzioni di debug) sembra usare strace per guardare le chiamate di sistema. Ciò potrebbe darti un suggerimento sul motivo per cui elasticsearch sta morendo. Per ridurre il volume, iniziare normalmente e quindi seguire il processo in esecuzione appena prima di iniziare la scrittura.
Paul Haldane,

Avere un arresto anomalo senza alcun registro mi ricorda i problemi di JNI, non c'è un dump del processo JVM ( hs_err_PID.log)? ES 1.5 utilizza una libreria nativa chiamata Sigar per il monitoraggio, potrebbe avere problemi con ARM di Raspberry. Potresti provare a far funzionare Sigar da solo? Vorrei provare ad aggiornare a ES 1.5.2 o ES 2.0 che non usa più Sigar.
G Quintana,

Hai disattivato lo scambio?
Rumbles,

Elasticsearch consiglia di iniziare con ram 8G. Una volta l'ho eseguito su un Raspberry Pi 3. Funziona, ma devi stare un po 'attento con la velocità con cui invii i dati e anche le query possono richiedere del tempo.
webwurst

Risposte:


1

Hai bisogno di più hardware

Il tuo raspi potrebbe essere (considerevolmente) sotto tensione per il tuo carico di lavoro.

Non sono affatto un esperto di Elasticstack, ma l'ho impostato in diversi scenari di test e per un uso di produzione limitato / leggero. Nella mia esperienza, mentre la configurazione iniziale richiede relativamente poche risorse, poiché il numero di indici cresce, il sistema genera un carico significativamente maggiore di I / O su disco e CPU.

Ciò è particolarmente evidente dopo un riavvio mentre il sistema sta recuperando i frammenti. Se i tuoi indici non sono troppo grandi, potresti considerare i bucket mensili anziché i bucket giornalieri predefiniti, il che sembra aiutare a questo proposito.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.