## Summary
Replaces the categorized table of links with a single link to the
observability alerting docs because this table is likely to get stale
over time (in fact, it already is stale).
The change looks like this when rendered in HTML:
Notes/open issues:
- [x] The [main alerting
page](https://www.elastic.co/guide/en/kibana/master/alerting-getting-started.html)
for Kibana now has links to related alerting documentation, but is it
clear that those links point to docs that describe how to manage alerts
from those apps? The link text seems maybe not descriptive enough and
might be causing confusion. _NO CHANGE REQUIRED: I'm going to leave this
as-is because I think the feedback we received initially about the lack
of links was before the links were added._
- [x] In the intro, I feel a thought might be missing from this
statement: "For information on creating security rules, refer to Create
a detection rule." Should this instead say something like: "Security
rules must be defined in the Security app. For more information, refer
to the security docs about creating a detection rule." _RESOLVED_
- [x] I think the descriptions about each app's alerting capabilities
should be more consistent, but I don't want to rewrite other folk's
sections. So I have aligned my description with the security section,
for better or worse. It's hard to make this info consistent when each
solution/app is doing its own thing with alerting. _DEFERRED: We will
fix inconsistencies later._
- [x] Is it correct to say "create alerts" rather than something like
"trigger alerts" or "generate alerts"? _RESOLVED: Will keep as "create"
for now since the UI is not using "trigger."_
### Checklist
n/a
cc @lcawl Can you help me sort through my list of open issues?
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/163959
While digging into the original issue, it was determined that the
existing components were unsalvageable. Fixing all of the issues would
have required more work than just starting over. Problems with original
components include:
1) updating rule state on component load. This is the cause of the
reported bug.
2) lack of loading state when performing async tasks, like loading data
views.
3) not displaying validation errors. When users clicked "save" with
missing configuration, no UI notifications were displayed
4) Heavy use of EuiExpression made it impossible to view all
configuration in a single time
Now, geo containment form:
1) Only updates rule state when users interact with inputs.
2) Displays loading state when performing async tasks, like loading data
views.
3) Displays validation errors
4) Has a simpler UI that allows users to see all configuration
information at the same time.
<img width="300" alt="Screen Shot 2023-08-30 at 5 34 00 PM"
src="65abfa5d-6c8e-45a9-b69f-cc07f5be7184">
<img width="300" alt="Screen Shot 2023-08-30 at 5 34 48 PM"
src="63b5af12-7104-43ae-a836-0236cf9d1e98">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/163996
### To test
1) Checkout [fake tracks geo_shape
branch](https://github.com/nreese/faketracks/tree/geo_shape)
2) run npm install
3) run `node ./generate_tracks.js`
4) in kibana, create `tracks*` data view
5) create map, use "create index" and draw boundaries that intersect
tracks. See screen shot
<img width="500" alt="Screen Shot 2023-08-17 at 2 49 52 PM"
src="5f1444d7-2e12-4dd2-99c1-c730c2157e04">
6) create geo containment alert where entity index is `tracks*` and
boundaries index is `boundaries`.
7) Verify alerts get generated with entity geo_shape locations
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Relates to https://github.com/elastic/elasticsearch/pull/98330
8.10 introduces a new method to configure remote clusters (API key
based), which will live next to the existing method (certificate based).
As a result, the ES remote cluster docs will be restructured. The deep
link from "[Alerting set
up](https://www.elastic.co/guide/en/kibana/current/alerting-setup.html#alerting-ccs-setup)"
to the setting up CCS privileges section in the ES docs will break (and
would potentially bring folks to the wrong page anyway).
This PR changes the link into a link to the higher-level remote cluster
docs, from where folks can click through to the section that is relevant
to them.
👋🏼 @gchaps asked me to file a new PR since my last
https://github.com/elastic/kibana/pull/122573 got too far behind.
## Summary
🙏🏼 per #116017, adds insight on how to temporarily disable Kibana Rules
for clusters which need breathing room.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
resolves https://github.com/elastic/kibana/issues/142874
The alerting framework now generates an alert UUID for every alert it
creates. The UUID will be reused for alerts which continue to be active
on subsequent runs, until the alert recovers. When the same alert (alert
instance id) becomes active again, a new UUID will be generated. These
UUIDs then identify a "span" of events for a single alert.
The rule registry plugin was already adding these UUIDs to it's own
alerts-as-data indices, and that code has now been changed to make use
of the new UUID the alerting framework generates.
- adds property in the rule task state
`alertInstances[alertInstanceId].meta.uuid`; this is where the alert
UUID is persisted across runs
- adds a new `Alert` method getUuid(): string` that can be used by rule
executors to obtain the UUID of the alert they just retrieved from the
factory; the rule registry uses this to get the UUID generated by the
alerting framework
- for the event log, adds the property `kibana.alert.uuid` to
`*-instance` event log events; this is the same field the rule registry
writes into the alerts-as-data indices
- various changes to tests to accommodate new UUID data / methods
- migrates the UUID previous stored with lifecycle alerts in the alert
state, via the rule registry *INTO* the new `meta.uuid` field in the
existing alert state.
