解析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，保存一些配置信息
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实现。