Protokollierung von Django unter UWSGI

Ich bin mit meinem django-app per uwsgi-server und bin ab 32 Prozesse -args in meinem init-script:

ARGS="--pidfile ${PIDFILE} --uid ${UID} -s /tmp/${NAME}.sock --pythonpath ${GCS_HOME}/server/src/gcs --master -w wsgi -d ${GCS_HOME}/logs/uwsgi.log -p 32 -z 30"

Versionen Python 2.6.5 , Django 1.2.1, uWSGI 0.9.5.1

Ich möchte eine einzelne log-Datei, so bin ich mit einem multprocessing basierten Protokoll-handler wie beschrieben in Frage 641420.

Den multilogging handler funktioniert gut in einem einfachen test-app, die ich habe und auch wenn ich laufen die manage.py runserver_plus mit werkzeug, aber nix ist protokolliert, wenn ich mit django und uwsgi (ich bekomme keine Fehler oder Ausnahmen von uwsgi Prozess entweder wenn) .

Meine wsgi-Datei ist unten, wenn jemand ein problem erkennen, können mit meiner config oder eine Erklärung für das, was geschieht, wäre ich dankbar:

APP_VIRTUAL_ENV = "/home/devadmin/gcs/server/gcs_env/"
APP_PARENT_PATH = "/home/devadmin/gcs/server/src/"

##                                                                              

import sys
# Redirect stdout to comply with WSGI                                           
sys.stdout = sys.stderr

import os, site

# Set the settings module django should use                                     
os.environ['DJANGO_SETTINGS_MODULE'] = "gcs.settings"

# set the sys.path                                                              
site_packages_subpath = "/lib/python%s.%s/site-packages" % (sys.version_info[0]\
, sys.version_info[1], )
site_packages_path = os.path.join(APP_VIRTUAL_ENV, site_packages_subpath[1:])

sys_path = []
for path in sys.path:
    if site_packages_subpath in path and not path.startswith(APP_VIRTUAL_ENV):
        continue
    sys_path.append(path)

sys.path = [ APP_PARENT_PATH ]
sys.path += sys_path
site.addsitedir(site_packages_path)

# reorder sys.path                                                              
for path in sys_path:
    sys.path.remove(path)
sys.path += sys_path

# setup logging                                                                 
import os.path
import logging
import logging.config
logging.config.fileConfig(os.path.join(os.path.dirname(__file__), "logging.conf\
"))
Schwer zu sagen, was ist deine config-Datei Aussehen? Welche version von Python Sie? Sie importieren aber nicht mit multiproc_handler, und Sie sind nicht mit log_conf_file, dass Sie ' ve berechnet die tatsächliche fileConfig nennen, aus irgendeinem Grund.
Hinzugefügt Versionen oben und entfernt störende Linien aus wsgi.py (Sie waren übrig von debugging-ich war dabei. Auch festgestellt, dass wenn ich werkzeug/runserver_plus, die Protokollierung ist ok. So wäre das ein Hinweis darauf, dass irgendwie meine Protokollierung ist nicht richtig initialisiert über wsgi.py. Wenn ich mit einem standard-python-logging-handler (RotatingLogFileHandler) bekomme ich log-Ausgabe, aber das ist keine Lösung für mehrere uwsgi Prozesse.
Ich denke, das ist, weil die Berechtigungen auf den Ordner Protokoll. Vielleicht führen Sie debug-server von einem Benutzer und der Produktion von anderen? vielleicht kennen Sie aber auch.. aber es müssen Berechtigungen. Versuchen Sie, rwx auf den log-Ordner und dessen Eltern, für den Anwender.. oder wie eine debug-set rwx für alle.

InformationsquelleAutor rtmie | 2010-11-26

  1. 12

    ANTWORT WURDE AKTUALISIERT -Mai 15, 2013 -
    siehe unten für weitere logging-option

    Wenn Sie möchten, um eine einzelne log-Datei - die Verwendung von syslog, lassen Sie es behandeln multiplexing alle Eingänge in einer einzigen Datei. Mehrere Prozesse Anhängen, um eine einzelne Datei ist hässlich, sogar mit multiprocessing - Lösungen.

    Abgesehen von dem Vorteil thread /Prozess sicher 'Heruntermixen' von verschiedenen streams von logging-Informationen, können Sie immer geben Sie einen remote-host zu senden die Protokolle an, wenn Sie es wünschen, auch macht es die log-Datei rotation-ein Kinderspiel, wie Sie Ihre Kunden zu schreiben sind entweder ein domain-socket oder UDP-socket - Sie müssen nicht warten, während Sie verwalten die Dateien darunter. Und noch besser, werden Sie nicht verlieren Nachrichten.

    In Kombination mit einem syslog Daemons wie syslog-ng, die Sie tun können, viel Phantasie slicing und dicing, message-Weiterleitung, doppelte Filterung, etc.

    Lange Geschichte kurz - syslog ist besser als die Verwaltung Ihrer eigenen log-Datei (meiner Meinung nach), das beste argument gegen syslog ist, dass du nicht 'eigenen' der server (und anscheinend die log-Dateien können werden off limits für Sie).

    Wenn Sie wollen super genial, senden Ihre Login-Daten an splunk und nehmen Sie Ihr Spiel auf die nächste Ebene. Die meisten Leute verwenden Sie Splunk für die log-aggregation, aber syslogging aus Ihrer Anwendung in splunk ist eine Verknüpfung zu genial data mining-Funktionen zu verstehen, performance-Engpässe, Muster und vieles mehr. 

    #!/usr/bin/python

import logging
from logging.handlers import SysLogHandler

# Setup
logger = logging.getLogger( "mything" )
hdlr = SysLogHandler( address = '/dev/log', facility = SysLogHandler.LOG_USER )
logger.addHandler( hdlr )
formatter = logging.Formatter('%(name)s: %(levelname)s %(message)s')
hdlr.setFormatter( formatter )
logger.setLevel( logging.INFO )


logger.info( 'hello Laverne!' )
logger.debug( 'The Great Ragu has taken ill!' )

    NEUE INHALTE - Mai 15, 2013

    Gibt es eine zusätzliche option erwähnenswert, wenn man die Infrastruktur /Hartnäckigkeit, um es einzurichten - Sentry, die Bibliotheken für Python (wie auch Javascript und andere), die bietet einen zentralen Ort für Sie zu senden, Fehler zu überwachen. Es sieht gut aus.

    Für diejenigen, die daran interessiert das hinzufügen der SysLog-handler, der durch das Django settings.py Konfiguration, siehe @raacer Antwort auf die Frage im Zusammenhang: link

    InformationsquelleAutor synthesizerpatel

Schreibe einen Kommentar