Skip to content

docs(alerting): add unified alerts view page to starlight docs - #431

Open
jackiehanyang wants to merge 2 commits into
opensearch-project:mainfrom
jackiehanyang:alertsManger37
Open

docs(alerting): add unified alerts view page to starlight docs#431
jackiehanyang wants to merge 2 commits into
opensearch-project:mainfrom
jackiehanyang:alertsManger37

Conversation

@jackiehanyang

Copy link
Copy Markdown

Summary

  • Add new Starlight doc page at /docs/alerting/unified-alerts-view/ describing Alerts Manager tabs and workflows.
  • Add Unified Alerts View into Alerting navigation.
  • Add cross-links from Alerting, Anomaly Detection, and Forecasting pages to the new unified page.

Testing

  • Docs content and links verified by local diff review.

Signed-off-by: Jackie Han <hnyng@amazon.com>
@codecov

codecov Bot commented Aug 19, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.62%. Comparing base (20c5da9) to head (0c642c0).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #431   +/-   ##
=======================================
  Coverage   55.62%   55.62%           
=======================================
  Files           4        4           
  Lines         169      169           
  Branches       47       47           
=======================================
  Hits           94       94           
  Misses         74       74           
  Partials        1        1           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@TackAdam

Copy link
Copy Markdown
Contributor

Verified the anomaly-detection and forecasting content against the implementation in dashboards-observability (create_ad_rule_flyout.tsx, shared_constants.ts, alerts_dashboard.tsx, anomaly_detail_flyout.tsx). It's accurate — step counts, max-5 features, auto-start default, forced forecaster start, the data-source filtering, type/status labels, anomaly grouping, and the stop-before-edit / restart-after-edit flow all match the code. Three small wording fixes so the doc quotes the actual UI labels:

1. Step names

The wizard omits "the". The <Steps> labels read as if quoting the UI, but the actual step titles are Define detector, Configure model, and Define data source.

  • Define the detector.Define detector.
  • Configure the model.Configure model.
  • Define the data source. (forecaster) → Define data source.

2. "Advanced settings" is mislabeled

The shingle-size section is titled Advanced model parameters in the UI, not Advanced settings:

Suggestion:

  1. Configure model. Add up to five features. For each feature, choose an aggregation method and field. Optionally add a categorical field to detect anomalies independently for each entity, then set the detection interval, frequency, window delay, and history. Use Suggest parameters for recommended operation settings, or open Advanced model parameters to configure the shingle size.

3. "Initially unselected" is slightly overstated

getInitialDatasourceId seeds the field from the currently-selected data source filter when one is set (empty only when none applies), so it's often pre-filled. Both <Aside> blocks (the AD one and the identical forecasting one) contain this sentence — suggest softening both:

The data source field defaults to the data source selected in the view, or is left unselected if none applies.

Also — not blocking, and outside this repo — this PR renames the anchors #rule-types#resource-types and inspect-and-manage-a-ruleinspect-and-manage-a-resource. They're consistent within the diff, but worth grepping the rest of the docs tree for any untouched links to the old anchors so they don't 404.

@jackiehanyang

Copy link
Copy Markdown
Author

Verified the anomaly-detection and forecasting content against the implementation in dashboards-observability (create_ad_rule_flyout.tsx, shared_constants.ts, alerts_dashboard.tsx, anomaly_detail_flyout.tsx). It's accurate — step counts, max-5 features, auto-start default, forced forecaster start, the data-source filtering, type/status labels, anomaly grouping, and the stop-before-edit / restart-after-edit flow all match the code. Three small wording fixes so the doc quotes the actual UI labels:

1. Step names

The wizard omits "the". The <Steps> labels read as if quoting the UI, but the actual step titles are Define detector, Configure model, and Define data source.

  • Define the detector.Define detector.
  • Configure the model.Configure model.
  • Define the data source. (forecaster) → Define data source.

2. "Advanced settings" is mislabeled

The shingle-size section is titled Advanced model parameters in the UI, not Advanced settings:

Suggestion:

  1. Configure model. Add up to five features. For each feature, choose an aggregation method and field. Optionally add a categorical field to detect anomalies independently for each entity, then set the detection interval, frequency, window delay, and history. Use Suggest parameters for recommended operation settings, or open Advanced model parameters to configure the shingle size.

3. "Initially unselected" is slightly overstated

getInitialDatasourceId seeds the field from the currently-selected data source filter when one is set (empty only when none applies), so it's often pre-filled. Both <Aside> blocks (the AD one and the identical forecasting one) contain this sentence — suggest softening both:

The data source field defaults to the data source selected in the view, or is left unselected if none applies.

Also — not blocking, and outside this repo — this PR renames the anchors #rule-types#resource-types and inspect-and-manage-a-ruleinspect-and-manage-a-resource. They're consistent within the diff, but worth grepping the rest of the docs tree for any untouched links to the old anchors so they don't 404.

Thanks for verifying these details against the implementation. I addressed all three wording issues:

  • Updated the step labels to Define detector, Configure model, and Define data source.
  • Replaced Advanced settings with Advanced model parameters.
  • Updated both data source callouts to explain that the field defaults to the data source selected in the view or remains unselected when none applies.

I also searched the Starlight documentation tree for links to #rule-types and #inspect-and-manage-a-rule and found no remaining references to the old anchors. The Starlight build and internal link validation pass.

Signed-off-by: Jackie Han <hnyng@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants