Create new Rule Page under Observability

[mgiota]

This is a sub-issue of #119100

Acceptance criteria

• Add Rules menu option in the Observability sidebar and create a new rules page under observability
• Create a new Rules route and rules page
• Update the old Manage rules link in the Observability alerts page to to link to the new Rules page
• Add Breadcrumbs to the new Observability Rules Page
• Query and list only Observability rule types
  • keep a list of observability rule types and
  • use the find API to filter by rule type id
• Add static parts on the page
  • Documentation link
  • Last updated
• Add rules table
  • EuiBasicTable (currently used by current Rules and Connectors page)
• Add pagination
• New rules page is hidden behind a feature flag xpack.observability.unsafe.rules.enabled which is false by default

Implementation details

triggers_actions_ui plugin exports a loadAlerts method that internally calls the find API. All we need to pass to the loadAlerts function is a typeFilter argument, which should be an array of all the observability rule types. The value we need to use for each rule type is the id of the rule type when registering it to the alerting framework.. The id is then stored in a savedObject as alert.attributes.alertTypeId (alertTypeId is actually ruleTypeId).

Below you can see an example code of how to use the existing loadAlerts method of the triggers_actions_ui plugin and right after the list of all observability registered rule types (id).

import {
  loadAlerts as loadRules,
} from '../../../../../../../plugins/triggers_actions_ui/public';

  async function loadObservabilityRules() {
    try {
      const response = await loadRules({
        http,
        page: { index: 0, size: 10 },
        typesFilter: ['xpack.uptime.alerts.monitorStatus'],
      });
      setRules({
        data: response.data,
      });
    } catch (_e) {
      toasts.addDanger({
        title: i18n.translate('xpack.observability.alerts.ruleStats.loadError', {
          defaultMessage: 'Unable to load rules',
        }),
      });
    }
  }

Uptime

export const CLIENT_ALERT_TYPES = {
  MONITOR_STATUS: 'xpack.uptime.alerts.monitorStatus',
  TLS_LEGACY: 'xpack.uptime.alerts.tls',
  TLS: 'xpack.uptime.alerts.tlsCertificate',
  DURATION_ANOMALY: 'xpack.uptime.alerts.durationAnomaly',
};

APM

export enum AlertType {
  ErrorCount = 'apm.error_rate', // ErrorRate was renamed to ErrorCount but the key is kept as `error_rate` for backwards-compat.
  TransactionErrorRate = 'apm.transaction_error_rate',
  TransactionDuration = 'apm.transaction_duration',
  TransactionDurationAnomaly = 'apm.transaction_duration_anomaly',
}

Metrics threshold and Inventory threshold

export const METRIC_INVENTORY_THRESHOLD_ALERT_TYPE_ID = 'metrics.alert.inventory.threshold';
export const METRIC_THRESHOLD_ALERT_TYPE_ID = 'metrics.alert.threshold';

Log Threshold

export const LOG_DOCUMENT_COUNT_RULE_TYPE_ID = 'logs.alert.document.count';

Sub-tickets

• Style EuiBasicTable according to design #126774
• Refactor Rules Table to use a useFetchRules hook #126775

[mgiota]

Here are a couple of questions we need to clarify as part of Query and list only Observability rule types

How do we define "observability" rules? Is there a tagging mechanism when a rule is created, or do we have to maintain a hard-coded list of rule type IDs to query for? If the latter, can we at least centralize that list of IDs for ourselves? What is the current list of these IDs?

According to this comment #116476 (comment) the find API takes filters so we can filter by rule type id (still named alertTypeId in the rule saved object). Here is an example of using the find API to filter by rule type: https://localhost:5601/api/alerting/rules/_find?page=1&per_page=10&filter=alert.attributes.alertTypeId%3A(apm.error_rate)&default_search_operator=AND&sort_field=name&sort_order=asc. So we need to keep a list of observability rule types for this kind of query.

[katrin-freihofner]

Rule list view for Observability

Notes

• As long as we only have edit and delete as actions for each rule, I would recommend showing them for each row. If we need more actions we can use and overflow menu (icon button showing three boxes horizontal that opens a dropdown). The prototype shows these actions on hover, I think we can show them immediately.
• Enable/disable/mute a rule:

• The mockups show only a few rules in the table, please show at least 25 rows by default.

Prototype: https://www.figma.com/proto/pgwzuZPxP2r8jMiLkRBrNe/Observability-Rules-Page?page-id=63%3A167314&node-id=63%3A167315&viewport=376%2C48%2C0.5&scaling=min-zoom&starting-point-node-id=63%3A167315&show-proto-sidebar=1

[mgiota]

• Enable/disable/mute a rule:

@katrin-freihofner Can you clarify a bit more the interaction with the Status column? I already see a challenge with the current design in the scenario user selects Muted. Taking into consideration the fact that muted option should appear in the status column as per your screenshot and considering also the current mute/unmute userflow, here are a couple of questions that arose and my recommended solution. You can watch the recording attached on a quick prototype of how this would look like:

• When user selects Muted, the status is actually both Enabled and Muted. How do we want to display this in the UI? Suggestion: Status column should say Enabled and Muted should appear next to the name similar to how it looks like in current implementation. In my opinion it looks a bit weird that user selects Muted and it still says Enabled. But if we show Muted, user won't be seeing that this rule is Enabled.
• How can a user Unmute a rule? I didn't find anything in the Figma file. Suggestion: I replace Muted with Mute if rule is muted, although I am not so confident about this solution, since we are mixing verb with adjectives. I tried to be as close as possible to your design with the three statuses you suggested.
• In case status is Disabled the Muted option should be disabled, right? Suggestion: As you can watch in the recording, I disable the muted option in this case
• If rule is Muted and Disabled, then instead of Muted it should say Unmute.

Screen.Recording.2022-03-06.at.16.07.52.mov

Another recommendation

• We can keep only Enabled and Disabled in the Status column and we display Muted next to the rule name
• We can add the Mute & Unmute options in the Actions column. In this case do we want to display buttons for muting/unmuting or do you want me to add three dots with Mute and Unmute text accordingly?
• In the filters we could filter by Enabled, Disabled and Muted

Let me know what you think and how I should proceed. Until the Mute user flow is clarified, I will display only Enabled and Disabled in the Status column.

cc @vinaychandrasekhar