-
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
[UII] Support integration-level outputs #189125
[UII] Support integration-level outputs #189125
Conversation
… behind enterprise license check
…he package (i.e. APM can only have ES output)
Include package policies in search for agent policies to be bumped when output is updated
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@kilfoyle for your radar |
…bana into feat/output-per-integration
/> | ||
} | ||
> | ||
<EuiSelect |
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.
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.
I can address this in a follow up PR
page: 1, | ||
perPage: SO_SEARCH_LIMIT, | ||
}); | ||
|
||
if (agentPolicies.error) { | ||
throw agentPolicies.error; | ||
} | ||
const agentPolicyCount = agentPolicies.data?.items?.length ?? 0; | ||
|
||
const packagePolicies = await sendGetPackagePolicies({ |
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.
Not necessarily related to that PR but I have more and more concerns about retrieving all package policies client side, this will be a blocker to support a larger number of policies, and I am not sure of the value of showing an exact count of policies for the user.
I am wondering if this could be simplified to two scenarios, the output is not used by any agent policy or the output is used by at least one agent policy.
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.
I agree with this, and I actually saw that on some of our other settings confirmation modals, we don't show the exact count like this. we just tell the user that this will agents enrolled into affected policies. I'll capture this in a follow up enhancement to remove these granular counts in modals
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 some one explain what this block is referring to? is it referring to the counts in the Fleet table?
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.
@nimarezainia It is the count in the confirmation modal when user updates/deletes an output, like "this will update X policies used by X agents"
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.
@nimarezainia @nchaulet I opened #190432
throw new PackagePolicyRequestError(canUseMultipleAgentPoliciesErrorMessage); | ||
} | ||
|
||
if (newPolicy.output_id && pkg) { |
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.
Should that validation happen at the package policy service level so it will also be validated for preconfigured package policies and in the future if other solution create package policy with output_id
Should we validate also for the update package policy method? (Maybe it's already done and I missed that)
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.
yes, this should happen at the service level. I was copying what was done for multiple policy IDs but I don't think that was a good pattern. I pushed changes to move both multiple policy and integration output validation to the service level. they are executed together in a preflight
function that is added to create, update, bulk create, and bulk update methods
thanks for catching this pattern!
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @jen-huang |
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.
Tested locally and work as expected 🚀
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 for the docs! 🚢
## Summary Resolves elastic#143905. This PR adds support for integration-level outputs. This means that different integrations within the same agent policy can now be configured to send data to different locations. This feature is gated behind `enterprise` level subscription. For each input, the agent policy will configure sending data to the following outputs in decreasing order of priority: 1. Output set specifically on the integration policy 2. Output set specifically on the integration's parent agent policy (including the case where an integration policy belongs to multiple agent policies) 3. Global default data output set via Fleet Settings Integration-level outputs will respect the same rules as agent policy-level outputs: - Certain integrations are disallowed from using certain output types, attempting to add them to each other via creation, updating, or "defaulting", will fail - `fleet-server`, `synthetics`, and `apm` can only use same-cluster Elasticsearch output - When an output is deleted, any integrations that were specifically using it will "clear" their output configuration and revert back to either `elastic#2` or `elastic#3` in the above list - When an output is edited, all agent policies across all spaces that use it will be bumped to a new revision, this includes: - Agent policies that have that output specifically set in their settings (existing behavior) - Agent policies that contain integrations which specifically has that output set (new behavior) - When a proxy is edited, the same new revision bump above will apply for any outputs using that proxy The final agent policy YAML that is generated will have: - `outputs` block that includes: - Data and monitoring outputs set at the agent policy level (existing behavior) - Any additional outputs set at the integration level, if they differ from the above - `outputs_permissions` block that includes permissions for each Elasticsearch output depending on which integrations and/or agent monitoring are assigned to it Integration policies table now includes `Output` column. If the output is defaulting to agent policy-level output, or global setting output, a tooltip is shown: <img width="1392" alt="image" src="https://github.com/user-attachments/assets/5534716b-49b5-402a-aa4a-4ba6533e0ca8"> Configuring an integration-level output is done under Advanced options in the policy editor. Setting to the blank value will "clear" the output configuration. The list of available outputs is filtered by what outputs are available for that integration (see above): <img width="799" alt="image" src="https://github.com/user-attachments/assets/617af6f4-e8f8-40b1-b476-848f8ac96e76"> An example of failure: ES output cannot be changed to Kafka while there is an integration <img width="1289" alt="image" src="https://github.com/user-attachments/assets/11847eb5-fd5d-4271-8464-983d7ab39218"> ## TODO - [x] Adjust side effects of editing/deleting output when policies use it across different spaces - [x] Add API integration tests - [x] Update OpenAPI spec - [x] Create doc issue ### Checklist Delete any items that are not applicable to this PR. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <[email protected]>
Closes #192339 ## Summary Display two additional columns with Outputs hosts in agent list table and agent details section - The two columns show monitoring output and the integrations output and link to the output flyout in settings - Display a badge that show the outputs set per integration introduced by #189125 - Same info displayed in agent details as well To achieve this, I added two new endpoints. 1. Endpoint that fetches all the outputs associated with a single agent policy (outputs defined on agent policy or default defined in global settings and if any, outputs per integration) ``` GET kbn:/api/fleet/agent_policies/<AGENT_POLICY_ID>/outputs ``` 2. Endpoint that fetches the outputs as above, for a defined set of agent policy ids ``` POST kbn:/api/fleet/agent_policies/outputs { "ids": ["policy_id1", "policy_id2", ...] } ``` The reason to pass an array of ids is to ensure that we fetch the info only for the policies displayed in the table at any given moment. ### Screenshots **Agent list** ![Screenshot 2024-10-16 at 17 51 57](https://github.com/user-attachments/assets/3ee08df1-9562-497f-9621-4a913b3dad74) ![Screenshot 2024-10-16 at 17 52 05](https://github.com/user-attachments/assets/72b9da7d-872a-45f8-b02d-29184ffb2179) **Agent details** ![Screenshot 2024-10-16 at 17 52 20](https://github.com/user-attachments/assets/b99aaf9e-14f1-44b8-9776-3e0136775af8) ### Checklist - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [ ] This will appear in the **Release Notes** and follow the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: kibanamachine <[email protected]>
Summary
Resolves #143905. This PR adds support for integration-level outputs. This means that different integrations within the same agent policy can now be configured to send data to different locations. This feature is gated behind
enterprise
level subscription.For each input, the agent policy will configure sending data to the following outputs in decreasing order of priority:
Integration-level outputs will respect the same rules as agent policy-level outputs:
fleet-server
,synthetics
, andapm
can only use same-cluster Elasticsearch output#2
or#3
in the above listThe final agent policy YAML that is generated will have:
outputs
block that includes:outputs_permissions
block that includes permissions for each Elasticsearch output depending on which integrations and/or agent monitoring are assigned to itIntegration policies table now includes
Output
column. If the output is defaulting to agent policy-level output, or global setting output, a tooltip is shown:Configuring an integration-level output is done under Advanced options in the policy editor. Setting to the blank value will "clear" the output configuration. The list of available outputs is filtered by what outputs are available for that integration (see above):
An example of failure: ES output cannot be changed to Kafka while there is an integration
TODO
Checklist
Delete any items that are not applicable to this PR.