I'm a bit confused by (1). Isn't it actually more complicated for you to restrict log collection to a relative path? Why not just look for log files no matter where they are written to? I also don't really follow the argument about why a user that writes to /var/logs is not going to want to use this command. Won't all users want to be able to gather their logs using this command?
2 seems reasonable. It seems like we should restrict the file names if we are going to have this limitation. -Dan On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao <jil...@pivotal.io> wrote: > Hello community, > > We are currently trying to improve what "export logs" should do. Currently > export logs only export the logs(filtered by logLevel and start and end > date) to each individual member's file system. We want to make all the > member's logs exported to a central location and if you are connecting > using http, it will be exported to your local file system. This is to > facilitate gathering logs in the cloud environment. > > That said, for the first round of implementation, we would like to impose > these restrictions to this command: > 1) it will only look for the logs/stats in each members working directory > only. > 2) it will only look for files that ends with .log, .log.gz, .gfs or > .gfs.gz. > > Background for 1): if you started your locator/server with "log-file" or > "statistics-archive-file" with an absolute path, it will write these files > to that location, but if you simply give it a relative path, the files will > be written to the member's working directory. The reasoning behind 1) is > that this command is mostly for those environment that you can't easily go > to the member's filesystem to get logs, but if you have started your > server/locator with an absolute path like "/var/logs", we are assuming you > already know how to get the logs, thus this command to not mean much to > you. > > For restriction 2), since logs and stats files roll over, it is much easier > to find the target files with extensions rather than file name patterns. We > could either do not allow you to start server/locator with other file name > suffix or post a warning. We would need the community's input on this. > > Any feedback is appreciated. > > -- > Cheers > > Jinmei >
