<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I forgot to mention that I chatted with David late last night and he pointed out cases where applications dump multiline data that makes parsing records impossible.</div><div><br></div><div>He also brought up a problem with expression based file names, that could make it not possible to reverse rolling logs.</div><div><br></div><div>We did come up with several potential solutions but we really need to nail the use cases first.</div><div><br></div><div>The download/view case could be done securely and address the rolling expression problem by making the feature more of a file browser that is locked into a set of directories. By default we would allow browsing into the log directories.&nbsp;</div><div><br>On Aug 15, 2013, at 6:45 PM, "James R. Perkins" &lt;<a href="mailto:jperkins@redhat.com">jperkins@redhat.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  
    <br>
    <div class="moz-cite-prefix">On 08/15/2013 03:27 PM, Harald Pehl
      wrote:<br>
    </div>
    <blockquote cite="mid:E217DAD3-204A-4C2C-85B1-8E378EBFCBC8@redhat.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>I agree that we should focus on the most important use cases:</div>
      <div>- Not able / not like to sshing into the server to look at
        the logs</div>
      <div>- Deployment failed and you want to know why (staying in the
        console)</div>
      <div><br>
      </div>
      <div>As for the console I would suggest to start with a very
        limited set of features. No filtering, just&nbsp;show the last n log
        entries, where n is specified as part of the &nbsp;management
        operation.&nbsp;At first the user would see the last n log entries
        and can navigate further backwards in n-steps.&nbsp;For all deeper
        analysis the user should be able to download the full log.&nbsp;When
        showing the log to the user, I can think of some kind of syntax
        highlighting (see&nbsp;<a moz-do-not-send="true" href="http://www.gnu.org/software/src-highlite/error.log.html">http://www.gnu.org/software/src-highlite/error.log.html</a>&nbsp;for
        an example).</div>
    </blockquote>
    The problem here is we don't know the last n entries if we read a
    file. We can read back the last n bytes or possibly lines, but that
    could contain portions of a stack trace.<br>
    <blockquote cite="mid:E217DAD3-204A-4C2C-85B1-8E378EBFCBC8@redhat.com" type="cite">
      <div><br>
      </div>
      <div>That said there are however use cases where parsing /
        filtering makes sense. The audit log has a well defined format (<a moz-do-not-send="true" href="https://docs.jboss.org/author/display/WFLY8/Audit+logging#Auditlogging-JSONFormatter">https://docs.jboss.org/author/display/WFLY8/Audit+logging#Auditlogging-JSONFormatter</a>)
        and in the current implementation I'm using a master / detail
        view to display the audit log items.</div>
    </blockquote>
    This might be a little easier for audit-logging since we have more
    control over what's happening. I have to look at the code, but we
    might just want to always write a formatted file in addition to
    other types like the syslog.<br>
    <blockquote cite="mid:E217DAD3-204A-4C2C-85B1-8E378EBFCBC8@redhat.com" type="cite">
      <div><br>
      </div>
      <div>.: Harald</div>
      <div><br>
      </div>
      <div>---&nbsp;</div>
      <div apple-content-edited="true">
        <div style="color: rgb(0, 0, 0); font-family: Helvetica;
          font-size: medium; font-style: normal; font-variant: normal;
          font-weight: normal; letter-spacing: normal; line-height:
          normal; orphans: 2; text-align: -webkit-auto; text-indent:
          0px; text-transform: none; white-space: normal; widows: 2;
          word-spacing: 0px; -webkit-text-size-adjust: auto;
          -webkit-text-stroke-width: 0px; word-wrap: break-word;
          -webkit-nbsp-mode: space; -webkit-line-break:
          after-white-space; ">Harald Pehl</div>
        <div style="color: rgb(0, 0, 0); font-family: Helvetica;
          font-size: medium; font-style: normal; font-variant: normal;
          font-weight: normal; letter-spacing: normal; line-height:
          normal; orphans: 2; text-align: -webkit-auto; text-indent:
          0px; text-transform: none; white-space: normal; widows: 2;
          word-spacing: 0px; -webkit-text-size-adjust: auto;
          -webkit-text-stroke-width: 0px; word-wrap: break-word;
          -webkit-nbsp-mode: space; -webkit-line-break:
          after-white-space; ">JBoss by Red Hat<br>
          <div><a moz-do-not-send="true" href="http://hpehl.info">http://hpehl.info</a></div>
          <div><br>
          </div>
        </div>
        <br class="Apple-interchange-newline">
        <br class="Apple-interchange-newline">
      </div>
      <br>
      <div>
        <div>Am 15.08.2013 um 03:11 schrieb <a moz-do-not-send="true" href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">On 8/14/2013 5:20 PM, Brian Stansberry
          wrote:<br>
          <blockquote type="cite">Agreed. IMHO this is the most
            important driver for this feature.<br>
            <br>
            On 8/14/13 3:44 PM, James R. Perkins wrote:<br>
            <blockquote type="cite">Just to add too in a domain it would
              be nice to have a central spot to<br>
              view logs instead of having to ssh into various servers.<br>
            </blockquote>
          </blockquote>
          Also realize that in many shops you don't have the option to
          ssh into<br>
          various servers. &nbsp;If they are serious about security then
          access to the<br>
          console is likely to be the only access you have.<br>
          <br>
          <blockquote type="cite">
            <blockquote type="cite"><br>
              On 08/14/2013 12:56 PM, Jason Greene wrote:<br>
              <blockquote type="cite">Mainly convenience. You deploy
                something it fails, you want to look at the log but
                don't feel like sshing into the server. As to
                performance the cost would be on request, and not more
                expensive then looking at the log file via ssh.<br>
                <br>
                On Aug 14, 2013, at 2:24 PM, Scott Marlow &lt;<a moz-do-not-send="true" href="mailto:smarlow@redhat.com">smarlow@redhat.com</a>&gt;
                wrote:<br>
                <br>
                <blockquote type="cite">What are the use cases for
                  online reading of the server logs? &nbsp;If there<br>
                  are problems occurring on the application server (e.g.
                  perhaps the cpu<br>
                  is pegged), reading logs online, could make the system
                  even less<br>
                  responsive.<br>
                  <br>
                  If we just want to read the server logs as part of a
                  health check, not<br>
                  requiring the server console to be working would be
                  better.<br>
                  <br>
                  Should the reading of the logs instead be an external
                  capability?<br>
                  Perhaps using the logs from the JBoss/WildFly
                  Diagnostic Reporter output<br>
                  (archive) or some other archived copy of logs.<br>
                  <br>
                  Another compromise, add the WildFly Diagnostic
                  Reporter (or at least the<br>
                  log collection part) to the management console (output
                  archive is<br>
                  downloaded for local viewing).<br>
                  <br>
                  On 08/14/2013 01:03 PM, James R. Perkins wrote:<br>
                  <blockquote type="cite">I had posted this to another
                    list, but this is a more appropriate place<br>
                    for it. I think there needs to be a general
                    discussion around this as<br>
                    it's been mentioned, at least to me, a few times
                    here and there and I<br>
                    know Heiko raised the issue some time a go now.<br>
                    <br>
                    The original JIRA, WFLY-280[1], is to display the
                    last 10 error messages<br>
                    only. To be honest I wouldn't find that very useful.
                    To me if I'm<br>
                    looking for logs I want to see all logs, but that's
                    not always so easy.<br>
                    Like the syslog-handler which doesn't log to a file
                    so there is no way<br>
                    to read those messages back.<br>
                    <br>
                    The current plan for the last 10 error messages is
                    we store messages in<br>
                    a queue that can be accessed via an operation. This
                    works fine until the<br>
                    error message you're interested in is 11 or you want
                    to see warning<br>
                    messages.<br>
                    <br>
                    Another option I had come up with is reading back
                    the contents of the<br>
                    file, for example the server.log. This could be
                    problematic too in that<br>
                    there is no way to filter information like only see
                    error messages or<br>
                    only see warning messages. To solve this I have
                    considered creating a<br>
                    JSON formatter so the results could be queried, but
                    I don't think it<br>
                    should be a default which would mean it's not
                    reliable for the console<br>
                    to assume it's getting back JSON.<br>
                    <br>
                    I've also thought about, haven't tested this and it
                    may not work at all,<br>
                    creating a handler that uses websockets to send
                    messages. I'm not sure<br>
                    how well this would work and it's possible it may
                    not even work for<br>
                    bootstrap logging.<br>
                    <br>
                    With regards to audit logging, we're probably going
                    to have to do<br>
                    something totally different from what we'll do in
                    the logging subsystem<br>
                    since it doesn't use standard logging.<br>
                    <br>
                    I guess the bottom line is what does the console
                    want to see? Do you<br>
                    want to see all raw text log messages? Do you want
                    all messages but in a<br>
                    format like JSON that you can query/filter? Do you
                    really want only the<br>
                    last 10 error messages only? All or none of these
                    might be possible, but<br>
                    I really need to understand the needs before I can
                    explore more in depth<br>
                    what the best option would be.<br>
                    <br>
                    [1]: <a moz-do-not-send="true" href="https://issues.jboss.org/browse/WFLY-280">https://issues.jboss.org/browse/WFLY-280</a><br>
                    <br>
                    --<br>
                    James R. Perkins<br>
                    Red Hat JBoss Middleware<br>
                    <br>
                    <br>
                    <br>
                    _______________________________________________<br>
                    wildfly-dev mailing list<br>
                    <a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
                    <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
                    <br>
                  </blockquote>
                  _______________________________________________<br>
                  wildfly-dev mailing list<br>
                  <a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
                  <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
                </blockquote>
                --<br>
                Jason T. Greene<br>
                WildFly Lead / JBoss EAP Platform Architect<br>
                JBoss, a division of Red Hat<br>
                <br>
              </blockquote>
            </blockquote>
            <br>
          </blockquote>
          <br>
          _______________________________________________<br>
          wildfly-dev mailing list<br>
          <a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
          <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
James R. Perkins
Red Hat JBoss Middleware</pre>
  

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>wildfly-dev mailing list</span><br><span><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span><br></div></blockquote></body></html>