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.

Sign up for GitHub

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

Jump to bottom

POC apm-data-access v2 #2

Closed
wants to merge 1 commit into from
Closed

POC apm-data-access v2 #2

wants to merge 1 commit into from

Conversation

crespocarlos
Copy link
Owner

@crespocarlos crespocarlos commented Jul 29, 2024 •
edited
Loading

Summary

Things moved from apm to apm-data-acess

  • APMEventClient and everything it depends on -> moved to apm-data-access and exposed via export
  • get_documents_source -> moved to apm-data-acess and exposed as service

Things moved from apm to kbn-apm-utils

  • typings/es_schemas/* (es_schemas) -> moved to kbn-utils
  • es_fields/apm (fields contants) -> moved to kbn-utils

To avoid a PR bigger than this, most of the files that were moved to apm-data-access that contained types and helper functions remained, however their content now points to their corresponding function in apm-data-access

client usage

 const client =  apmDataAccess.getClient({
    apmEventClient: new APMEventClient({
      indices: apmIndices,
      options: {
        includeFrozen: false,
        inspectableEsQueriesMap?: map
      },
      debug: false,
      esClient,
      request,
    }),
    deps: {
      uiSettings: coreContext.uiSettings.client
    },
  });

client.[services]([...args])

todo: Split this PR into smaller ones to facilitate reviews

@crespocarlos crespocarlos force-pushed the 188752-poc-apm-data-access branch 3 times, most recently from be462c8 to 565c019 Compare July 29, 2024 19:48
@crespocarlos crespocarlos force-pushed the 188752-poc-apm-data-access branch 2 times, most recently from 1abefd7 to 1c966aa Compare July 29, 2024 21:55
@crespocarlos crespocarlos deleted the 188752-poc-apm-data-access branch August 7, 2024 14:53
crespocarlos pushed a commit that referenced this pull request Aug 14, 2024
@jen-huang @kibanamachine
[UII] Support integration-level outputs (elastic#189125)
8266415 
## 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 `#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:

<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]>
elasticmachine pushed a commit that referenced this pull request Sep 19, 2024
@delanni
[fix] regenerate and add missing openapi-generated files #2 (elastic#…
f785002 
…193441)

## Summary
More files to be regenerated with a different shape since the js-yaml
update: elastic#190678
crespocarlos pushed a commit that referenced this pull request Oct 3, 2024
@miloszmarcinkowski
Merge pull request #2 from bryce-b/192749-refactor-the-normalize-func…
b4c5a95 
…tion-into-per-data-structure-serialization-logic

added span-link normalization and fixed errors in getTransaction
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@crespocarlos