🌵 [SPIKE] Investigate feasibility of using prom-client for Ghost metrics

[cmraible]

ref https://linear.app/tryghost/issue/ENG-1505/start-monitoring-event-loop-utilization-in-production-with
ref https://linear.app/tryghost/issue/PRO-197/node-runtime-performance-prometheus-exporter

• This spike adds a /metrics endpoint to Ghost that exposes all the default metrics included in prom-client. The list includes some basics, like CPU and memory usage, metrics for Node's event loop, and metrics for Node's garbage collection. For many of these metrics, we currently have no visibility into them.
• It also includes some custom metrics like Ghost's connection pool utilization, request queue depth, active workers for the jobs manager, and some basic HTTP response time percentile data.
• It also adds two new services to our docker-compose.yml for development: prometheus, to scrape the metrics from Ghost, and Grafana to expose the metrics in a nice browser-based dashboard so you can view these metrics locally:

• With this foundation, we can also add our own custom metrics to our code, that will automatically be reported to prometheus and can be visualized in Grafana.

Todo

• Decouple from existing express apps and expose this on its own port, to avoid exposing metrics publicly and so Ghost will (hopefully) respond to scraping requests even if the main express apps are falling over
• Pull the prometheus (and any custom metrics) into their own package?
• Figure out why request queue unit tests are failing
• Investigate using docker compose profiles to only boot prometheus and grafana if opted in via environment variable