-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Infra] Create service in apm_data_access
to fetch APM colleced hosts
#189046
[Infra] Create service in apm_data_access
to fetch APM colleced hosts
#189046
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
55721b3
to
e3a418d
Compare
e3a418d
to
c9ddb1e
Compare
/ci |
/ci |
@elasticmachine merge upstream |
/ci |
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
@elasticmachine merge upstream |
const getCoreStart = () => core.getStartServices().then(([coreStart]) => coreStart); | ||
const getResourcesForServices = async () => { | ||
const coreStart = await getCoreStart(); | ||
const soClient = coreStart.savedObjects.createInternalRepository(); |
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.
Have you tried changing the APM index patterns on the APM settings page and see if the correct indices are returned with this createInternalRepository
?
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 tested it and it worked. APM also uses it here here. It could be due to the fact that when APM indices are changed on the Settings page, Kibana does a full page refresh.
@elasticmachine merge upstream |
const { apmIndices, esClient } = await params.getResourcesForServices(); | ||
|
||
const esResponse = await esClient.search({ | ||
index: [apmIndices.metric, apmIndices.transaction, apmIndices.span, apmIndices.error], |
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 will be slow, because you're aggregating over all data. Even if it's just a single service, you'll run into performance issues. What would be more efficient here is if you figure out what data source to query first (tx metrics or raw events, 1m vs 10m and 60m), and then execute 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.
that would be the same thing that the get_document_sources
does. We'd have to move that to apm_data_access
. Is that your idea?
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.
yeah, how involved would that be?
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.
it's a relatively big change. A few things would have to be moved (could be more):
document_type
, get_document_sources
and the types they depend on.
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.
ok, sounds fine to do it in a follow-up but I'd like to make it happen, to set a good first example
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.
yeah, makes sense. I'm going to get a sense of how much effort it would be. it might as well be doable in this PR.
|
||
export function createGetHostNames(params: RegisterParams) { | ||
return async ({ from: timeFrom, to: timeTo, query, limit }: ServicesHostNamesParams) => { | ||
const { apmIndices, esClient } = await params.getResourcesForServices(); |
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 think we should stay away from patterns like this, and expect the consumer to pass in asynchronously resolved dependencies, such as getting the APM indices. If we don't do that, we'll end up with a ton of small requests - I see this happen with e.g. the ML plugin that does a ton of small requests because it encapsulates privilege and other checks in each service call. For instance: #161229
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.
Yeah, I was just having second thoughts about this approach.
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.
though it's kind of weird asking the consumer to pass the APM indices to a service in the apm_data_acess
plugin.
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.
it is a little weird, and there might be a better way (e.g. to have a per-request service that does per-request caching, but that also might create some risks).
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't really see the risks of getting the APM indices when calling a service in the apm_data_access
, what could happen? if we just get the APM indices there, do you think it would still end up in the same situation from ML plugin?
I'm more concerned about the fact I'm using the internal user to get both apm indices and typed esClient.
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.
One downside is potentially requesting APM indices twice.
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.
One downside is potentially requesting APM indices twice.
This is my (only) concern. It might end up being more than twice however. Especially in the context of e.g. rule executors this becomes more important. My experience is that if we abstract away async operations, people lose awareness of what is happening as part of the service call, and it leads to performance bottlenecks. I'd be less concerned about this if we have really good insight in production bottlenecks, but we don't.
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.
For the lack of better alternatives, I'll leave it up to the consumer the send the APM indices for now. It's bad DX but for the time being it's better than end up in situation where it might lead to performance problems.
aggs: { | ||
hostNames: { | ||
terms: { | ||
field: 'host.name', |
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 a constant for this somewhere (HOST_NAME
).
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 in the apm_data_access
. we need to either move the constants from apm
plugin here or create a new constants file.
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.
yeah, let's move the constants then
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'll do that in a follow up PR, over 250 files will be changed after 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.
package might be better at that point, WDYT?
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.
yeah. When doing this #189046 (comment), some types could also be moved to this new package.
💔 Build Failed
Failed CI StepsMetrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
History
To update your PR or re-run it, just comment with: |
I'll open a new PR for this. |
closes 188752
Summary
Create a service in APM data access that will return host names collected by APM agents. This change is key to allow the hosts view to list only hosts that are monitored with the system module #188756.
I've made some changes to the Hosts API, simplifying the code. The payload has been slightly changed.
How to test
node scripts/synthtrace infra_hosts_with_apm_hosts --live