sentry to coś w rodzaju agregatora logów. W przypadku projektów Django używamy go do logowania wyjątków jak i innych informacji pisanych przez nasz kod do logów. Zamiast wysyłać maila z wyjątkiem do administratora wszystko zapisywane jest w sentry.
Sentry to aplikacja napisana w Django. Obsługuje logowanie z różnych frameworków, czy języków (nawet JavaScript). Aplikację można szybko odpalić lokalnie, odpalić na własnym serwerze, albo wykupić instancję na getsentry.
W tym artykule przedstawię jak odpalić Sentry lokalnie (np. do testów) i jak skonfigurować Django by logowało wszystko do Sentry.
Pod Ubuntu-pochodną nie miałem plików nagłówkowych Pythona (pakiet *-dev) co wyłożyło kompilację setproctitle. Zainstalowanie libpython-all-dev z repozytorium załatwiło sprawę. Dodatkowo obecne Sentry (0.5.5) nie jest kompatybilne z Django 1.5, więc jeżeli w systemie masz tą lub nowszą wersję to Sentry trzeba zainstalować w virtualenvie.
Po instalacji musimy stworzyć gdzieś plik konfiguracyjny:
sentry init conf.py
Wygenerowany zostanie plik konfiguracyjny, który możemy edytować. Jak na konfigurację testową wystarczy. Można zmienić EMAIL_BACKEND na konsolę, by próby wysłania emaila nie kończyły się wyjątkiem:
Następnie tworzymy tabele i wszystko co Sentry chce (tworzymy konto superużytkownika):
sentry --config=conf.py upgrade
Możemy już uruchomić aplikację poleceniem:
sentry --config=conf.py start
Wejdź na http://localhost:9000 by dokończyć rejestrację i założyć pierwszy logowany projekt:
Tworzenie zespołu w Sentry
Zakładanie pierwszego projektu
Jako platformę wybieramy ten język/framework, którego używamy i chcemy zintegrować z Sentry. W tym przypadku będzie to Django. Po stworzeniu pierwszego projektu Sentry wyświetli instrukcje podpięcia logowania wyjątków z Django. Nie powie jednak wszystkiego...
To by było na tyle jeżeli chodzi o logowanie wyjątków. Ta konfiguracja nie obejmuje logowania wyjątków Celery (jeżeli używamy), jak i nie uwzględnia przekazywania przydanych danych do logów gdy używamy Pythonowego modułu logging. O tym za chwilę. Teraz czas na test logowania wyjątków.
Załóżmy że mamy widok, któremu zdarzy się rzucić wyjątkiem:
fromdjango.viewsimportgenericclassExceptionView(generic.View):defget(self,request,**kwargs):raiseValueError('I don\'t like this value')exception_view=ExceptionView.as_view()
Co powinno zostać zapisane do Sentry:
Wyjątek z widoku zapisany w Sentry
Można kliknąć na wpis by zobaczyć szczegóły, w tym wyjątek, stacktrace, informacje o użytkowniku Django i parę innych danych.
Moduł logging często jest wykorzystywany by logować jakieś zdarzenia, które np. nie powinny wystąpić (ale jak wystąpią to rzucenie wyjątkiem nie jest potrzebne). Oto prosty przykład:
Co opisano także w dokumentacji Sentry. W powyższym przykładzie "root" jak i "sentry" mają poziom ustawiony na "DEBUG" więc będą logować wszystkie typy zdarzeń. Po takim skonfigurowaniu LOGGING zdarzenia z naszych testowych widoków zapiszą się do Sentry, ale będą dość skąpe w informacje:
Mamy komunikat, miejsce w pliku i tyle. Nie wiemy która klasa (widok) rzucił tym wpisem, nie mamy requestu. Możemy wykorzystać dodatkowy argument przyjmowany przez metody loggera - extra będący słownikiem z dodatkowymi danymi do zapisu. Sentry używa extra do zapisu requestu jak i staktrace.
Request pod kluczem request ładnie zaloguje cały obiekt request. Dodanie stack ustawionego na True spowoduje zapisanie stacktrace (co powie, np. który z widoków tak naprawdę wygenerował wpis). Zamiast wszędzie dodawać stack można w settingsach dodać:
Gdzie "celery_task" to nazwa funkcji-taska Celery.
Warning z zapisanym stacktrace z zadania Celery
Żeby używać loggera normalnie można w settingsach dodać:
CELERYD_HIJACK_ROOT_LOGGER = False
Gdy Celery porywa loggera to wiadomości wysyłane przez ten moduł zobaczymy w konsoli Celery (django-admin.py celeryd -l info). Gdy wyłączymy porywanie to zobaczymy je w Sentry.
Comment article