Elasticsearch dies when Logstash attempts to write dataScaling Logstash (with redis/elasticsearch)Multiple...
How spaceships determine each other's mass in space?
What is Tony Stark injecting into himself in Iron Man 3?
How strong is the axiom of well-ordered choice?
Is it a Cyclops number? "Nobody" knows!
Averaging over columns while ignoring zero entries
Should I file my taxes? No income, unemployed, but paid 2k in student loan interest
I am the person who abides by rules but breaks the rules . Who am I
Unidentified signals on FT8 frequencies
An Undercover Army
Is this Paypal Github SDK reference really a dangerous site?
Does the US political system, in principle, allow for a no-party system?
How does learning spells work when leveling a multiclass character?
A vote on the Brexit backstop
How does a sound wave propagate?
Can Witch Sight see through Mirror Image?
Use Mercury as quenching liquid for swords?
Why does this boat have a landing pad? (SpaceX's GO Searcher) Any plans for propulsive capsule landings?
Why isn't P and P/poly trivially the same?
After Brexit, will the EU recognize British passports that are valid for more than ten years?
PTIJ: Sport in the Torah
If nine coins are tossed, what is the probability that the number of heads is even?
Was this cameo in Captain Marvel computer generated?
Tool for measuring readability of English text
Why does a car's steering wheel get lighter with increasing speed
Elasticsearch dies when Logstash attempts to write data
Scaling Logstash (with redis/elasticsearch)Multiple instances of Logstash + Elasticsearch on AWSOutput Logstash to Elasticsearch clusterLogstash tcp input not passed to elasticsearchlogstash doesn't create index in elasticsearchLogstash/elasticsearch stops accepting new dataElasticsearch Cluster ConfigurationInfo sent from Logstash via elastic output not showing in Kibana, but file output works fine - what am I doing wrong?Simplest upgrade data from ElasticSearch 2 to ElasticSearch 6?Logstash losing connection to Elasticsearch nodes
I've got a Raspberry Pi 2 (latest Raspbian as of Apr 2015) setup that last week was running both ElasticSearch and Logstash on a test network (not a straightforward setup, but it was stable for over a week!). I rebooted my machine today and have been having a really hard time getting things running again; ES and LS will both run independently, but when I try to push LS output into ES the ES instance dies without explanation. My goal is to get both running and LS pumping data into ES via the standard output plugin.
ElasticSearch [v1.5.0]
I believe this is where the core problem is. ES can start up via service elasticsearch start
and remains running, is accessible via HTTP requests to port 9200, and all signs of life seem healthy. As soon as something (anything, as far as I can tell) tries to write data to an index, the process dies and debug logs @ /var/log/elasticsearch/* don't contain anything related to service failure. I've tried inserting via logstash (see below) as well as with curl, both of which terminate the ES process. The curl command I'm running is curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ "type" : "specialRecord" }"
.
Logstash [v1.4.2]
I'm currently running with this simple config:
input {
stdin { }
}
output {
stdout { codec => rubydebug }
elasticsearch {
host => '127.0.0.1'
cluster => 'elasticsearch'
}
}
Other notes
Some things I've tried:
I've tried cranking up logging levels for ElasticSearch to DEBUG /
TRACE and the output is remarkably uninteresting. Happy to provide
logs if it'd be helpful.I've tried giving ES 256MB and 512MB of heap
space, which doesn't seem to affect anything. I've also watched
memory utilization during all of this and running out of memory
doesn't appear to be a problem.I've tried disabling multicast to try
to weed out a bunch of networking variables but that didn't seem to
make a difference.I've ensured that the data directory for ES has
plenty of space, write permissions, etc. ES creates subdirectories in
thepath.data
directory when it's loaded but I don't believe
anything is added since when I restart the ES process the index stats
suggest that the total # of documents is zero.
I'm pretty stumped now and disappointed that nothing I need (or at least am able to find) is being logged. Any ideas on what might be going on here?
elasticsearch logstash
add a comment |
I've got a Raspberry Pi 2 (latest Raspbian as of Apr 2015) setup that last week was running both ElasticSearch and Logstash on a test network (not a straightforward setup, but it was stable for over a week!). I rebooted my machine today and have been having a really hard time getting things running again; ES and LS will both run independently, but when I try to push LS output into ES the ES instance dies without explanation. My goal is to get both running and LS pumping data into ES via the standard output plugin.
ElasticSearch [v1.5.0]
I believe this is where the core problem is. ES can start up via service elasticsearch start
and remains running, is accessible via HTTP requests to port 9200, and all signs of life seem healthy. As soon as something (anything, as far as I can tell) tries to write data to an index, the process dies and debug logs @ /var/log/elasticsearch/* don't contain anything related to service failure. I've tried inserting via logstash (see below) as well as with curl, both of which terminate the ES process. The curl command I'm running is curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ "type" : "specialRecord" }"
.
Logstash [v1.4.2]
I'm currently running with this simple config:
input {
stdin { }
}
output {
stdout { codec => rubydebug }
elasticsearch {
host => '127.0.0.1'
cluster => 'elasticsearch'
}
}
Other notes
Some things I've tried:
I've tried cranking up logging levels for ElasticSearch to DEBUG /
TRACE and the output is remarkably uninteresting. Happy to provide
logs if it'd be helpful.I've tried giving ES 256MB and 512MB of heap
space, which doesn't seem to affect anything. I've also watched
memory utilization during all of this and running out of memory
doesn't appear to be a problem.I've tried disabling multicast to try
to weed out a bunch of networking variables but that didn't seem to
make a difference.I've ensured that the data directory for ES has
plenty of space, write permissions, etc. ES creates subdirectories in
thepath.data
directory when it's loaded but I don't believe
anything is added since when I restart the ES process the index stats
suggest that the total # of documents is zero.
I'm pretty stumped now and disappointed that nothing I need (or at least am able to find) is being logged. Any ideas on what might be going on here?
elasticsearch logstash
If you're not getting anything useful from the logs the the only option (other than compiling from source and adding more debug statements) seems to be using strace to watch system calls. That might give you a hint as to why elasticsearch is dying. To reduce volume, start as normal and then strace the running process just before you initiate the write.
– Paul Haldane
Apr 6 '15 at 11:28
Having a crash without any logs reminds me of JNI problems, isn't there a JVM process dump (hs_err_PID.log
)? ES 1.5 uses a native library called Sigar for monitoring, it may have problem with Raspberry's ARM. Could you try to run Sigar by itself? I would try to upgrade to ES 1.5.2 or ES 2.0 which doesn't use Sigar anymore.
– G Quintana
Nov 3 '15 at 10:48
Have you turned off swap?
– Rumbles
Feb 13 '17 at 22:47
add a comment |
I've got a Raspberry Pi 2 (latest Raspbian as of Apr 2015) setup that last week was running both ElasticSearch and Logstash on a test network (not a straightforward setup, but it was stable for over a week!). I rebooted my machine today and have been having a really hard time getting things running again; ES and LS will both run independently, but when I try to push LS output into ES the ES instance dies without explanation. My goal is to get both running and LS pumping data into ES via the standard output plugin.
ElasticSearch [v1.5.0]
I believe this is where the core problem is. ES can start up via service elasticsearch start
and remains running, is accessible via HTTP requests to port 9200, and all signs of life seem healthy. As soon as something (anything, as far as I can tell) tries to write data to an index, the process dies and debug logs @ /var/log/elasticsearch/* don't contain anything related to service failure. I've tried inserting via logstash (see below) as well as with curl, both of which terminate the ES process. The curl command I'm running is curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ "type" : "specialRecord" }"
.
Logstash [v1.4.2]
I'm currently running with this simple config:
input {
stdin { }
}
output {
stdout { codec => rubydebug }
elasticsearch {
host => '127.0.0.1'
cluster => 'elasticsearch'
}
}
Other notes
Some things I've tried:
I've tried cranking up logging levels for ElasticSearch to DEBUG /
TRACE and the output is remarkably uninteresting. Happy to provide
logs if it'd be helpful.I've tried giving ES 256MB and 512MB of heap
space, which doesn't seem to affect anything. I've also watched
memory utilization during all of this and running out of memory
doesn't appear to be a problem.I've tried disabling multicast to try
to weed out a bunch of networking variables but that didn't seem to
make a difference.I've ensured that the data directory for ES has
plenty of space, write permissions, etc. ES creates subdirectories in
thepath.data
directory when it's loaded but I don't believe
anything is added since when I restart the ES process the index stats
suggest that the total # of documents is zero.
I'm pretty stumped now and disappointed that nothing I need (or at least am able to find) is being logged. Any ideas on what might be going on here?
elasticsearch logstash
I've got a Raspberry Pi 2 (latest Raspbian as of Apr 2015) setup that last week was running both ElasticSearch and Logstash on a test network (not a straightforward setup, but it was stable for over a week!). I rebooted my machine today and have been having a really hard time getting things running again; ES and LS will both run independently, but when I try to push LS output into ES the ES instance dies without explanation. My goal is to get both running and LS pumping data into ES via the standard output plugin.
ElasticSearch [v1.5.0]
I believe this is where the core problem is. ES can start up via service elasticsearch start
and remains running, is accessible via HTTP requests to port 9200, and all signs of life seem healthy. As soon as something (anything, as far as I can tell) tries to write data to an index, the process dies and debug logs @ /var/log/elasticsearch/* don't contain anything related to service failure. I've tried inserting via logstash (see below) as well as with curl, both of which terminate the ES process. The curl command I'm running is curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ "type" : "specialRecord" }"
.
Logstash [v1.4.2]
I'm currently running with this simple config:
input {
stdin { }
}
output {
stdout { codec => rubydebug }
elasticsearch {
host => '127.0.0.1'
cluster => 'elasticsearch'
}
}
Other notes
Some things I've tried:
I've tried cranking up logging levels for ElasticSearch to DEBUG /
TRACE and the output is remarkably uninteresting. Happy to provide
logs if it'd be helpful.I've tried giving ES 256MB and 512MB of heap
space, which doesn't seem to affect anything. I've also watched
memory utilization during all of this and running out of memory
doesn't appear to be a problem.I've tried disabling multicast to try
to weed out a bunch of networking variables but that didn't seem to
make a difference.I've ensured that the data directory for ES has
plenty of space, write permissions, etc. ES creates subdirectories in
thepath.data
directory when it's loaded but I don't believe
anything is added since when I restart the ES process the index stats
suggest that the total # of documents is zero.
I'm pretty stumped now and disappointed that nothing I need (or at least am able to find) is being logged. Any ideas on what might be going on here?
elasticsearch logstash
elasticsearch logstash
asked Apr 5 '15 at 23:46
SalisSalis
1484
1484
If you're not getting anything useful from the logs the the only option (other than compiling from source and adding more debug statements) seems to be using strace to watch system calls. That might give you a hint as to why elasticsearch is dying. To reduce volume, start as normal and then strace the running process just before you initiate the write.
– Paul Haldane
Apr 6 '15 at 11:28
Having a crash without any logs reminds me of JNI problems, isn't there a JVM process dump (hs_err_PID.log
)? ES 1.5 uses a native library called Sigar for monitoring, it may have problem with Raspberry's ARM. Could you try to run Sigar by itself? I would try to upgrade to ES 1.5.2 or ES 2.0 which doesn't use Sigar anymore.
– G Quintana
Nov 3 '15 at 10:48
Have you turned off swap?
– Rumbles
Feb 13 '17 at 22:47
add a comment |
If you're not getting anything useful from the logs the the only option (other than compiling from source and adding more debug statements) seems to be using strace to watch system calls. That might give you a hint as to why elasticsearch is dying. To reduce volume, start as normal and then strace the running process just before you initiate the write.
– Paul Haldane
Apr 6 '15 at 11:28
Having a crash without any logs reminds me of JNI problems, isn't there a JVM process dump (hs_err_PID.log
)? ES 1.5 uses a native library called Sigar for monitoring, it may have problem with Raspberry's ARM. Could you try to run Sigar by itself? I would try to upgrade to ES 1.5.2 or ES 2.0 which doesn't use Sigar anymore.
– G Quintana
Nov 3 '15 at 10:48
Have you turned off swap?
– Rumbles
Feb 13 '17 at 22:47
If you're not getting anything useful from the logs the the only option (other than compiling from source and adding more debug statements) seems to be using strace to watch system calls. That might give you a hint as to why elasticsearch is dying. To reduce volume, start as normal and then strace the running process just before you initiate the write.
– Paul Haldane
Apr 6 '15 at 11:28
If you're not getting anything useful from the logs the the only option (other than compiling from source and adding more debug statements) seems to be using strace to watch system calls. That might give you a hint as to why elasticsearch is dying. To reduce volume, start as normal and then strace the running process just before you initiate the write.
– Paul Haldane
Apr 6 '15 at 11:28
Having a crash without any logs reminds me of JNI problems, isn't there a JVM process dump (
hs_err_PID.log
)? ES 1.5 uses a native library called Sigar for monitoring, it may have problem with Raspberry's ARM. Could you try to run Sigar by itself? I would try to upgrade to ES 1.5.2 or ES 2.0 which doesn't use Sigar anymore.– G Quintana
Nov 3 '15 at 10:48
Having a crash without any logs reminds me of JNI problems, isn't there a JVM process dump (
hs_err_PID.log
)? ES 1.5 uses a native library called Sigar for monitoring, it may have problem with Raspberry's ARM. Could you try to run Sigar by itself? I would try to upgrade to ES 1.5.2 or ES 2.0 which doesn't use Sigar anymore.– G Quintana
Nov 3 '15 at 10:48
Have you turned off swap?
– Rumbles
Feb 13 '17 at 22:47
Have you turned off swap?
– Rumbles
Feb 13 '17 at 22:47
add a comment |
1 Answer
1
active
oldest
votes
You need more hardware
Your raspi may be (considerably) under powered for your workload.
I'm in no way an Elasticstack expert, but I have set it up in several test scenarios and for limited/light production use. In my experience, while the initial setup requires relatively few resources, as the number of indexes grow the system generates significantly more disk IO and CPU load.
This is especially apparent after a restart while the system is recovering the shards. If your indexes are not too big, you could consider monthly buckets instead of the default daily buckets, which seems to help in this regards.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f680605%2felasticsearch-dies-when-logstash-attempts-to-write-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You need more hardware
Your raspi may be (considerably) under powered for your workload.
I'm in no way an Elasticstack expert, but I have set it up in several test scenarios and for limited/light production use. In my experience, while the initial setup requires relatively few resources, as the number of indexes grow the system generates significantly more disk IO and CPU load.
This is especially apparent after a restart while the system is recovering the shards. If your indexes are not too big, you could consider monthly buckets instead of the default daily buckets, which seems to help in this regards.
add a comment |
You need more hardware
Your raspi may be (considerably) under powered for your workload.
I'm in no way an Elasticstack expert, but I have set it up in several test scenarios and for limited/light production use. In my experience, while the initial setup requires relatively few resources, as the number of indexes grow the system generates significantly more disk IO and CPU load.
This is especially apparent after a restart while the system is recovering the shards. If your indexes are not too big, you could consider monthly buckets instead of the default daily buckets, which seems to help in this regards.
add a comment |
You need more hardware
Your raspi may be (considerably) under powered for your workload.
I'm in no way an Elasticstack expert, but I have set it up in several test scenarios and for limited/light production use. In my experience, while the initial setup requires relatively few resources, as the number of indexes grow the system generates significantly more disk IO and CPU load.
This is especially apparent after a restart while the system is recovering the shards. If your indexes are not too big, you could consider monthly buckets instead of the default daily buckets, which seems to help in this regards.
You need more hardware
Your raspi may be (considerably) under powered for your workload.
I'm in no way an Elasticstack expert, but I have set it up in several test scenarios and for limited/light production use. In my experience, while the initial setup requires relatively few resources, as the number of indexes grow the system generates significantly more disk IO and CPU load.
This is especially apparent after a restart while the system is recovering the shards. If your indexes are not too big, you could consider monthly buckets instead of the default daily buckets, which seems to help in this regards.
answered 6 mins ago
Jens EhrichJens Ehrich
43326
43326
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f680605%2felasticsearch-dies-when-logstash-attempts-to-write-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If you're not getting anything useful from the logs the the only option (other than compiling from source and adding more debug statements) seems to be using strace to watch system calls. That might give you a hint as to why elasticsearch is dying. To reduce volume, start as normal and then strace the running process just before you initiate the write.
– Paul Haldane
Apr 6 '15 at 11:28
Having a crash without any logs reminds me of JNI problems, isn't there a JVM process dump (
hs_err_PID.log
)? ES 1.5 uses a native library called Sigar for monitoring, it may have problem with Raspberry's ARM. Could you try to run Sigar by itself? I would try to upgrade to ES 1.5.2 or ES 2.0 which doesn't use Sigar anymore.– G Quintana
Nov 3 '15 at 10:48
Have you turned off swap?
– Rumbles
Feb 13 '17 at 22:47