Push for performance improvement

[mdecrevoisier]

Hi, I would like to suggest the following modification on all subscriptions regarding event size and WEC server performance. The change consists in switching the subscription from "rendered" mode to "events" mode.

Direct impact of this change will be to not collect the "Message" text included on each event, reducing the CPU load on the collector. Indead, the Message, when forwarded, is usually not very important as most of the information is included in the XML. And for subscriptions like Kerberos or Authentication, this can really decrease the performance impact on the server.

For switching a subscription to this "optimized" mode: wecutil ss <subscription_name> /cf:events

For changing this parameter inside the XML: <ContentFormat>Events</ContentFormat>

Please let me know if this make sense for you so I will make a pull request.

[JPvRiel]

I've also wondered about the trade-off of rendered vs unrendered events mode and if using the events mode can save on network bandwidth?

As per https://docs.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection#what-format-is-used-for-forwarded-events:

WEF has two modes for forwarded events. The default is “Rendered Text” which includes the textual description of the event as you would see it in Event Viewer. This means that the event size is effectively doubled or tripled depending on the size of the rendered description. The alternative mode is “Events” (also sometimes referred to as “Binary” format) – which is just the event XML itself sent in binary XML format (as it would be written to the evtx file.) This is very compact and can more than double the event volume a single WEC server can accommodate.

At a guess, it depends:

• If your collection server has an agent that needs to render the text before ingesting e.g. into your SIEM or log data lake, then the collection sever has to expend the CPU rendering the text anyhow?
• It's more scalable for each source to render than have a central collection server rendering?
• If your source systems have log providers not common to the base OS install, you might get "Event Message Not Found" or other rendering related errors because the collection server doesn't have the DLLs needed to render the events?

I guess the 2nd point is moot if the subscriptions are specific enough to avoid selecting broadly such that they'd also collect on non-base OS apps logging, e.g. SQL, exchange, etc sharing event logs where the collector doesn't have the event provider dll files installed.