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













9















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
    the path.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?










share|improve this question























  • 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
















9















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
    the path.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?










share|improve this question























  • 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














9












9








9


2






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
    the path.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?










share|improve this question














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
    the path.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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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



















  • 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










1 Answer
1






active

oldest

votes


















0














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.





share























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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.





    share




























      0














      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.





      share


























        0












        0








        0







        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.





        share













        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.






        share











        share


        share










        answered 6 mins ago









        Jens EhrichJens Ehrich

        43326




        43326






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            As a Security Precaution, the user account has been locked The Next CEO of Stack OverflowMS...

            Список ссавців Італії Природоохоронні статуси | Список |...

            Українські прізвища Зміст Історичні відомості |...