The edge proxy exposes structured JSON logs and health endpoints but no metrics. Operators have no visibility into the running instance resource usage or how effectively the flag cache is serving requests. The Flagsmith API already supports a Prometheus /metrics endpoint via PROMETHEUS_ENABLED plus OTLP export, so the edge proxy is the gap in an otherwise observable stack.
Proposed: expose a Prometheus /metrics endpoint, opt-in via config (PROMETHEUS_ENABLED, mirroring the backend). Optional OTLP export for shops already on OpenTelemetry.
Runtime / process performance:
- CPU time (process_cpu_seconds_total)
- Resident and virtual memory (process_resident_memory_bytes, process_virtual_memory_bytes)
- Open file descriptors (process_open_fds)
- Process uptime (process_start_time_seconds)
- Runtime stats where feasible: worker thread count, active tasks, queue depth (it is an async runtime)
Cache (if possible):
- Hits and misses as counters, so hit ratio is derivable
- Current entries vs capacity (occupancy)
- Evictions
The edge proxy exposes structured JSON logs and health endpoints but no metrics. Operators have no visibility into the running instance resource usage or how effectively the flag cache is serving requests. The Flagsmith API already supports a Prometheus /metrics endpoint via PROMETHEUS_ENABLED plus OTLP export, so the edge proxy is the gap in an otherwise observable stack.
Proposed: expose a Prometheus /metrics endpoint, opt-in via config (PROMETHEUS_ENABLED, mirroring the backend). Optional OTLP export for shops already on OpenTelemetry.
Runtime / process performance:
Cache (if possible):