Mam konfigurację Raspberry Pi 2 (najnowszą wersję Raspbian z kwietnia 2015 r.), Która w zeszłym tygodniu uruchamiała zarówno ElasticSearch, jak i Logstash w sieci testowej (nie jest to prosta konfiguracja, ale była stabilna przez ponad tydzień!). Ponownie uruchomiłem komputer dzisiaj i bardzo ciężko mi było uruchomić go ponownie; ES i LS będą działać niezależnie, ale kiedy próbuję wypchnąć wyjście LS do ES, instancja ES umiera bez wyjaśnienia. Moim celem jest, aby zarówno działające, jak i LS pompowały dane do ES poprzez standardową wtyczkę wyjściową.
ElasticSearch [v1.5.0]
Uważam, że właśnie tam leży główny problem. ES może uruchomić się service elasticsearch start
i działa, jest dostępny za pośrednictwem żądań HTTP do portu 9200, a wszystkie oznaki życia wydają się zdrowe. Gdy tylko coś (cokolwiek, o ile mi wiadomo) próbuje zapisać dane do indeksu, proces umiera i dzienniki debugowania @ / var / log / elasticsearch / * nie zawierają niczego związanego z awarią usługi. Próbowałem wstawiać za pomocą logstash (patrz poniżej), a także za pomocą curl, które kończą proces ES. Uruchamiam polecenie curl curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ \"type\" : \"specialRecord\" }"
.
Logstash [v1.4.2]
Obecnie korzystam z tej prostej konfiguracji:
input {
stdin { }
}
output {
stdout { codec => rubydebug }
elasticsearch {
host => '127.0.0.1'
cluster => 'elasticsearch'
}
}
Inne notatki
Niektóre rzeczy próbowałem:
Próbowałem podkręcić poziomy rejestrowania dla ElasticSearch do DEBUG / TRACE, a wyniki są wyjątkowo nieciekawe. Z przyjemnością udostępniamy logi, jeśli byłoby to pomocne.
Próbowałem podać ES 256 MB i 512 MB miejsca na stercie, co nie wydaje się mieć żadnego wpływu. Przez cały ten czas obserwowałem też wykorzystanie pamięci i wyczerpywanie się pamięci nie wydaje się być problemem.
Próbowałem wyłączyć rozsyłanie grupowe, aby wyplenić kilka zmiennych sieciowych, ale to nie miało znaczenia.
Upewniłem się, że katalog danych dla ES ma dużo miejsca, uprawnienia do zapisu itp. ES tworzy podkatalogi w
path.data
katalogu, gdy jest załadowany, ale nie wierzę, aby coś zostało dodane, ponieważ po ponownym uruchomieniu procesu ES statystyki indeksu sugerują, że całkowita liczba dokumentów wynosi zero.
Jestem teraz bardzo zaskoczony i rozczarowany, że nic, czego potrzebuję (a przynajmniej jestem w stanie znaleźć), nie jest rejestrowane. Jakieś pomysły na to, co się tutaj dzieje?
hs_err_PID.log
)? ES 1.5 korzysta z natywnej biblioteki o nazwie Sigar do monitorowania, może mieć problem z ARM Raspberry. Czy mógłbyś spróbować uruchomić Sigar sam? Spróbowałbym zaktualizować do wersji ES 1.5.2 lub ES 2.0, która już nie używa Sigara.