解析Erlang日志组件lager的监督树和模块

为什么80%的码农都做不了架构师？>>>   

                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