2:10 p.m.
This is relatively minor but I've been sitting on it for a pretty long
time so I wanted to see if anyone had a strong opinion about it.
In the past few years, we've internationalized many of our projects, and
in the process assigned unique, searchable codes to exceptions and
INFO-and-higher log messages. In the meantime, as part of our existing
logging standards, we always log a version string for each library as it
is activated (this lets us quickly identify which versions of which
libraries are active, in order to aid in troubleshooting, etc.).
At present it is not part of our logging standard to assign a searchable
code to the version message. It has been suggested that we begin doing
so. If we did, I would recommend that the code be '0' for such messages
as most if not all of our projects use '1' as the lowest message ID.
The advantage of doing so is that it allows a given library's version
message to be quickly found in a log file, even if the language of the
log file is not known to the searcher. The disadvantage is that it
brings in additional noise to the log which makes it harder to read.
Does anyone have any strong feelings one way or the other, or better
yet, some pros or cons to add?
--
- DML
3:54 p.m.
We already have codes for a lot of these messsages so there’s not much added noise.
FWIW I hope we don’t have a standard to log every lib version. We already are way too
noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not
the console that would be lovely. And I’d like a pony too. ;)
On Mar 28, 2017, at 2:10 PM, David M. Lloyd
<david.lloyd(a)redhat.com> wrote:
This is relatively minor but I've been sitting on it for a pretty long
time so I wanted to see if anyone had a strong opinion about it.
In the past few years, we've internationalized many of our projects, and
in the process assigned unique, searchable codes to exceptions and
INFO-and-higher log messages. In the meantime, as part of our existing
logging standards, we always log a version string for each library as it
is activated (this lets us quickly identify which versions of which
libraries are active, in order to aid in troubleshooting, etc.).
At present it is not part of our logging standard to assign a searchable
code to the version message. It has been suggested that we begin doing
so. If we did, I would recommend that the code be '0' for such messages
as most if not all of our projects use '1' as the lowest message ID.
The advantage of doing so is that it allows a given library's version
message to be quickly found in a log file, even if the language of the
log file is not known to the searcher. The disadvantage is that it
brings in additional noise to the log which makes it harder to read.
Does anyone have any strong feelings one way or the other, or better
yet, some pros or cons to add?
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
4:15 p.m.
Since 2007 at least [1]. I believe it came from an earlier set of
standards which predate my employment with JBoss but that was so long
ago that I don't recall for certain.
That said, I'm open to revising how we do this as well. The log
segregation tools we theoretically have at our disposal are:
• Level
• Category
• NDC
• MDC
• Source class/method/file/line
• Arbitrary filter
However, I don't really have any bright ideas as to a *good* way to do
this (which is simple and hard for users to break, but also doesn't
screw up performance).
[1] https://developer.jboss.org/wiki/LoggingStandards/version/2
On 03/28/2017 03:54 PM, Brian Stansberry wrote:
We already have codes for a lot of these messsages so there’s not
much added noise.
FWIW I hope we don’t have a standard to log every lib version. We already are way too
noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not
the console that would be lovely. And I’d like a pony too. ;)
> On Mar 28, 2017, at 2:10 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
> This is relatively minor but I've been sitting on it for a pretty long
> time so I wanted to see if anyone had a strong opinion about it.
>
> In the past few years, we've internationalized many of our projects, and
> in the process assigned unique, searchable codes to exceptions and
> INFO-and-higher log messages. In the meantime, as part of our existing
> logging standards, we always log a version string for each library as it
> is activated (this lets us quickly identify which versions of which
> libraries are active, in order to aid in troubleshooting, etc.).
>
> At present it is not part of our logging standard to assign a searchable
> code to the version message. It has been suggested that we begin doing
> so. If we did, I would recommend that the code be '0' for such messages
> as most if not all of our projects use '1' as the lowest message ID.
>
> The advantage of doing so is that it allows a given library's version
> message to be quickly found in a log file, even if the language of the
> log file is not known to the searcher. The disadvantage is that it
> brings in additional noise to the log which makes it harder to read.
>
> Does anyone have any strong feelings one way or the other, or better
> yet, some pros or cons to add?
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
4:51 p.m.
Before I never directly addressed your message id 0 point. Sounds good to me. Some
existing ids would need to change to comply but that doesn’t seem like a big deal.
On Mar 28, 2017, at 4:15 PM, David M. Lloyd
<david.lloyd(a)redhat.com> wrote:
Since 2007 at least [1]. I believe it came from an earlier set of standards which
predate my employment with JBoss but that was so long ago that I don't recall for
certain.
Thanks; I’d never seen that one.
That said, I'm open to revising how we do this as well. The log
segregation tools we theoretically have at our disposal are:
Sorry about derailing your thread!
In my defense though, despite my whinging about the log noise, as we move toward Alexey’s
more flexible provisioning the utility of these kinds of messages will go up. The
relationship of library version to overall server version may be more fluid. So I dislike
them now but will probably like them later and we’ll want more. But spamming the *console*
with dozens of such messages will also leave a bad impression on users. Big, slow, bloated
etc.
• Level
• Category
We use this now, to get debug output for org.jboss.as.config in the server.log. Seems to
work ok, but doing it for versions would mean having some standard log category for these
messages. A common category also makes it easy for users to turn this off, which is both
a pro and a con.
I doubt projects would accept a common category though, as it makes it harder for their
users to configure their logging when the project is used elsewhere.
• NDC
• MDC
• Source class/method/file/line
• Arbitrary filter
Another tangent: Do we have a standard for the message code format? There’s a defacto one
but I mean a formal one. I know there are efforts going on to make better use of these in
search, and having a formal spec I think will be helpful in reliably extracting the code
from surrounding text. I believe we could say the codes are required to be 4 or more chars
A-Z followed by 3 or more digits, followed by “: “.
I raise this tangent because if in the version messages the digits are all 0 that’s a
pattern that can be filtered on. But I expect that would be quite bad for perf.
However, I don't really have any bright ideas as to a *good* way to do this (which is
simple and hard for users to break, but also doesn't screw up performance).
[1] https://developer.jboss.org/wiki/LoggingStandards/version/2
On 03/28/2017 03:54 PM, Brian Stansberry wrote:
> We already have codes for a lot of these messsages so there’s not much added noise.
>
> FWIW I hope we don’t have a standard to log every lib version. We already are way too
noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not
the console that would be lovely. And I’d like a pony too. ;)
>
>> On Mar 28, 2017, at 2:10 PM, David M. Lloyd <david.lloyd(a)redhat.com>
wrote:
>>
>> This is relatively minor but I've been sitting on it for a pretty long
>> time so I wanted to see if anyone had a strong opinion about it.
>>
>> In the past few years, we've internationalized many of our projects, and
>> in the process assigned unique, searchable codes to exceptions and
>> INFO-and-higher log messages. In the meantime, as part of our existing
>> logging standards, we always log a version string for each library as it
>> is activated (this lets us quickly identify which versions of which
>> libraries are active, in order to aid in troubleshooting, etc.).
>>
>> At present it is not part of our logging standard to assign a searchable
>> code to the version message. It has been suggested that we begin doing
>> so. If we did, I would recommend that the code be '0' for such messages
>> as most if not all of our projects use '1' as the lowest message ID.
>>
>> The advantage of doing so is that it allows a given library's version
>> message to be quickly found in a log file, even if the language of the
>> log file is not known to the searcher. The disadvantage is that it
>> brings in additional noise to the log which makes it harder to read.
>>
>> Does anyone have any strong feelings one way or the other, or better
>> yet, some pros or cons to add?
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
- DML
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
5:04 p.m.
On 03/28/2017 04:51 PM, Brian Stansberry wrote:
Before I never directly addressed your message id 0 point. Sounds
good to me. Some existing ids would need to change to comply but that doesn’t seem like a
big deal.
On Mar 28, 2017, at 4:15 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> Since 2007 at least [1]. I believe it came from an earlier set of standards which
predate my employment with JBoss but that was so long ago that I don't recall for
certain.
Thanks; I’d never seen that one.
> That said, I'm open to revising how we do this as well. The log segregation
tools we theoretically have at our disposal are:
Sorry about derailing your thread!
Nah it's an important (if decidedly unglamorous) topic!
In my defense though, despite my whinging about the log noise, as we
move toward Alexey’s more flexible provisioning the utility of these kinds of messages
will go up. The relationship of library version to overall server version may be more
fluid. So I dislike them now but will probably like them later and we’ll want more. But
spamming the *console* with dozens of such messages will also leave a bad impression on
users. Big, slow, bloated etc.
Makes sense.
> • Level
> • Category
We use this now, to get debug output for org.jboss.as.config in the server.log. Seems to
work ok, but doing it for versions would mean having some standard log category for these
messages. A common category also makes it easy for users to turn this off, which is both
a pro and a con.
I doubt projects would accept a common category though, as it makes it harder for their
users to configure their logging when the project is used elsewhere.
Agreed.
> • NDC
> • MDC
> • Source class/method/file/line
> • Arbitrary filter
Another tangent: Do we have a standard for the message code format? There’s a defacto one
but I mean a formal one. I know there are efforts going on to make better use of these in
search, and having a formal spec I think will be helpful in reliably extracting the code
from surrounding text. I believe we could say the codes are required to be 4 or more chars
A-Z followed by 3 or more digits, followed by “: “.
I'm pretty sure there is one, but I can't immediately find it. When
coming up with it, we discussed various options like "AAAA-####" or
"AAAA_####" but decided on "AAAA####" because it would count as a
single
word from the perspective of web searches. I don't think we formally
specified the number of letters or numbers in a doc, nor the ": " suffix.
I raise this tangent because if in the version messages the digits
are all 0 that’s a pattern that can be filtered on. But I expect that would be quite bad
for perf.
Yeah, undoubtedly, in addition to being a bit ugly (obscure special
handling) and maybe confusing ("why are some of my messages missing?").
Playing devil's advocate though: INFO messages are fairly infrequent, so
at least the perf argument is less relevant if the filter checks the
level of the message before anything else.
--
- DML
6:57 a.m.
On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda
<rsvoboda(a)redhat.com> wrote:
> Some existing ids would need to change to comply but that doesn’t seem like
> a big deal.
Maybe not for community, but can be trouble for product. Customers are encouraged to
parse logs based on message IDs.
I think the likelihood that people are relying on parsing out our version # messages is
really low. If they did a convention of reserving 0 for these might be a benefit for them
too.
Here’s what we log now (standalone-full-ha.xml):
06:49:15,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6
06:49:15,503 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1
06:49:15,638 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full
11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting
06:49:16,987 INFO [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001:
WildFly Elytron version 1.1.0.Beta33
06:49:17,202 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2
06:49:17,208 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version
3.5.0.Beta2
06:49:17,238 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016:
RESTEasy version 3.0.21.Final
06:49:17,271 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52)
WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13
06:49:17,392 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current
PicketBox version=5.0.0.Beta1
06:49:17,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003:
Undertow 1.4.11.Final starting
06:49:17,409 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009: Starting
JCA Subsystem (WildFly/IronJacamar 1.4.2.Final)
06:49:17,705 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version
5.0.0.Beta19
06:49:18,544 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052:
Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10)
8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final “started”
message is more likely what would be monitored and it shows the versions too.
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
7:57 a.m.
FYI :
I monitor the starting and started message in the netbeans plugin to check that everything
is correct and then try to connect when I launch
WildFly with nice regexp.
Emmanuel
Le 29/03/2017 à 13:57, Brian Stansberry a écrit :
> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <rsvoboda(a)redhat.com> wrote:
>
>
>> Some existing ids would need to change to comply but that doesn’t seem like
>> a big deal.
>
> Maybe not for community, but can be trouble for product. Customers are encouraged to
parse logs based on message IDs.
>
I think the likelihood that people are relying on parsing out our version # messages is
really low. If they did a convention of reserving 0 for these might be a benefit for them
too.
Here’s what we log now (standalone-full-ha.xml):
06:49:15,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6
06:49:15,503 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1
06:49:15,638 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full
11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting
06:49:16,987 INFO [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001:
WildFly Elytron version 1.1.0.Beta33
06:49:17,202 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2
06:49:17,208 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation
Version 3.5.0.Beta2
06:49:17,238 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016:
RESTEasy version 3.0.21.Final
06:49:17,271 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52)
WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13
06:49:17,392 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current
PicketBox version=5.0.0.Beta1
06:49:17,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003:
Undertow 1.4.11.Final starting
06:49:17,409 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009:
Starting JCA Subsystem (WildFly/IronJacamar 1.4.2.Final)
06:49:17,705 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version
5.0.0.Beta19
06:49:18,544 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052:
Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10)
8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final “started”
message is more likely what would be monitored and it shows the versions too.
2:01 p.m.
On 03/29/2017 06:57 AM, Brian Stansberry wrote:
> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <rsvoboda(a)redhat.com> wrote:
>
>
>> Some existing ids would need to change to comply but that doesn’t seem like
>> a big deal.
>
> Maybe not for community, but can be trouble for product. Customers are encouraged to
parse logs based on message IDs.
>
I think the likelihood that people are relying on parsing out our version # messages is
really low. If they did a convention of reserving 0 for these might be a benefit for them
too.
Here’s what we log now (standalone-full-ha.xml):
06:49:15,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6
06:49:15,503 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1
06:49:15,638 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full
11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting
06:49:16,987 INFO [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001:
WildFly Elytron version 1.1.0.Beta33
06:49:17,202 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2
06:49:17,208 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation
Version 3.5.0.Beta2
06:49:17,238 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016:
RESTEasy version 3.0.21.Final
06:49:17,271 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52)
WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13
06:49:17,392 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current
PicketBox version=5.0.0.Beta1
06:49:17,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003:
Undertow 1.4.11.Final starting
06:49:17,409 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009:
Starting JCA Subsystem (WildFly/IronJacamar 1.4.2.Final)
06:49:17,705 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version
5.0.0.Beta19
06:49:18,544 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052:
Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10)
8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final “started”
message is more likely what would be monitored and it shows the versions too.
It's even more now if you have a deployment, since many libraries are
only initialized once applications begin using them.
--
- DML
7:06 p.m.
We could just ensure that "version" is in the category and use a filter.
That requires some buy-in from external dependencies though. I guess really
any solution requires some kind of buy-in.
On Tue, Mar 28, 2017 at 2:15 PM, David M. Lloyd <david.lloyd(a)redhat.com>
wrote:
Since 2007 at least [1]. I believe it came from an earlier set of
standards which predate my employment with JBoss but that was so long
ago that I don't recall for certain.
That said, I'm open to revising how we do this as well. The log
segregation tools we theoretically have at our disposal are:
• Level
• Category
• NDC
• MDC
• Source class/method/file/line
• Arbitrary filter
However, I don't really have any bright ideas as to a *good* way to do
this (which is simple and hard for users to break, but also doesn't
screw up performance).
[1] https://developer.jboss.org/wiki/LoggingStandards/version/2
On 03/28/2017 03:54 PM, Brian Stansberry wrote:
> We already have codes for a lot of these messsages so there’s not much
added noise.
>
> FWIW I hope we don’t have a standard to log every lib version. We
already are way too noisy at boot, IMHO. If someone has a nifty way to
write these to the server log but not the console that would be lovely. And
I’d like a pony too. ;)
>
>> On Mar 28, 2017, at 2:10 PM, David M. Lloyd <david.lloyd(a)redhat.com>
wrote:
>>
>> This is relatively minor but I've been sitting on it for a pretty long
>> time so I wanted to see if anyone had a strong opinion about it.
>>
>> In the past few years, we've internationalized many of our projects, and
>> in the process assigned unique, searchable codes to exceptions and
>> INFO-and-higher log messages. In the meantime, as part of our existing
>> logging standards, we always log a version string for each library as it
>> is activated (this lets us quickly identify which versions of which
>> libraries are active, in order to aid in troubleshooting, etc.).
>>
>> At present it is not part of our logging standard to assign a searchable
>> code to the version message. It has been suggested that we begin doing
>> so. If we did, I would recommend that the code be '0' for such
messages
>> as most if not all of our projects use '1' as the lowest message ID.
>>
>> The advantage of doing so is that it allows a given library's version
>> message to be quickly found in a log file, even if the language of the
>> log file is not known to the searcher. The disadvantage is that it
>> brings in additional noise to the log which makes it harder to read.
>>
>> Does anyone have any strong feelings one way or the other, or better
>> yet, some pros or cons to add?
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
2821
days inactive
2825
days old
9 comments
5 participants
participants (5)
-
Brian Stansberry -
David M. Lloyd -
Emmanuel Hugonnet -
James Perkins -
Rostislav Svoboda