Auditty vs Edge Delta

In steady state, 60 to 80 MB of memory per node. The agent also ships with an enforced ceiling of 768 MiB and 1.5 vCPU, which it cannot exceed however much log volume you put through it, so the typical figure is what you should expect and the ceiling is what protects you if you are the exception.

That headroom exists for sustained back-pressure, where the worst case we size for is around 420 MB, rather than for normal operation. Consumption is flat with respect to log volume rather than proportional to it, so a tenfold burst in logging does not become a tenfold burst in the agent, and it does not degrade into unbounded growth when a cache or buffer fills.

Both figures are the defaults in the Helm chart, and you can lower them. On a high-pod-density node the guidance goes the other way: raise the ceiling or reduce the event buffer.

No. It runs with two scoped Linux capabilities, DAC_READ_SEARCH and SYS_PTRACE, rather than in privileged mode. Reading other containers’ output does require host-level access, and those two capabilities are the whole of what that takes.

Concretely, the agent needs read and write access to the node's container log directory, so that it can intercept each container's output and put the reduced stream where kubectl logs and your log shipper already read, and read-only access to process information on the host, so that it acts only on containers that are running.

Auditty does not exec into containers, read application memory, modify workloads, or touch logs for pods outside the rules you wrote. A container Auditty was not asked to handle is left alone.

Your log data is stored in your own Amazon S3, Google Cloud Storage or Azure Blob Storage bucket, under a prefix you choose, compressed and partitioned by time in an open format your own tools can read. Auditty never holds a copy.

Retention is whatever your own bucket lifecycle policy says, because it is your storage and your billing relationship. Auditty applies no retention limit and takes no storage margin.

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.