How do you keep only the NAT records out of everything syslog sends?

Filtering can happen on the router, somewhere in between, or at the collector, and the three trade bandwidth against flexibility in different directions. What decides the outcome is not where you filter but what you decide counts as noise, because one of the streams people discard first is the one that turns an address into an account.

What is actually arriving when a router points at a collector?

Everything the device has an opinion about. Translations are a small share of it, and on a busy evening they are buried in traffic that has nothing to do with the question you set this up to answer.

Only the highlighted block is a translation. The rest is a login, an address handout, an authentication, a wireless event and a reboot notice, and all of it arrives over the same connection at the same time.

The proportions shift with the network. A router carrying subscriber sessions produces a steady stream of connect and disconnect events. One carrying wireless backhaul produces its own. What stays constant is that translations are the minority and the majority is not useless, merely unrelated to this particular job.

Where can the filtering happen, and what does each place cost?

Three places, and the choice is a trade rather than a right answer. Filtering early saves carrying things. Filtering late keeps the option of changing your mind.

The three places to cut, and what each one takes from you

Where	What it saves	What it costs
On the router, by choosing what gets sent	Bandwidth on the management link and work at the far end	Anything not sent is gone. Changing your mind means touching every device
In between, at a relay	One place to change the rules for the whole estate	Another machine that has to be running, and a new place for things to stop silently
At the collector, on arrival	Nothing is lost before you decide, and rules change in one place	You carry and inspect the whole stream, including the parts you discard

Small networks usually do best filtering at the collector, because the volume is modest and the freedom is worth more than the saving. Larger estates end up doing some of it at the source, purely because carrying every wireless event across a constrained link stops being sensible.

The arrangement worth knowing about is neither of those. Most equipment can send different categories to different destinations, so translations go one way and the operational chatter goes another, and each stream is kept on its own terms without either being thrown away.

One caution about splitting streams. Two destinations means two things that can stop, and the one nobody watches is the one that stops quietly. Whatever split is chosen, both ends need the same weekly glance, because a stream that arrived reliably for a year is exactly the stream nobody checks.

What happens when the filter is drawn too tightly?

You lose records without any indication that you have. A filter that matches on a narrow string keeps the lines that look like the example somebody tested it against and quietly drops every variant.

The variants are real. Lines carrying no ports at all look different from ones that do. Lines describing traffic arriving from outside are shaped differently from ones describing traffic leaving. Some are complete records and some answer nothing, and telling them apart in the raw is worth doing before writing a rule that assumes one shape.

The failure is silent in both directions. Nothing errors, the collector reports healthy, the record count looks plausible because it never had a baseline, and the gap only appears when somebody searches for a period and finds a category of traffic missing from it.

The defence is to check what a filter rejects rather than only what it accepts. Watching the discard stream for a few minutes after any rule change tells you immediately whether you drew the line where you thought you did.

Rules written against a live sample age badly for a second reason. A filter tuned on an evening of ordinary browsing has never seen what the stream looks like during an incident, when one customer generates an unusual shape of traffic and the lines describing it are precisely the ones somebody will ask about.

Which lines look like noise and are not?

The ones announcing that a subscriber connected or disconnected. They carry no addresses being translated, they arrive constantly, and they are the first thing most people cut, which is unfortunate because they are half the answer.

A translation record ends at an internal address. Turning that into a customer means identifying whichever customer was using that internal address then, and on many networks the only surviving evidence of that is exactly these connect and disconnect events. Discard them and you are left with perfect translation records that stop one step short of naming anybody.

Three categories deserve that same protection, and they are easy to name.

• Subscriber connect and disconnect events, the only surviving note of who sat on an internal address and for how long
• Address handouts, which serve the same purpose where subscribers are not authenticated individually
• Restarts and lost time sources, which explain gaps and cast doubt on timestamps before anybody else raises it

Everything else is genuinely optional. Wireless association noise, routing protocol chatter, administrative logins to the router and interface flap on internal links can all go without affecting your ability to answer a question about a connection.

There is a simple test for whether a category is safe to drop. Ask whether it would appear anywhere in the working of an answer you might have to defend later. Translations appear. Session events appear. A wireless client roaming between access points does not, and never will.

What does keeping everything cost instead?

Search speed first, which is the cost people feel. A store holding several times more rows than it needs answers every query more slowly, and the slowdown arrives gradually enough that nobody attributes it to the decision that caused it.

Then it costs you retention, indirectly. Space filled with wireless events is space not holding translations, so the period you can cover shrinks in proportion to how much unrelated material you kept. The trade is silent and it is always running.

The third cost is judgement. A store full of everything invites people to search it for things it was not built for, and results start being quoted in situations where the records were never meant to carry weight.

The fourth cost is the one nobody budgets for, which is attention. Every category kept is a category somebody eventually asks a question about, and answering those questions is unpaid work that grows with the size of the store rather than with the value of it.

Search behaviour changes too, and the change is easy to miss. Where a store carries many categories, people start searching by keyword rather than by field, because that is faster to type, and keyword searches across mixed content return matches from categories nobody intended to include.

What does a sensible arrangement look like?

Two streams, one purpose each. Translations and subscriber session events go into the store that has to survive and be searchable months later. Operational chatter goes wherever your monitoring already looks, kept for as long as troubleshooting needs it and no longer.

Write down which categories sit in which stream, alongside the search procedure itself. This takes a few lines and prevents the argument that follows when somebody discovers a category is missing and nobody can say whether it was excluded deliberately.

Then check the filter after every change to the network, not on a schedule. A new device added, an interface renamed or a category switched off during troubleshooting are the three ways a working arrangement stops working, and all three are somebody making a sensible local decision without knowing what depends on it.