Developers tend to ignore that users can be more creative than them. Use their debugging skills for your own benefit: post-mortem debugging is one of the most important features your web framework can provide. This talk will cover some of the simplest practices and available tools for debugging on production environments and to immediately improve quality of your web applications.
Citation preview
1. POST-MORTEM DEBUGGING AND WEB DEVELOPMENT Alessandro Molina
@__amol__ [email protected]
2. Who am I CTO @ Axant.it, mostly Python company (with some
iOS and Android) TurboGears2 dev team member Contributions to web
world python libraries MING MongoDB ODM ToscaWidgets2
Formencode
3. Why Debugging is a core part of the development process. You
can try to prevent issues as much as possible, but users will find
new ones. Gathering informations to replicate issues is required to
fix them
4. Debugging
5. At least know you have an issue. Debugging is the process of
finding and reducing the number of bugs Users are already doing
half of the work. When users find a bug for you, make sure to be
aware that they found it Log it or it will be forgotten
6. Log what you really need Log to replicate Then you are able
to write tests that actually verify the issue has been solved. You
probably want to log: WSGI Environ Traceback Last N stack frames
local variables Request Headers & Body (when size permits)
7. Log in an useful way Log data in an easy to use way Log
request in a way its quick to replay it Log in a computer friendly
format for test units Request dump is good: netcat to replay it and
is already understood by computers. Organize your informations Use
a tool to group and avoid duplicates Know what got solved and what
didnt Log by email, so you dont have to check yourself
8. Log or...
9. But log in a separate thread or...
10. Crash Report Many middlewares and frameworks provide
exception reporting by email: pyramid_exclog (Pyramid) WebError
(Pylons) BackLash (TurboGears) Django & Flask, framework
provided Logging module has what you need: Logger.exception +
handlers.SMTPHandler
11. Ready-Made Email Reporting Looking for a stand-alone
solution? Backlash can be used by itself, not bound to TurboGears.
Only dependency is WebOb Supports both Python2 and Python3 from
backlash.trace_errors import EmailReporter email_reporter =
EmailReporter(smtp_server="localhost",
error_email="[email protected]", from_address="[email protected]") app =
backlash.TraceErrorsMiddleware(app, [email_reporter])
12. Try Sentry Gathers data and detects duplicates Provides
Reply Request button Mark exceptions as solved to keep track Can
log multiple events, not only exceptions from
backlash.trace_errors.sentry import SentryReporter sentry_reporter
= SentryReporter(sentry_dsn="http://public:[email protected]/1")
app = backlash.TraceErrorsMiddleware(app, [sentry_reporter])
13. Sentry
14. See whats happening now On development and test
environments receiving errors by email is not convenient In case of
freezes you dont get an exception that can be reported Some
problems need to be troubleshooted on the fly
15. Interactive Debugger Python provides built-in Post Mortem
debugging through pdb module try: return app(environ,
start_response) except: import pdb pdb.post_mortem() While its
ready to use and works great its not the most comfortable tool when
working on web development
16. Browser Debugger Many frameworks have browser debugger
Pyramid DebugBar Werkzeug DebuggedApplication TurboGears ErrorWare
BackLash provides a stand-alone version of the Werkzeug debugger.
import backlash app = backlash.DebuggedApplication(app)
17. Werkzeug Debugger
18. Browser Debugger Console Browser debuggers usually
implement a special URL with an interactive console that runs in
the context of the application. Use it to see whats happening right
now for threadId, stack in sys._current_frames().items() Try
/__console__ on Werkzeug or Backlash
19. Production Debugging In-browser debugger must be disabled
on production environments Unless you are PythonAnyware you want to
block people from running code on your servers. So we are back
again at the starting point How do I debug issues that dont provide
an exception traceback on production?
20. Attaching to running processes To inspect running
applications you can rely on tools like ispyd and pyrasite that are
able to attach to a running python process from ispyd.plugins.wsgi
import WSGIApplicationWrapper app =
WSGIApplicationWrapper(app)
21. ispyd (wsgi:18630) requests No active transactions.
(wsgi:18630) requests ==== 67 ==== thread_id = 140735076232384
start_time = Mon Apr 9 21:49:54 2012 duration = 0.013629 seconds
HTTP_HOST = 'localhost:5000' QUERY_STRING = '' File: "wsgi.py",
line 19, in hello time.sleep(0.05)
22. Pyrasite
23. Not only Debugging Debugging tools can also help in finding
and solving performance issues When a request is taking a lot of
time, just attach ipsyd and see what its happening There are
specific tools that can proactively notify you of slow
requests
24. Dogslow Dogslow is a Django tool created by Bitbucket guys
to monitor slow requests Notifies you by email, no need to check
Really small codebase, its easy to port it to other environments
Upcoming BackLash version will provide a port of dogslow for
frameworks apart Django
25. New Relic Full stack tracing Controllers SQLAlchemy queries
Background Tasks External Services Groups informations by
controller, not URL On-Demand profiling Turn On / Off controllers
profiling from remote
26. New Relic
27. Slow requests stack trace might not be enough
28. Profiling Full profiling has a big cost, so it is usually
constrained to development environment If you want to profile on
production, perform sampling, dont profile every request Use a Low
Overhead profiler like PLOP, not built-in profile module.