Elasticsearch mati ketika Logstash mencoba menulis data


9

Saya memiliki pengaturan Raspberry Pi 2 (Raspbian terbaru pada Apr 2015) yang minggu lalu menjalankan ElasticSearch dan Logstash pada jaringan uji (bukan pengaturan yang mudah, tetapi stabil selama lebih dari seminggu!). Saya mem-boot ulang komputer saya hari ini dan mengalami kesulitan menjalankan berbagai hal; ES dan LS keduanya akan berjalan secara independen, tetapi ketika saya mencoba untuk mendorong output LS ke ES contoh ES mati tanpa penjelasan. Tujuan saya adalah menjalankan dan memompa data LS ke ES melalui plugin output standar.

ElasticSearch [v1.5.0]

Saya percaya di sinilah masalah intinya. ES dapat memulai melalui service elasticsearch startdan tetap berjalan, dapat diakses melalui permintaan HTTP ke port 9200, dan semua tanda kehidupan tampak sehat. Begitu sesuatu (apa pun, sejauh yang saya tahu) mencoba menulis data ke indeks, proses mati dan debug log @ / var / log / elasticsearch / * tidak mengandung apa pun yang terkait dengan kegagalan layanan. Saya sudah mencoba memasukkan melalui logstash (lihat di bawah) dan juga dengan curl, yang keduanya menghentikan proses ES. Perintah curl yang saya jalankan adalah curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ \"type\" : \"specialRecord\" }".

Logstash [v1.4.2]

Saya sedang menjalankan dengan konfigurasi sederhana ini:

input {
    stdin { }
}

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

Catatan lain

Beberapa hal yang saya coba:

  • Saya sudah mencoba menaikkan level logging untuk ElasticSearch ke DEBUG / TRACE dan hasilnya sangat tidak menarik. Senang memberikan log jika itu akan membantu.

  • Saya sudah mencoba memberikan ES 256MB dan 512MB ruang heap, yang sepertinya tidak mempengaruhi apa pun. Saya juga telah melihat pemanfaatan memori selama semua ini dan kehabisan memori tampaknya tidak menjadi masalah.

  • Saya sudah mencoba menonaktifkan multicast untuk mencoba menyingkirkan sekelompok variabel jaringan tetapi itu tampaknya tidak membuat perbedaan.

  • Saya telah memastikan bahwa direktori data untuk ES memiliki banyak ruang, menulis izin, dll. ES membuat subdirektori dalam path.datadirektori ketika dimuat tetapi saya tidak percaya ada yang ditambahkan karena ketika saya memulai kembali proses ES, statistik indeks menunjukkan bahwa total # dokumen adalah nol.

Saya cukup bingung sekarang dan kecewa karena tidak ada yang saya butuhkan (atau setidaknya saya dapat menemukan) sedang dicatat. Ada ide tentang apa yang mungkin terjadi di sini?


Jika Anda tidak mendapatkan sesuatu yang berguna dari log, satu-satunya pilihan (selain mengkompilasi dari sumber dan menambahkan lebih banyak pernyataan debug) tampaknya menggunakan strace untuk menonton panggilan sistem. Itu mungkin memberi Anda petunjuk mengapa elasticsearch sedang sekarat. Untuk mengurangi volume, mulailah seperti biasa dan hentikan proses yang berjalan tepat sebelum Anda memulai penulisan.
Paul Haldane

Mengalami crash tanpa log mengingatkan saya pada masalah JNI, bukankah ada proses dump JVM ( hs_err_PID.log)? ES 1.5 menggunakan perpustakaan asli yang disebut Sigar untuk memantau, mungkin ada masalah dengan ARM Raspberry. Bisakah Anda mencoba menjalankan Sigar sendiri? Saya akan mencoba meningkatkan ke ES 1.5.2 atau ES 2.0 yang tidak menggunakan Sigar lagi.
G Quintana

Sudahkah Anda mematikan swap?
Rumbles

Elasticsearch merekomendasikan ram 8G untuk memulai. Saya pernah menjalankannya pada Raspberry Pi 3. Berhasil, tetapi Anda harus sedikit berhati-hati dengan kecepatan Anda mengirim data dan juga permintaan dapat memakan waktu.
webwurst

Jawaban:


1

Anda membutuhkan lebih banyak perangkat keras

Raspi Anda mungkin (jauh) di bawah daya untuk beban kerja Anda.

Saya sama sekali bukan ahli Elasticstack, tetapi saya telah mengaturnya dalam beberapa skenario pengujian dan untuk penggunaan produksi terbatas / ringan. Dalam pengalaman saya, sementara pengaturan awal membutuhkan sumber daya yang relatif sedikit, karena jumlah indeks tumbuh, sistem ini secara signifikan menghasilkan lebih banyak disk IO dan beban CPU.

Ini terutama terlihat setelah restart saat sistem memulihkan pecahan. Jika indeks Anda tidak terlalu besar, Anda dapat mempertimbangkan ember bulanan, bukan ember harian default, yang tampaknya membantu dalam hal ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.