What it is for
What applies to the whole of meulog in this account.
Identity
- Customer label: whoever installs it does not always say "company". Agency, Store, Branch, Client. It changes across the whole interface and in the alert messages.
- Time zone: it matters more than it looks. Several bug report formats declare no time zone at all in their dates, and meulog reads them as local time. The wrong zone shifts the "when it breaks" chart and makes the filter period catch the wrong day.
Retention and purging
Five policies, one per kind of thing stored, each with its own schedule:
- Whole occurrences: the event rows.
- Evidence: .eml and attachments. They weigh the most on disk, and a short schedule here usually solves space without losing the count history.
- URL checks and job heartbeats: the monitoring history. It grows an order of magnitude faster than everything else, which is why it has its own, shorter schedule.
- Run and cycle history: each job pass and each mailbox sweep, with what it returned.
- Application log: what came from a log fetcher.
Each policy has a button that says how many rows would go now without deleting anything. A purge schedule is the easiest setting to get wrong by one zero, and the most expensive.
Before deleting an occurrence, meulog has already condensed its day into one row: how much, from whom, on which version. It loses the callstack, the hour and each customer name, and that is the trade. The trend charts keep existing after the detail is gone, which is why you can have a short schedule without losing the story.
Where the attachments live
Disk, S3, Google, Azure or a mirror, by environment variable. It has its own entry: Evidence.
Backup
With one database per account, a backup is a file copy. Except that copying a SQLite
file in use with cp gives you a file that opens and
lies: it can be copied mid-write.
meulog uses VACUUM INTO, which is SQLite itself writing a new,
consistent database without locking whoever is writing. It comes out smaller
than the original. On Postgres it is pg_dump, for the same reason.
It runs on its own. It used to be a button and a
rake task, and nothing else — whoever forgot to press it had no
copy, and nobody notices they have no copy until they need one. It is a daily
routine now, with the hour and how many copies to keep on this screen. The
default is 3am, an hour before the purge: copying after
deleting keeps a database that already lost what the purge took.
A copy that is turned on and has produced nothing for two days becomes a finding in the configuration check-up. It is the quietest defect there is: the routine fails, nobody looks, and the gap shows up the day someone needs to restore.
The second copy, where the first one cannot reach
The copy sits on this machine's disk, and that protects against the common cases: a table dropped by mistake, a bad migration, someone deleting what they should not. It does not protect against the machine going away, which is the rare and total one.
That is what the vault is for, under
Parts: turn one on and every
nightly copy goes up right after it is written, with the old ones pruned there
too. The first one is an S3 bucket — and anything that speaks S3 works, which
is what keeps one vendor from locking anyone in: an empty
endpoint is Amazon, a filled one is Cloudflare R2, Backblaze,
MinIO or Wasabi.
A vault that fails does not bring the copy down. The local one is already on disk, and an expired credential cannot make meulog stop copying — what failed is written on the Processes screen.
Run now
Three buttons that do not wait for the schedule: read the inputs, purge, analyze. They exist to prove the configuration works without waiting for the night.