-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
OSquery fix issue with document rejection by upgrading osquery_manager package and rolling over indices on upgrade #148991
OSquery fix issue with document rejection by upgrading osquery_manager package and rolling over indices on upgrade #148991
Conversation
c63b8f6
to
6a6641d
Compare
1f9025e
to
7915504
Compare
…-ref HEAD~1..HEAD --fix'
…-ref HEAD~1..HEAD --fix'
Pinging @elastic/security-defend-workflows (Team:Defend Workflows) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@paul-tavares Hey, do you mind taking a look to check if the function above meets all the ''requirements'' of a good a async function within plugin as we discussed? It's quite late for me and my brain stopped working so would appreciate a second pair of eyes :P |
@elasticmachine merge upstream |
@tomsonpl I checked out and tried your change and it looks to be working. thanks for pushing up the change! I can get the data after the fix in OSQuery: and I get the log output as expected to show that we update the package and rollover the indices: |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I am not sure about the way (force) to upgrade for users' integration, but it seems to be the best idea we have for now :) Thanks @kevinlog !
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks great to me. I just wonder about the amount of async calls and awaits it will do during the plugin start process. Is this something could take too much time?
@@ -135,6 +136,9 @@ export class OsqueryPlugin implements Plugin<OsqueryPluginSetup, OsqueryPluginSt | |||
await this.initialize(core, dataViewsService); | |||
} | |||
|
|||
// Upgrade integration into 1.6.0 and rollover if found 'generic' dataset - we do not want to wait for it | |||
upgradeIntegration({ packageInfo, client, esClient, logger: this.logger }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: as the upgrade is conditional, could this be renamed to something like upgradeIntegrationIfNeeded
or checkAndUpgradeIntegrationIfNeeded
}); | ||
|
||
// Then for each of those datastreams, we need to see if they need to rollover. | ||
await asyncForEach(dataStreams.data_streams, async (dataStream) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't need to be changed, but if you would like to avoid asyncForEach
import, you could just use a for
loop:
for (const dataStream of dataStreams.data_streams) {
[....]
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be done in parallel? Wondering if you could use pMap
here and speed up the process.
We discussed this offline with @dasansol92 , and given the short time we have for the 8.6.1 FF, we agreed that it's gonna be merged in the current state and the performance improvements can be added in a next iteration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code changes LGTM, suggestions can be done later.
Merged, @kevinlog FYI. |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…r package and rolling over indices on upgrade (elastic#148991) (cherry picked from commit 192c739) # Conflicts: # x-pack/plugins/osquery/server/plugin.ts # x-pack/plugins/osquery/tsconfig.json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay. I left a comment regarding the pinning of the package version to 1.6.0
savedObjectsClient: client, | ||
pkgkey: pkgToPkgKey({ | ||
name: packageInfo.name, | ||
version: '1.6.0', // This package upgrade is specific to a bug fix, so keeping the upgrade focused on 1.6.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You seem to be pinning the version to 1.6.0
here, is that correct? What if the newest version is higher than 1.6.0
?
The reason this looks strange to me is because this PR is being merged to main
which means it applies to v8.7++.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank @paul-tavares! Thanks for raising the issue :) I haven’t really think about it, but the goal is to force upgrade older version than 1.6.0 to 1.6.0 which fixed the issue. The rest - update to any other versions are not crucial to us.
I think we can still discuss how to handle this 8.7 onwards, the most crucial part is to fix 8.6.1 and actually @kevinlog suggested another way to fix it: #149325
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@paul-tavares - osquery doesn't normally upgrade it's package automatically. We wanted to make an exception in this case since 1.6.0
contains a critical fix. We'll only try to upgrade if the package version is below 1.6.0
. We will make sure the package is at 1.6.0
and after that, users can check and upgrade the package as normal with newer changes pushed out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary
This PR helps address this bug: elastic/beats#34250
The issue is that with the Agent v2, osquery beat sends different values in the
data_stream
field, which are typeconstant_keyword
, to thelogs-osquery_manager.result-*
indices. This causes document rejection if users upgraded to Agentv8.6.0
and already had data OR if they start fresh with Agentv8.6.0
and upgrade to the8.6.1
Agent/osquery beat with the fix for sending this data incorrectly.To make the fix for this problem seamless for users on upgrade, we need to do the following:
1.6.0
osquery_manager
package which has a new pipeline which will correct the values that the8.6.0
Agent/osquery beat send.Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers