This picks up where #425 left off.

We need a better UX around severe failures in heartbeat that cannot be correlated to a specific monitor. This was specifically inspired by #425 , where the failure to download a zip_url, or load the files inside (perhaps due to a syntax error) should create an actionable error in the Uptime UI rather than force the user to look through logs, something we're addressing in the beats in elastic/beats#29692.

To accomplish this we'll need to:

1. Have heartbeat send error documents to ES rather than logging wherever possible
2. Design a UI to display these error documents.

Proposed schema for error documents, uses the ECS fields for Error and Event

// datastream: synthetics-errors-default , could be synthetics-events-default if we want this index to be more generic for future uses
{
  @timestamp: "2022-01-01T00:00:00",
  timespan: { ... } // timespan field indicates how long this is relevant for
  event: {
    action: "run-suite",
  },
  error: {
    id: "unique-id-generated-by-application-or-service",
    message: "syntax error"
    type: "synthetics.suite.syntax-error",
    stack_trace: [ ... ], // optional
  },
  monitor: { // all fields here are optional, only necessary if it can be linked to a monitor
    id: "my-monitor",
    name: "My Monitor",
  },
}

CC @liciavale

As a side note, we could consider having this new index be more generic, an events index that could be used for other non-monitor result data than just these errors.

Tasks

• Kibana UI
  • Design
• Fleet package / schema update
• Heartbeat error reporting