In Django application, '/metrics' unaccessible when using Unix Domain Sockets

Offen

#926 erstellt am 19.6.2023 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 4/5
Geschätzter Aufwand: 3-5 Tage
Anfängerfreundlichkeit: 25/100

Issue-Typ: Bug
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: nginx, python
Bereich: backend, networking, observability

Rechercherichtung

Beginne mit den im Issue gezeigten NGINX location blocks und der Prometheus scrape target-Konfiguration und vergleiche anschließend die Einrichtung des Unix domain socket mit der funktionierenden Gunicorn TCP-Einrichtung. Ermittle, ob der metrics endpoint diesen Bereitstellungspfad unterstützt, und dokumentiere entweder eine verifizierte Konfiguration oder die erforderliche Einschränkung.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Im using the django_prometheus library which is a wrapper for prometheus_client library for my Django app. I am not running Prometheus, (or the entire applcaition in a Docker container), which might be part of my problem, though I dont see why this would be a requirement. The Django application is bound to Unix Domain Sockets,. NGINX is listening on default port 80 and re-routes traffic with the proxy_pass header.

NGINX

server {
    server_name hotname www.hostname ip;

[...]
    location /metrics{

        proxy_pass http://<unix_domain_socket>;
    }

    location / {
        proxy_pass http://unix:<unix_domain_socket>;
        
}

prometheus

<default prom config>
[...]
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "django-app"
    scrape_interval: 10s
    static_configs:
      - targets: ["localhost] # nothing works (IP, etc..) and prometheus attempts to use port 80 with a predefined scheme of http://

  - job_name: "node"
    scrape_interval: 10s
    static_configs:
      - targets: ["localhost:9100"]

Solution

By removing the unix domain socket in NGINX and going back to TCP/IP that gunicorn uses by default, Prometheus was able to successfully pickup metrics from /metrics

Is there something Im missing? I feel like the only other options are changing the whole infrastructure ( to docker), or try and use a log based-metrics.

Vorherrschende Sprache: Python
Sterne: 4.4k
Forks: 876
Ø Merge: 8 T. 4 Std.
Gemergte PRs (30 T.): 1

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus prometheus/client_python

OpenMetrics content negotiation: `escaping=underscores` causes name mismatch between `HELP/TYPE` metadata and sample lines for metrics with colons Offen

bug

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100

prometheus/client_python#1177 · 1 Kommentar · Erstellt am 15.5.2026
Support OpenMetrics 2.0 exposition format Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100

prometheus/client_python#1210 · Erstellt am 23.9.2026
MultiProcessCollector fails permanently on an empty metrics file left by a killed worker Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 58/100

prometheus/client_python#1199 · 1 Reaktion · Erstellt am 12.8.2026
feature request/RFC: leave out a label (from at least `*MetricFamily` samples) when it's value is set to `None` Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

prometheus/client_python#1176 · Erstellt am 14.5.2026
WSL and MultiProcessCollector Offen

Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 52/100

prometheus/client_python#1126 · 2 Kommentare · Erstellt am 29.8.2025

Alle Issues in prometheus/client_python