Allow differenciation when several log files are tailed
I am using dockerize (right now for the templating feature), and considering how to proceed with logs.
Using several -stdout options I can ship several logs to stdout, however the result in docker logs is interleaved from the several input files.
Would it be possible to optionally prefix each log line with a tag to distinguish which log cons from which file ?
What is your use case?
I mean, in most cases I've seen log contents makes it clear enough about which app produces that log, and nearly all services running in docker are able to write logs to stdout and thus don't need dockerize for this. But your case sounds like you've several apps which are both unable to write logs to stdout, produce similar logs and runs at same container - which is sounds unusual to me.
I am building a container with apache and shibboleth (SAML service provider solution). Shibboleth consists in an apache module + a standalone service handling the heavy lifting. Both write to various files.
We already have some settings in place to ingest docker logs to ELK stack, but need dedicated filebeat connfiguration then to target each application's logs.
Shipping all logs to STDOUT would allow me to simplify the log ingestion, but the resulting mess is not very easy to analyse :)
Okay. So, how you imagine this feature to work? Naive implementation probably will just prefix log lines with log file path (e.g. like grep does - /path/to/file.log:logged text). But log lines usually begins with date in some format, and having log file name before date may be not really convenient. What do you think?
I was thinking of
- grep like result (indeed)
- perhaps a way to provide a tag to act as a prefix (instead of using my/way/too/long/full/path/complicatedFileName.log as prefix)
- pm2 offers similar features (I do not remember how customizable it is, but I remember that when displaying the logs of many processes, the name of the process is prepended by default)
I do not think the prefix being ahead of the timestamp should be a big concern ? It should be easy to prune after initial triage has been done if we do not want to see it in the final logs accessible to the admins.
That being said, your initial reply prompted me to look into other directions: it seems that at least for httpd I can update the configuration to add my prefix directly at the source. This makes me wonder whether what I thought as an obvious feature initially is really that needed. So I am going back to do some more homework and reassess how much I would need this