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

Unable to tell which anomaly asset properties belong to which anomaly prediction definition #349

Open
hwandersman opened this issue Aug 16, 2024 · 1 comment

Comments

@hwandersman
Copy link
Collaborator

hwandersman commented Aug 16, 2024

Since anomaly prediction definition composite model asset properties always have the same names (i.e., AWS/L4E-ANOMALY_RESULT) and the SW Grafana asset property selector only displays asset properties by name, it is not possible for a customer to determine which prediction definition an anomaly result asset property belongs to when selecting in a query. This issue extends to alarms definition composite models, yet the exact ask is for prediction definitions. To solve the problem, it is recommended we prepend the names of composite models to asset property names, as described below.

Recommended solution:

To provide the best user experience while maintaining technical consistency, we recommend showing a navigation path (e.g., MyPrediction1->AWS/L4E-ANOMALY_RESULT) instead of changing the name by prefixing it with the prediction definition name (e.g., MyPrediction1-AWS/L4E-ANOMALY_RESULT). This approach allows users to form a mental model that AWS/L4E-ANOMALY_RESULT is a property within a prediction and avoids creating the impression that MyPrediction1-AWS/L4E-ANOMALY_RESULT is a valid property name in SiteWise, which is not the case.
 
This navigation path format is also used by SiteWise expressions (when properties are referenced through hierarchies), so this approach will ensure a consistent user experience across both the SiteWise console and Grafana.

image

@iwysiu
Copy link
Contributor

iwysiu commented Aug 19, 2024

It looks like we currently just take the last part of the path as the name (here). Instead we could construct a string based on the path to to be more clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Next
Development

No branches or pull requests

3 participants