Thanks for the feedback David, Adam! I actually am outfitting a variety of Java apps with the logstash-logback-encoder for storing logs in ELK / Elasticstack and was aiming to store implementation info in MDC so it would be available. Aside from the suggestions both of you offered, I had only 2 other ideas: 1. Have logback read maven-generated pom.properties under META-INF for version, artifactId, groupId 2. Create a custom context listener as described in StackOverflow question <http://stackoverflow.com/questions/1975939/read-environment-variables-from-logback-configuration-file/23969706#23969706> that would figure out the main class and lookup it's implementation info Customizing the appender seems weird since it's concern is persisting log events to an external system (ELK, file, syslog, etc). On Sun, Mar 12, 2017 at 11:05 AM, <logback-user-request@qos.ch> wrote:
Date: Sun, 12 Mar 2017 11:04:39 -0400 From: Adam Gent <adam.gent@snaphop.com> To: logback users list <logback-user@qos.ch> Subject: Re: [logback-user] Manifest Question Message-ID: <CAG4f71u9ye=Uog0n5wUY-J3tDjdg6Tw67LoOVN8A6ODMxMy7eA@ mail.gmail.com> Content-Type: text/plain; charset="utf-8"
The appender way is the easiest way but there are bunch of caveats to that method. We used to do it this way but needed more flexibility.
If you are going to do it the custom Appender way I recommend not using the MDC. You also can really only have pretty static attributes.
For example for Spring MVC we actually add the routing path to the MDC and thus the Appender would not be helpful.
Yeah you could make a unified thread local context that your custom appender uses but that is basically what the MDC is.
There is also the tricky biz of handing of dynamic MDC information to child threads. Again for example for every request we generate a uuid so that we can track that request and everything it executes.
But if your attributes are mainly static I agree that the custom appender is the route to go.... I feel stupid for not mentioning it first.
On Sun, Mar 12, 2017 at 8:51 AM, David Tkaczyk <davidtkaczyk69@gmail.com> wrote:
Extend your preferred appender.
On Mar 12, 2017 6:59 AM, <logback-user-request@qos.ch> wrote:
Send logback-user mailing list submissions to logback-user@qos.ch
To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qos.ch/mailman/listinfo/logback-user or, via email, send a message with subject or body 'help' to logback-user-request@qos.ch
You can reach the person managing the list at logback-user-owner@qos.ch
When replying, please edit your Subject line so it is more specific than "Re: Contents of logback-user digest..."
Today's Topics:
1. Recommendations on including manifest implementation information into logging events (Andrew Feller)
---------- Forwarded message ---------- From: Andrew Feller <afeller@bandwidth.com> To: logback-user@qos.ch Cc: Bcc: Date: Sat, 11 Mar 2017 14:59:35 -0500 Subject: [logback-user] Recommendations on including manifest implementation information into logging events Does anyone have recommendations on how to best to add manifest implementation information (Implementation-Title, Implementation-Version, etc) to logback MDC trivially?
I know this information can retrieved programmatically from a package ( Package.getImplementationTitle() <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html# getImplementationTitle-->, Package.getImplementationVersion() <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html# getImplementationVersion-->, etc), but I'd rather avoid having every application hardcode logic on startup to determine this and stash it in MDC for later use. I would also like to avoid hard coding this information within logback.xml / logback-spring.xml as the manifest is the source of truth.
Any recommendations would be greatly appreciated! --
[image: email-signature-logo.jpg]
*Andy Feller*
Sr. DevOps Engineer 900 Main Campus Drive, Suite 500
Raleigh, NC 27606
Bandwidth <http://www.bandwidth.com/> <http://www.bandwidth.com/>e afeller@bandwidth.com
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
-- CTO SnapHop (snaphop.com) (twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt (cell) 781-883-5182
To get the Maven information we use the Manifest and if the /META-INF/MANIFEST.MF doesn't exist we then create a fake one from the pom.xml file in the ${user.dir}. The reason you don't always have the Manifest (or it is empty) is if you run the project with out building it (ie using Eclipse or Intellij). It is fairly easy to make Maven add info to the Manifest (google it). I'm not sure why it isn't the default. The code that parses and normalizes between either a MANIFEST.MF or pom.xml is here: https://gist.github.com/agentgt/997d7662f4942b4127525a8478ce6a95 (see fromPom and fromManifest). I suppose I could make it read pom.properties as well (I believe though there is information missing from pom.properties). Once you create PomManifest you can store it as a static singleton somewhere in your app (you can use servlet context attributes as well or whatever your comfortable with). On Mon, Mar 13, 2017 at 8:25 AM, Andrew Feller <afeller@bandwidth.com> wrote:
Thanks for the feedback David, Adam! I actually am outfitting a variety of Java apps with the logstash-logback-encoder for storing logs in ELK / Elasticstack and was aiming to store implementation info in MDC so it would be available.
Aside from the suggestions both of you offered, I had only 2 other ideas:
1. Have logback read maven-generated pom.properties under META-INF for version, artifactId, groupId 2. Create a custom context listener as described in StackOverflow question <http://stackoverflow.com/questions/1975939/read-environment-variables-from-logback-configuration-file/23969706#23969706> that would figure out the main class and lookup it's implementation info
Customizing the appender seems weird since it's concern is persisting log events to an external system (ELK, file, syslog, etc).
On Sun, Mar 12, 2017 at 11:05 AM, <logback-user-request@qos.ch> wrote:
Date: Sun, 12 Mar 2017 11:04:39 -0400 From: Adam Gent <adam.gent@snaphop.com> To: logback users list <logback-user@qos.ch> Subject: Re: [logback-user] Manifest Question Message-ID: <CAG4f71u9ye=Uog0n5wUY-J3tDjdg6Tw67LoOVN8A6ODMxMy7eA@mail. gmail.com> Content-Type: text/plain; charset="utf-8"
The appender way is the easiest way but there are bunch of caveats to that method. We used to do it this way but needed more flexibility.
If you are going to do it the custom Appender way I recommend not using the MDC. You also can really only have pretty static attributes.
For example for Spring MVC we actually add the routing path to the MDC and thus the Appender would not be helpful.
Yeah you could make a unified thread local context that your custom appender uses but that is basically what the MDC is.
There is also the tricky biz of handing of dynamic MDC information to child threads. Again for example for every request we generate a uuid so that we can track that request and everything it executes.
But if your attributes are mainly static I agree that the custom appender is the route to go.... I feel stupid for not mentioning it first.
On Sun, Mar 12, 2017 at 8:51 AM, David Tkaczyk <davidtkaczyk69@gmail.com> wrote:
Extend your preferred appender.
On Mar 12, 2017 6:59 AM, <logback-user-request@qos.ch> wrote:
Send logback-user mailing list submissions to logback-user@qos.ch
To subscribe or unsubscribe via the World Wide Web, visit http://mailman.qos.ch/mailman/listinfo/logback-user or, via email, send a message with subject or body 'help' to logback-user-request@qos.ch
You can reach the person managing the list at logback-user-owner@qos.ch
When replying, please edit your Subject line so it is more specific than "Re: Contents of logback-user digest..."
Today's Topics:
1. Recommendations on including manifest implementation information into logging events (Andrew Feller)
---------- Forwarded message ---------- From: Andrew Feller <afeller@bandwidth.com> To: logback-user@qos.ch Cc: Bcc: Date: Sat, 11 Mar 2017 14:59:35 -0500 Subject: [logback-user] Recommendations on including manifest implementation information into logging events Does anyone have recommendations on how to best to add manifest implementation information (Implementation-Title, Implementation-Version, etc) to logback MDC trivially?
I know this information can retrieved programmatically from a package ( Package.getImplementationTitle() <https://docs.oracle.com/javase/8/docs/api/java/lang/Package .html#getImplementationTitle-->, Package.getImplementationVersion() <https://docs.oracle.com/javase/8/docs/api/java/lang/Package .html#getImplementationVersion-->, etc), but I'd rather avoid having every application hardcode logic on startup to determine this and stash it in MDC for later use. I would also like to avoid hard coding this information within logback.xml / logback-spring.xml as the manifest is the source of truth.
Any recommendations would be greatly appreciated! --
[image: email-signature-logo.jpg]
*Andy Feller*
Sr. DevOps Engineer 900 Main Campus Drive, Suite 500
Raleigh, NC 27606
Bandwidth <http://www.bandwidth.com/> <http://www.bandwidth.com/>e afeller@bandwidth.com
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
-- CTO SnapHop (snaphop.com) (twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt (cell) 781-883-5182
participants (2)
-
Adam Gent -
Andrew Feller