Skip to content
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

Merged
merged 43 commits into from
Aug 13, 2024

Conversation

jen-huang
Copy link
Contributor

@jen-huang jen-huang commented Jul 24, 2024

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:

  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 #2 or #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:

image

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):

image

An example of failure: ES output cannot be changed to Kafka while there is an integration
image

TODO

  • Adjust side effects of editing/deleting output when policies use it across different spaces
  • Add API integration tests
  • Update OpenAPI spec
  • Create doc issue

Checklist

Delete any items that are not applicable to this PR.

@obltmachine
Copy link

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

@jen-huang

This comment was marked as outdated.

@jen-huang

This comment was marked as outdated.

@nimarezainia
Copy link
Contributor

@kilfoyle for your radar

@nchaulet nchaulet self-requested a review August 8, 2024 19:45
/>
}
>
<EuiSelect
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use a super select like we do for the agent policy output selector? the default value looks more explicit to me
Currently
Screenshot 2024-08-12 at 10 13 11 AM
Agent policy output selector
Screenshot 2024-08-12 at 10 13 30 AM

Copy link
Contributor Author

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({
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

throw new PackagePolicyRequestError(canUseMultipleAgentPoliciesErrorMessage);
}

if (newPolicy.output_id && pkg) {
Copy link
Member

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)

Copy link
Contributor Author

@jen-huang jen-huang Aug 12, 2024

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!

@jen-huang jen-huang requested a review from nchaulet August 12, 2024 23:58
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
fleet 1229 1234 +5

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
fleet 1.8MB 1.8MB +2.4KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
fleet 168.8KB 169.0KB +198.0B
Unknown metric groups

API count

id before after diff
fleet 1351 1357 +6

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @jen-huang

Copy link
Member

@nchaulet nchaulet left a 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 🚀

Copy link
Contributor

@kilfoyle kilfoyle left a 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! 🚢

@jen-huang jen-huang merged commit 8266415 into elastic:main Aug 13, 2024
21 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Aug 13, 2024
@jen-huang jen-huang deleted the feat/output-per-integration branch August 13, 2024 15:50
bryce-b pushed a commit to bryce-b/kibana that referenced this pull request Aug 13, 2024
## 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]>
criamico added a commit that referenced this pull request Oct 22, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:enhancement Team:Fleet Team label for Observability Data Collection Fleet team v8.16.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Fleet] Defining Output per integration
10 participants