Closed nj0yeh closed 4 years ago
Thought about this a little but and I'm not sure it shouldn't be a property in the spec per service. Seems odd to configure that per service rather than per invocation of m8s
. Do you need the ability to configure it per service?
Actually yes. When automatically parsing the logs, it should be able to parse the log of specific services, while it should also be possible to consolidate different (other) services into one log file.
Another possible solution would be to add a web request to m8s to ask for the logs of one or more running services. Would be more complicated to integrate into the bash files, but perhaps better from an architectural perspective. If this is the solution of your choice, you should also be able to specify an oldest timestamp to be queried.
You can have log files per service without specifying paths for each. You would pass a root folder to m8s and then each service would get a folder or file from that base path
I think that would be okay. What do you think about (optionally) writing two log files, one per service and one consolidated? So you could have one big log file that is in the correct chronological order if you want to analyze something.
Would one file be better in your scenario?
Multiple files are better for the automatical parsing of the log files, one file is better for manual analysis of problems. So the optimum would be to have both.
After finishing our migration from Kubernetes to M8s I can now say that it is sufficient to have one log file that contains the output of all processes consolidated.
All progress will be moving to https://github.com/dotnet/tye
We need the ability to collect the logs (stdout + stderr) from every process into one or more files so that other processes can parse the log during lifetime and post-mortem.