[wildfly-dev] Reading Logs from Web Console

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[wildfly-dev] Reading Logs from Web Console

James Perkins
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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

jtgreene
Administrator
IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.

On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins
That's my thinking too. The only complaint I've had about that solution
is that it can't be filtered since it's just raw text. I had a working
example operation that just took a file name and the number of bytes to
read. To me this is the best solution, but it wouldn't have access to
anything in a syslog or the console. Though that's okay IMO since they
likely have other viewers for those.

I'll resurrect that example. It shouldn't take all that long. One thing
to note is it will only allow files to be read that are in the
jboss.server.log.dir (and possibly only files that end in *.log?).

So in general I agree here, I think this is the best, the least invasive
approach and the lowest performance hit.

On 08/14/2013 10:36 AM, Jason Greene wrote:

> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
>
> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Stan Silvert
In reply to this post by jtgreene
On 8/14/2013 1:36 PM, Jason Greene wrote:
> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
I tend to agree.  I dealt with this problem in the past and found that
what I really needed was a just a copy (or partial copy) of the log file
itself.  So give me something that just lets me download the file.  Then
I can throw it into my favorite log file analyzer and deal with it that
way.  If we tried to embed our own analyzer into the console we'd never
finish meeting all our customer's requirements.

>
> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

jtgreene
Administrator
In reply to this post by James Perkins
We could technically support server side filtering. We simply pattern search the file.  We could also support client side filtering. We could for example utilize browser offline storage. The big issue is just that there are efficiency limits to the size of the file since it's not an indexed store. That could be improved by doing a real indexed data store (e.g. something like bdb). In the future I could picture an SPI that logging backends could implement for the purpose of searching. Although I think we will find that simply searching the normal text log file is good enough.

On Aug 14, 2013, at 12:55 PM, James R. Perkins <[hidden email]> wrote:

> That's my thinking too. The only complaint I've had about that solution is that it can't be filtered since it's just raw text. I had a working example operation that just took a file name and the number of bytes to read. To me this is the best solution, but it wouldn't have access to anything in a syslog or the console. Though that's okay IMO since they likely have other viewers for those.
>
> I'll resurrect that example. It shouldn't take all that long. One thing to note is it will only allow files to be read that are in the jboss.server.log.dir (and possibly only files that end in *.log?).
>
> So in general I agree here, I think this is the best, the least invasive approach and the lowest performance hit.
>
> On 08/14/2013 10:36 AM, Jason Greene wrote:
>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
>>
>> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>
> --
> James R. Perkins
> Red Hat JBoss Middleware
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins
The problem with filtering comes in parsing the log file. While I have
had some success doing this with I tool I was playing with for Jesper,
once you get a stack trace you have to start making guesses. I tend to
agree with dmlloyd in that log files tend to be a one way write. You can
do some parsing with a best guess, but well we all know what happens
when we start assuming and guessing :)

That said I do like the challenge of trying to parse log files. I did
start a project to do it in my spare time I just haven't found time to
put into working on it lately.

On 08/14/2013 11:12 AM, Jason Greene wrote:

> We could technically support server side filtering. We simply pattern search the file.  We could also support client side filtering. We could for example utilize browser offline storage. The big issue is just that there are efficiency limits to the size of the file since it's not an indexed store. That could be improved by doing a real indexed data store (e.g. something like bdb). In the future I could picture an SPI that logging backends could implement for the purpose of searching. Although I think we will find that simply searching the normal text log file is good enough.
>
> On Aug 14, 2013, at 12:55 PM, James R. Perkins <[hidden email]> wrote:
>
>> That's my thinking too. The only complaint I've had about that solution is that it can't be filtered since it's just raw text. I had a working example operation that just took a file name and the number of bytes to read. To me this is the best solution, but it wouldn't have access to anything in a syslog or the console. Though that's okay IMO since they likely have other viewers for those.
>>
>> I'll resurrect that example. It shouldn't take all that long. One thing to note is it will only allow files to be read that are in the jboss.server.log.dir (and possibly only files that end in *.log?).
>>
>> So in general I agree here, I think this is the best, the least invasive approach and the lowest performance hit.
>>
>> On 08/14/2013 10:36 AM, Jason Greene wrote:
>>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
>>>
>>> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>> --
>> James R. Perkins
>> Red Hat JBoss Middleware
>>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Brian Stansberry
In reply to this post by Stan Silvert
On 8/14/13 12:55 PM, [hidden email] wrote:
> On 8/14/2013 1:36 PM, Jason Greene wrote:
>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
> I tend to agree.  I dealt with this problem in the past and found that
> what I really needed was a just a copy (or partial copy) of the log file
> itself.  So give me something that just lets me download the file.  Then
> I can throw it into my favorite log file analyzer and deal with it that
> way.  If we tried to embed our own analyzer into the console we'd never
> finish meeting all our customer's requirements.
>

+1.

Even if we end up writing a lot of log analysis stuff someday, there's
always going to be a solid use case for just providing the file or
chunks thereof. So do that first.

>>
>> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

jtgreene
Administrator
In reply to this post by James Perkins
Custom pattern formats could be a problem, but as long as the format has delimiters it can be pretty reliable. As an example a category search can include the [] delimiters, and you can back search for a timestamp to detect the record start. A stack trace will always end before  another record start.

Although who knows maybe a simple grep like behavior is good enough to start with.

On Aug 14, 2013, at 1:20 PM, "James R. Perkins" <[hidden email]> wrote:

> The problem with filtering comes in parsing the log file. While I have had some success doing this with I tool I was playing with for Jesper, once you get a stack trace you have to start making guesses. I tend to agree with dmlloyd in that log files tend to be a one way write. You can do some parsing with a best guess, but well we all know what happens when we start assuming and guessing :)
>
> That said I do like the challenge of trying to parse log files. I did start a project to do it in my spare time I just haven't found time to put into working on it lately.
>
> On 08/14/2013 11:12 AM, Jason Greene wrote:
>> We could technically support server side filtering. We simply pattern search the file.  We could also support client side filtering. We could for example utilize browser offline storage. The big issue is just that there are efficiency limits to the size of the file since it's not an indexed store. That could be improved by doing a real indexed data store (e.g. something like bdb). In the future I could picture an SPI that logging backends could implement for the purpose of searching. Although I think we will find that simply searching the normal text log file is good enough.
>>
>> On Aug 14, 2013, at 12:55 PM, James R. Perkins <[hidden email]> wrote:
>>
>>> That's my thinking too. The only complaint I've had about that solution is that it can't be filtered since it's just raw text. I had a working example operation that just took a file name and the number of bytes to read. To me this is the best solution, but it wouldn't have access to anything in a syslog or the console. Though that's okay IMO since they likely have other viewers for those.
>>>
>>> I'll resurrect that example. It shouldn't take all that long. One thing to note is it will only allow files to be read that are in the jboss.server.log.dir (and possibly only files that end in *.log?).
>>>
>>> So in general I agree here, I think this is the best, the least invasive approach and the lowest performance hit.
>>>
>>> On 08/14/2013 10:36 AM, Jason Greene wrote:
>>>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
>>>>
>>>> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> --
>>>> Jason T. Greene
>>>> WildFly Lead / JBoss EAP Platform Architect
>>>> JBoss, a division of Red Hat
>>>>
>>> --
>>> James R. Perkins
>>> Red Hat JBoss Middleware
>>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>
> --
> James R. Perkins
> Red Hat JBoss Middleware
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Brian Stansberry
In reply to this post by James Perkins
On 8/14/13 12:55 PM, James R. Perkins wrote:

> That's my thinking too. The only complaint I've had about that solution
> is that it can't be filtered since it's just raw text. I had a working
> example operation that just took a file name and the number of bytes to
> read. To me this is the best solution, but it wouldn't have access to
> anything in a syslog or the console. Though that's okay IMO since they
> likely have other viewers for those.
>
> I'll resurrect that example. It shouldn't take all that long. One thing
> to note is it will only allow files to be read that are in the
> jboss.server.log.dir (and possibly only files that end in *.log?).
>

That's only true if the viewer operation is not associated with a
management resource that maps to the log file (i.e. the appender resource).

I think it's a mistake to create any kind of viewer that can serve an
arbitrary file.

For cases of serving previous versions of the file (i.e. ones before the
current with any kind of rolling appender) the API can expose a param
that allows the desired file to be chosen but only from a set of files
that the management resource knows it created.

> So in general I agree here, I think this is the best, the least invasive
> approach and the lowest performance hit.
>
> On 08/14/2013 10:36 AM, Jason Greene wrote:
>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
>>
>> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins
In reply to this post by jtgreene
You're just trying to get me to resurrect my simple little parser :P

That's essentially all I did. Take a pattern, parse it and make a regex pattern out of the format pattern. It worked fine, but exceptions were a problem. I just had a enum[1] that represented each pattern format type with a following regex expression. Note though I kind of suck at regex so it might be horrible.

[1]: https://github.com/jamezp/log-parser/blob/master/src/main/java/org/jboss/logging/tools/parser/FormatType.java#L33

On 08/14/2013 11:41 AM, Jason Greene wrote:
Custom pattern formats could be a problem, but as long as the format has delimiters it can be pretty reliable. As an example a category search can include the [] delimiters, and you can back search for a timestamp to detect the record start. A stack trace will always end before  another record start.

Although who knows maybe a simple grep like behavior is good enough to start with.

On Aug 14, 2013, at 1:20 PM, "James R. Perkins" [hidden email] wrote:

The problem with filtering comes in parsing the log file. While I have had some success doing this with I tool I was playing with for Jesper, once you get a stack trace you have to start making guesses. I tend to agree with dmlloyd in that log files tend to be a one way write. You can do some parsing with a best guess, but well we all know what happens when we start assuming and guessing :)

That said I do like the challenge of trying to parse log files. I did start a project to do it in my spare time I just haven't found time to put into working on it lately.

On 08/14/2013 11:12 AM, Jason Greene wrote:
We could technically support server side filtering. We simply pattern search the file.  We could also support client side filtering. We could for example utilize browser offline storage. The big issue is just that there are efficiency limits to the size of the file since it's not an indexed store. That could be improved by doing a real indexed data store (e.g. something like bdb). In the future I could picture an SPI that logging backends could implement for the purpose of searching. Although I think we will find that simply searching the normal text log file is good enough.

On Aug 14, 2013, at 12:55 PM, James R. Perkins [hidden email] wrote:

That's my thinking too. The only complaint I've had about that solution is that it can't be filtered since it's just raw text. I had a working example operation that just took a file name and the number of bytes to read. To me this is the best solution, but it wouldn't have access to anything in a syslog or the console. Though that's okay IMO since they likely have other viewers for those.

I'll resurrect that example. It shouldn't take all that long. One thing to note is it will only allow files to be read that are in the jboss.server.log.dir (and possibly only files that end in *.log?).

So in general I agree here, I think this is the best, the least invasive approach and the lowest performance hit.

On 08/14/2013 10:36 AM, Jason Greene wrote:
IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.

On Aug 14, 2013, at 12:03 PM, James R. Perkins [hidden email] 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-- 
James R. Perkins
Red Hat JBoss Middleware

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-- 
James R. Perkins
Red Hat JBoss Middleware

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


-- 
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins
In reply to this post by James Perkins
Ha, yes it's been a couple of years now :) I'm enjoying Red Hat a lot
and I hope you are too.

Thanks. I'll see what Google turns up with that. Maybe we could at least
get some ideas from it.


On 08/14/2013 11:51 AM, Rob Cernich wrote:

>> The problem with filtering comes in parsing the log file. While I have
>> had some success doing this with I tool I was playing with for Jesper,
>> once you get a stack trace you have to start making guesses. I tend to
>> agree with dmlloyd in that log files tend to be a one way write. You can
>> do some parsing with a best guess, but well we all know what happens
>> when we start assuming and guessing :)
>>
>> That said I do like the challenge of trying to parse log files. I did
>> start a project to do it in my spare time I just haven't found time to
>> put into working on it lately.
>>
> Hey James, long time since orientation...
>
> Eclipse used to have a project called TPTP which did some of this.  It was architected with a "collector" that received events from various "agents" associated with servers running in your system.  I believe the events were typed as Common Base Events which included fields to help correlate events across multiple servers.  I don't recall whether or not the source for the server components (collector and agent) was open sourced or not (the binaries were available from Eclipse).  The Eclipse side provided tooling for viewing and analyzing these CBE messages, which included the capability for creating rules that could be used to diagnose common problems when applied across a set of events.
>
> Hope you've been enjoying your time at Red Hat!
>
> Rob

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins
In reply to this post by Brian Stansberry

On 08/14/2013 11:45 AM, Brian Stansberry wrote:

> On 8/14/13 12:55 PM, James R. Perkins wrote:
>> That's my thinking too. The only complaint I've had about that solution
>> is that it can't be filtered since it's just raw text. I had a working
>> example operation that just took a file name and the number of bytes to
>> read. To me this is the best solution, but it wouldn't have access to
>> anything in a syslog or the console. Though that's okay IMO since they
>> likely have other viewers for those.
>>
>> I'll resurrect that example. It shouldn't take all that long. One thing
>> to note is it will only allow files to be read that are in the
>> jboss.server.log.dir (and possibly only files that end in *.log?).
>>
> That's only true if the viewer operation is not associated with a
> management resource that maps to the log file (i.e. the appender resource).
>
> I think it's a mistake to create any kind of viewer that can serve an
> arbitrary file.
>
> For cases of serving previous versions of the file (i.e. ones before the
> current with any kind of rolling appender) the API can expose a param
> that allows the desired file to be chosen but only from a set of files
> that the management resource knows it created.
The only reason I thought of limiting it to the jboss.server.log.dir was
there is no real way to know what handlers are file handlers. For
example a custom-handler could be a file handler, but there is no real
way to know that. Those files should be allowed to viewed, IMO, as well.

On the other hand I do agree there is an issue with being able to read
arbitrary files. A good example would be if the logs are placed in
/var/log/ we don't want to allow access to any of the log files not
created by WildFly.

I guess what we could do, at least to start, is just add a read-log
operation only to file handlers. Then we could just get the file name
from the resource. Further down maybe we could add an attribute to the
custom-handler to enable the operation.

>
>> So in general I agree here, I think this is the best, the least invasive
>> approach and the lowest performance hit.
>>
>> On 08/14/2013 10:36 AM, Jason Greene wrote:
>>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
>>>
>>> On Aug 14, 2013, at 12:03 PM, James R. Perkins <[hidden email]> 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
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins

On 08/14/2013 12:01 PM, James R. Perkins wrote:

>
> On 08/14/2013 11:45 AM, Brian Stansberry wrote:
>> On 8/14/13 12:55 PM, James R. Perkins wrote:
>>> That's my thinking too. The only complaint I've had about that solution
>>> is that it can't be filtered since it's just raw text. I had a working
>>> example operation that just took a file name and the number of bytes to
>>> read. To me this is the best solution, but it wouldn't have access to
>>> anything in a syslog or the console. Though that's okay IMO since they
>>> likely have other viewers for those.
>>>
>>> I'll resurrect that example. It shouldn't take all that long. One thing
>>> to note is it will only allow files to be read that are in the
>>> jboss.server.log.dir (and possibly only files that end in *.log?).
>>>
>> That's only true if the viewer operation is not associated with a
>> management resource that maps to the log file (i.e. the appender
>> resource).
>>
>> I think it's a mistake to create any kind of viewer that can serve an
>> arbitrary file.
>>
>> For cases of serving previous versions of the file (i.e. ones before the
>> current with any kind of rolling appender) the API can expose a param
>> that allows the desired file to be chosen but only from a set of files
>> that the management resource knows it created.
> The only reason I thought of limiting it to the jboss.server.log.dir
> was there is no real way to know what handlers are file handlers. For
> example a custom-handler could be a file handler, but there is no real
> way to know that. Those files should be allowed to viewed, IMO, as well.
>
> On the other hand I do agree there is an issue with being able to read
> arbitrary files. A good example would be if the logs are placed in
> /var/log/ we don't want to allow access to any of the log files not
> created by WildFly.
>
> I guess what we could do, at least to start, is just add a read-log
> operation only to file handlers. Then we could just get the file name
> from the resource. Further down maybe we could add an attribute to the
> custom-handler to enable the operation.
Just thought of one possible issue here is how would the web console
know which handlers have the operation.

>>
>>> So in general I agree here, I think this is the best, the least
>>> invasive
>>> approach and the lowest performance hit.
>>>
>>> On 08/14/2013 10:36 AM, Jason Greene wrote:
>>>> IMO the best solution is a management operation that simply
>>>> displays portions of the log file. The dependency on the log file
>>>> is IMO not a problem because we support multiple appenders.
>>>>
>>>> On Aug 14, 2013, at 12:03 PM, James R. Perkins
>>>> <[hidden email]> 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
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> --
>>>> Jason T. Greene
>>>> WildFly Lead / JBoss EAP Platform Architect
>>>> JBoss, a division of Red Hat
>>>>
>>
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Rob Cernich
In reply to this post by James Perkins
This is the best link I have.  Note that many of the links on that page are dead, but I think most of the meat is still there.

http://www.eclipse.org/tptp/index.php

----- Original Message -----

> Ha, yes it's been a couple of years now :) I'm enjoying Red Hat a lot
> and I hope you are too.
>
> Thanks. I'll see what Google turns up with that. Maybe we could at least
> get some ideas from it.
>
>
> On 08/14/2013 11:51 AM, Rob Cernich wrote:
> >> The problem with filtering comes in parsing the log file. While I have
> >> had some success doing this with I tool I was playing with for Jesper,
> >> once you get a stack trace you have to start making guesses. I tend to
> >> agree with dmlloyd in that log files tend to be a one way write. You can
> >> do some parsing with a best guess, but well we all know what happens
> >> when we start assuming and guessing :)
> >>
> >> That said I do like the challenge of trying to parse log files. I did
> >> start a project to do it in my spare time I just haven't found time to
> >> put into working on it lately.
> >>
> > Hey James, long time since orientation...
> >
> > Eclipse used to have a project called TPTP which did some of this.  It was
> > architected with a "collector" that received events from various "agents"
> > associated with servers running in your system.  I believe the events were
> > typed as Common Base Events which included fields to help correlate events
> > across multiple servers.  I don't recall whether or not the source for the
> > server components (collector and agent) was open sourced or not (the
> > binaries were available from Eclipse).  The Eclipse side provided tooling
> > for viewing and analyzing these CBE messages, which included the
> > capability for creating rules that could be used to diagnose common
> > problems when applied across a set of events.
> >
> > Hope you've been enjoying your time at Red Hat!
> >
> > Rob
>
> --
> James R. Perkins
> Red Hat JBoss Middleware
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Scott Marlow
In reply to this post by James Perkins
What are the use cases for online reading of the server logs?  If there
are problems occurring on the application server (e.g. perhaps the cpu
is pegged), reading logs online, could make the system even less
responsive.

If we just want to read the server logs as part of a health check, not
requiring the server console to be working would be better.

Should the reading of the logs instead be an external capability?
Perhaps using the logs from the JBoss/WildFly Diagnostic Reporter output
(archive) or some other archived copy of logs.

Another compromise, add the WildFly Diagnostic Reporter (or at least the
log collection part) to the management console (output archive is
downloaded for local viewing).

On 08/14/2013 01:03 PM, 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
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Brian Stansberry
In reply to this post by James Perkins
On 8/14/13 2:12 PM, James R. Perkins wrote:

>
> On 08/14/2013 12:01 PM, James R. Perkins wrote:
>>
>> On 08/14/2013 11:45 AM, Brian Stansberry wrote:
>>> On 8/14/13 12:55 PM, James R. Perkins wrote:
>>>> That's my thinking too. The only complaint I've had about that solution
>>>> is that it can't be filtered since it's just raw text. I had a working
>>>> example operation that just took a file name and the number of bytes to
>>>> read. To me this is the best solution, but it wouldn't have access to
>>>> anything in a syslog or the console. Though that's okay IMO since they
>>>> likely have other viewers for those.
>>>>
>>>> I'll resurrect that example. It shouldn't take all that long. One thing
>>>> to note is it will only allow files to be read that are in the
>>>> jboss.server.log.dir (and possibly only files that end in *.log?).
>>>>
>>> That's only true if the viewer operation is not associated with a
>>> management resource that maps to the log file (i.e. the appender
>>> resource).
>>>
>>> I think it's a mistake to create any kind of viewer that can serve an
>>> arbitrary file.
>>>
>>> For cases of serving previous versions of the file (i.e. ones before the
>>> current with any kind of rolling appender) the API can expose a param
>>> that allows the desired file to be chosen but only from a set of files
>>> that the management resource knows it created.
>> The only reason I thought of limiting it to the jboss.server.log.dir
>> was there is no real way to know what handlers are file handlers. For
>> example a custom-handler could be a file handler, but there is no real
>> way to know that. Those files should be allowed to viewed, IMO, as well.
>>

The AS would then have to provide an SPI via which the handler could
expose whatever is necessary. Is that SPI likely to be implemented?

This is a nice-to-have IMHO.

>> On the other hand I do agree there is an issue with being able to read
>> arbitrary files. A good example would be if the logs are placed in
>> /var/log/ we don't want to allow access to any of the log files not
>> created by WildFly.
>>
>> I guess what we could do, at least to start, is just add a read-log
>> operation only to file handlers. Then we could just get the file name
>> from the resource. Further down maybe we could add an attribute to the
>> custom-handler to enable the operation.
> Just thought of one possible issue here is how would the web console
> know which handlers have the operation.

Any custom handler could have a read-only attribute that describes
whether the viewer ops are supported. The description of the viewer ops
clearly states that they will fail if executed if not supported.

This could be done other ways that are more complex and fussy and best
avoided.

>>>
>>>> So in general I agree here, I think this is the best, the least
>>>> invasive
>>>> approach and the lowest performance hit.
>>>>
>>>> On 08/14/2013 10:36 AM, Jason Greene wrote:
>>>>> IMO the best solution is a management operation that simply
>>>>> displays portions of the log file. The dependency on the log file
>>>>> is IMO not a problem because we support multiple appenders.
>>>>>
>>>>> On Aug 14, 2013, at 12:03 PM, James R. Perkins
>>>>> <[hidden email]> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> --
>>>>> Jason T. Greene
>>>>> WildFly Lead / JBoss EAP Platform Architect
>>>>> JBoss, a division of Red Hat
>>>>>
>>>
>>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

jtgreene
Administrator
In reply to this post by Scott Marlow
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.

On Aug 14, 2013, at 2:24 PM, Scott Marlow <[hidden email]> wrote:

> What are the use cases for online reading of the server logs?  If there
> are problems occurring on the application server (e.g. perhaps the cpu
> is pegged), reading logs online, could make the system even less
> responsive.
>
> If we just want to read the server logs as part of a health check, not
> requiring the server console to be working would be better.
>
> Should the reading of the logs instead be an external capability?
> Perhaps using the logs from the JBoss/WildFly Diagnostic Reporter output
> (archive) or some other archived copy of logs.
>
> Another compromise, add the WildFly Diagnostic Reporter (or at least the
> log collection part) to the management console (output archive is
> downloaded for local viewing).
>
> On 08/14/2013 01:03 PM, 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
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

jtgreene
Administrator
In reply to this post by Stan Silvert

On Aug 14, 2013, at 12:55 PM, [hidden email] wrote:

> On 8/14/2013 1:36 PM, Jason Greene wrote:
>> IMO the best solution is a management operation that simply displays portions of the log file. The dependency on the log file is IMO not a problem because we support multiple appenders.
> I tend to agree.  I dealt with this problem in the past and found that
> what I really needed was a just a copy (or partial copy) of the log file
> itself.  So give me something that just lets me download the file.  Then
> I can throw it into my favorite log file analyzer and deal with it that
> way.  If we tried to embed our own analyzer into the console we'd never
> finish meeting all our customer's requirements.


Yeah I agree that a simple download it all should be an option.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

James Perkins
In reply to this post by jtgreene
Just to add too in a domain it would be nice to have a central spot to
view logs instead of having to ssh into various servers.

On 08/14/2013 12:56 PM, Jason Greene wrote:

> 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.
>
> On Aug 14, 2013, at 2:24 PM, Scott Marlow <[hidden email]> wrote:
>
>> What are the use cases for online reading of the server logs?  If there
>> are problems occurring on the application server (e.g. perhaps the cpu
>> is pegged), reading logs online, could make the system even less
>> responsive.
>>
>> If we just want to read the server logs as part of a health check, not
>> requiring the server console to be working would be better.
>>
>> Should the reading of the logs instead be an external capability?
>> Perhaps using the logs from the JBoss/WildFly Diagnostic Reporter output
>> (archive) or some other archived copy of logs.
>>
>> Another compromise, add the WildFly Diagnostic Reporter (or at least the
>> log collection part) to the management console (output archive is
>> downloaded for local viewing).
>>
>> On 08/14/2013 01:03 PM, 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
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

--
James R. Perkins
Red Hat JBoss Middleware

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Reading Logs from Web Console

Brian Stansberry
Agreed. IMHO this is the most important driver for this feature.

On 8/14/13 3:44 PM, James R. Perkins wrote:

> Just to add too in a domain it would be nice to have a central spot to
> view logs instead of having to ssh into various servers.
>
> On 08/14/2013 12:56 PM, Jason Greene wrote:
>> 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.
>>
>> On Aug 14, 2013, at 2:24 PM, Scott Marlow <[hidden email]> wrote:
>>
>>> What are the use cases for online reading of the server logs?  If there
>>> are problems occurring on the application server (e.g. perhaps the cpu
>>> is pegged), reading logs online, could make the system even less
>>> responsive.
>>>
>>> If we just want to read the server logs as part of a health check, not
>>> requiring the server console to be working would be better.
>>>
>>> Should the reading of the logs instead be an external capability?
>>> Perhaps using the logs from the JBoss/WildFly Diagnostic Reporter output
>>> (archive) or some other archived copy of logs.
>>>
>>> Another compromise, add the WildFly Diagnostic Reporter (or at least the
>>> log collection part) to the management console (output archive is
>>> downloaded for local viewing).
>>>
>>> On 08/14/2013 01:03 PM, 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123