『壹』 python 多線程logger問題
因為logging是threadsafe的，但不是process-safe（應該沒有這個詞兒，只是為了便於理解）的。這段代碼就是多個進程共同操作一個日誌文件。這種情況下，logging的行為就很難說了。
我測試了一下，日誌中大概幾百行。而且，可以看到一些順序錯亂現象：
Fri, 08 Aug 2014 01:19:38 logging_in_multithread.py[line:40] theadWorking ERROR 2
FFri, 08 Aug 2014 01:19:36 logging_in_multithread.py[line:40] theadWorking ERROR 11（注意這里的FFri）
把代碼這樣改：
fornuminrange(processNum):
p=Process(target=processWorking,args=('2',))
processs.append(p)
p.start()
p.join()
還有其他方法，比如：為logging實現一個FileHandler，以使logging在multiple process的環境下也能正常工作。這是我從網上了解到的做法，自己還沒實踐過。
Python Manual中logging Cookbook中有這么一段話：
Logging to a single file from multiple processes
Although logging is thread-safe, and logging to a single file from multiple threads in a single process is supported, logging to a single file from multiple processes is not supported, because there is no standard way to serialize access to a single file across multiple processes in Python. If you need to log to a single file from multiple processes, one way of doing this is to have all the processes log to a SocketHandler, and have a separate process which implements a socket server which reads from the socket and logs to file. (If you prefer, you can dedicate one thread in one of the existing processes to perform this function.)
這段話中也提出了另外一種解決方案。
『貳』 如何理解Python裝飾器
裝飾器本質上是一個Python函數，它可以讓其他函數在不需要做任何代碼變動的前提下增加額外功能，裝飾器的返回值也是一個函數對象。它經常用於有切面需求的場景，比如：插入日誌、性能測試、事務處理、緩存、許可權校驗等場景。裝飾器是解決這類問題的絕佳設計，有了裝飾器，我們就可以抽離出大量與函數功能本身無關的雷同代碼並繼續重用。概括的講，裝飾器的作用就是為已經存在的對象添加額外的功能。
先來看一個簡單例子：
def foo():
print('i am foo')
現在有一個新的需求，希望可以記錄下函數的執行日誌，於是在代碼中添加日誌代碼：
def foo():
print('i am foo')
logging.info("foo is running")
bar()、bar2()也有類似的需求，怎麼做？再寫一個logging在bar函數里？這樣就造成大量雷同的代碼，為了減少重復寫代碼，我們可以這樣做，重新定義一個函數：專門處理日誌 ，日誌處理完之後再執行真正的業務代碼
def use_logging(func):
logging.warn("%s is running" % func.__name__)
func()
def bar():
print('i am bar')
use_logging(bar)
邏輯上不難理解，
但是這樣的話，我們每次都要將一個函數作為參數傳遞給use_logging函數。而且這種方式已經破壞了原有的代碼邏輯結構，之前執行業務邏輯時，執行運行bar()，但是現在不得不改成use_logging(bar)。那麼有沒有更好的方式的呢？當然有，答案就是裝飾器。
簡單裝飾器
def use_logging(func):
def wrapper(*args, **kwargs):
logging.warn("%s is running" % func.__name__)
return func(*args, **kwargs)
return wrapper
def bar():
print('i am bar')
bar = use_logging(bar)
bar()
函數use_logging就是裝飾器，它把執行真正業務方法的func包裹在函數裡面，看起來像bar被use_logging裝飾了。在這個例子中，函數進入和退出時
，被稱為一個橫切面(Aspect)，這種編程方式被稱為面向切面的編程(Aspect-Oriented Programming)。
@符號是裝飾器的語法糖，在定義函數的時候使用，避免再一次賦值操作
def use_logging(func):
def wrapper(*args, **kwargs):
logging.warn("%s is running" % func.__name__)
return func(*args)
return wrapper
@use_logging
def foo():
print("i am foo")
@use_logging
def bar():
print("i am bar")
bar()
如上所示，這樣我們就可以省去bar =
use_logging(bar)這一句了，直接調用bar()即可得到想要的結果。如果我們有其他的類似函數，我們可以繼續調用裝飾器來修飾函數，而不用重復修改函數或者增加新的封裝。這樣，我們就提高了程序的可重復利用性，並增加了程序的可讀性。
裝飾器在Python使用如此方便都要歸因於Python的函數能像普通的對象一樣能作為參數傳遞給其他函數，可以被賦值給其他變數，可以作為返回值，可以被定義在另外一個函數內。
帶參數的裝飾器
裝飾器還有更大的靈活性，例如帶參數的裝飾器：在上面的裝飾器調用中，比如@use_logging，該裝飾器唯一的參數就是執行業務的函數。裝飾器的語法允許我們在調用時，提供其它參數，比如@decorator(a)。這樣，就為裝飾器的編寫和使用提供了更大的靈活性。
def use_logging(level):
def decorator(func):
def wrapper(*args, **kwargs):
if level == "warn":
logging.warn("%s is running" % func.__name__)
return func(*args)
return wrapper
return decorator
@use_logging(level="warn")
def foo(name='foo'):
print("i am %s" % name)
foo()
上面的use_logging是允許帶參數的裝飾器。它實際上是對原有裝飾器的一個函數封裝，並返回一個裝飾器。我們可以將它理解為一個含有參數的閉包。當我
們使用@use_logging(level="warn")調用的時候，Python能夠發現這一層的封裝，並把參數傳遞到裝飾器的環境中。
類裝飾器
再來看看類裝飾器，相比函數裝飾器，類裝飾器具有靈活度大、高內聚、封裝性等優點。使用類裝飾器還可以依靠類內部的\_\_call\_\_方法，當使用 @ 形式將裝飾器附加到函數上時，就會調用此方法。
class Foo(object):
def __init__(self, func):
self._func = func
def __call__(self):
print ('class decorator runing')
self._func()
print ('class decorator ending')
@Foo
def bar():
print ('bar')
bar()
functools.wraps
使用裝飾器極大地復用了代碼，但是他有一個缺點就是原函數的元信息不見了，比如函數的docstring、__name__、參數列表，先看例子：
裝飾器
def logged(func):
def with_logging(*args, **kwargs):
print func.__name__ + " was called"
return func(*args, **kwargs)
return with_logging
函數
@logged
def f(x):
"""does some math"""
return x + x * x
該函數完成等價於：
def f(x):
"""does some math"""
return x + x * x
f = logged(f)
不難發現，函數f被with_logging取代了，當然它的docstring，__name__就是變成了with_logging函數的信息了。
print f.__name__ # prints 'with_logging'
print f.__doc__ # prints None
這個問題就比較嚴重的，好在我們有functools.wraps，wraps本身也是一個裝飾器，它能把原函數的元信息拷貝到裝飾器函數中，這使得裝飾器函數也有和原函數一樣的元信息了。
from functools import wraps
def logged(func):
@wraps(func)
def with_logging(*args, **kwargs):
print func.__name__ + " was called"
return func(*args, **kwargs)
return with_logging
@logged
def f(x):
"""does some math"""
return x + x * x
print f.__name__ # prints 'f'
print f.__doc__ # prints 'does some math'
內置裝飾器
@staticmathod、@classmethod、@property
裝飾器的順序
@a
@b
@c
def f ():
等效於
f = a(b(c(f)))
『叄』 Python日誌—Python日誌模塊logging介紹
從事與軟體相關工作的人，應該都聽過「日誌」一詞。
日誌就是跟蹤軟體運行時事件的方法，為了能夠在程序運行過程中記錄錯誤。
通過日誌記錄程序的運行，方便我們查詢信息，以便追蹤問題、進行維護和調試、還是數據分析。
並且各編程語言都形成了各自的日誌體系和相應的框架。
日誌的作用總結：
首先我們要樹立一個觀點，那就是「不是為了記錄日誌而記錄日誌，日誌也不是隨意記的」。要實現能夠只通過日誌文件還原整個程序執行的過程，達到能透明地看到程序里執行情況，每個線程每個過程到底執行結果的目的。日誌就像飛機的黑匣子一樣，應當能夠復原異常的整個現場乃至細節。
在項目中，日誌這個功能非常重要，我們要重視起來。
在Python中，使用logging模塊來進行日誌的處理。
logging是Python的內置模塊，主要用於將日誌信息進行格式化內容輸出，可將格式化內容輸出到文件，也可輸出到屏幕。
我們在開發過程中，常用print()函數來進行調試，但是在實際應用的部署時，我們要將日誌信息輸出到文件中，方便後續查找以及備份。
在我們使用日誌管理時，我們也可以將日誌格式化成Json對象轉存到ELK中方便圖形化查看及管理。
logging模塊將日誌系統從高向低依次定義了四個類，分別是logger（日誌器）、handler（處理器）、filter(過濾器)和formatter(格式器)。其中由日誌器生成的實例將接管原本日誌記錄函數logging.log的功能。
說明：
我們先來思考下下面的兩個問題：
在軟體開發階段或部署開發環境時，為了盡可能詳細的查看應用程序的運行狀態來保證上線後的穩定性，我們可能需要把該應用程序所有的運行日誌全部記錄下來進行分析，這是非常耗費機器性能的。
當應用程序正式發布或在生產環境部署應用程序時，我們通常只需要記錄應用程序的異常信息、錯誤信息等，這樣既可以減小伺服器的I/O壓力，也可以避免我們在排查故障時被淹沒在日誌的海洋里。
那麼怎樣才能在不改動應用程序代碼的情況下，根據事件的重要性或者稱之為等級，實現在不同的環境中，記錄不同詳細程度的日誌呢？
這就是日誌等級的作用了，我們通過配置文件指定我們需要的日誌等級就可以了。
說明：
總結：
開發應用程序時或部署開發環境時，可以使用DEBUG或INFO級別的日誌獲取盡可能詳細的日誌信息，可以方便進行開發或部署調試。 應用上線或部署生產環境時，應用使用WARNING或ERROR或CRITICAL級別的日誌，來降低機器的I/O壓力和提高獲取錯誤日誌信息的效率。 日誌級別的指定通常都是在應用程序的配置文件中進行指定的。 不同的應用程序所定義的日誌等級會有所差別，根據實際需求來決定。