2010-07-23 15 views
11

Mam stronę internetową z Django i używam standardowego modułu logowania do śledzenia aktywności w Internecie.Problem z logowaniem w Pythonie RotatingFileHandler na stronie Django

Rejestr jest wykonywany za pomocą programu RotatingFileHandler, który jest skonfigurowany z 10 plikami dzienników, po 1000000 bajtów. System logowania działa, ale są to pliki dziennika, które otrzymuję:

-rw-r--r-- 1 apache  apache   83 Jul 23 13:30 hr.log 
-rw-r--r-- 1 apache  apache  446276 Jul 23 13:03 hr.log.1 
-rw-r--r-- 1 apache  apache  999910 Jul 23 06:00 hr.log.10 
-rw-r--r-- 1 apache  apache   415 Jul 23 16:24 hr.log.2 
-rw-r--r-- 1 apache  apache  479636 Jul 23 16:03 hr.log.3 
-rw-r--r-- 1 apache  apache   710 Jul 23 15:30 hr.log.4 
-rw-r--r-- 1 apache  apache  892179 Jul 23 15:03 hr.log.5 
-rw-r--r-- 1 apache  apache   166 Jul 23 14:30 hr.log.6 
-rw-r--r-- 1 apache  apache  890769 Jul 23 14:03 hr.log.7 
-rw-r--r-- 1 apache  apache  999977 Jul 23 12:30 hr.log.8 
-rw-r--r-- 1 apache  apache  999961 Jul 23 08:01 hr.log.9 

Jak widać, jest bałagan. Ostatni log został zapisany do pliku hr.log.2 (lip 23 16:24) zamiast hr.log i logging documentation stwierdza, że:

[...] Na przykład, z backupCount z 5 i nazwa pliku podstawowego app.log, dostaniesz app.log, app.log.1, app.log.2, aż do app.log.5. Zapisywany plik to zawsze app.log. Gdy ten plik zostanie wypełniony, zostanie zamknięty i zmieni jego nazwę na app.log.1, a jeśli pliki app.log.1, app.log.2 itd. Istnieją, to zostaną zmienione na app.log.2, app. log.3 itd., odpowiednio.

Co robię źle?


Mój plik konfiguracyjny jest rejestrowanie:

logger.conf:

[loggers] 
keys=root 

[handlers] 
keys=fileHandler 

[formatters] 
keys=simple 

#-------------------------------------------------------------------- 
# Formatters 
[formatter_simple] 
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s 

#-------------------------------------------------------------------- 
# Handlers 
[handler_fileHandler] 
class=handlers.RotatingFileHandler 
level=DEBUG 
formatter=simple 
args=("/data/django/hr/hr.log",'a',1000000,10) 

#-------------------------------------------------------------------- 
# Loggers 
[logger_root] 
level=DEBUG 
handlers=fileHandler 

i mój moduł Pythona aby skonfigurować system dziennika jest:

logger.py

import os, logging 

# Load config file 
logger_config_file = \ 
    os.path.join(os.path.abspath(os.path.dirname(__file__)), 'logger.conf') 
logging.config.fileConfig(logger_config_file) 

# Create logger 
logger = logging.getLogger('hr_Logger') 

# Log start message 
logger.info("Logging system started") 

, wtedy szczycie mojej views.py mam:

import logging 
from hr import logger 

log = logging.getLogger('hr.views') 
log.info('Load hr.views') 

[...] 
+1

próbowałem konfiguracji lokalnie z kodem i działa dobrze. Nie mogę pomóc, ale zauważ, że znaczniki czasu to w większości: 30 i: 03. Zwłaszcza od 14:03 wygląda na to, że pliki dzienników zostały obrócone poza aplikację. Jedna idea: czy jesteś pewien, że jest to jedyne skonfigurowane rejestrowanie? Wygląda trochę tak, jakbyś miał inny kod logowania, który zachowuje uchwyt otwartego pliku. Podczas gdy ten drugi uchwyt wskazywał na hr.log, gdy uruchomiono aplikację, od tego czasu został obrócony do hr.2. –

+0

Więc ... nie mówisz, że system logowania jest uszkodzony, tylko że znaczniki czasu zostały zmienione? Czy pliki dziennika są obracane we właściwej kolejności? Właśnie sprawdziłem znaczniki czasu na moich obrotowych dziennikach za pomocą tej samej metody i są one we właściwej kolejności. Nie mam żadnego przetwarzania dziennika, który przetwarza dzienniki. Wygląda na to, że możesz mieć okresowe zadanie, które może dotyka plików? – Kekoa

+0

@Kekoa Jak już mówisz, system dzienników nie jest uszkodzony, po prostu nie działa zgodnie z oczekiwaniami. Niestety, nie pracuję już nad projektem i nie jestem w stanie przetestować żadnej możliwej sugestii. Dziękuję Ci. – ssoler

Odpowiedz

7

Znalazłem to zachowanie, gdy istnieje wiele precesses są uruchomione z kodu.

Niestety nie istnieje opcja idealna.

Kilka pomysłów, można włączyć to:

  • użycie WatchedFileHandler (nowego w 2.6) i obracać z zewnętrznych programów jak logrotate
  • użytkowania syslog lub inny dziennik agregowania serwer
  • użycie Pythona dziennika agregację sentry - jest to szczególnie przydatne w przypadku django, ponieważ można rejestrować nie tylko komunikaty dziennika, ale także wyjątki z pełnym stosem stacków i 404.
Powiązane problemy