observer_cli基础使用扩展指南

observer_cli是一个针对erlang虚拟机&＃xff0c;基于recon实现的模仿werl的observer功能的工具。因为生产环境一般都是linux系统&＃xff0c;而observer是不支持linux系统&＃xff0c;有了observer_cli就可以在linux环境下更直观的观察环境&＃xff0c;及早发现问题。以下是作者自己介绍&＃xff1a;

Visualize Erlang/Elixir Nodes On The Command Line base on recon.
Provide a high-performance tool usable both in development and production settings.
Focus on important and detailed information about real-time running system.
Keep minimal consumption.

本文只会简单的介绍基础用法&＃xff0c;着重点在如果编写一个自己的扩展插件&＃xff0c;安装和使用部分参看作者写的内容更详尽

Git库地址

observer_cli支持rebar构建&＃xff0c;如果你的项目支持rebar&＃xff0c;只需要将observer加入到你的deps目录中

{deps, [{observer_cli, ".*",{git, https://github.com/zhongwencool/observer_cli.git, {branch, "master"}}}
]}.


作者用的rebar3&＃xff0c;好像不需要填写项目地址这些&＃xff1f;
如果用的rebar而不是rebar3&＃xff0c;而且你的项目之前没有使用recon&＃xff0c;那么还需要修改下项目本身的rebar.config

{deps, [{recon, ".*", {git, https://github.com/ferd/recon.git, {branch, "master"}}}
]}.


如果使用了recon那么只需要保证get-deps的时候recon在observer_cli check前get到即可

除了rebar构建&＃xff0c;也支持erlang.mk的构建
另外Elixir也可以使用
这两种构建方式直接参照项目的ReadMe即可

使用

observer_cli:start().


来启动本地的observer_cli程序&＃xff0c;可以填入一个时间作为刷新间隔&＃xff0c;单位为毫秒&＃xff0c;默认为1000

observer_cli不仅可以查看本地节点&＃xff0c;也可以查看远程节点

observer_cli:start(&＃39;test&＃64;127.0.0.1&＃39;)
observer_cli:start(&＃39;test&＃64;127.0.0.1&＃39;, COOKIE).
observer_cli:start(&＃39;test&＃64;127.0.0.1&＃39;, [{COOKIE,COOKIE},{interval, 1000}]).


以上三种方式都可以启动&＃xff0c;如果没有指定COOKIE的时候就需要自己保证当前node和目标node的COOKIE一致&＃xff0c;当然远程调用的时候还是可以指定刷新间隔

本地节点和远程节点都必须将observer_cli的库加进来&＃xff0c;自定义插件&＃xff08;后面会介绍&＃xff09;部分的环境变量设置部分必须在查看的节点上确保&＃xff0c;而查看的目标节点必须能确实能完成自定义插件配置的功能&＃xff0c;目标节点自定义插件的环境变量的设置不是必须的

observer_cli提供的功能和observer非常像&＃xff0c;而且依靠recon还完成了更细致的内存分配数据&＃xff0c;例如内存的利用率等
标题依次为

• 首页&＃xff1a;提供概览信息&＃xff0c;内存分配&＃xff0c;进程数量&＃xff0c;虚拟机基础配置&＃xff0c;cpu利用率&＃xff0c;还有模仿etop的进程列表&＃xff0c;可以使用关键字完成排序
• 网络&＃xff1a;提供当前虚拟机已经打开的端口综述&＃xff0c;会列出当前已经打开的端口&＃xff0c;同样可以使用关键字完成排序&＃xff0c;这部分内容大多依赖recon完成
• 系统&＃xff1a;提供当前系统的概览&＃xff0c;这里可以看到当前虚拟机内存分配的详细情况&＃xff0c;R18&＃xff08;需要考证&＃xff09;以后的observer也支持了具体的内存分配查看
• ETS&＃xff1a;提供ETS表的查看&＃xff0c;和observer功能类似&＃xff0c;不过不能直接查看内容&＃xff0c;也没必要。
• Mnesia&＃xff1a;Mnesia数据表的查看
• App&＃xff1a;查看当前虚拟机已经启动的application&＃xff0c;不过不能像observer那种直接以结构树的形式展示&＃xff0c;毕竟是命令行下&＃xff0c;如果熟悉架构&＃xff0c;这种平铺列表的内容已经可以满足解决问题的目的
• Doc&＃xff1a;帮助文档&＃xff0c;提供基础命令的说明
• Plugin&＃xff1a;最新版本新增的支持自定义插件界面

关于内存和网络端口详细数据介绍可以查看recon&＃xff0c;当然observer_cli也贴心的做了介绍observer_cli文档
最新版本的界面和上图有一丢丢的差距&＃xff0c;最新的版本加入了自定义插件部分

主界面上展示的进程可以进入二级菜单针对单个进行进行详细的查看

在Home页面输入当前进程的编号&＃xff08;最左边的数字&＃xff09;即可&＃xff0c;进程较多时可以使用pu/pd进程翻页&＃xff0c;刷新较快时使用p暂停页面操作

这里以Process界面举例&＃xff0c;加入一个dump当前字典内容的命令&＃xff0c;并在界面打印出dump文件所在目录&＃xff0c;通过这个扩展也可以理解observer_cli实现的一些基础逻辑

Process界面主要由observer_cli_process模块进行管理&＃xff0c;先看一下observer_cli_process模块的内容

start(Pid, Opts) ->#view_opts{process &＃61; #process{interval &＃61; RefreshMs}} &＃61; Opts,RenderPid &＃61; spawn_link(fun() ->?output(?CLEAR),render_worker(info, RefreshMs, Pid, ?INIT_TIME_REF, ?INIT_QUEUE, ?INIT_QUEUE)end),manager(RenderPid, Opts).manager(RenderPid, #view_opts{process &＃61; ProcOpts} &＃61; Opts) ->case parse_cmd(Opts, RenderPid) ofquit ->erlang:send(RenderPid, quit);{new_interval, NewInterval} ->erlang:send(RenderPid, {new_interval, NewInterval}),manager(RenderPid,Opts#view_opts{process &＃61; ProcOpts#process{interval &＃61; NewInterval}});ViewAction ->erlang:send(RenderPid, ViewAction),manager(RenderPid, Opts)end.render_worker(state, Interval, Pid, TimeRef, RedQ, MemQ) ->case render_state(Pid, Interval) ofok ->next_draw_view(state, TimeRef, Interval, Pid, RedQ, MemQ);error ->next_draw_view_2(state, TimeRef, Interval, Pid, RedQ, MemQ)end.


observer_cli_process本身是我们在选中了查看某一进程详细信息的时候触发并开始走创建流程&＃xff0c;除了自己本身外会额外spawn一个进程用来管理控制台的显示
进程自己本身负责从命令行中读取命令解读后抓发给显示进程&＃xff0c;同是还维护定时刷新逻辑和退出逻辑
负责绘制的进程根据当前绘制的选中的状态&＃xff0c;会get数据然后输入到界面并进入下次循环&＃xff0c;逻辑并不复杂

next_draw_view(Status, TimeRef, Interval, Pid, NewRedQ, NewMemQ) ->NewTimeRef &＃61; observer_cli_lib:next_redraw(TimeRef, Interval),next_draw_view_2(Status, NewTimeRef, Interval, Pid, NewRedQ, NewMemQ).next_draw_view_2(Status, TimeRef, Interval, Pid, NewRedQ, NewMemQ) ->receivequit ->quit;{new_interval, NewInterval} ->?output(?CLEAR),render_worker(Status, NewInterval, Pid, TimeRef, NewRedQ, NewMemQ);info_view ->?output(?CLEAR),render_worker(info, Interval, Pid, TimeRef, NewRedQ, NewMemQ);message_view ->?output(?CLEAR),render_worker(message, Interval, Pid, TimeRef, NewRedQ, NewMemQ);dict_view ->?output(?CLEAR),render_worker(dict, Interval, Pid, TimeRef, NewRedQ, NewMemQ);stack_view ->?output(?CLEAR),render_worker(stack, Interval, Pid, TimeRef, NewRedQ, NewMemQ);state_view ->?output(?CLEAR),render_worker(state, Interval, Pid, TimeRef, NewRedQ, NewMemQ);_Msg ->render_worker(Status, Interval, Pid, TimeRef, NewRedQ, NewMemQ)end.


next_draw_view和next_draw_view2的区别只有next_draw_view会额外根据当前的界面刷新时间给自己发送一个定时刷新消息而已&＃xff0c;所以state的处理中&＃xff0c;如果get失败了就直接进入next_draw_view2没必要再次循环刷新了

observer_cli_lib:next_redraw生成的消息最后会有_Msg分支catch住根据当前状态&＃xff0c;完成当前界面的刷新
new_interval则是给全局的设置刷新间隔的API的handle&＃xff0c;每个模块都会带
其他分支则就是具体的功能模块

现在我们开始给Process模块加入dump命令

1. 首先我们给尾行加入我们新加的命令描述

render_last_line() ->observer_cli_lib:render_last_line("q(quit) dump(dump dict into file dict.txt)").


2. 修改parse_cmd命令加入我们新加的dump命令

parse_cmd(ViewOpts, Pid) ->case observer_cli_lib:to_list(io:get_line("")) of"q\n" ->quit;"Q\n" ->quit;"P\n" ->info_view;"M\n" ->message_view;"D\n" ->dict_view;"C\n" ->stack_view;"S\n" ->state_view;"H\n" ->erlang:exit(Pid, stop),observer_cli:start(ViewOpts);"dump\n" ->{dump_dict,false}; //新加部分Number ->observer_cli_lib:parse_integer(Number)end.


这里我们在进入刷新逻辑的时候额外加了一个bool变量&＃xff0c;因为dump是一个一次性的命令&＃xff0c;不需要刷新&＃xff0c;但是我们又要不能破坏刷新逻辑的同时&＃xff0c;确保dump只执行一次&＃xff0c;且能保持显示dump文件所在的目录

3. 增加dump命令的handle逻辑

next_draw_view_2(Status, TimeRef, Interval, Pid, NewRedQ, NewMemQ) ->receivequit ->quit;{new_interval, NewInterval} ->?output(?CLEAR),render_worker(Status, NewInterval, Pid, TimeRef, NewRedQ, NewMemQ);info_view ->?output(?CLEAR),render_worker(info, Interval, Pid, TimeRef, NewRedQ, NewMemQ);message_view ->?output(?CLEAR),render_worker(message, Interval, Pid, TimeRef, NewRedQ, NewMemQ);dict_view ->?output(?CLEAR),render_worker(dict, Interval, Pid, TimeRef, NewRedQ, NewMemQ);stack_view ->?output(?CLEAR),render_worker(stack, Interval, Pid, TimeRef, NewRedQ, NewMemQ);state_view ->?output(?CLEAR),render_worker(state, Interval, Pid, TimeRef, NewRedQ, NewMemQ);{dump_dict, Done} ->?output(?CLEAR), //新加部分render_worker({dump_dict, Done}, Interval, Pid, TimeRef, NewRedQ, NewMemQ);_Msg ->render_worker(Status, Interval, Pid, TimeRef, NewRedQ, NewMemQ)end.render_worker({dump_dict, Done}, Interval, Pid, TimeRef, RedQ, MemQ) ->Menu &＃61; render_menu(dict, Interval),Line1 &＃61; "file:write_file(FileName,io_lib:format(p,[List]),[write]), ~n",LastLine &＃61; render_last_line(),{Done2, Line2} &＃61; case Done oftrue ->{ok, Pwd} &＃61; file:get_cwd(),{Done, io_lib:format("Dict write in ~s/~s ~n", [Pwd, "dict.txt"])};_ ->case dump_dict(Pid) ofundefined ->{undefined, "dict empty! ~n"};FileName ->{ok, Pwd} &＃61; file:get_cwd(),{true, io_lib:format("Dict write in ~s/~s ~n", [Pwd, FileName])}endend,?output([?CURSOR_TOP, Menu, Line1, Line2, LastLine]),next_draw_view({dump_dict, Done2}, TimeRef, Interval, Pid, RedQ, MemQ);dump_dict(Pid) ->case erlang:process_info(Pid, dictionary) of{dictionary, List} ->FileName &＃61; "dict.txt",file:write_file(FileName, io_lib:format("~p", [List]), [write]),FileName;undefined ->undefinedend.


render_worker 的内容并不算复杂&＃xff0c;根据dump_dict命令带入的参数决定是否进行dump操作&＃xff0c;如果是由dump_dict命令来完成指定Pid的dump操作&＃xff0c;如果dump成功就返回true状态&＃xff0c;如果已经是true就保持原状态
dump_dict写的很粗糙&＃xff0c;如果要进生产环境记得包装
render_worker的结束我们直接进入下次dump_dict的循环&＃xff0c;确保界面上显示的dump文件所在目录不会被定时刷新逻辑刷新成其他
现在启动来看下命令执行结果
主界面

执行后

执行结果

ok&＃xff0c;看来成功了&＃xff0c;至此我们就完成了对Process的一个简单的扩展
如果要做刷新逻辑那就更简单了只需要编写自己的render函数&＃xff0c;确保每次刷新时get到最新的数据并返回即可

这些新的扩展功能必须要保证要查看的目标节点拥有这些逻辑&＃xff0c;如果是用的远程节点查看&＃xff0c;远程节点只需要有基础版本的observer_cli库即可

这里先摘抄一段作者的使用介绍&＃xff0c;原文已经介绍的很详尽了

1. Configure observer_cli&＃xff0c;tell observer_cli how to find your plugin.
2. Write observer_cli_plugin behaviour.

主要内容在需要完成的3个回调&＃xff0c;回调格式如下&＃xff1a;

-callback kv_label() -> [Rows] whenRows :: #{key &＃61;> string(), key_width &＃61;> pos_integer(),value &＃61;> string()|integer()|{byte, pos_integer()}, value_width &＃61;> pos_integer()}.


要注意的原文这里还是用的name&＃xff0c;作者的文档还没更新&＃xff0c;使用key即可
这里定义的是类似System界面的那种键值对结构&＃xff0c;如果不想使用可以直接返回一个空字符串&＃xff0c;一般返回一个界面的总览

-callback sheet_header() -> [SheetHeader] whenSheetHeader :: #{title &＃61;> string(), width &＃61;> pos_integer(), shortcut &＃61;> string()}.


这部分返回表头其中Shortcut指的是如果表格需要排序&＃xff0c;指定快捷键后就可以根据当前列排序&＃xff0c;还需要注意的是&＃xff0c;关键词也会加入到title显示中&＃xff0c;所有width设置的时候也需要考虑进去&＃xff0c;当然还要考虑下面的数据的具体长度

-callback sheet_body() -> [SheetBody] whenSheetBody :: list().


表内容&＃xff0c;主要注意和表头一一对应即可&＃xff0c;value支持绝大多数的erlang数据类型&＃xff0c;
如果要显示内存大小之类的字节大小&＃xff0c;可以使用observer_cli_lib:to_byte函数&＃xff0c;不过用了后排序就不准了。。。
要修复也可以实现&＃xff0c;新包装一个数据结构&＃xff0c;然后在observer_cli_plugin:render_sheet_body函数中将

DataSet &＃61; lists:map(fun(I) ->{0, lists:nth(SortRow, I), I} end,Module:sheet_body()),


在这里对I进行检查和特殊处理&＃xff0c;如果是需要转变的数据直接转变

is_memory_type({memory,_}) -> true;
is_memory_type(_) -> false.render_sheet_body(Module, CurPage, Rows, SortRow, Widths) ->DataSet &＃61; lists:map(fun(I) ->Value &＃61; lists:nth(SortRow, I),I1 &＃61; lists:map(fun(V) ->case is_memory_type(V) oftrue ->observer_cli_lib:to_byte(element(2, V));_ ->Vendend, I),case is_memory_type(Value) oftrue ->{0, element(2, Value), I1};_ ->{0, Value, I1}endend,Module:sheet_body()),SortData &＃61; observer_cli_lib:sublist(DataSet, Rows, CurPage),[beginList &＃61; mix_value_width(Item, Widths, []),?render(List)end || {_, _, Item} <- SortData].


这里可以细致点&＃xff0c;包装一个observer_cli_memory结构然后include进来&＃xff0c;然后配合宏使用

也就是目标节点主要提供这三个回调函数&＃xff0c;然后配置到observer_cli 的application env
下就可以在插件界面使用&＃xff0c;环境变量配置格式如下

%% module - Specific module implements plugin behavior. It&＃39;s mandatory.
%% title - Menu title. It&＃39;s mandatory.
%% shortcut - Switch plugin by shortcut. It&＃39;s mandatory.
%% interval - Refresh interval ms. It&＃39;s optional. default is 1500ms.
%% sort_column - Sort the sheet by this index. It&＃39;s optional default is 2.{plugins,[#{module &＃61;> observer_cli_plug_behaviour1, title &＃61;> "XPlug",interval &＃61;> 1500, shortcut &＃61;> "X", sort_column &＃61;> 3},#{module &＃61;> observer_cli_plug_behaviour2, title &＃61;> "YPlug",interval &＃61;> 1600, shortcut &＃61;> "Y", sort_column &＃61;> 3}]
}

一般来说我们不会直接修改deps目录的内容&＃xff0c;所以可以在你的项目启动的时候&＃xff0c;额外配置一个appenv文件&＃xff0c;针对observer_cli的application增加plugins变量即可&＃xff0c;最好不要直接修改deps下的app文件&＃xff0c;需要注意的是这个设置部分是调用发起的节点必须有&＃xff0c;也就是界面显示所在的节点&＃xff0c;也就是说如果用的远程节点查看&＃xff0c;则查看用的这个节点必须有这些环境变量才行&＃xff0c;而布标节点必提供配置中模块指定的回调

下面我们加入一个查看当前服务器玩家进程的自定义插件为例介绍这个功能
在项目内建立observer_cli_role模块&＃xff0c;名字可以随意指定

kv_label() ->[[#{key &＃61;> "online_role", key_width &＃61;> 20,value &＃61;> user_default:n(), value_width &＃61;> 10}]].sheet_header() ->[#{title &＃61;> "RoleID", width &＃61;> 15},#{title &＃61;> "RoleName", width &＃61;> 20},#{title &＃61;> "level", width &＃61;> 10, shortcut &＃61;> "Lv"},#{title &＃61;> "VipLv", width &＃61;> 10, shortcut &＃61;> "VLv"},#{title &＃61;> "FID", width &＃61;> 15},#{title &＃61;> "FamilyName", width &＃61;> 20},#{title &＃61;> "Pid", width &＃61;> 15},#{title &＃61;> "Memory", width &＃61;> 20, shortcut &＃61;> "Me"},#{title &＃61;> "Reductions", width &＃61;> 24, shortcut &＃61;> "Re"},#{title &＃61;> "MsgQL", width &＃61;> 10, shortcut &＃61;> "Mq"}].
sheet_body() ->[beginPid &＃61; user_default:rs_pid(RoleID),RolePublic &＃61; user_default:get_role_public(RoleID),[RoleID,maps:get(rolename, RolePublic),maps:get(rolelv, RolePublic),maps:get(viplv, RolePublic),maps:get(familyid, RolePublic),maps:get(familyname, RolePublic),Pid,{memory,(element(2, erlang:process_info(Pid, memory)))},element(2, erlang:process_info(Pid, reductions)),element(2, erlang:process_info(Pid, message_queue_len))]end || RoleID <- user_default:onlines()].


这里面用了一些user_default模块假设存在的功能。这些功能不是非要在user_default模块提供&＃xff0c;调用自己项目的内容即可&＃xff0c;注意内存那格&＃xff0c;使用了前面说的{memory, Memory}格式&＃xff0c;如果没有修改过排序显示部分最好直接显示数字本身&＃xff0c;否则会报错&＃xff0c;启动后切换到自定义插件下&＃xff0c;效果如图

设定了快捷键的列就可以使用快捷键进行排序&＃xff0c;修改后&＃xff0c;内存显示修改后的方式&＃xff0c;排序也不会有问题。

ok&＃xff0c;现在可以模仿写一个你自己的插件了&＃xff0c;如果自写插件部分有错误&＃xff0c;会在目标节点那边抛出异常&＃xff0c;会由项目本身的日志逻辑catch住方便调试。