The activity log: a record of decisions, not traffic

Four things, because judging a decision needs all four.

What was asked for. The URL path, the HTTP method, and the shape of the request, which is what lets you recognise whether this was somebody using your site or something probing it. A request for a path your site has never had tells you something on its own; a request for a form your customers use every day tells you the opposite.

What matched. Which rule fired, since a decision you cannot attribute to a rule is a decision you cannot change.

What happened. Whether the request was recorded and forwarded or recorded and refused. In monitor mode the record says what would have happened, which is the entire reason the mode exists.

Enough context to tell a person from a machine. The surrounding activity matters more than any single field: a flagged request sitting inside an ordinary sequence of successful ones reads differently from one arriving alone, which is the pattern false positives is read for.

Flagged requests reach the log in batches and arrive near-real-time, which is what makes reading the record practical while the traffic that produced it is still current rather than as a historical exercise.

This matters enough to state plainly, because the log looks like something it is not.

It is not a traffic overview. It is not a count of attacks by volume, and it is not a view of volumetric attack figures of any kind. It is not a general analytics surface, and it is not a dashboard for the class of attack measured in bandwidth rather than in requests.

The reason is a missing denominator rather than a missing feature. The log contains flagged requests, so it knows nothing about the requests that were not flagged, and every ratio you might want, the share of traffic affected, the proportion of visitors refused, the fraction of attacks caught, requires the part it does not have. A record built to answer a decision question cannot be extended into a measurement surface without becoming worse at the job that made it useful.

That mistake misleads in both directions, which is what makes it expensive. A rise in entries can mean more hostile traffic, or it can mean a rule you added last week matches something ordinary. A fall can mean the attacks stopped, or it can mean a rule stopped matching what it used to. Neither reading is available from the log alone, and neither is safe to report.

Three questions, and they are the ones to ask.

Was this decision right? The original purpose. One entry, its context, and a judgement about whether that request should have been refused.

What does this rule do to my site? Group the entries by rule and by route. Concentration on one path usually means a collision with your own content rather than a pattern of attack, which is the distinction that decides whether you write an exception or leave the rule alone.

What changed since my last configuration change? Compare the same rule and the same route before and after. This is the only comparison in which the denominator is stable, because you are measuring your own edit rather than the behaviour of the world.

Three questions people bring to it anyway.

How much traffic do I receive? Answered by whatever measures all requests, not by a record of the flagged ones.

Was I attacked, and how large was it? Volume questions belong to volume measurement. A record of individual flagged requests is the wrong instrument for something described in bandwidth, and reading it that way produces confident numbers with nothing underneath them.

How many customers did this cost me? The log shows refused HTTP requests, not people. What a refusal cost is visible in the business signal for that route, completions, orders, successful calls, which is why that signal is watched alongside the log rather than after it.

Its role changes between modes even though its contents do not.

During observation it is a list of predictions: what would have been refused, read to build the exception list before anything is enforced. That is the work described under monitor mode, and the exceptions it produces are written calmly, with dates, as exceptions sets out.

After enforcement begins it becomes a list of events: what was actually refused, read to catch the collisions that observation missed. Same entries, same fields, different question, and the second job never fully ends.

Establish one thing early: how far back the record goes.

Reports about refused requests arrive late. Somebody could not submit a form on Friday, mentions it on Tuesday, and the investigation depends entirely on whether Friday is still in the record. Find out what the retention is while nothing is wrong, and if it is shorter than the delay at which your reports typically arrive, arrange to keep what you need elsewhere before the first report rather than after it.