Closed felipejfc closed 7 years ago
I've thought about this a few different times. Currently, we dont separate the log data in such a way that would allow us to easily recall it like this. We would have to change how we store the data in memory and redis to also be based on process type.
What would the behavior be if you just typed deis logs
in that situation? Interlacing the data once it has been separated would be incredibly difficult.
In kubernetes, kubectl logs pod
requires user to tell what container he wants the log if the pod contains more than 1 container. We could do something like that...
Or maybe show the logs for the routable process type by default but inserting some message before the logs, like:
$ deis logs -a someapp
Showing logs for process type cmd, for viewing logs of another process type use -p option
...
...
...
...
Or, yet another option:
$ deis logs -a someapp
**CMD LOGS**
...
...
...
...
**WORKER LOGS**
...
...
...
I think that any of the options is better than mixing the logs like we are doing today, what do you think?
I'm not sure I like either of those approaches.
In an app that has sufficiently long log trails for multiple proctypes it would be difficult to distinguish where one section starts and another begins. This is why interlacing is preferred.
What might be better would be for us to append the proctype to the logline so it shows up and can be easily grepped out.
INFO [bar-web]: waited 30s and 1 pods are in service
INFO [bar-cmd]: waited 30s and 1 pods are in service
@helgi @mboersma what do you two think
Hm, I think I agree with you... Attaching the proctype would be nice :)
That'd work out fine yeah. Tho I must admit I kinda like the idea of being able to query per proc type
@felipejfc my above solution about appending the proc type to the log format is coming soon. The pr is open just waiting for reviews.
fixed in #123
E.g.
deis logs -a someapp -p cmd
or deis logs -a someapp -p worker
This would give better visualization of the logs for an app with many process types
regards