Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: web gui
    • Labels:
      None

      Description

      We can show logging events in the Admin UI.

      1. SOLR-3367.png
        266 kB
        Stefan Matheis (steffkes)
      2. SOLR-3367.patch
        13 kB
        Stefan Matheis (steffkes)
      3. SOLR-3367.patch
        12 kB
        Stefan Matheis (steffkes)
      4. SOLR-3367.patch
        14 kB
        Stefan Matheis (steffkes)
      5. SOLR-3367.patch
        8 kB
        Stefan Matheis (steffkes)

        Issue Links

          Activity

          Hide
          Andreas Hubold added a comment -

          This feature is broken in Solr 4.0-BETA - at least with certain schema.xml files. See SOLR-3829.

          Show
          Andreas Hubold added a comment - This feature is broken in Solr 4.0-BETA - at least with certain schema.xml files. See SOLR-3829 .
          Hide
          Ryan McKinley added a comment -

          See SOLR-3358 for how to do this with log4j – implementing a LogBack version should be similarly straightforward

          Show
          Ryan McKinley added a comment - See SOLR-3358 for how to do this with log4j – implementing a LogBack version should be similarly straightforward
          Hide
          Antony Stubbs added a comment -

          This functionality appears to break when using LogBack instead of the default setup.. Is there a known way to make it work with logback? Looks like a cool feature.

          Show
          Antony Stubbs added a comment - This functionality appears to break when using LogBack instead of the default setup.. Is there a known way to make it work with logback? Looks like a cool feature.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Ah okay, makes sense. So, what about the following:

          If the Record contains a trace-Index, everything is great - otherwise we take the message (which in this case will contain the whole thing) and split on the first newline .. using the former part as new message and the latter as trace.

          I have to check if this works for only a few / most / or perhaps all exceptions i can get ;>

          Will create a new Ticket for this.

          Show
          Stefan Matheis (steffkes) added a comment - Ah okay, makes sense. So, what about the following: If the Record contains a trace -Index, everything is great - otherwise we take the message (which in this case will contain the whole thing) and split on the first newline .. using the former part as new message and the latter as trace . I have to check if this works for only a few / most / or perhaps all exceptions i can get ;> Will create a new Ticket for this.
          Hide
          Ryan McKinley added a comment -

          the issue is that some exceptions take the output of 'cause' exceptions and put it in the message body

          throw new RuntimeException( "error "+cause );
          

          vs

          throw new RuntimeException( "error message", cause );
          

          The UI should look OK regardless of how people create the error message, but yes keeping the cause as a trace element is much nicer. This is just an easy way to make a very long message string.

          Show
          Ryan McKinley added a comment - the issue is that some exceptions take the output of 'cause' exceptions and put it in the message body throw new RuntimeException( "error " +cause ); vs throw new RuntimeException( "error message" , cause ); The UI should look OK regardless of how people create the error message, but yes keeping the cause as a trace element is much nicer. This is just an easy way to make a very long message string.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Ah, perhaps i was not clear .. or just misunderstood your last comment?

          The Length of the Message (itself) is not really a problem .. we could either use overflow:hidden, like you're already suggesting .. or break on whitespaces - that will both work.

          My Point is about the Fact that second one contains the complete stacktrace as message-key. If we can split them, so that we have a message and a trace (like the first one) for every entry - that would be great .. but don't know if that would be possible?

          Show
          Stefan Matheis (steffkes) added a comment - Ah, perhaps i was not clear .. or just misunderstood your last comment? The Length of the Message (itself) is not really a problem .. we could either use overflow:hidden, like you're already suggesting .. or break on whitespaces - that will both work. My Point is about the Fact that second one contains the complete stacktrace as message -key. If we can split them, so that we have a message and a trace (like the first one) for every entry - that would be great .. but don't know if that would be possible?
          Hide
          Ryan McKinley added a comment -

          ya, i see the difference. Obviously it is best if we can change the messages so they are reasonably short, but this is not realistic for all error messages. (yes, we should open an issue for this specific error, but it is not an easy fix)

          Whatever format we pick should be able to support short or long messages (i think)

          Perhaps overflow:hidden? or an option to toggle overflow:hidden?

          Show
          Ryan McKinley added a comment - ya, i see the difference. Obviously it is best if we can change the messages so they are reasonably short, but this is not realistic for all error messages. (yes, we should open an issue for this specific error, but it is not an easy fix) Whatever format we pick should be able to support short or long messages (i think) Perhaps overflow:hidden? or an option to toggle overflow:hidden?
          Hide
          Stefan Matheis (steffkes) added a comment -

          Ryan, would you mind to have a look at my last comment?

          Show
          Stefan Matheis (steffkes) added a comment - Ryan, would you mind to have a look at my last comment?
          Hide
          Stefan Matheis (steffkes) added a comment -

          Hm, i think we should open another Issue for this, or do you think otherwise?

          Because, if you check the difference between:

          {
          	time: "2012-05-16T13:25:03.679Z",
          	level: "SEVERE",
          	logger: "org.apache.solr.handler.admin.LoggingHandler",
          	message: "error (with exception)",
          	trace: "java.lang.RuntimeException: test
          		at org.apache.solr.handler.admin.LoggingHandler.handleRequestBody(LoggingHandler.java:75)
          		at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
          		..."
          }

          (from /solr/admin/logging?wt=json&since=0&test=true)

          and

          {
          	time: "2012-05-16T13:26:10.722Z",
          	level: "SEVERE",
          	logger: "org.apache.solr.core.SolrCore",
          	message: "org.apache.solr.common.SolrException: Can not find: schema.not [/opt/solr-trunk/solr/example/solr/./conf/schema.not]
          		at org.apache.solr.handler.admin.ShowFileRequestHandler.showFromFileSystem(ShowFileRequestHandler.java:229)
          		at org.apache.solr.handler.admin.ShowFileRequestHandler.handleRequestBody(ShowFileRequestHandler.java:122)
          		..."
          }

          (from /solr/collection1/admin/file?file=schema.not&contentType=text/xml;charset=utf-8)

          it is pretty clear why your screen looks like what it looks *g it's just one big fat text-message, even the latest revision will not be able to display that in a good fashion.

          the difference seems to be: throwing a new exception (directly) vs. calling a log.xy(), passing a exception as parameter, but can we (and should we?) change this behaviour?

          Show
          Stefan Matheis (steffkes) added a comment - Hm, i think we should open another Issue for this, or do you think otherwise? Because, if you check the difference between: { time: "2012-05-16T13:25:03.679Z" , level: "SEVERE" , logger: "org.apache.solr.handler.admin.LoggingHandler" , message: "error (with exception)" , trace: "java.lang.RuntimeException: test at org.apache.solr.handler.admin.LoggingHandler.handleRequestBody(LoggingHandler.java:75) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) ..." } (from /solr/admin/logging?wt=json&since=0&test=true ) and { time: "2012-05-16T13:26:10.722Z" , level: "SEVERE" , logger: "org.apache.solr.core.SolrCore" , message: "org.apache.solr.common.SolrException: Can not find: schema.not [/opt/solr-trunk/solr/example/solr/./conf/schema.not] at org.apache.solr.handler.admin.ShowFileRequestHandler.showFromFileSystem(ShowFileRequestHandler.java:229) at org.apache.solr.handler.admin.ShowFileRequestHandler.handleRequestBody(ShowFileRequestHandler.java:122) ..." } (from /solr/collection1/admin/file?file=schema.not&contentType=text/xml;charset=utf-8 ) it is pretty clear why your screen looks like what it looks *g it's just one big fat text-message, even the latest revision will not be able to display that in a good fashion. the difference seems to be: throwing a new exception (directly) vs. calling a log.xy(), passing a exception as parameter, but can we (and should we?) change this behaviour?
          Hide
          Ryan McKinley added a comment -

          dooh – attached the screenshot to the wrong issue. This is what I see for errors on a small (ish) screen:

          Do you need stacktrace for this? just putting in ?test=true should get you one too

          Show
          Ryan McKinley added a comment - dooh – attached the screenshot to the wrong issue. This is what I see for errors on a small (ish) screen: Do you need stacktrace for this? just putting in ?test=true should get you one too
          Hide
          Stefan Matheis (steffkes) added a comment -

          I added the missing Icon in r1335229 - it's mentioned in the patch, but because it's a binary file, it's not fully included .

          The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide

          Hm, i played a bit around, but i didn't get such a huge stacktrace? Would you mind attaching one (as plain text), that i can check this one?

          What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible.

          Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?

          Hm, never thought about that ;o i just continued the Navigation-Logic which we used for f.e the Plugins. Will open a separate Ticket for that and start moving the Sub-Navigation for all "global" Items out to the left Panel - good idea!

          Show
          Stefan Matheis (steffkes) added a comment - I added the missing Icon in r1335229 - it's mentioned in the patch, but because it's a binary file, it's not fully included . The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide Hm, i played a bit around, but i didn't get such a huge stacktrace? Would you mind attaching one (as plain text), that i can check this one? What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible. Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core? Hm, never thought about that ;o i just continued the Navigation-Logic which we used for f.e the Plugins. Will open a separate Ticket for that and start moving the Sub-Navigation for all "global" Items out to the left Panel - good idea!
          Hide
          Ryan McKinley added a comment -

          looks like we re missing the "information-white.png"

          Show
          Ryan McKinley added a comment - looks like we re missing the "information-white.png"
          Hide
          Ryan McKinley added a comment -

          looks good stefan – i commited this in r1335204, but think we can continue making it better.

          The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide – this is why i like the colspan version better. Looking at it more, I think it would be even better if we could use the 2nd level tab space (Viewer vs Level) as well.

          What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible.

          Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?

          Show
          Ryan McKinley added a comment - looks good stefan – i commited this in r1335204, but think we can continue making it better. The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide – this is why i like the colspan version better. Looking at it more, I think it would be even better if we could use the 2nd level tab space (Viewer vs Level) as well. What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible. Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?
          Hide
          Stefan Matheis (steffkes) added a comment -

          To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it?

          I've included two Versions, one with the colspan and one without (you'll find these at lines 340-350). I like the one without colspan, because i find it easier to "follow" the list to the next row - but i'm also fine using the other one. just let me know which one we'd like to have :>

          Show
          Stefan Matheis (steffkes) added a comment - To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it? I've included two Versions, one with the colspan and one without (you'll find these at lines 340-350). I like the one without colspan, because i find it easier to "follow" the list to the next row - but i'm also fine using the other one. just let me know which one we'd like to have :>
          Hide
          Stefan Matheis (steffkes) added a comment -

          New Version, includes all Remarks

          Show
          Stefan Matheis (steffkes) added a comment - New Version, includes all Remarks
          Hide
          Ryan McKinley added a comment -

          The auto-update continues to check even when you are not on the page!

          Once I navigate away from logging page, I still see requests going to the logging handler!

          Show
          Ryan McKinley added a comment - The auto-update continues to check even when you are not on the page! Once I navigate away from logging page, I still see requests going to the logging handler!
          Hide
          Ryan McKinley added a comment -

          better – some things to consider

          • i don't think it is necessary to grey out the older events
          • rather then showing the long date form in Last Check, how about one that matches the format in the Time column
          • this patch is missing the 'logging.html' file

          What do you think about adding something like:

          Unable to find source-code formatter for language: css. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
          #content #logging #viewer thead th.message
          {
            width:100%;
          }
          

          and giving the rest more padding – this way the layout will stay consistent when you open an exception.

          To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it? Perhaps a right-aligned column/icon to show that it has a trace?

          Show
          Ryan McKinley added a comment - better – some things to consider i don't think it is necessary to grey out the older events rather then showing the long date form in Last Check, how about one that matches the format in the Time column this patch is missing the 'logging.html' file What do you think about adding something like: Unable to find source-code formatter for language: css. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml #content #logging #viewer thead th.message { width:100%; } and giving the rest more padding – this way the layout will stay consistent when you open an exception. To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it? Perhaps a right-aligned column/icon to show that it has a trace?
          Hide
          Stefan Matheis (steffkes) added a comment -

          So, how about this one?

          The Handling of Auto-Scrolling right now is a bit poor, bit i'll have a look at the jenkins-one, that is really smooth.

          Show
          Stefan Matheis (steffkes) added a comment - So, how about this one? The Handling of Auto-Scrolling right now is a bit poor, bit i'll have a look at the jenkins-one, that is really smooth.
          Hide
          Ryan McKinley added a comment -

          Great start! A few comments:

          • For ordering events – I like older events on the top and newer ones at the bottom. For Auto Refresh, just keep adding rows at the bottom. I don't think we need a "Load new Events" button – just put a spinner at the bottom and refresh every 5/10? seconds. similar to jenkins
          • rather then "~logging/config" maybe "~logging/level" since this does not really configure your logging

          I like it

          Show
          Ryan McKinley added a comment - Great start! A few comments: color scale – I don't follow the color coding scheme. I would expect something where red is severe and blue is just info. something like: http://www.mediacollege.com/lighting/colour/colour-temperature.html For ordering events – I like older events on the top and newer ones at the bottom. For Auto Refresh, just keep adding rows at the bottom. I don't think we need a "Load new Events" button – just put a spinner at the bottom and refresh every 5/10? seconds. similar to jenkins rather then "~logging/config" maybe "~logging/level" since this does not really configure your logging I like it
          Hide
          Stefan Matheis (steffkes) added a comment -

          TBD:

          • Toggle-Option for trace information
          • Color-Coding for different Levels
          • Kind of 'Auto Refresh'

          About the Auto-Refresh Option .. I'm not really sure, would we like to have that? If so, will it be enough to have it enabled/disabled (like Autoload on Schema-Browser), or is there a need for additional settings like polling-interval and things like this?

          Show
          Stefan Matheis (steffkes) added a comment - TBD: Toggle-Option for trace information Color-Coding for different Levels Kind of 'Auto Refresh' About the Auto-Refresh Option .. I'm not really sure, would we like to have that? If so, will it be enough to have it enabled/disabled (like Autoload on Schema-Browser), or is there a need for additional settings like polling-interval and things like this?
          Hide
          Stefan Matheis (steffkes) added a comment -

          First Version of the UI attached.

          TBD:

          • Toggle-Option for trace information
          • Color-Coding for different Levels
          • Kind of 'Auto Refresh'
          Show
          Stefan Matheis (steffkes) added a comment - First Version of the UI attached. TBD: Toggle-Option for trace information Color-Coding for different Levels Kind of 'Auto Refresh'
          Hide
          Ryan McKinley added a comment -

          I think it makes sense to have the logging page first show events, and only show the levels as a second step.

          In SOLR-3358, the logging events are returned as a SolrDocumentList so that we can have a unified UI if the events come from a search or the simple RAM buffer

          Show
          Ryan McKinley added a comment - I think it makes sense to have the logging page first show events, and only show the levels as a second step. In SOLR-3358 , the logging events are returned as a SolrDocumentList so that we can have a unified UI if the events come from a search or the simple RAM buffer

            People

            • Assignee:
              Stefan Matheis (steffkes)
              Reporter:
              Ryan McKinley
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development