日誌
沒錯，就是日誌。再多強調在你的應用里保留足量的日誌的重要性也不為過。你應當對重要的內容打日誌。如果你的日誌打的足夠好的話，單看日誌你就能發現問題所在。那樣可以節省你大量的時間。
如果一直以來你都在代碼里亂用 print 語句，馬上停下來。換用logging.debug。以後你還可以繼續復用，或是全部停用等等。
跟蹤
有時更好的辦法是看執行了哪些語句。你可以使用一些IDE的調試器的單步執行，但你需要明確知道你在找那些語句，否則整個過程會進行地非常緩慢。
標準庫裡面的trace模塊，可以列印運行時包含在其中的模塊里所有執行到的語句。(就像製作一份項目報告)
python -mtrace –trace script.py
這會產生大量輸出（執行到的每一行都會被列印出來，你可能想要用grep過濾那些你感興趣的模塊）.
比如：
python -mtrace –trace script.py | egrep '^(mod1.py|mod2.py)'
調試器
以下是如今應該人盡皆知的一個基礎介紹：
import pdb
pdb.set_trace() # 開啟pdb提示
或者
try:
（一段拋出異常的代碼）
except:
import pdb
pdb.pm() # 或者 pdb.post_mortem()
或者(輸入 c 開始執行腳本)
python -mpdb script.py
在輸入-計算-輸出循環(註：REPL，READ-EVAL-PRINT-LOOP的縮寫)環境下，可以有如下操作：
c or continue
q or quit
l or list, 顯示當前步幀的源碼
w or where,回溯調用過程
d or down, 後退一步幀（註：相當於回滾）
u or up, 前進一步幀
(回車), 重複上一條指令
其餘的幾乎全部指令（還有很少的其他一些命令除外）,在當前步幀上當作python代碼進行解析。
如果你覺得挑戰性還不夠的話，可以試下smiley，-它可以給你展示那些變量而且你能使用它來遠程追蹤程序。
更好的調試器
pdb的直接替代者：
ipdb(easy_install ipdb) – 類似ipython(有自動完成，顯示顏色等)
pudb(easy_install pudb) – 基於curses（類似圖形介面接口），特別適合瀏覽原始碼
遠程調試器
安裝方式:
sudo apt-get install winpdb
用下面的方式取代以前的pdb.set_trace()：
import rpdb2
rpdb2.start_embedded_debugger("secretpassword")
現在運行winpdb,文件-關聯
不喜歡Winpdb?也可以直接包裝PDB在TCP之上運行！
這樣做：
import loggging
class Rdb(pdb.Pdb):
"""
This will run pdb as a ephemeral telnet service. Once you connect no one
else can connect. On construction this object will block execution till a
client has connected.
Based on https://github.com/tamentis/rpdb I think ...
To use this::
Rdb(4444).set_trace()
Then run: telnet 127.0.0.1 4444
"""
def __init__(self, port=0):
self.old_stdout = sys.stdout
self.old_stdin = sys.stdin
self.listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.listen_socket.bind(('0.0.0.0', port))
if not port:
logging.critical("PDB remote session open on: %s", self.listen_socket.getsockname())
print >> sys.__stderr__, "PDB remote session open on:", self.listen_socket.getsockname()
sys.stderr.flush()
self.listen_socket.listen(1)
self.connected_socket, address = self.listen_socket.accept()
self.handle = self.connected_socket.makefile('rw')
pdb.Pdb.__init__(self, completekey='tab', stdin=self.handle, stdout=self.handle)
sys.stdout = sys.stdin = self.handle
def do_continue(self, arg):
sys.stdout = self.old_stdout
sys.stdin = self.old_stdin
self.handle.close()
self.connected_socket.close()
self.listen_socket.close()
self.set_continue()
return 1
do_c = do_cont = do_continue
def set_trace():
"""
Opens a remote PDB on first available port.
"""
rdb = Rdb()
rdb.set_trace()
只想要一個REPL環境？試試IPython如何？
如果你不需要一個完整齊全的調試器，那就只需要用一下的方式啟動一個IPython即可：
import IPython
IPython.embed()
標準linux工具
我常常驚訝於它們竟然遠未被充分利用。你能用這些工具解決很大範圍內的問題：從性能問題（太多的系統調用，內存分配等等）到死鎖，網絡問題，磁碟問題等等。
其中最有用的是最直接的strace，只需要運行 sudo strace -p 12345 或者 strace -f 指令(-f 即同時追蹤fork出來的子進程)，這就行了。輸出一般會非常大，所以你可能想要把它重定向到一個文件以便作更多的分析（只需要加上 &> 文件名）。
再就是ltrace,有點類似strace，不同的是，它輸出的是庫函數調用。參數大體相同。
還有lsof 用來指出你在ltrace/strace中看到的句柄數值的意義。比如：
lsof -p 12345
更好的跟蹤
使用簡單而可以做很多事情-人人都該裝上htop！
sudo apt-get install htop
sudo htop
現在找到那些你想要的進程，再輸入：
s - 代表系統調用過程(類似strace)
L - 代表庫調用過程(類似ltrace)
l - 代表lsof
監控
沒有好的持續的伺服器監控，但是如果你曾遇到一些很詭異的情況，諸如為什麼一切都運行的那麼慢，那些系統資源都幹什麼去了，。。。等這些問題，想弄明白卻又 無處下手之際，不必動用iotop,iftop,htop,iostat,vmstat這些工具，就用dstat吧！它可以做之前我們提過的大部分工作可 以做的事情，而且也許可以做的更好！
它會用一種緊湊的，代碼高亮的方式（不同於iostat,vmstat）向你持續展示數據，你還經常可以看到過去的數據（不同於iftop,iostop,htop）。
只需運行：
dstat --cpu --io --mem --net --load --fs --vm --disk-util --disk-tps --freespace --swap --top-io --top-bio-adv
很可能有一種更簡短的方式來寫上面這條命令，
這是一個相當複雜而又強大的工具，但是這裡我只提到了一些基本的內容（安裝以及基礎的命令）
sudo apt-get install gdb python-dbg
zcat /usr/share/doc/python2.7/gdbinit.gz > ~/.gdbinit
用python2.7-dbg 運行程序：
sudo gdb -p 12345
現在使用：
bt - 堆棧跟蹤（C 級別）
pystack - python 堆棧跟蹤,不幸的是你需要有~/.gdbinit 並且使用python-dbg
c - 繼續
發生段錯誤？用faulthandler ！
python 3.3版本以後新增的一個很棒的功能，可以向後移植到python2.x版本。只需要運行下面的語句，你就可以大抵知道什麼原因引起來段錯誤。
import faulthandler
faulthandler.enable()
內存泄露
嗯，這種情況下有很多的工具可以使用，其中有一些專門針對WSGI的程序比如Dozer，但是我最喜歡的當然是objgraph。使用簡單方便，讓人驚訝！
它沒有集成WSGI或者其他，所以你需要自己去發現運行代碼的方法，像下面這樣：
import objgraph
objs = objgraph.by_type("Request")[:15]
objgraph.show_backrefs(objs, max_depth=20, highlight=lambda v: v in objs,
filename="/tmp/graph.png")
Graph written to /tmp/objgraph-zbdM4z.dot (107 nodes)
Image generated as /tmp/graph.png
你會得到像這樣一張圖（注意：它非常大)。你也可以得到一張點輸出。
內存使用
有時你想少用些內存。更少的內存分配常常可以使程序執行的更快，更好，用戶希望內存合適好用)
有許多可用的工具，但在我看來最好用的是pytracemalloc。與其他工具相比，它開銷非常小（不需要依賴於嚴重影響速度的sys.settrace）而且輸出非常詳盡。但安裝起來比較痛苦，你需要重新編譯python，但有了apt，做起來也非常容易。
只需要運行這些命令然後去吃頓午餐或者干點別的：
apt-get source python2.7
cd python2.7-*
wget? https://github.com/wyplay/pytracemalloc/raw/master/python2.7_track_free_list.patch
patch -p1 < python2.7_track_free_list.patch
debuild -us -uc
cd ..
sudo dpkg -i python2.7-minimal_2.7*.deb python2.7-dev_*.deb
接著安裝pytracemalloc （注意如果你在一個virtualenv虛擬環境下操作，你需要在重新安裝python後再次重建 – 只需要運行 virtualenv myenv）
pip install pytracemalloc
現在像下面這樣在代碼里包裝你的應用程式
import tracemalloc, time
tracemalloc.enable()
top = tracemalloc.DisplayTop(
5000, # log the top 5000 locations
file=open('/tmp/memory-profile-%s' % time.time(), "w")
)
top.show_lineno = True
try:
# code that needs to be traced
finally:
top.display()
輸出會像這樣：
2013-05-31 18:05:07: Top 5000 allocations per file and line
#1: .../site-packages/billiard/_connection.py:198: size=1288 KiB, count=70 (+0),
average=18 KiB
#2: .../site-packages/billiard/_connection.py:199: size=1288 KiB, count=70 (+0),
average=18 KiB
#3: .../python2.7/importlib/__init__.py:37: size=459 KiB, count=5958 (+0),
average=78 B
#4: .../site-packages/amqp/transport.py:232: size=217 KiB, count=6960 (+0),
average=32 B
#5: .../site-packages/amqp/transport.py:231: size=206 KiB, count=8798 (+0),
average=24 B
#6: .../site-packages/amqp/serialization.py:210: size=199 KiB, count=822 (+0),
average=248 B
#7: .../lib/python2.7/socket.py:224: size=179 KiB, count=5947 (+0), average=30
B
#8: .../celery/utils/term.py:89: size=172 KiB, count=1953 (+0), average=90 B
#9: .../site-packages/kombu/connection.py:281: size=153 KiB, count=2400 (+0),
average=65 B
#10: .../site-packages/amqp/serialization.py:462: size=147 KiB, count=4704
(+0), average=32 B
…
更多技巧請《轉發 + 關注》哦！