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.

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

[Profiling] Allow wildcards for custom indices #105372

Merged
merged 4 commits into from
Feb 12, 2024

Conversation

danielmitterdorfer
Copy link
Member

Several profiling APIs allow to specify custom event indices with the indices parameter. So far this parameter has allowed only one index and also disallowed wildcards. With this commit we extend this parameter to support multiple indices and each index can use wildcards.

Several profiling APIs allow to specify custom event indices with the
`indices` parameter. So far this parameter has allowed only one index
and also disallowed wildcards. With this commit we extend this parameter
to support multiple indices and each index can use wildcards.
@danielmitterdorfer danielmitterdorfer added >non-issue cloud-deploy Publish cloud docker image for Cloud-First-Testing :UniversalProfiling/Application Elastic Universal Profiling REST APIs and infrastructure test-update-serverless v8.13.0 labels Feb 12, 2024
@danielmitterdorfer danielmitterdorfer self-assigned this Feb 12, 2024
@elasticsearchmachine elasticsearchmachine added the Team:obs-knowledge Meta label for Observability Knowledge team label Feb 12, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/obs-knowledge-team (Team:obs-knowledge)

@danielmitterdorfer
Copy link
Member Author

Note: I'm labeling this as non-issue as the respective API is exclusive to Kibana and it is not yet in use.

@@ -32,7 +35,7 @@
/**
* A request to get profiling details
*/
public class GetStackTracesRequest extends ActionRequest implements IndicesRequest {
public class GetStackTracesRequest extends ActionRequest implements IndicesRequest.Replaceable {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementing IndicesRequest.Replaceable indicates to infrastructure in Elasticsearch that we want to support wildcards, see also

private static boolean requiresWildcardExpansion(IndicesRequest indicesRequest) {
// IndicesAliasesRequest requires special handling because it can have wildcards in request body
if (indicesRequest instanceof IndicesAliasesRequest) {
return true;
}
// Replaceable requests always require wildcard expansion
if (indicesRequest instanceof IndicesRequest.Replaceable) {
return true;
}
return false;
}

);
}
}
return indices.toArray(new String[0]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the String array be pre-allocated with indices.size()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -330,7 +350,7 @@ public String[] indices() {
if (this.indices == null) {
indices.addAll(EventsIndex.indexNames());
} else {
indices.add(this.indices);
indices.addAll(List.of(this.indices));
}
return indices.toArray(new String[0]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use pre-allocation here as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@rockdaboot rockdaboot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (left some minor comments)

As we set indices now internally in all cases due to wildcard
resolution, we need a means to distinguish whether `indices` have been
provided originally via the API or whether Elasticsearch has set them
internally after wildcard resolution.
@danielmitterdorfer danielmitterdorfer merged commit 858c614 into elastic:main Feb 12, 2024
16 checks passed
@danielmitterdorfer danielmitterdorfer deleted the patterns branch February 12, 2024 09:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cloud-deploy Publish cloud docker image for Cloud-First-Testing >non-issue Team:obs-knowledge Meta label for Observability Knowledge team test-update-serverless :UniversalProfiling/Application Elastic Universal Profiling REST APIs and infrastructure v8.13.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants