Skip to content

Monitoring

NuGetKeep exposes a Prometheus scrape endpoint at /metrics — anonymous and on by default; set NUGETKEEP_METRICS_ENABLED=false to disable it. What’s in the scrape (ASP.NET Core request metrics, .NET runtime metrics, and NuGetKeep’s per-feed push/quarantine/download counters) is documented in the configuration reference.

If you already run Prometheus, just point a scrape job at /metrics. If you don’t, the installer can bring a ready-made stack up next to the server.

Terminal window
curl -fsSL https://nugetkeep.com/install | bash -s -- --with-monitoring

This adds two sidecar containers to the compose stack:

  • Prometheus — internal-only (not published on a host port); scrapes the app’s /metrics every 15 seconds over the compose network.
  • Grafana — published on the host at --grafana-port (default 3000). Log in as admin with the generated NUGETKEEP_GRAFANA_PASSWORD from deploy/.env; the install summary prints it too.

Grafana comes provisioned with the Prometheus datasource and a NuGetKeep dashboard charting HTTP request rate and latency (p50/p95), package downloads by feed, push / quarantine / release rates, memory working set, and GC pause time.

Metrics history survives docker compose down in the prometheus-data and grafana-data volumes.

If your cluster runs the Prometheus Operator, enable the chart’s ServiceMonitor:

Terminal window
helm upgrade <release> oci://ghcr.io/atypical-consulting/charts/nugetkeep \
--reuse-values --set monitoring.serviceMonitor.enabled=true

It scrapes /metrics on the service’s HTTP port every monitoring.serviceMonitor.interval (default 30s); add selector labels for your Prometheus instance via monitoring.serviceMonitor.labels. The toggle is off by default because it requires the Prometheus Operator CRDs (monitoring.coreos.com/v1) — without them the install fails with “no matches for kind ServiceMonitor”.