-
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
[Infra] Provide troubleshooting information on the host details page #191104
Changes from 4 commits
b533b77
7613e09
611d6b3
cdfb4f6
f37b2c1
a56bc7f
e7b829e
5ae2fa6
30ee7a1
429f136
ab69314
bac9b25
5a7ac87
ad40529
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,12 +15,14 @@ import { | |
} from '../../../lib/adapters/framework'; | ||
import { KibanaFramework } from '../../../lib/adapters/framework/kibana_framework_adapter'; | ||
import { InfraSourceConfiguration } from '../../../lib/sources'; | ||
import { TIMESTAMP_FIELD } from '../../../../common/constants'; | ||
import { HOST_NAME_FIELD, SYSTEM_INTEGRATION, TIMESTAMP_FIELD } from '../../../../common/constants'; | ||
import { getFilterByIntegration } from '../../infra/lib/helpers/query'; | ||
|
||
export interface InfraMetricsAdapterResponse { | ||
id: string; | ||
name?: string; | ||
buckets: InfraMetadataAggregationBucket[]; | ||
hasSystemIntegration: boolean; | ||
} | ||
|
||
export const getMetricMetadata = async ( | ||
|
@@ -70,6 +72,20 @@ export const getMetricMetadata = async ( | |
size: 1000, | ||
}, | ||
}, | ||
monitoredHost: { | ||
filter: getFilterByIntegration(SYSTEM_INTEGRATION), | ||
aggs: { | ||
name: { | ||
terms: { | ||
field: HOST_NAME_FIELD, | ||
size: 1, | ||
order: { | ||
_key: 'asc', | ||
}, | ||
}, | ||
}, | ||
}, | ||
}, | ||
}, | ||
}, | ||
}; | ||
|
@@ -79,17 +95,25 @@ export const getMetricMetadata = async ( | |
{ | ||
metrics?: InfraMetadataAggregationResponse; | ||
nodeName?: InfraMetadataAggregationResponse; | ||
monitoredHost?: { name: InfraMetadataAggregationResponse }; | ||
} | ||
>(requestContext, 'search', metricQuery); | ||
|
||
const buckets = | ||
response.aggregations && response.aggregations.metrics | ||
? response.aggregations.metrics.buckets | ||
: []; | ||
const hostWithSystemIntegration = | ||
response.aggregations && (response.aggregations?.monitoredHost?.name?.buckets ?? []).length > 0 | ||
? response.aggregations?.monitoredHost?.name.buckets[0]?.key | ||
: null; | ||
|
||
const hasSystemIntegration = hostWithSystemIntegration === nodeId; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This could also be done only when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done 👍 |
||
|
||
return { | ||
id: nodeId, | ||
name: get(response, ['aggregations', 'nodeName', 'buckets', 0, 'key'], nodeId), | ||
hasSystemIntegration, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This attribute kind of makes it harder to extend the same idea to other asset types because this condition is specific to hosts. For now, I think it's OK because we don't know if the problem we're solving here will happen to other asset types, but I would return this attribute only when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I changed that to be returned only for hosts, thanks for catching that! |
||
buckets, | ||
}; | ||
}; |
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 endpoint is used for other asset types. We might want to run this agg only if
nodeType === 'host'
.Also, perhaps running a query like
getHasDataFromSystemIntegration
parallel to this query might be faster than this term agg because it early terminates as soon as it finds a document that satisfies the criteria.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 made the aggregation conditional so it will be set only if we have
nodeType === 'host'
In this query we already filter by node name so it shouldn't be slow I think 🤔 Wdyt? I can also write an extra query again filtered by node name and use it as a boolean flag (if any data is returned or not) but I am not sure if there is a big benefit in this case as you need to query and filter again to get the results as the aggregation is added to an existing query.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.
Hey! Thanks for adding the condition.
The fact that the query filters by
host.name
helps, but elasticsearch still needs to collect documents to build the aggregation.getHasDataFromSystemIntegration
requires less computation - this function could even be reused.Another potential downside is if we need to do something similar for other asset types. I'm not sure if adding aggregations to this query will scale nicely.
But it's up to you. We can always revisit this in the future.
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.
Got it, thanks. Yeah, when I think about it it is a good idea - it brings dependency to the
infraMetricsClient
but I guess that is fine as we can use it in case we have similar queries for different assets.