[ws-man-bridge] Add started and completed metrics to track health

[easyCZ]

Description

Introduce metrics for when an update is received, and when an update is finished processing. The combination of these gives us something like and measurements for the system. This allows us to construct graphs where we can clearly see the following:

• How much data flows in
• How much data is completed
• How much of it errored
• How long it took to process

It's important to note these are seperate metrics, and should be. Sometimes a system doesn't output anything (due to error) and only reporting metrics on output would prevent us from capturing this case.

This PR also introduces a sub-method which does most of the existing logic, the original method is used to wrap the private one with metircs.

Related Issue(s)

• Part of [bridge] Ensure we do not override "failed" instance states (affects prebuilds!) #8596

How to test

• Workspace starts work
• Prebuilds work

Release Notes

NONE

Documentation

NONE

/hold

[easyCZ]

/werft run

👍 started the job as gitpod-build-mp-wsman-update-metrics.7

[geropl]

BTW: If a PR seems otherwise ready, but still has a "hold" label, I tend to be slightly put off to just start reviewing it.
Is there a reason this PR still has it? Would it make sense to add sth akin "make sure to remove the label before marking a PR as "review ready"" to our "how we work"? 🤔

[easyCZ]

Is there a reason this PR still has it? Would it make sense to add sth akin "make sure to remove the label before marking a PR as "review ready"" to our "how we work"? 🤔

I want to land them myself, so that I'm in control of the order of PRs going in and can ensure I know what has landed and what hasn't. It's a personal workflow. I tried to change it such that hold is on PRs by default but didn't get consensus as it seems it'd interfere with workflows of others.

IMO, we'll need to move this down the line in particular with stacked PRs as it's unlikely others will have the right context to know when exactly changes should land. In particular with feature flags, there may be some additional validation the author may want to do ahead of landing the change (ensure prod is disabled in the feature, for example). This in general goes back to putting more responsiblity on the author of the PR, and less on the reviewer - trust by default.

[easyCZ]

/unhold

[easyCZ]

/hold

[geropl]

Got this while testing:
💯 unrelated, but blocks testing.

[easyCZ]

Thanks @geropl, will investigate. Sorry about that, preview looks to be broken more often than not..

[geropl]

/werft run with-vm=true

👍 started the job as gitpod-build-mp-wsman-update-metrics.9

@easyCZ Got the same error, and just made very good experience with with-vm=true, so took the liberty to re-trigger 👍

[geropl]

After minutes of image pull I was able to use my workspace 😌

[easyCZ]

Thanks @geropl!

[easyCZ]

/unhold