-
Notifications
You must be signed in to change notification settings - Fork 81
Description
What are you proposing?
I propose adding support for wildcard cluster names (e.g., *:index-pattern) when configuring anomaly detection jobs in OpenSearch. This would allow users to specify indices across all remote clusters without needing to know the exact cluster name in advance. I have implemented this feature and would like to contribute it to the anomaly detection plugin.
How did you come up with this proposal?
We manage a platform with many remote clusters and a single coordinating cluster, and our users' data can be moved between remote clusters for operational reasons. Currently, users must specify the exact cluster name when configuring anomaly detection, which is not always possible or user-friendly in our environment. Supporting wildcard cluster names would greatly simplify configuration and improve usability for multi-cluster setups.
What is the user experience going to be?
Users will be able to specify indices using a wildcard cluster prefix (e.g., *:logs-*). The anomaly detection plugin will resolve this to all matching indices across all remote clusters, so users do not need to know or update the cluster name if their data moves. This makes configuration more robust and less error-prone in dynamic environments.
Why should it be built? Any reason not to?
Why it should be built:
- Simplifies anomaly detection configuration in multi-cluster environments.
- Reduces operational overhead for users and administrators.
- Makes OpenSearch Anomaly Detection more flexible and user-friendly for large-scale, distributed deployments.
Potential concerns:
- There may be a performance impact when resolving wildcard clusters, especially in environments with many remote clusters. To mitigate this, the implementation can short-circuit and use the original logic if no wildcard cluster is detected in the index pattern.
What will it take to execute?
- Review and discuss the proposed approach and implementation details with the community.
- Ensure the implementation is robust, performant, and well-tested.
- Update documentation to describe the new configuration option and any limitations.
What are remaining open questions?
- Are there additional performance or security considerations for very large or sensitive multi-cluster environments?
- Should there be configuration options to limit or control wildcard cluster resolution?
- Are there other OpenSearch plugins or features that would benefit from similar wildcard cluster support?
Since this is only a backend change, the frontend plugin (Anomaly Detection Dashboards) would also need updates to allow users to specify a wildcard cluster prefix. I have tested the changes using the anomaly detection API and it works as expected, but it is not currently possible to cleanly create these configurations using the frontend. The UI would need to be updated to fully support this feature.
The main limitation in the backend is specifically in the validation logic for validating the Time Field and Categorical Fields, which do not currently support wildcard cluster prefixes. The rest of the backend/API can already process these configurations if created via the API.
I am happy to provide a pull request with the implementation and work with the community to refine the approach. Thank you for considering this proposal!