[Uptime] Allow Heartbeat to capture body text on error

[dov0211]

Allow Heartbeat to capture text on error.
Since the text might be long we should consider limit its size.

   "monitor": {
      ...
      "status": "down",
      "text_on_error": "500 Internal Server Error"
      ...
     }

@andrewvc

[andrewvc]

PR Here: elastic/beats#13022

[andrewvc]

@katrin-freihofner we'll need some help on the design for this one. We'll want to add this to the monitor detail pages somehow.

[andrewvc]

@katrin-freihofner one additional thought, my initial thinking here is that we should keep it simple for v1, since we're thinking of replacing the ping list component with timelines. Fitting this data (and error data) into timelines is kind of tricky, but I don't think we need to solve that here of course.

[katrin-freihofner]

@andrewvc I would combine it with the error column and give this one more space/width. Similar to this:

[andrewvc]

@katrin-freihofner to be clear, you'd literally concatenate the error + body strings if I understand. Is that right?

[katrin-freihofner]

@andrewvc yes, that is my proposal. Having it in it's own column would only make sense if users want to sort it by error message and error type separately - but I guess sorting it by error type makes more sense, doesn't is?

[andrewvc]

Hmmm, how would that work when the body is recorded but the response is a success. In the patch that is a possibility. Additionally, displaying a full kilobyte in that column might be a bit much.

I'm thinking a drawer makes a lot of sense here because it will handle larger content sizes really well and we could include the first N bytes of the body + the checksum (with a zoom to filter icon on the body checksum).

WDYT? Is this a misuse of drawers? I'm worried that cramming it all into one column will yield some weird pages.

[katrin-freihofner]

@andrewvc yes, I agree it is better to move it to an expandable row.

[andrewvc]

Closing this in favor of implementation issue here: #76