<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Yes, parsing is the biggest issue. There are all kinds of
possibilities with the format. For example they could use a null
terminator for the records rather than a new line terminator. That
is why I thought allowing list files in the jboss.server.log.dir
directory was the best option.<br>
<br>
Essentially there would probably be two operations. One that lists
the available files and one that reads the contents of the file. The
read would probably be best in chunks since big files could be an
issue. The main security issue here would be if someone starts the
server with
-Djboss.server.log.dir=$JBOSS_HOME/standalone/configuration they
would have access to files like the mgmt-users.properties. This is
one of the reasons I thought maybe it should be required to have a
.log extension.<br>
<br>
One idea I just thought of, and it might not even be possible, but
it maybe have a way to email a compressed version of the log file. I
could see some benefit with large files, but maybe ssh is better for
that.<br>
<br>
<div class="moz-cite-prefix">On 08/15/2013 08:14 PM, Jason Greene
wrote:<br>
</div>
<blockquote
cite="mid:D2CB82FA-BBB5-46EA-B5AE-A82A42D615FB@redhat.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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. </div>
<div><br>
On Aug 15, 2013, at 6:45 PM, "James R. Perkins" <<a
moz-do-not-send="true" href="mailto:jperkins@redhat.com">jperkins@redhat.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=UTF-8"
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=UTF-8">
<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 show the last
n log entries, where n is specified as part of the
management operation. At first the user would see the
last n log entries and can navigate further backwards in
n-steps. For all deeper analysis the user should be able
to download the full log. When showing the log to the
user, I can think of some kind of syntax highlighting
(see <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> 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>--- </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. 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 <<a
moz-do-not-send="true"
href="mailto:smarlow@redhat.com">smarlow@redhat.com</a>>
wrote:<br>
<br>
<blockquote type="cite">What are the use cases for
online reading of the server logs? 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a></span><br>
<span><a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span><br>
</div>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
James R. Perkins
Red Hat JBoss Middleware</pre>
</body>
</html>