Hmm... we do have the concept of Event Policies that do the second thing you described (filter on the manager side from console/storage/rules), but they are mostly global based on event type (e.g. all logons) OR hardcoded (e.g. all interactive logons or windows filtering platform events) to big buckets.
On the agent side, the only thing that does filtering right now are the connectors themselves, but since there's not really an exposed way for you to edit or create a "rule" in a connector, I think you're stuck there, too.
So we're really close, but I'm not sure there's a really good way. Most people in this situation are able to filter them from hitting the security log, so we can kind of cheat.
Is there a list of which events are filtered by the following LEM Connectors:
Windows Application Log
Windows System Log
Windows 7/2008/Vista Security Log
I can setup a filter in LEM based on the Tool Alias to find out which events are being passed through from the Agents but it would be far easier to have the full list to hand to see at a glance which events are filtered on the Agent side by the above Connectors and which are normalised and passed through to LEM. (e.g. Citrix XenApp 6.5 logs many events to both Windows Application Log and Windows System Log and it would be useful to see at a glance which event IDs are being picked up and normalised by the Agent Connectors and which events are being filtered/discarded and not passed to LEM.)
There hasn't been a list published, though the team may be looking at it. The only way you can sort of "reverse engineer" this list is in the connectors themselves. Each connector has patterns that match by event ID and source. It might be a little tough to extract that data, since some patterns are grouped together. There is a master list of which eventIDs are passed through the connector at the top of the connector (it's an element that looks like "eventIDs=" and may honestly just say eventIDs="all" - which means any eventID COULD pass into the connector, but there could ALSO be later filtering that drops it, which makes it complicated).
I have raised this too with the guys from SolarWinds on the stand at InfoSec in London and with the LEM support department manager in the US
it would be a huge benefit to us too
We have a similar issue looking for privileged logins when we have applications that login to the servers every time the user interacts with the application. In some cases the application manages the user login and an the application uses a master login to connect to the backend or database server, so we get thousands of login events for user accounts that we aren't interested in.