Support push-based metrics export (OTLP) for serverless/Cloud Run deployments

[akshat-kumar-singhal]

GoFr currently exposes metrics via a /metrics endpoint for Prometheus scraping. This works well on Kubernetes where the Prometheus operator handles service discovery, but falls short on serverless platforms like Cloud Run, Lambda, or Knative where:

• Instances scale to zero — no long-lived process for Prometheus to scrape
• Setting up a Prometheus operator is significant operational overhead
• Instances are ephemeral — short-lived instances get missed between scrape intervals

Proposal

Since GoFr already uses OpenTelemetry for metrics internally (and supports OTLP for traces via TRACE_EXPORTER=otlp), extend the same pattern to metrics:

METRICS_EXPORTER=prometheus          # default, backwards-compatible
METRICS_EXPORTER=otlp                # push via OTLP
OTEL_EXPORTER_OTLP_ENDPOINT=...     # standard OTel env var

The commented-out otlpmetrichttp exporter in pkg/gofr/metrics/exporters/exporter.go suggests this was already considered.

Why OTLP push (not Prometheus PushGateway)

• PushGateway is designed for batch jobs, not services — it doesn't handle instance identity well
• OTLP is a vendor-neutral standard accepted by GCP Managed Prometheus, Grafana Cloud, Datadog, and others
• OTel SDK's PeriodicReader handles batching and graceful shutdown flush out of the box
• GoFr already depends on go.opentelemetry.io/otel — no new dependencies needed beyond otlpmetrichttp or otlpmetricgrpc

Alternatives considered

Approach	Downside
Prometheus PushGateway	Anti-pattern for services; stale metric handling is fragile
Sidecar Prometheus + remote_write	Extra container per instance; overkill on Cloud Run
Cloud-specific agents (e.g., GCP ops agent)	Vendor lock-in; not available on all platforms

Design decisions

• No dual export — METRICS_EXPORTER picks one mode (prometheus or otlp), not both simultaneously. Keeps the exporter pipeline simple and avoids double-counting concerns.
• Separate config from traces — OTLP metrics endpoint is configured independently from TRACER_URL, even when they point to the same collector. This avoids coupling and makes it clear which config controls what.
• 30s push interval default — shorter than OTel's 60s default to better capture metrics from short-lived serverless instances before they're terminated.

Open questions

1. Should the default transport be HTTP (otlpmetrichttp) or gRPC (otlpmetricgrpc)? HTTP is simpler to deploy behind load balancers and Cloud Run; gRPC is more efficient for high-volume push.
2. Config key naming — METRICS_OTLP_ENDPOINT and METRICS_OTLP_INTERVAL vs reusing the standard OTEL_EXPORTER_OTLP_METRICS_ENDPOINT?