fix: properly determine running workspaces count

[ethanndickson]

Part of the previous query didn't make sense and was completely wrong (though it is admittedly confusing). Here's part of the DB query for retrieving running workspaces:

-- Special case where the provisioner status and workspace status
-- differ. A workspace is "running" if the job is "succeeded" and
-- the transition is "start". This is because a workspace starts
-- running when a job is complete.
WHEN $4 = 'running' THEN
    latest_build.job_status = 'succeeded'::provisioner_job_status AND
    latest_build.transition = 'start'::workspace_transition

This new promql query follows this logic, but also uses a max by to handle duplicate metrics from multiple coder replicas:

 count(kube_pod_status_ready{condition="true", namespace=`coder-workspaces`} == 1)
 or
-count(coderd_api_workspace_latest_build{status="running"})
+sum(max by (workspace_owner, template_name, template_version) (coderd_workspace_latest_build_status{status="succeeded", workspace_transition="start"}))
 or
 vector(0)

Tested on dogfood and on my scaletest cluster.

[ethanndickson]

• fix: properly determine running workspaces count #59 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[dannykopping]

Good catch, thanks!
Can you cut a patch release pls? https://github.com/coder/observability/blob/main/PUBLISH.md