Updates to JEP-158: JVM Unified Logging are coming...
kirk at kodewerk.com
Fri Apr 17 20:40:15 UTC 2015
On Apr 17, 2015, at 11:29 AM, Fredrik Arvidsson <fredrik.arvidsson at oracle.com> wrote:
> Ill try to reply in-line below.
> On 2015-04-17 10:27, Mattis Castegren wrote:
>> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc.
> Of course there is a risk that people would forget to add a tag. But I can't see that this risk is very high. Logging code has to be put through code review just like any other change and we just have to pay extra attention to this in the beginning i guess. Using the hierarchical scheme there is also a risk that the logging topic is set to the wrong one.
> There are no recommendations right now on what tags to create or use in the logging code. We will work with all groups trying to establish some guidelines I guess to have tag names consistent.
My recommendation to teams has always been to give architectural guidelines or use requirements from operations to define logging. If you leave logging to dev it’s generally useful for dev and no one else.
> If we see a real need to have 'meta-tags' consisting of several other tags we could introduce something like that I'm sure, but this is just something we have discussed briefly.
JMS has a spec for managing this type of behavior.
> There will also be a way to list all existing 'tag combinations' used in the code in runtime. This could maybe be used to spot the ones that are potentially wrong?
>> If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like
>> log ("gc,g1,g1_init", ...)
>> If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..."
> Yes, this would be the way to handle missed tags in the code. I can't see that there is another way really :(
Make them manageable so if you forget on the command line you can change them on the fly.
More information about the hotspot-dev