In the Winlogbeat code, "localhost" is hardcoded as the Event Log session/log:
Here for "wineventlog.go":
subscriptionHandle, err := win.Subscribe(
**0, // Session - nil for localhost**
signalEvent,
"", // Channel - empty b/c channel is in the query
l.query, // Query - nil means all events
bookmark, // Bookmark - for resuming from a specific event
win.EvtSubscribeStartAfterBookmark)
if err != nil {
return err
}
If you open a PR I think it would be easier to discuss the changes.
Things I'm most concerned are how can we automate the testing of this and what impact does it have on the registry file. The registry keys are currently based on the log name alone, so having remote logs probably means changes to what's stored in the registry in order to have a unique key.
Error handling is another concern. Are there new errors that need to be handled for things like connection failures.
For the tests, I didn't try, but I guess you can specify the UNC path of the local computer in a domain.
For the registry keys, it is related to the QueryEventMessageFiles function in "winlogbeat/sys/eventlogging/eventlogging_windows.go", line 498, last function of the file.
In my case, for now, I had to comment out line 501-539. Remove the 'for' loop at 542 and hardcode "eventMessageFile" to the path of the dll.
That is a quick bypass to make things work but the registry of the remote computer is accessible. However, the EventMessageFile key in the registry is a local path like "c:\.etc\thatdll.dll.". That would need to be changed to a UNC path like "\\remote\c$\.etc\thatdll.dll". I don't konw if the Windows API takes care of that.
As for error handling, the Windows API describes them. They can be integrated.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.