[wildfly-dev] Reading Logs from Web Console

Wed Sep 25 03:34:22 EDT 2013

On Wednesday 25 September 2013 09:25 AM, Ondrej Zizka wrote:
> 1) Could it have a "read-log-file()" without name= specified, which 
> would read the "current" log file?
Given the way logger categories and appenders/handlers interact, within 
a logging framework, I don't think there's any notion of "current log 
file". It's a very valid scenario where a single logging category can be 
backed by different appenders (some of themfile appenders) with 
different attributes and each such appender writing out to a different 
file.So having a name of the log file you want to view, becomes necessary.

-Jaikiran

> 2) Regarding security - what, besides logs, do we expect to be in the 
> log dir? Could the admin block it by setting write-only rights?
>
> Ondra
>
> On 25.9.2013 02:40, James R. Perkins wrote:
>> 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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130925/b16f30f1/attachment-0001.html