ebx-structuredlogging-sdk
Logging is a critical pillar of service observability. Occasionally it's desirable to include structured information and depending on the logging solution these can then be more easily graphed, analysed etc, for example with loggly.
This library intends to make including such structured logging as easy as possible by allowing structured arguments to be included in ch.qos.logback.classic.net.SyslogAppender
.
How to use
- Include this sdk (assuming maven):
<dependency>
<groupId>com.echobox</groupId>
<artifactId>ebx-structuredlogging-sdk</artifactId>
<version>1.0.0</version>
</dependency>
- Update the relevant project
logback.xml
file to include the extendedSyslogAppender
config:
<!-- Get an optional threadid, tid, value for logging -->
<conversionRule conversionWord="tid" converterClass="com.echobox.logging.ThreadIdConverter" />
<!-- Congiure the structured SyslogAppender -->
<appender name="SYSLOG" class="com.echobox.logging.SyslogAppenderWithAppendix">
<syslogHost>localhost</syslogHost>
<facility>USER</facility>
<suffixPattern>[%logger] %nopex</suffixPattern>
<appendixLayout
class="net.logstash.logback.layout.LoggingEventCompositeJsonLayout">
<providers>
<pattern>
<pattern>{ "threadId": "%tid-%thread", "message": "%msg", "exception":"%rEx{30}" }</pattern>
</pattern>
<arguments />
</providers>
</appendixLayout>
</appender>
The pattern can be modified as required, see here.
- Start including
net.logstash.logback.argument.StructuredArguments
where required:
Map<String, Object> loggingMap = new HashMap<>();
loggingMap.put("executionTimeMS", endTimeMS - startTimeMS);
logger.debug("Completed execution in MS {}", StructuredArguments.entries(loggingMap));
or
logger.warn(...
etc.
Getting in touch
- GitHub Issues: If you have ideas, bugs, or problems with our library, just open a new issue.
Contributing
If you would like to get involved please follow the instructions here
Releases
We use semantic versioning.
All merges into DEV will automatically get released as a maven central snapshot, which can be easily included in any downstream dependencies that always desire the latest changes (see above for 'Most Up To Date' installation).
Each merge into the MASTER branch will automatically get released to Maven central and github releases, using the current library version. As such, following every merge to master, the version number of the dev branch should be incremented and will represent 'Work In Progress' towards the next release.
Please use a merge (not rebase) commit when merging dev into master to perform the release.
To create a full release to Maven central please follow these steps:
- Ensure the
CHANGELOG.md
is up to date with all the changes in the release, if not please raise a suitable PR intoDEV
. Typically the change log should be updated as we go. - Create a PR from
DEV
intoMASTER
. Ensure the version in thepom.xml
is the correct version to be released. Merging this PR intoMASTER
will automatically create the maven and github releases. Please note that a release is final, it can not be undone/deleted/overwritten. - Once the public release has been successful create a final PR into
DEV
that contains an incrementedpom.xml
version to ensure the correct snapshot gets updated on subsequent merges intoDEV
. This PR should also include:- An update to the
README.md
latest stable release version number. - A 'Work In Progress' entry for the next anticipated release in
CHANGELOG.md
.
- An update to the