（写在前面的话：对于erlang的开发者来说，observer_cli 不算是个新的项目，git@github.com:zhongwencool/observer_cli（感谢文哥开源），十分好用的，简单整理个文档）
1) 简介
observer_cli是一个针对erlangVM，基于recon和observer的实时监控系统指标的工具。因为生产环境一般都是linux系统，而observer是不支持linux系统(需要安装wx)，
有了observer_cli就可以在linux环境下更直观的观察环境，及早发现问题。
工具的好处：
线上可视化，数据的实时性，操作简洁，帮助发现和定位问题.
特点：
Visualize Erlang/Elixir Nodes On The Command Line base on recon. （基于recon在命令行上可视化Erlang/Elixir节点）
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. （尽量减少消耗）
2)安装
observer_cli支持rebar构建，如果项目用的是rebar，只需要将observer加入到对应项目的配置中.deps目录中
{deps, [
{observer_cli, ".*", {git,"git@github.com:zhongwencool/observer_cli.git","7f80ae49570612b3732094b76494c0fbb073aa2b"}}
]}.
若用rebar3也可以构件引入该依赖项，另外Elixir也可以使用, 构建方式直接参照项目的ReadMe.
3)基础用法
在./xxxx debug的shell下, 使用 observer_cli:start().
来启动本地的observer_cli程序，可以填入一个时间作为刷新间隔，单位为毫秒，默认为1000
>observer_cli不仅可以查看本地节点，也可以查看远程节点
>observer_cli:start('test@127.0.0.1').
>observer_cli:start('test@127.0.0.1',Cookie).
>observer_cli:start('test@127.0.0.1',[{cookie,Cookie}],{interval,1000}).
以上三种方式都可以启动，如果没有指定cookie的时候就需要自己保证当前node和目标node的cookie一致，当然远程调用的时候还是可以指定刷新间隔.
本地节点和远程节点都必须将observer_cli的库加进来，自定义插件部分的环境变量设置部分必须在查看的节点上确保，而查看的目标节点必须能确实能完成自定义插件配置的功能，
目标节点自定义插件的环境变量的设置不是必须的.
4)主界面介绍
observer_cli提供的功能和observer非常像，而且依靠recon还完成了更细致的内存分配数据，例如内存的利用率等
标题依次为
- 首页Home(H)：提供概览信息，内存分配，进程数量，虚拟机基础配置，cpu利用率，还有模仿etop的进程列表，可以使用关键字完成排序
- 网络Network(N)：提供当前虚拟机已经打开的端口综述，会列出当前已经打开的端口，同样可以使用关键字完成排序，这部分内容大多依赖recon完成
- 系统System(S)：提供当前系统的概览，这里可以看到当前虚拟机内存分配的详细情况。
- ETS(E)：提供ETS表的查看，和observer功能类似，不过不能直接查看内容。
- Mnesia(M)：Mnesia数据表的查看
- App(A)：查看当前虚拟机已经启动的application，不过不能像observer那种直接以结构树的形式展示，毕竟是命令行下，如果熟悉架构，这种平铺列表的内容已经可以满足解决问题的目的
- Doc(D)：帮助文档，提供基础命令的说明
- Plugin(P)：最新版本新增的支持自定义插件界面
关于内存和网络端口详细数据介绍可以查看recon，
observer_cli做了介绍observer_cli文档
主界面上展示的进程可以进入二级菜单针对单个进行进行详细的查看
在Home页面输入当前进程的编号（最左边的数字）即可，进程较多时可以使用F/B进程翻页，刷新较快时使用p暂停页面操作
5)自带插件功能扩展
需要自定义功能可开发自行扩展
6) erlang Shell下的recon操作举例:
比如：使用总的积累结果，查询哪个port对应的在吃带宽最多.
接下来，可以调用函数 recon:port_info(“#Port<XXXX>”)获取更详细的信息，找到该 socket 的拥有者以及下一步工作需要的信息
recon:port_info/1
元信息
id 端口的内部索引。除了用来区分端口外，没啥特殊用途。
name 端口的类型——比如像”tcp_inet”、”udp_inet”或者”efile”之类的名字
os_pid 如果端口不是 inet socket，而是代表一个外部的进程或者程序，那么这个值会包含和外部程序对应的 OS 进程的 pid
信号
connected 每个端口都会有一个控制进程来对其负责，connected 指的就是这个进程的pid。
links 端口可以和进程链接起来，方式和进程间的类似。links 包含的就是所链接进程的列表。
如果端口曾经的 owner 并不多，或者没有被手工和许多进程链接在一起，这个调用应该是安全的。
monitors 端口(代表外部程序)可以让外部程序监控 Erlang 进程。这个调用会显示这些进程。
IO
input 端口读入的字节数 output 写入端口的字节数
内存使用
memory 运行时系统为该端口分配的内存(单位为字节)。这个值会偏小，并没有包含
端口自己分配的空间
queue_size 端口程序有一个特殊的队列，称为驱动程序队列。这个调用会返回队列大小，单位为字节。
特定类型
Inet Ports 返回inet特定的数据，包括统计数据、socket(sockename)的本地地址和端口号以及使用的inet选项。
其他目前除了inet端口外，recon不支持其他类型的端口，会返回空列表。
再根据recon:info(Pid)查询具体的进程相关信息.
recon:info/1
元信息
dictionary 返回进程字典中的所有数据项。通常可安全使用，因为一般不应该把G字节的数据存放于此。
group_leader 进程的group_leader决定IO(文件，io:format的输出)的去向。
suspended 不管是因为 BIF 调用，还是因为 socket 或端口缓冲满，作为一种反压 机制的结果而被挂起，都是此值。仅当端口不忙时，进程才会再次变 成 runnable 的。
信号
links 会报告出进程所链接的所有其他进程以及端口(socket、文件描述符)列表。一般来说可安全调用，不过对于一些大的 supervisor 要小心使用，因为返回的列表中会有成千上万的项。
monitored_by 会返回所有监控当前进程(通过 erlang:monitor/2)的进程列表。 monitors 和 monitored_by 相反，返回所有被当前进程监控的进程列表。 trap_exit 如果该进程捕获 exit，就返回 true，否则返回 false。
位置
current_function 以 tuple 的形式({Mod, Fun, Arity})显示进程的当前运行函数。 current_location 显示进程在模块中的位置，显示格式为:{Mod, Fun, Arity, [{file,FileName},{line, Num}]}
current_stacktrace 上一个选项(current_location)的更详细版本，会以“current_location”列表的形式显示当前的堆栈跟踪信息。
initial_call 显示进程 spawn 时运行的函数，形式为:{Mod, Fun, Arity}。该信息可以用来识别进程创建时执行的函数，
不能识别当前运行的函数。
内存使用
binary 显示所有refc binary的引用及其大小。如果此类binary分配过多，那么调用起来就不安全。
garbage_collection 报告进程中有关垃圾回收的信息。这部分信息在官方文档中被声明为“subject to change”，应当以此为准。这部分内容往往会包括进 程已经执行的垃圾回收的次数，
完整清理(full‐sweep)垃圾回收的 选项，堆大小等等。
heap_size 典型的 Erlang 进程包含有一个“老”堆和一个“新”堆，并会经历分代型
registered_name 如果进程有名字的话，可以通过这个键值获取。 status 进程在调度器内部的分类。有如下几种值:
exiting 进程已经结束，但是还未被完全清除
waiting 进程在 receive ... end 中等待
running 运行中
runnable 准备就绪，但是尚未被调度，因为另一个进程正在运行中 garbage_collecting 垃圾(generational)的垃圾回收。这项内容会显示进程最新代的堆大小，通常也包 括堆栈大小。返回值的单位是 word。
memory 返回进程占用内存的大小，单位为字节，包括:调用栈、堆以及作为进程的一 部分由 VM 使用的内部结构。
message_queue_len 显示进程邮箱中等待的消息个数。
messages 返回进程邮箱中的所有消息。在生产环境中，这个调用是极度危险的，比如，
如果正在调试某个进程而导致它被锁住，那么其邮箱中会堆积上百万条消息。 一定要先调用 message_queue_len 以确保安全。
total_heap_size 和 heap_size 类似，不过也会包含所有其他部分的堆，包括老堆。返回 值的单位是 word
工作量
reductions
Erlang VM 基于 reduction 来进行调度，reduction 是一种规定的工作量单位， 用来保证调度实现的高度可移植性(基于时间的调度很难做到在所有 Erlang 运行的 OS 上都高效)。
进程的 reduction 值越高，表示其(在 CPU 和函数调 用意义上)所做的工作就越多。
如果寻找内存占用高的进程，可以把节点中的所有进程都罗列出来，并找到占用最高 的前 N 个。使用前面列出来的属性以及 recon:proc_count(Attribute, N)函数，可以得到需要的信息: recon:proc_count(memory,3).
不过，如果大部分进程都是短期的，尤其是生存期短到无法通过工具观察，或者需要一个移 动的观察窗口时(比如，现在有哪些进程在消耗内存或者运行代码)，就会出现问题。
对于这种情况，Recon 提供了 recon:proc_window(Attribute, Num, Milliseconds)函数.