2:40 a.m.
I'm replying to this old thread to reopen this conversation about
reading log files. I've complete some work [1] on reading log files via
an operation. This is not exactly like the JIRA suggests where it would
only read the last 10 error messages. All this change allows is the raw
contents of the file to be read. The idea is this could be used to read
the entire contents of the log file as a whole, or in chunks.
What I've done is added two new operations list-log-files and read-log-file.
The list-log-files simply lists all files in the jboss.server.log.dir.
This may or may not be a good idea really. I can see some potential
security risks here mainly just seeing files that may contain sensitive
data. One way I've thought of to get around that is read the logging
subsystem model and only show files from known types like the
file-handlers. The main issue with that is there is no good way to get
this to work for custom-handlers.
The read-log-file simple does what it says and reads the contents of a
log file line by line. Reading line by line should work for the most
part unless the an non-standard line delimiter is used. There are 5
options for this option;
* name (required): the name of the log file to read
* encoding: the encoding for the log file
* lines: the number of lines to read, defaults to 10
* skip: the number of lines to skip before adding the results
* tail: true to read from the bottom up, default is true
The result of this is just a list of lines with the \n or \r\n stripped.
Just to clarify too a line means a line in the file, not a log record
e.g. stack traces are generally composed of multiple lines.
So this begs the question, will this work for what we want? What
concerns does anyone else have?
I have not yet submitted a PR yet as I wanted to get some feedback
before we bake it in.
[1]: https://github.com/jamezp/wildfly/compare/WFLY-280-read
On 08/14/2013 10:03 AM, James R. Perkins wrote:
I had posted this to another list, but this is a more appropriate
place for it. I think there needs to be a general discussion around
this as it's been mentioned, at least to me, a few times here and
there and I know Heiko raised the issue some time a go now.
The original JIRA, WFLY-280[1], is to display the last 10 error
messages only. To be honest I wouldn't find that very useful. To me if
I'm looking for logs I want to see all logs, but that's not always so
easy. Like the syslog-handler which doesn't log to a file so there is
no way to read those messages back.
The current plan for the last 10 error messages is we store messages
in a queue that can be accessed via an operation. This works fine
until the error message you're interested in is 11 or you want to see
warning messages.
Another option I had come up with is reading back the contents of the
file, for example the server.log. This could be problematic too in
that there is no way to filter information like only see error
messages or only see warning messages. To solve this I have considered
creating a JSON formatter so the results could be queried, but I don't
think it should be a default which would mean it's not reliable for
the console to assume it's getting back JSON.
I've also thought about, haven't tested this and it may not work at
all, creating a handler that uses websockets to send messages. I'm not
sure how well this would work and it's possible it may not even work
for bootstrap logging.
With regards to audit logging, we're probably going to have to do
something totally different from what we'll do in the logging
subsystem since it doesn't use standard logging.
I guess the bottom line is what does the console want to see? Do you
want to see all raw text log messages? Do you want all messages but in
a format like JSON that you can query/filter? Do you really want only
the last 10 error messages only? All or none of these might be
possible, but I really need to understand the needs before I can
explore more in depth what the best option would be.
[1]: https://issues.jboss.org/browse/WFLY-280
--
James R. Perkins
Red Hat JBoss Middleware
--
James R. Perkins
Red Hat JBoss Middleware