Solr
  1. Solr
  2. SOLR-6233

Provide basic command line tools for checking Solr status and health.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.10, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      As part of the start script development work SOLR-3617, example restructuring SOLR-3619, and the overall curb appeal work SOLR-4430, I'd like to have an option on the SystemInfoHandler that gives a shorter, well formatted JSON synopsis of essential information. I know "essential" is vague but right now using curl to http://host:port/solr/admin/info/system?wt=json gives too much information when I just want a synopsis of a Solr server.

      Maybe something like &overview=true?

      Result would be:

      {
        "address": "http://localhost:8983/solr",
        "mode": "solrcloud",
        "zookeeper": "localhost:2181/foo",
        "uptime": "2 days, 3 hours, 4 minutes, 5 seconds",
        "version": "5.0-SNAPSHOT",
        "status": "healthy",
        "memory": "4.2g of 6g"
      }
      

      Now of course, one may argue all this information can be easily parsed from the JSON but consider cross-platform command-line tools that don't have immediate access to a JSON parser, such as the bin/solr start script.

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          Maybe something like &overview=true?

          better: &details=false, (default is true)

          Side question...

          Now of course, one may argue all this information can be easily parsed from the JSON but consider cross-platform command-line tools that don't have immediate access to a JSON parser, such as the bin/solr start script.

          would it make more sense for these cross-platform command-line tools to exec java to do things like fetch these details & process them? then you can leverage the cross-platform nature of java to do more heavy lifting and minimize the worry about quirks in the implementation details of the more complex script language features.

          Show
          Hoss Man added a comment - Maybe something like &overview=true? better: &details=false, (default is true) Side question... Now of course, one may argue all this information can be easily parsed from the JSON but consider cross-platform command-line tools that don't have immediate access to a JSON parser, such as the bin/solr start script. would it make more sense for these cross-platform command-line tools to exec java to do things like fetch these details & process them? then you can leverage the cross-platform nature of java to do more heavy lifting and minimize the worry about quirks in the implementation details of the more complex script language features.
          Hide
          Timothy Potter added a comment -

          would it make more sense for these cross-platform command-line tools to exec java to do things like fetch these details & process them? then you can leverage the cross-platform nature of java to do more heavy lifting and minimize the worry about quirks in the implementation details of the more complex script language features.

          Great suggestion I've been thinking about contributing the SolrCloudTools code from the scale-scale-toolkit project (see: https://github.com/LucidWorks/solr-scale-tk/blob/master/src/main/java/com/lucidworks/SolrCloudTools.java) to serve just that purpose. Of course we'd need to rename it to SolrTools but having the full power of Java at our disposal from the start script seems like a better long-term solution vs. one-offs like what I proposed in this ticket. The Tools code serves two purposes: 1) a set of built-in tools such as healthcheck and 2) a framework for building out custom tools that are launched / managed in a consistent fashion.

          Show
          Timothy Potter added a comment - would it make more sense for these cross-platform command-line tools to exec java to do things like fetch these details & process them? then you can leverage the cross-platform nature of java to do more heavy lifting and minimize the worry about quirks in the implementation details of the more complex script language features. Great suggestion I've been thinking about contributing the SolrCloudTools code from the scale-scale-toolkit project (see: https://github.com/LucidWorks/solr-scale-tk/blob/master/src/main/java/com/lucidworks/SolrCloudTools.java ) to serve just that purpose. Of course we'd need to rename it to SolrTools but having the full power of Java at our disposal from the start script seems like a better long-term solution vs. one-offs like what I proposed in this ticket. The Tools code serves two purposes: 1) a set of built-in tools such as healthcheck and 2) a framework for building out custom tools that are launched / managed in a consistent fashion.
          Hide
          Mark Miller added a comment -

          The best thing about using Java beyond having to have an extensive unix and windows script is that it's much easier to add to our unit tests, which is an important step if we want to have these scripts as first class. We can get a lot of milage from the release checking scripts as well I think, but much nicer to have a heavily unit tested chunk of java code.

          Show
          Mark Miller added a comment - The best thing about using Java beyond having to have an extensive unix and windows script is that it's much easier to add to our unit tests, which is an important step if we want to have these scripts as first class. We can get a lot of milage from the release checking scripts as well I think, but much nicer to have a heavily unit tested chunk of java code.
          Hide
          Otis Gospodnetic added a comment - - edited

          Please consider adding a non-JSON format that's easier for grepping, piping, etc. See http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cat.html

          Show
          Otis Gospodnetic added a comment - - edited Please consider adding a non-JSON format that's easier for grepping, piping, etc. See http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cat.html
          Hide
          Timothy Potter added a comment -

          I'm starting on this as part of the effort for SOLR-3617 (some of the things I'm trying to do with the start script needs this)

          Show
          Timothy Potter added a comment - I'm starting on this as part of the effort for SOLR-3617 (some of the things I'm trying to do with the start script needs this)
          Hide
          ASF subversion and git services added a comment -

          Commit 1616256 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1616256 ]

          SOLR-6233: Basic implementation of a command-line application for checking status of Solr and running a healthcheck for a collection; intended to be used with bin/solr script.

          Show
          ASF subversion and git services added a comment - Commit 1616256 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1616256 ] SOLR-6233 : Basic implementation of a command-line application for checking status of Solr and running a healthcheck for a collection; intended to be used with bin/solr script.
          Hide
          ASF subversion and git services added a comment -

          Commit 1619482 from Timothy Potter in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1619482 ]

          SOLR-6233: Provide basic command line tools for checking Solr status and health.

          Show
          ASF subversion and git services added a comment - Commit 1619482 from Timothy Potter in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1619482 ] SOLR-6233 : Provide basic command line tools for checking Solr status and health.
          Hide
          ASF subversion and git services added a comment -

          Commit 1619491 from Timothy Potter in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1619491 ]

          SOLR-6233: backport SolrCLI (needed by bin/solr scripts) into the 4.10 branch

          Show
          ASF subversion and git services added a comment - Commit 1619491 from Timothy Potter in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1619491 ] SOLR-6233 : backport SolrCLI (needed by bin/solr scripts) into the 4.10 branch
          Hide
          ASF subversion and git services added a comment -

          Commit 1619494 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1619494 ]

          SOLR-6233: Add to 4.10 section of CHANGES

          Show
          ASF subversion and git services added a comment - Commit 1619494 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1619494 ] SOLR-6233 : Add to 4.10 section of CHANGES
          Hide
          Steve Davids added a comment -

          I was looking over some of the command line tools (extremely useful), and refactored some of the code to make it a little more readable.

          Show
          Steve Davids added a comment - I was looking over some of the command line tools (extremely useful), and refactored some of the code to make it a little more readable.
          Hide
          Timothy Potter added a comment -

          Nice Steve, thanks! much better - I'll get this committed to trunk later tonight

          Show
          Timothy Potter added a comment - Nice Steve, thanks! much better - I'll get this committed to trunk later tonight
          Hide
          Steve Davids added a comment -

          One other note, it looks like you created your own Json parser to provide an xpath-like experience, there is a library that I have used before which is great named JsonPath (https://code.google.com/p/json-path/). Not sure if this specific class warrants bringing in that package but if we start seeing a higher need for similar mechanisms we may want to consider pulling it in since it does provide a much readable experience.

          Show
          Steve Davids added a comment - One other note, it looks like you created your own Json parser to provide an xpath-like experience, there is a library that I have used before which is great named JsonPath ( https://code.google.com/p/json-path/ ). Not sure if this specific class warrants bringing in that package but if we start seeing a higher need for similar mechanisms we may want to consider pulling it in since it does provide a much readable experience.
          Hide
          ASF subversion and git services added a comment -

          Commit 1626802 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1626802 ]

          SOLR-6233: Minor refactorings provided by Steve Davids.

          Show
          ASF subversion and git services added a comment - Commit 1626802 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1626802 ] SOLR-6233 : Minor refactorings provided by Steve Davids.
          Hide
          ASF subversion and git services added a comment -

          Commit 1626824 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1626824 ]

          SOLR-6233: Minor refactorings provided by Steve Davids.

          Show
          ASF subversion and git services added a comment - Commit 1626824 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1626824 ] SOLR-6233 : Minor refactorings provided by Steve Davids.

            People

            • Assignee:
              Timothy Potter
              Reporter:
              Timothy Potter
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development