-
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
[APM] Add data access plugin #162367
[APM] Add data access plugin #162367
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
dc9a777
to
04795e5
Compare
Thanks so much for jumping on this @sqren @neptunian ! |
951db70
to
ac04548
Compare
@neptunian This PR is now ready to test out. Can you try consuming the
|
Pinging @elastic/apm-ui (Team:APM) |
export const config: PluginConfigDescriptor<APMDataAccessConfig> = { | ||
deprecations: ({ renameFromRoot }) => [ | ||
// deprecations due to removal of apm_oss plugin | ||
renameFromRoot('apm_oss.transactionIndices', 'xpack.apm.indices.transaction', { |
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.
Do we still have to use xpack.apm.*
as the new keys here? Can these be replaced with xpack.apm_data_access.*
?
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 will log a visible warning to the user if they are using apm_oss.transactionIndices
. In that case they should be recommended to use xpack.apm.indices.transaction
- not xpack.apm_data_access.indices.transaction
.
For now apm_data_access
is purely an implementation detail, and not something end users should know about (maybe that changes in the future but I'd like to keep this change invisible for now).
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.
@sqren I'm getting an error unless I use xpack.apm_data_access.indices.*
[config validation of [xpack.apm].indices]: definition for this key is missing
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.
@neptunian What's in your kibana.yml?
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.
Just a copy paste of my remote oblt cluster config
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.
xpack.apm.indices.sourcemap
and xpack.apm.indices.onboarding
were missing in the config definitions. I re-added them which should fix the issue
2e019c7
to
faf6c9e
Compare
d839e7a
to
85d88e4
Compare
@@ -76,7 +74,8 @@ const ruleTypeConfig = RULE_TYPES_CONFIG[ApmRuleType.TransactionDuration]; | |||
export function registerTransactionDurationRuleType({ | |||
alerting, | |||
ruleDataClient, | |||
config$, | |||
getApmIndices, |
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.
Why not passing directly the indices instead of the function? Couldn't we get the indices on plugin start and save them as a resource for the routes?
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 considered it, but decided to load the indices lazily for two reasons:
-
registerTransactionDurationRuleType
is called when kibana starts. Retrieving the apm indicies at this point would mean that if the indices were update via APM Settings, the change would not be reflected until Kibana was restarted. -
Because
registerTransactionDurationRuleType
is called during startup it is called with the privileges of the internal kibana user and not with the privileges of the rule execution user. I don't think this is a problem in practice but it feels slightly wrong.
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.
LGTM 📦
e3aa6ee
to
60cba7b
Compare
f8ea7ef
to
af8bb34
Compare
This reverts commit 8f3abab9d44614b78e67a85f0492cbc10be7d0a0.
af8bb34
to
a8c4e9c
Compare
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Public APIs missing comments
Public APIs missing exports
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
#164750) Closes #164695 Uses [apm_data_access plugin](#162367) in place of statically defined indices to extract services --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Kevin Lacabane <[email protected]>
Closes #161906
Related to: https://github.com/elastic/observability-dev/discussions/2787 (internal)
This add a new plugin
apm_data_access
that contains the APM query targets (indices to query for APM data).This plugin can be consumed by apm and any other plugin, making it possible for other plugins to know about the configured APM query targets.
Example:
APM query targets can be specified in kibana[.dev].yml using
xpack.apm.indices.{dataset}: some-index-*
for instances:See all config options on: https://www.elastic.co/guide/en/kibana/current/apm-settings-kb.html#general-apm-settings-kb
Query targets can also be specified via the UI (and persisted in a saved object) via the settings page:
/app/apm/settings/apm-indices
Retrieving the query targets
Query targets can be retrieved from other plugins via
getApmIndices
:TODO: