解析Erlang日誌組件lager的監督樹和模塊

                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，保存一些配置信息

一、{loglevel, {[2#00001111], []}}      %% 假定日誌級別爲error  

                 lager_util

一、config_to_levels_int

        若是日誌級別爲error，那麼最終函數會返回 [error, critical, alert, emergency, none]

二、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實現。