Repository: JakeWharton/timber

Issue #184: Adding optional meta data to Timber logs
Created: 2016-11-21T17:47:47Z
We are currently using Timber for all our logging purposes and want to send them up to our backend for monitoring from our production app. However in order to do so we need the ability to pass in optional metadata to each log statement. The extra metadata can be of any type, such as a Map.
Currently using Timber, we don’t have a way to pass in extra information besides Object[] args and overriding the formatMessage() to handle them. The issue with this is that we miss out on type safety and can’t enforce the required schema or make it explicit that the arguments passed in is metadata vs formatting args.
Our current implementation is to add a thin layer on top of Timber which enforces various schema requirements for the consumers ensuring that the data that gets funneled down is compatible for our transport system to send it up to our servers. We’d like to propose upstreaming this to enhance Timber’s API. We’re also interested in getting others thoughts on if it can already be solved by Timber’s current API or why it should remain separate.
Using our current use case:

Errors and Warnings should have a unique identifier

solved by using Timber.tag() + Lint


Errors and Warnings must have a stacktrace

can use linting to enforce that they provide an Exception


Optional meta data of type Map<String, String> can be passed in with each log

This is lacking as we don’t have a clear way of enforcing type safety on these optional args.
Furthermore, by overriding formattingMessage() we will be unable to distinguish between arguments that should be formatted into the string vs. arguments that are to be sent up to our servers.



Suggested implementation:
Timber can support generics when logging in order to define a specific log format that the downstream trees can listen and consume.
i.e.
e(T logMeta); -- where the generic T is a instance of LogMeta (can implement a common interface defined in Timber i.e. LogMeta)
public interface LogMeta { }
Using this interface the consumer can create a log meta-data class
public class MyLogMeta implements LogMeta {
	public MyLogMeta(String msg, Throwable tr, Map<String, String> extra);
}
then on the client the following call can be made
Timber.e(new MyLogMeta("message",new Exception(),new HashMap<String, String>()));
we can create a tree with the following method signature to intercept the log statement
public class MyLogMetaTree implements Timber.Tree {
    ...
    protected void log(MyLogMeta meta) {
        // do something
    }
}
This way the consumer can define the metadata it expects for one or more of its trees downstream.

Duplicate issue #394: Setting custom keys/properties on the trees through Timber API
Created: 2020-07-07T09:29:28Z
We created a Tree wrapper for FirebaseCrashlytics and other error reporting libraries.
Most of those libraries support setting a custom key/value properties for example FirebaseCrashlytics.setCustomKey.
It would be really helpful to extend the Timber api to allow such a functionality.
For example by introducing
Timber.setCustomKey(String key, String/int/float.. value) and  Tree.setCustomKey(String key, String/int/float value) methods. Calling Timber.setCustomKey will simply delegate the calls to all the planted trees.
I would gladly create a PR if this is something that you may be interested in...

Closing comment (2021-08-06T21:08:05Z): Tracked by #184