[Heartbeat] Monitor Retries

[andrewvc]

After experimenting around a bit, this gets retries working, using code at the monitor level. This also really neatly refactors the summary and state wrappers into much easier to understand code. This is an experiment only. Code is still pretty ugly and we should reorganize parameters and objects into something neater than what's here.

The main question this seeks to answer is where we should put this logic.

Sample output of:

x-pack/heartbeat$  mage build && ELASTIC_SYNTHETICS_CAPABLE=true ./heartbeat -e | jq -c  '{"monitor": {"name": .monitor.name, "status": .monitor.status}, "summary": .summary, "state": .state}'
{"monitor":{"name":"Test","status":"up"},"summary":null,"state":null}
{"monitor":{"name":"Test","status":"up"},"summary":null,"state":null}
{"monitor":{"name":"Test","status":"up"},"summary":null,"state":null}
{"monitor":{"name":"Test","status":"up"},"summary":{"status":"up","retry_group":"R-netflix-1898aee1e84","attempt":1,"max_attempts":2,"final_attempt":false,"up":5,"down":0},"state":{"duration_ms":"0","up":1,"id":"default-1898aee1ec0-0","started_at":"2023-07-24T21:43:28.576999-05:00","status":"up","checks":1,"down":0,"flap_history":[],"ends":null}}
{"monitor":{"name":"Test","status":"up"},"summary":null,"state":null}
{"monitor":{"name":"Test","status":"up"},"summary":null,"state":null}
{"monitor":{"name":"Test","status":"up"},"summary":null,"state":null}
{"monitor":{"name":"Test","status":"up"},"summary":{"up":5,"down":0,"status":"up","retry_group":"R-netflix-1898aee1e84","attempt":2,"max_attempts":2,"final_attempt":true},"state":{"id":"default-1898aee1ec0-0","started_at":"2023-07-24T21:43:28.576999-05:00","duration_ms":"23","checks":2,"down":0,"ends":null,"status":"up","up":2,"flap_history":[]}}

Why is it important?

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[elasticmachine]

Pinging @elastic/uptime (Team:Uptime)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @andrewvc? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-08-31T18:00:47.286+0000

• Duration: 92 min 39 sec

Test stats 🧪

Test	Results
Failed	0
Passed	28157
Skipped	2015
Total	30172

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[andrewvc]

@emilioalvap thanks for the review feedback, I think I've addressed your concerns. Now if I can make the linter happy 🤞 I think the build may go green soon

[emilioalvap]

LGTM. One last concern, changes to enrich.go we discussed the other day about emitting summaries on cmd/status only don't seem to have been included yet:

beats/x-pack/heartbeat/monitors/browser/synthexec/enrich.go

Line 144 in eef9598

return je.createSummary(event)

[ycombinator]

Not sure this needs to be a pointer.

[ycombinator]

I'm far from an expert in Heartbeat / Synthetics so I didn't review the logic in this PR. But I made a few general Golang code review comments.

[andrewvc]

@ycombinator thanks for the review, I think I've addressed all of your comments

[ycombinator]

LGTM.

[vigneshshanmugam]

@andrewvc Sorry for the delayed note on this PR, Would this break the existing uptime UI in any way.

[andrewvc]

No, the UI treats the UUID as opaque values, as does ES (it's a keyword type, there's no dedicated UUID type).