-
Notifications
You must be signed in to change notification settings - Fork 455
[Windows] Stop enabling sysmon per default to avoid unhealthy agent status #13893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[Windows] Stop enabling sysmon per default to avoid unhealthy agent status #13893
Conversation
🚀 Benchmarks reportPackage
|
Data stream | Previous EPS | New EPS | Diff (%) | Result |
---|---|---|---|---|
forwarded |
1240.69 | 915.75 | -324.94 (-26.19%) | 💔 |
To see the full report comment with /test benchmark fullreport
💚 Build Succeeded
|
|
Pinging @elastic/sec-windows-platform (Team:Security-Windows Platform) |
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
This feels like it is a breaking change for users who actually do use sysmon. It is less disruptive for people without sysmon to turn it off, then to turn it off unconditionally and break anyone who relies on it. I think ideally we'd be able to detect that sysmon isn't installed and just not run the input at all, but that would require a change in agent. An even easier way to fix this that isn't a breaking change is to stop marking the winlog input as degraded/failed when it can't find the sysmon channel. |
@cmacknz but this change would only apply for all new policies, right? |
If that is how it works, then that is what we want to happen. I made an assumption that by explicitly adding a new default for a configuration value that wasn't specified before, we'd update that field value to the new explicit value everywhere (new and old installs). If the upgrade behavior handles this properly that would be ideal, did we explicitly test the behavior on upgrade here to confirm this is how it works? |
@cmacknz, yeah, but we don't introduce a new value here. We just change the default value. Therefore, the value is already set in all policies. Only when I create a new integration policy now, it's set to |
If works out to be purely a change of default for new installations and upgrades of the package work properly, then LGTM, no concerns. |
Currently, Sysmon collection is enabled by default when you add the Windows integration.
Since Version 9 this can cause the Agent to be in an unhealthy state in fleet when the Channel does not exist.
See: elastic/elastic-agent#7448
As sysmon isn't installed on Windows per default, it also shouldn't be enabled in the integration as default to improve user experience when they just add the Windows integration without changing the default values.