Auditty vs Grepr

Sampling and drop filters destroy data permanently, so they force you to decide in advance which logs will matter during an incident that has not happened yet. Auditty never destroys anything: a suppressed line is still written in full to your own object storage, and can be retrieved later by pattern, time range or field value.

That difference changes how aggressively you can reduce. With sampling, cutting 95% of volume means accepting a 95% chance that any specific line is gone. With Auditty, cutting 95% of forwarded volume costs you nothing but a lookup if you later need one of those lines.

No. What leaves your cluster is log templates, the shape of a line with all values masked to placeholders, plus counts, rates, timing and node, namespace and workload names. A template records that a line of a given shape occurred, not what was in it, and cannot reconstruct the original.

This holds for anomalies too. When a pattern is seen for the first time or its rate spikes, what reaches us is the template and the rates, which is enough to alert you and to identify the pattern. It is not a sample of your logs.

Reading the lines themselves is a request you make: a retrieval is served out of your own bucket, by a component running in your own account, returning only the rows you asked for. Everything forwarded to your own SIEM or log vendor goes there directly and never passes through Auditty either way.

Yes, in seconds, and without scanning the archive. Every suppression summary links to the raw lines behind it, and following that link returns the actual log lines. The archive is indexed so that a retrieval reads only the small part of it that can contain matches, however large the bucket has become.

You can narrow a retrieval to a single field, such as a latency above a threshold or one specific tenant, and only matching rows are returned. Retrieval also covers the present moment: data too recent to have reached storage is still returned, so there is no blind spot over the last few seconds.

Your logs keep flowing. Restoring your log pipeline is the very first thing Auditty does on the way out, ahead of any of its own cleanup, so the file your log shipper watches is working again within milliseconds, before the process has finished exiting. After an abrupt kill or a node reboot there is nothing to repair by hand either: the same restoration happens automatically, in milliseconds, and removing Auditty entirely leaves your logging exactly as it was before you installed it.

If the connection to the control plane fails, nodes continue running the last rule set they successfully validated; an empty rule set is never synthesised from a failure. If your object storage becomes unreachable, suppression stops automatically, so events are forwarded rather than summarised into an archive that is not accepting writes. You get a larger bill rather than a gap in your data.