My gut feeling is that your second route will be the more easy to follow. The first route involves touching two different systems, each one with its own quirks:
- install+setup remote syslog server on Linux;
- make Windows send the logs to remote syslog server;
- also setup the syslog reading on Linux
This approach seems to create more "points of failure" (imagine a network problem blocking Windows from logging its events to the remote syslog).
The first route would require only installing a wmi client for Linux. I'd recommend
wbemcli. (On Debian/Ubuntu try
apt-get install wbemcli.) With this, Windows logging (which in my experience is rock-solid) remains unchanged. Even if you have temporary network problems, your access to un-compromised logs will return after the network came back to full operation.
As you may know, WMI is just Microsoft's implementation of WBEM (Web-based Enterprise Management). WBEM in turn is an industry standard defined by the Distributed Management Task Force consortium.
There are some differences in MS's WMI from the WBEM standard (as it's mostly the case when MS says they 'implement a standard'). For example, it uses a different transport protocol than stock WBEM (WBEM typically uses HTTP over TCP/5988 or HTTPS over TCP/5989. WMI also uses slightly different namespaces. Otherwise, they are mostly identical.