Platform
What actually happens to a log line.
Five stages, all of them on the node, all of them finished before the line would have left your cluster. No queue to operate, no collector tier to scale, and nothing new sitting in the path between your workloads and their log files.
- 01
Interception
In place, not in the path.
The agent filters container logs on the node itself. Your container runtime is untouched and unaware of it, and your log shipper keeps watching the same path it always did — it simply finds the filtered stream there. Nothing is inserted between your workload and its log file and no sidecar is injected, which means Auditty cannot become a new reason your logs stop flowing.
- 02
Classification
Every line reduced to its pattern, in microseconds.
Plain text, JSON and logfmt are all understood without a schema, a parser or a regex from you. Values that vary line to line — identifiers, addresses, timestamps, counts, Kubernetes resource names — are masked out, so ten thousand variations of one log statement collapse to a single identity. The collapsing is aggressive but never lossy in the way that matters: two lines a human would call different are never merged into one pattern.
- 03
Extraction
The specifics are lifted out before the line is collapsed.
As the pattern is recognised, the particulars are kept: levels, status codes, durations, trace and request identifiers, and anything else that looks like an identity — UUIDs, internal addresses, prefixed keys, long tokens. So when a pattern is later summarised, the individual values from the lines behind it are still there to search on.
- 04
Decision
Automatic by default. Yours by exception.
Most deployments never configure this stage. A pattern has to prove itself genuinely repetitive before it is summarised, and sheer volume is not proof — a health check emitted once by each of two hundred pods is read as telemetry, not as repetition. Errors, warnings and fatal levels are never suppressed here at all. A first-ever occurrence, a sudden rate spike, or a numeric value far outside a pattern's established range is forwarded even when the pattern it belongs to is being suppressed. If you do write a rule, it wins outright.
- 05
Delivery
Two destinations, different jobs.
What matters goes to your SIEM or log vendor in real time. Everything — including the lines that were suppressed — is written to your own object storage as compressed Parquet, an open format your own tools can read. It is indexed on the way in, so a retrieval later reads only the fraction of the archive that can contain matches instead of scanning all of it.
The part people don't believe
Summarising ten thousand lines does not mean losing what was in them.
This is the objection every log-reduction tool has to answer, and the reason most of them get switched off after the first incident.
When a pattern is suppressed, Auditty does not emit a count and throw the rest away. The summary carries the specifics: the actual identifiers seen in the lines it replaced — request IDs, trace IDs, tenant IDs, addresses, the values of any field you asked it to keep. You lose the repetition, not the detail.
On top of that, suppression is not blind to content. Auditty learns the normal range of a numeric field on a suppressed pattern, and a value far enough outside it is forwarded on its own — one slow request inside a million fast ones still reaches you. The same applies to a field seeing a value it has never seen before.
And underneath all of it, the raw line is in your bucket regardless. Suppression only ever decides what you pay to forward, never what exists.
pattern GET /api/orders/<id> 200 <num>ms
window 14:20:00 → 14:25:00 UTC
count 15,293
preserved request_id 1,204 distinct
tenant_id 38 distinct
duration_ms p50 12 · p99 480
outliers 1 forwarded separately
└─ duration_ms 8,412 (well outside range)
raw s3://acme-logs/dt=2026-08-20/h=14/Recovery
Getting it back is the whole point.
Ask by pattern
Every suppression summary carries a link back to the lines behind it. One click returns them, out of your own bucket.
Narrow by field
Add a condition on a specific field — a latency above a threshold, a particular tenant — and only matching lines come back. This works on any field in the line, not only the ones a summary happened to highlight.
Including the last few seconds
Data too recent to have reached storage is returned as well, so there is no blind spot at the present moment. You do not have to know or care whether what you are asking for has been archived yet.
Rules
Two jobs, and neither of them is switching the product on.
Everything above happens without configuration. Rules exist for the two decisions the statistics cannot make for you — which workloads Auditty is allowed to read, and the specific cases where you want to overrule what it concluded.
Scope is a whitelist, and it is the one thing you have to decide. Name the namespaces and workloads Auditty may read; every other pod on the node is ignored, including when its log file is visibly broken and Auditty could have repaired it.
Overrides are worth writing only where you disagree with the automatic result. Forcing errors to be kept is not one of those places — they are never rate-suppressed to begin with, so that rule would do nothing at all.
A rule defined on the node beats a fleet rule of the same name, so a central team cannot quietly change what a cluster owner depends on, and the control plane reports every place that is happening.
rules:
# Scope. Auditty reads what you name here and nothing else.
- name: payments-prod
action: intercept
scope:
namespace: payments
# Override. Spread thin across pods, so the automatic pass
# keeps it — but you are never going to read it.
- name: health-probes
action: suppress
scope:
namespace: payments
match:
entryRegex: "GET /(healthz|readyz) 200"
# Override. Info level and repetitive, so it would be
# summarised — but the audit trail needs every line.
- name: access-audit
action: preserve
scope:
workload: authz
match:
entryIncludes: audit.accessOperating it
A fleet you can actually reason about.
Most of the work of running something on every node is not the processing. It is knowing what each node is doing and being able to change it safely.
Rules land in ~1s
A rule saved in the control plane reaches the whole fleet almost immediately — no polling interval to wait out, and no background chatter when nothing is changing.
Local always beats central
A rule defined on the node shadows a fleet rule of the same name, and the control plane shows you which nodes are overriding what. A platform team cannot silently change a behaviour a cluster owner depends on.
Convergence is visible
Each node reports which rule version it has applied, and why it is stuck if it is. You can see the fleet agree, rather than assuming it did.
Nothing lost is checked for you
That everything ingested is accounted for is verified continuously on our side, and a real discrepancy pages us — rather than sitting in a dashboard you were supposed to be watching.
Questions
How it behaves, specifically.
How does Auditty intercept container logs?
On the node, at the file level, without anything being inserted into the path between your workload and its log file. Your container runtime is unaffected and needs no reconfiguration: it goes on writing exactly as before, unaware that Auditty is there.
Your existing log shipper also needs no change. It keeps watching the same path it always did, and now finds the filtered stream there. Because nothing new sits in the network path and no sidecar is injected, Auditty cannot become a new reason logs stop flowing.
Does Auditty add latency to my applications?
No. Auditty never sits in the request path of your application, and it does not touch the write path your container uses to emit logs. Your workload writes its logs exactly as before, at exactly the same speed.
Auditty reads asynchronously, after the line has already been written. Processing is sub-millisecond per line, but even if it were slower it could not delay the process that wrote the line, because that process has already moved on.
What log formats does Auditty support?
Auditty handles plain text, JSON and logfmt. Deeply nested JSON is understood, including awkward real-world shapes: keys that contain literal dots, flattened ECS-style fields, and arrays whose contents vary from line to line.
No schema declaration or parser configuration is required. Auditty works out the structure of each line for itself, and recognises a repeated shape in microseconds.
How does Auditty decide what to forward and what to suppress?
In almost all cases, automatically and without configuration. A pattern has to prove itself genuinely repetitive before Auditty will summarise it, and volume alone is not proof: a message emitted once by each of two hundred pods is treated as telemetry, not as noise. Errors, warnings and fatal levels are never suppressed automatically at all.
Three things additionally override automatic suppression: the first time a pattern is ever seen, a sudden spike in a pattern's rate, and a value far outside the established range for a numeric field you opted to track. So a single anomalous request still reaches you even when the pattern it belongs to is being summarised.
Explicit rules are optional and exist for the two decisions statistics cannot make for you: which workloads the agent may read at all, and the specific patterns where you want to overrule the result. Where a rule exists it wins outright — a line you marked preserve is never suppressed by any automatic mechanism.
When Auditty suppresses thousands of lines, what do I actually receive?
You receive a summary event carrying the pattern, the time window, the count, and the specifics: the actual distinct identifiers that appeared in the suppressed lines — request IDs, trace IDs, tenant IDs, IP addresses — together with the distribution of any numeric field, so you can see the spread of latencies rather than only that there were some. You lose the repetition, not the detail.
The summary also carries a link that resolves back to the original raw lines in your object storage, so the full text of any suppressed line is one click away.
Can I get suppressed logs back later, and how fast?
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 — a latency above a threshold, 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.
How much CPU and memory does the Auditty agent use?
The Auditty agent is capped at 1 vCPU and 256 MiB of memory per node, and those are enforced limits rather than recommended ones — the agent cannot exceed them however much log volume you put through it.
This means it cannot grow into the memory your workloads need during a traffic spike. 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.
The details are all in the documentation.
Configuration reference, rule syntax, Helm values, and the guarantees each component makes.