Event filters: a console you can actually read

A busy network produces more events than anyone can read. A campus with a few hundred switches can log a link change every few seconds during the working day, and almost none of them matter to the person on shift. Filters turn that stream into a view that fits one job: the night operator, the server team, whoever is chasing a security question.

A filter is a saved query against the event and alarm data. It changes what you see. It does not change what is stored, what opens alarms, or who gets notified. Keeping that line clear avoids the worst filtering mistake, which comes up below.

What a filter is made of

Every filter, in every tool, comes down to conditions joined with AND and OR. Each condition has three parts:

• A field: host, host group, site, object, event type, severity, state, acknowledged or not, source, time, message.
• An operator: equals, not equals, greater or less than (for severity and time), contains or matches a pattern (for names and message text), in a list.
• A value: critical, core-routers, last 24 hours, Gi1/0/4[0-8].

Evaluation order is where filters go wrong. "Type is login OR type is config change AND host group is core" means different things depending on whether AND binds tighter than OR (it does in SQL and most query languages) or whether the tool reads rows top to bottom, as some older consoles do. If your tool offers brackets or nested groups, use them. If it only has a flat list, test with a known event before trusting the result.

If your events live in a SQL database, a filter is just a WHERE clause, and writing one out makes the logic plain:

SELECT ts, host, object, type, severity, message
FROM events
WHERE (type = 'login' OR type = 'config_change')
  AND host_group = 'core'
  AND ts > now() - interval '24 hours'
ORDER BY ts DESC;

That time expression is PostgreSQL syntax; MySQL writes it as NOW() - INTERVAL 24 HOUR.

Filter, suppress or alert: three different jobs

The classic mistake is a filter doing suppression's job. An operator hides a noisy host from the shared default view "for now". A week later the host fails for real, and nobody sees it because the default view still hides it. If something should be quiet for a while, use a maintenance window or a suppression with an end time. If something is noisy forever, fix the event rule or lower its severity. Keep filters for choosing what to look at. Who gets told is covered in triggers and actions.

Five filters worth saving

These suit almost any console. The expressions are written in a neutral form; translate them into your tool's query box or filter builder.

1. Unacknowledged critical: severity >= critical AND acknowledged = no AND state != ok. The default view for whoever is on shift. If it is empty, the shift is quiet. If it is long, nobody should be reading anything else.
2. Core routers only: host_group IN (core, wan-edge) AND severity >= warning. For the network team during an incident, when hundreds of access-layer events are noise. It only works if host groups are kept current, one more reason to organize hosts with care.
3. Hide maintenance windows: in_maintenance = no. Most tools mark events from objects in a scheduled window. Add this condition to the shift view so planned work does not crowd out real problems, and keep a separate "maintenance only" view so whoever runs the change can watch their own work.
4. Hide known-noisy interfaces: NOT (type = link_state AND object_tag = user-port). Desk ports flap whenever a laptop sleeps. Tagging user-facing ports once is cleaner than chasing them by name. Review the tag list each quarter, because a "noisy" port that has since become an uplink is exactly what you must not hide.
5. Authentication failures, last 24 hours: type = auth_failure AND time > now - 24h, grouped by source address. For the question that comes up every Monday: who tried to log in to what, and from where. Grouping by source makes a password-spraying run stand out from one person mistyping three times.

Time ranges and sorting

Time is the field people get wrong most often, so it deserves its own note. Use relative ranges ("last 4 hours") in saved views and absolute ranges ("Tuesday 02:00 to 04:00") only for one-off investigations. A saved view with an absolute range quietly goes stale the next day.

For alarms, decide which time you mean. "Opened in the last hour" and "seen in the last hour" give different answers: an alarm opened yesterday that is still firing appears in the second and not the first. Shift views usually want "still open, newest activity first". Reports want "opened in the period".

Finally, check the time zone. Events are best stored in UTC, but a branch operator reading "03:15" expects local time. A filter written in one zone and read in another is a common source of "the event is missing" tickets.

Saved views per team

Once the filters exist, save them as named views and give each team a sensible default:

What the shift does with its view is covered in working the monitoring console.

Name views by purpose ("Shift: open problems"), not by owner ("Alex's view"), and keep the list short. A console with forty saved views has the same problem as one with none: nobody knows which view is telling the truth.

Test every new filter once

Before sharing a filter, make it prove itself. Send one test event that should match (a test trap, or a logger line from a host in scope) and one that should not, then check that the view shows the first and hides the second. Finally, write the purpose in the filter's description field. Six months from now, that one sentence is the only thing that explains why a view hides what it hides.