We might also get a performance increase if store the logs inside the guest. You'd have to ssh in to look, but is that a big deal?

By turning off $wgDebugLogFile (set it to an empty string in a setting.d override file), I was able to switch from spending *most* of the time logging, to almost none:

55.51% 2712.461 44 - MWLoggerLegacyLogger::log

to:

0.09% 2.496 54 - MWLoggerLegacyLogger::log

These tests were on Zend and NFS.

If you don't use this file, I highly recommend disabling it, especially if you're on NFS.

In T92595#1115677, @Mattflaschen wrote:

We might also get a performance increase if store the logs inside the guest. You'd have to ssh in to look, but is that a big deal?

People have asked for more and more to be on the host OS rather than in the VM. What we could possibly do to make access to logs easy however would be to build something similar to [[https://devcenter.heroku.com/articles/logging|Heroku's log command]]. That might actually be more useful new MediaWiki users and developers than the current setup.

In T92595#1115728, @bd808 wrote:

People have asked for more and more to be on the host OS rather than in the VM. What we could possibly do to make access to logs easy however would be to build something similar to [[https://devcenter.heroku.com/articles/logging|Heroku's log command]]. That might actually be more useful new MediaWiki users and developers than the current setup.

I like the idea of a unified vagrant log command. Could we use logstash for this, or is that too bloaty?

In T92595#1117171, @dduvall wrote:

I like the idea of a unified vagrant log command. Could we use logstash for this, or is that too bloaty?

Logstash would make implementation easier. It is pretty bloaty however. Logstash is a JRuby app that needs a reasonable JVM heap to work and the default backend of Elasticsearch is a second JVM based app with even more hunger for RAM. I think we could make something much lighter. It really could be a multi-tail of a list of log files that can be curated by Puppet somehow. The access from outside the VM would be the equivalent of vagrant ssh -- /usr/local/bin/fancy-tail-script.

In T92595#1117223, @bd808 wrote:

I think we could make something much lighter. It really could be a multi-tail of a list of log files that can be curated by Puppet somehow. The access from outside the VM would be the equivalent of vagrant ssh -- /usr/local/bin/fancy-tail-script.

That sounds one thousand times more reasonable.

For fancy-tail-script, we could use puppet concat so that roles add log files that should be tail -f-ed. These are all collected in a single file, and then a one-liner could tail them:

tail -f $(cat puppet_managed_file)

Maybe it wouldn't be bad to think about some compartmentalisation, per role, per level or a combo of both. If each role adds a couple of files to tail, that can quickly become useless.

In T92595#1119700, @mobrovac wrote:

For fancy-tail-script, we could use puppet concat so that roles add log files that should be tail -f-ed. These are all collected in a single file, and then a one-liner could tail them:

tail -f $(cat puppet_managed_file)

Maybe it wouldn't be bad to think about some compartmentalisation, per role, per level or a combo of both. If each role adds a couple of files to tail, that can quickly become useless.

Puppet concat is overkill for something like this I think. I'd propose a config directory like /etc/mwvagrant-tail that each role and service can add a config file to. The driver script can easily be smart enough to concat the various files at runtime. This would also expose the ability to list all the configured log collections (e.g. vagrant log --available) and to select a subset of them for viewing (e.g. vagrant log --source apache2).