We log to graylog to keep a searchable overview. Logging directly with the docker GELF driver resulted in a ton of hard to read messages with metabase, because e.g. every line of a Query or Exception trace that got logged was its own message.
Relevant excerpt of our solution, on the Metabase service in docker-compose
:
1 volumes:
2 - ./logstash-gelf-1.12.0.jar:/gelf.jar:ro
3 - ./log4j2.xml:/log4j2.xml:ro
4 environment:
[…]
11 - MB_EMOJI_IN_LOGS="false"
12 - "JAVA_OPTS=-Xms1G -Xmx1G -Dlog4j.configurationFile=file:/log4j2.xml -cp /gelf.jar:/app/metabase.jar metabase.bootstrap; echo"
So, (L.2-3) Mount a log sink jar and the corresponding log4j2.xml into the container. Then (L.12):
- (LSet log4j to use the mounted config
- Set the Classpath to the alternative log sink jar and metabase itself
- Set the same bootstrap class as the
META-INF/MANIFEST.MF
in the Metabas JAR would - Deactivate the rest of the command line with
; echo
[1]
Question for Metabase staff potentially reading this: How robust should this be to changes? E.g., is the bootstrap namespace expected to get renamed at some point?
[1] basically a SQL injection attack, but for a command line (the echo
is actually superfluous since this will never get called – exec
replaces the process image and never returns, but it’s a bit more robust to changes in invocation structure that way since it will only print should the rest ever get called)