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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 10 2018
i feel unethical
Apr 9 2018
How often does the size directive in a logrotate script get evaluated?
Maybe vertical-align: top? Or display: inline-flex?
yikes
FYI Chrome/Windows after the change (extra whitespace added?)
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.
This feels a bit like a return to the era of "epriestley design", but I think it's an improvement overall:
Still needs work:
Apr 8 2018
I don't currently plan to pursue this. We haven't seen interest from other installs and I think the upstream behavior is reasonably good most of the time and not a huge issue even when we get it wrong (you can still review the file without doing anything, and can get highlighting with a few clicks -- plus, the file and page render much faster).
- The secret $1-2,7-9 syntax for highlighting multiple noncontiguous blocks of lines in Diffusion is no longer supported.
Apr 7 2018
im super ethical https://github.com/PoE-Profile/poe-profile/pull/20
A related attack is a bare whatever.patch file which writes to .git/config or .hg/hgconfig or whatever.
In Safari we get this marvel:
Apr 6 2018
Apr 5 2018
This will ultimately be covered by T13105.
Effectively now covered by T13105.
See T13105 for browse cases (and perhaps diff cases, eventually).
- 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):
Apr 4 2018
I don't currently plan to pursue this.
We now support emoji; we might support stickers at some point. If we did, I'd expect them to use the autocomplete element (which I think is in a relatively good place for emoji), not actually be invoked with :P, ^-^, etc.
Since there's no known actual problem with this today, I don't plan to fix it.
