Hmmm, then maybe the narrowest way to solve this is to just setup disk space alarms. That's a thing we'd want independent of how we eventually build the One True Logging System. The CloudWatch agent collects disk stats out of the box, and takes a list of mountpoints to track. Details here: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html

I think "run weekly with the deploy" already works pretty well for normal log rotation with logs on local disk, and in a perfect world logs would be buffering on disk only briefly before being sent over the network to dedicated log service so we wouldn't need cron there either.

How often does the size directive in a logrotate script get evaluated?

Yeah, I think "solve it forever" is probably "first-party Sentry-like application", this just seems like a problem that should have a 15-minute "solve it for now" solution in the form of something that gives us "a thing that looks like a disk but never fills up" that will hold for a year or two until we build "Phentry".

That makes sense. I was coming at it more from the direction of “if we’re going to touch logs, lets solve it forever”. How about we make everything log locally through syslog and use logrotate to avoid filling disks? Then we can come back and point syslog at something more elaborate later without having to touch all the things that currently generate logs.

I believe there are zero or nearly-zero actionable errors in the log today and that if we had a perfect Sentry-like system it wouldn't actually help us identify or fix any errors -- we'd just ignore it after a week like we currently ignore all the other production error logs.

There's some flavor of bin/remote ssh <some-host> -- tail -f <some-log_location>.

The "logs fill up disks" problem is more "sudden bursts of unusual error/activity that cause log rates to increase 1000x+ fill up disks", not "logs don't rotate / normal log volumes fill up disks". Most logs do already rotate today, I think with the exception of the aphlict log being a bit of a weird case, maybe.

phage tail <some-instance-name> <some-log-type>

But I don't think this is too valuable if it doesn't solve the "logs fill up disks" problem -- does the agent rotate/reap the logs?

In my mind, the only real problem here is...

Possibly something dumb like "mount an EFS volume on /mnt/logs/ on every host" is another AWS-only approach. That feels really dumb but maybe it's only somewhat dumb?

I'm fine with CloudWatch logs, I didn't realize it had a logging thing. I'm currently not terribly warm on investing a ton in CloudWatch alarms or log analysis, but if we can get logs reliably streaming into some storage service so they can't fill up the disk I think that's quite valuable on its own. We can always replace that with something we control directly in the future if we want to invest more here. I can't imagine ever really caring about old logs no matter what happens in the future.

I definitely don't want to send logs to a third-party service.

In the modern era: I think we generally understand what private clusters will look like now, but I'd like to take a much more iterative approach to getting there than we have in the past. I had this concern above (circa June 2017):

Multiple installs would like API access to edit Almanac bindings.

Still needs work:

• The secret $1-2,7-9 syntax for highlighting multiple noncontiguous blocks of lines in Diffusion is no longer supported.

• If a file is non-UTF8, we should try the repository's "Encoding" as a default (or maybe just remove this feature).

Junk I'm about to break in Diffusion (but plan to restore):

This script can back-populate revision sizes that haven't been updated since D18832:

where I plan to explore the [----++ ] element

Some states:

• shouldBroadcast() has been removed; getShouldBroadcast() now means the same thing.

• getHasBroadcast(), setHasBroadcast(), and PROPERTY_HAS_BROADCAST are now getShouldBroadcast(), etc.

• Implementing BuildableInterface now requires implementing newBuildableEngine().
• Implementing BuildableInterface no longer requires implementing getHarbormasterPublishablePHID(). Publishing indirection is now handled by BuildableEngine.
• PhabricatorTransactions::TYPE_BUILDABLE no longer exists. Instead, applications should implement application-specific modular transactions to report build status information. DiffusionCommitBuildableTransaction may be useful as a template.

I'd like to analyze data on the $5 tier with an eye to removing it. Anecdotally, this doesn't seem to be doing anything good for us ... It also feels like we have a lot of $5 test instances.

The UI and allocation logic for shards need tweaking.