[Heartbeat] Add managed status reporter at monitor factory level #41077
Conversation
emilioalvap
added
enhancement
Team:obs-ds-hosted-services
|
Pinging @elastic/obs-ds-hosted-services (Team:obs-ds-hosted-services) |
botelastic
bot
added
needs_team
| @@ -175,6 +182,9 @@ func newMonitorUnsafe( | |||
|
|
|||
| logp.L().Error(fullErr) | |||
| p.Jobs = []jobs.Job{func(event *beat.Event) ([]jobs.Job, error) { | |||
| // if statusReporter is set, as it is for running managed-mode, update the input status | |||
| // to failed, specifying the error | |||
| m.updateStatus(status.Failed, fmt.Sprintf("monitor could not be started: %s, err: %s", m.stdFields.ID, fullErr)) | |||
There was a problem hiding this comment.
Reading this
// Failed is status describing unit is failed. This status should
// only be used in the case the beat should stop running as the failure
// cannot be recovered.
Could this cause other HB to stop and also other monitors from running? Is this intended?
There was a problem hiding this comment.
Could this cause other HB to stop and also other monitors from running?
It probably won't (it doesn't, as of now). Even if that were the case, since the status is scoped at monitor level, it should only filter the failed integrations, but I'm speculating here. There are also multiple status layers, this change only affects the stream (not even the integration) status.
As for the status, either failed or degraded should achieve the same purpose, I'm open to discussion on the implications. I leaned on failed because the type of error that is caught on this part is generally not recoverable.
There was a problem hiding this comment.
I was worried if it could stop the other monitors. But if thats not the case, I am not super inclined towards changing this.
| } | ||
|
|
||
| // SetStatusReporter | ||
| func (m *Monitor) SetStatusReporter(statusReporter status.StatusReporter) { |
There was a problem hiding this comment.
Since its set on the Monitor level, what happens if multiple monitors were configured, does the errors get accumulated or there is upper limit to how its shown in the UI ?
There was a problem hiding this comment.
Every monitor will map 1:1 to an agent integration, which Fleet UI already shows individually:
|
@emilioalvap Do you intent to add changelog entry? |
emilioalvap
added
backport-8.15
) * [Heartbeat] Add status reporting for monitors when running under elastic-agent (cherry picked from commit c70d2d8)
) * [Heartbeat] Add status reporting for monitors when running under elastic-agent (cherry picked from commit c70d2d8)
…auto-merge #41077 (#41133) * [Heartbeat] Fix linting issues introduced by auto-merge #41077 (#41128) * Manual merge * [Heartbeat] Add status reporter at monitor factory level (#41077) --------- Co-authored-by: Emilio Alvarez Piñeiro <95703246+emilioalvap@users.noreply.github.com> Co-authored-by: emilioalvap <emilio.alvarezpineiro@elastic.co>
…uto-merge #41077 (#41134) * [Heartbeat] Fix linting issues introduced by auto-merge #41077 (#41128) (cherry picked from commit efb563c) # Conflicts: # heartbeat/monitors/monitor.go # heartbeat/monitors/monitor_test.go * Merge conflicts * [Heartbeat] Add status reporter at monitor factory level * Add unit test and changelog --------- Co-authored-by: Emilio Alvarez Piñeiro <95703246+emilioalvap@users.noreply.github.com> Co-authored-by: emilioalvap <emilio.alvarezpineiro@elastic.co>
Proposed commit message
Add status reporting for monitors when running under elastic-agent, this will allow the Fleet UI to reflect theres an issue with one or more heartbeat integrations.
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.How to test this PR locally