>>>

lager_app
應用行為模式實現
Handlers =[{ lager_console_backend, info}, { lager_file_backend, [ {"log/error.log", error, 10485760, "", 5}, {"log/console.log", info, 10485760, "", 5} ]}];
函式 expand_handlers，最終要返回{Module, Config}列表。
如果是lager_console_backend，最終會返回，{lager_console_backend, info}
如果是lager_file_backend，最終會返回 [ {{lager_file_backend, "log/error.log"},{"log/error.log", error, 10485760, "", 5}}, {{lager_file_backend, "log/console.log"},{"log/console.log", info, 10485760, "", 5} }]


上面列表中的每個，都將呼叫：supervisor:start_child(lager_handler_watcher_sup, [lager_event, Module, Config])，這會導致生成一個lager_handler_watche程序，並且註冊Module事件處理器。


lager_sup
根監督樹
lager_handler_watcher
是gen_server的實現，通過add_sup_handler建立和事件處理器的連線；當前程序(gen_server程序)如果終止，事件處理器就會被刪除；如果事件處理器被刪除，事件管理器會發送訊息給當前程序。
gen_event:add_sup_handler(Event, Module, Config)
如果Module是這種模式{lager_file_backend, "log/error.log"}，後面的ID="log/error.log"，就是為了區分事件處理器是同一模組的情況。
lager_config
內部引用一個ETS表，名字是lager_config，儲存一些配置資訊
1、{loglevel, {[2#00001111], []}} %% 假定日誌級別為error

lager_util
1、config_to_levels_int 如果日誌級別為error，那麼最終函式會返回 [error, critical, alert, emergency, none]
2、config_to_mask(Conf) 根據巨集定義，DEBUG 128，INFO 64，NOTICE 32，WARNING 16，ERROR 8， CRITICAL 4，ALERT 2，EMERGENCY 1，LOG_NONE 0 最終這個函式返回掩碼 2#0000 1111

lager_crash_log
lager crash log記錄器。以原生格式，寫error_logger錯誤訊息到外部檔案中。crash log的配置在lager的元資料檔案 lager.app 中。
lager_console_backend
控制檯後端，gen_event實現。
lager_file_backend
檔案後端，也是gen_event實現。

轉載於:https://my.oschina.net/astute/blog/115579