Add Prometheus Metric QOL improvements to local env

[liam-lowe]

What was changed

• Adds Prometheus to local development environment to facilitate easier local testing / debugging / verification.

Why?

• Local develop environment lacked ease of validation for prometheus metrics.

Checklist

How was this tested

• make start-dependencies and opened http://localhost:9090/

Documentation

• Added make target: show-dependencies-ports.
  • Preferred over adding documentation (docs can go stale, this is more accessible - prints in cli after docker compose up

[liam-lowe]

Opted to derive from env file as source of truth. Result is a more readable, and links are cmd+clickable:

Exposed localhost ports:
  temporal-left                      http://localhost:4000
  temporal-right                     http://localhost:5000
  proxy-left                         http://localhost:4001
  proxy-right                        http://localhost:5001
  proxy-left-metrics                 http://localhost:4091
  proxy-right-metrics                http://localhost:5091
  prometheus                         http://localhost:9090
  temporal-left-ui                   http://localhost:4233
  temporal-right-ui                  http://localhost:5233

The "more-correct" approach would be to derive from running containers directly - something like docker compose ps --format "table {{.Service}}\t{{.Ports}}"

But the result is actually less-usable and descriptive imo.

SERVICE          PORTS
prometheus       0.0.0.0:9090->9090/tcp, [::]:9090->9090/tcp
proxy-left       0.0.0.0:4001->6233/tcp, [::]:4001->6233/tcp, 0.0.0.0:4091->9091/tcp, [::]:4091->9091/tcp
proxy-right      0.0.0.0:5001->6333/tcp, [::]:5001->6333/tcp, 0.0.0.0:5091->9091/tcp, [::]:5091->9091/tcp
temporal-left    0.0.0.0:4000->7233/tcp, [::]:4000->7233/tcp, 0.0.0.0:4233->8233/tcp, [::]:4233->8233/tcp
temporal-right   0.0.0.0:5000->7233/tcp, [::]:5000->7233/tcp, 0.0.0.0:5233->8233/tcp, [::]:5233->8233/tcp

The downside of implemented approach is that the make implementation isn't particularly easy to read, and isn't deriving from more reliable source of truth.

[temporal-nick]

Why do we want a prometheus server in here?

[liam-lowe]

Intent is to facilitate faster and more-reliable local testing, specifically for metrics - which is where I'm making changes next.

There are 3 approaches I see:

• Grep via /metrics (either inside container or exposed localhost port)
• Prometheus
• Grafana

I think Prometheus is faster to validate locally than exposing each /metrics/ port and grepping logs, and lighter weight with less configuration than Grafana.

There could be use case for Grafana in the future, but at the moment, I don't believe we need it.

[hehaifengcn]

i thought we want to use different name other than left/right? not need for this PR. just want to understand if we still plan to do so.

[liam-lowe]

Agreed. We will standardize - but outside scope of this PR.