-
Notifications
You must be signed in to change notification settings - Fork 8.5k
[APM] Add UI Indices runtime configuration #48079
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 UI Indices runtime configuration #48079
Conversation
💔 Build Failed
|
|
@ogupte Would it be possible to rename all things "UI indices" to simply "Indices". So in the sidenav and page title. |
x-pack/legacy/plugins/apm/index.ts
Outdated
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.
Is the problem that injectDefaultVars has to return synchronously?
Or could you fetch the saved object here?
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 do believe it has to be synchronous, but regardless: the issue here is that the value of apm_oss.transactionIndices could have changed via the UI Indices settings UI since it was injected here during plugin startup. So I'll have to make an API call for it whenever the client requires this index.
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.
Ahh yes ofc. Instead of making a separate endpoint for this, can you call the existing endpoint that exposes the ui indices?
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.
Is it necessary to say it comes from a hook? I got a little confused with that name at first.
| const callApmApiFromHook = useCallApmApi(); | |
| const callApmApi = useCallApmApi(); |
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.
Naming conflicts with the function argument to useFetcher.
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.
What about using calApmApi from the hook everywhere?
const callApmApi = useCallApmApi();
const { data = [], status, refetch } = useFetcher(
() => callApmApi({ pathname: `/api/apm/settings/ui-indices` }),
[callApmApi]
);I think it's confusing having two different instances of it.
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 refetch on Cancel?
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.
cancel behavior resets the values to whatever was previously saved, which can be accomplished by calling refetch. Alternatively i could add more to the component state to store the initial values, and set that when cancel is clicked.
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.
Ah, makes sense. Seems simpler to just refetch 👍
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 preservePreviousData: false?
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 these need translations?
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.
Naming conflicts with the function argument to useFetcher.
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.
nit: I think it's generally more robust to initially create an empty object for the form values, and then merge them synchronously inside of the render function. This explicitly prioritizes user changes over network data, and can help eliminate situations where the user will lose data due to a race condition
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.
Translation?
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.
Further down, I thought configuration was an object, but it is a string, so maybe something like configurationName would be helpful.
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'm having a bit of a hard time understanding what this function does. I guess it's getting all the values from apm_oss? Would it be better to just explicitly define that here? Seems like deepValues is not being used either? e.g.:
return Object.values(apmIndices.apm_oss);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.
the purpose of flatValues as opposed to Object.values(apmIndices.apm_oss); is to keep getApmIndicesList generic. If we add a new index configuration, e.g. xpack.apm.ui.someNewIndex, then it gets included in getApmIndicesList without having to change that function. I open to changing this, but that was my original motivation.
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.
perhaps an enum would limit the amount of times we have to (re)define this?
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.
Is it possible to use this function for getApmIndices as well? Or are there subtle differences that I'm 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.
the difference is that getApmIndices returns the resolved static/runtime indices, while this function returns more of a breakdown of the resolution, which informs the UI how to render the settings page. i.e. getApmIndices could be derived from the result of this function, not the other way around.
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've seen this a couple of times now as well, should we use a constant for this?
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.
out of curiosity, should we always intercept server errors and log them explicitly, or does that happen automatically?
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.
Your right, it's not necessary here. I'll remove these.
💔 Build Failed
|
ef64486 to
5e191ed
Compare
💔 Build Failed
|
💔 Build Failed
|
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'm not following this. Why would getApmIndices not return unique values? Or rather: is it important whether they are unique?
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.
Ahh, now I see. This is specifically for addFilterForLegacyData? I found getApmIndicesList a little confusing. Perhaps you can call Object.values(await getApmIndices(server)) from getParamsForSearchRequest and delete getApmIndicesList because I don't see the necessity for removing duplicates.
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 is both getApmIndicesList and listUiIndices. That seems a little ambiguous.
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.
This is the nice thing about having identical structures in the config and saved object. It's straightforward to merge them 👍
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 forget: did we settle on whether runtime index configuration should be per user, or across all users? And whether anyone should be able to change it or only admins?
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.
| const indexPatternName = await callApmApi({ | |
| const transactionIndices = await callApmApi({ |
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.
Instead of filtering on the backend, what about simply returning all config options:
return await getApmIndices(server);It's not a big response, so the savings ar negligible.
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.
This way you can get rid of get_ui_index.ts
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.
Shouldn't this file be located in lib/settings/ui_indices?
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 is the reducer above necessary? Currently only keys in apm_oss is supported anyway. So wouldn't this work?
| return await storeApmUiIndicesSavedObject(server, uiIndicesSavedObject); | |
| return await storeApmUiIndicesSavedObject(server, uiIndices); |
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.
Is this only necessary to satisfy the savedObjectsClient.get interface?
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.
correct, it satisfies the SavedObjectAttributes type
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.
Currently getApmIndices is called twice for each request. First to get the list of APM indices, and afterwards to verify whether it is an APM index that was queries or not.
What do you think about caching getApmIndices for a short amount of time, eg. 5 seconds? That way if we make several concurrent requests hopefully they won't all have to call getApmIndices. At worst they'll only do it once per request.
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.
As mentioned elsewhere I don't think this method is necessary.
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.
text is mostly used for full-text searches. It will go through the analyzer, will be tokenized and such.
Unless we want that we should use keyword
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.
What about moving this to x-pack/legacy/plugins/apm/server/routes/settings/ui_indices.ts.
Similarly x-pack/legacy/plugins/apm/server/routes/settings.ts should be moved to x-pack/legacy/plugins/apm/server/routes/settings/agent_configuration.ts
84bf62b to
6262e63
Compare
💔 Build Failed
|
6262e63 to
d0421ac
Compare
💔 Build Failed
|
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.
Seems like a good move to flatten the option keys 👍
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.
Thanks for doing this everywhere. Tedious work but much more consistent 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.
Nice to be back on a single line 👍
sorenlouv
left a comment
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!
Couple of TODOs
- decide whether it should be per person or for all
- decide whether specific permissions are required
- possible caching so each request doesn't fetch the saved object twice
I'm okay with merging as-is and then tackle the above questions in follow-up PRs
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.
Each config options can contain a comma separated list of several options. This is mostly used for CCS like apm-*, *:apm-*:
index: [
'apm-*-transaction-*, *:apm-*-transaction-*',
'apm-*-span-*, *:apm-*-span-*',
'apm-*-error-*, *:apm-*-error-*'
]Can you make sure that queries work with comma-separated strings?
- index configuration in settings page - defaults to kibana.yml configuration values
.apm-agent-configuration index which caused failures in those APIs
d0421ac to
0409cd2
Compare
💚 Build Succeeded |
* Add UI Indices runtime configuration - index configuration in settings page - defaults to kibana.yml configuration values * fix tests * Code review feedback and cleanup * fix i18n * Code review feedback * Address code review feedback. * Fixes bug where legacy data filter was including the .apm-agent-configuration index which caused failures in those APIs
* Add UI Indices runtime configuration - index configuration in settings page - defaults to kibana.yml configuration values * fix tests * Code review feedback and cleanup * fix i18n * Code review feedback * Address code review feedback. * Fixes bug where legacy data filter was including the .apm-agent-configuration index which caused failures in those APIs
|
Great to see this merged. Good job @ogupte ! Will you create the follow-up issues regarding permission model? |
|
Test: |
Closes #45247
Adds UI Indices runtime configuration