[ERLANG_QUESTION33] using recon to view Erlang running status from a Web page

0. Demand analysis one of the best selling points of Erlang is to provide a very powerful shell to view the various states of the node runtime, with various internal views, debugging and parsing at runtime, and hot-updating code. However, there are always some state viewing functions that you should use sparingly in a production environment. Like what:

1. Node call erlang:processes () in the process number above 10w to get all the process PID. Then calculate the length blabla ...; 2. Call Erlang:process_info (pid,messages) to view all messages when a process's mailbox is blocked by tens of thousands of message queues.

In order to avoid these dangerous operations in the shell, there is recon the project. It guarantees that security can be invoked in a production environment. Project address Github:recon, document visible: Fred and Erlang in Anger eat better. However, after experiencing the power of recon for a period of time, I suddenly felt that in order to check the status entering the same set of commands in the shell is a very dull thing., so you want a tool that can directly view the status using a Web page. and the table shows. Make analytic issues faster and easier to understand. Recon_web is a tool that can view the various states of ERALNG nodes through the web. The difference between IT and Observer:

Recon_web	Observer
Web page view, no need WX GUI	Requires Erlang to install WX GUI application
Guaranteed to be safely called in the production environment	If there is a lot of ETS or a certain number of processes will crash, not suitable for most of the node has been out of the situation when used

1. Project description Project address Github:recon_web.Demo Address: Demo (Tap it to open it ~ ~)
Frames used:

Cowboy 1.0.1	WebSocket for server communication
Recon	Used to view the node state
Jsx	For JSON conversion
Lager	Log records
Socket.io.client	WebSocket maintenance of web-side
Highcharts	Web-side drawing diagram

Get started is also very simple, make&&make shell and then open 127.0.0.1:8080 can see the effect, but also to try ~. Other commands are described in the readme. 2.recon_web implementation

Explanation: 2.1. Why divide into System_info and recon_info? System_info refers to those metrics that are essentially unchanged in node: 　　Because they do not change at all, they will only build simultaneous once on the connection. Recon_info is the memory that is obtained with Recon, Scheduler, Port of the situation, they will always change, so in each heartbeat will be updated once to client. 2.2. If a large number of (for example, 1000) connections come up to view.　　Each connected heartbeat will use recon to get new node information, will it cause the CPU to consume too much? This is the duty of Recon_server, which is a separate gen_server, with the node information and computation time calculated last time using recon: {reconinfo, lastupdatetime}. Every point that comes up is going to be recon_ Server Request Reconinfo, if now-lastupdatetime > Rule time will recalculate a copy of the reconinfo saved up. So a large number of connections at the same time request Reconinfo,recon_server will only be counted once.　　 2.3. Why not just use handler to synchronize call Recon_server to get recon_info and then back to the client?　　Now the implementation is: 2.3.1 handler synchronous call Session_gen_server;　　2.3.2 Session_gen_server again asynchronous info recon_server; 2.3.3 Recon_server again asynchronous info recon_info to Session_gen_server, 2.3.4 Session_gen_server get recon_info Post Async Info Handler have new news in my This, you come to fetch; 2.3.5 Handller know 3.4, then sync call session_gen_server get recon_info, and then encode to the client through WebSocket.　　  This way is more session_gen_server this intermediate buffer layer.　　The advantage is that you can buffer multiple messages to the client and send them to the client at once. Of course, there is no advantage in the news that there is only recon_info now. But given the extensibility (messages that don't need to be sent to the client in time), adding a buffer layer is obviously much better.    3. Description of various diagrams in Recon_web

1>Recon_web_status:get_recon_info (node_stats_list). [{process_summary,[{process_count,86}, {run_queue,0}, {Error_logger_queue_len,0}, {memory_total,20032952}, {Memory_procs,6067544}, {memory_atoms,330312}, {memory_bin,467040}, {memory_ets,465936}]}, {mem_summary,[{bytes_in,0}, {bytes_out,0}, {gc_count,2}, {gc_words_reclaimed,256}, {reductions,130454}, {scheduler_usage,[{1,0.9252873563218391},                                 {2,0.147239263803681},                                 {3,0.13218390804597702},                                 {4,0.14285714285714285}]}]}]

3.1. Draw the following table according to Error_logger_queue_len Process_count Run_queue:

3.2. Draw according to the above memory_total,memory_procs,memory_atoms,memory_bin,memory_ets:

3. 3. Draw according to Scheduler_usage:

3.4 is drawn according to Bytes_in,bytes_out:

2>Recon_web_status:get_recon_info (Proc_count). [{proc_count,[{memory,[{<< "Application_controller" >>,602096},                       {<< "0.26.0" >>,372368},                       {<< "Recon_server" >>,372328},                       {<< "Code_server" >>,284656},                       {<< "Kernel_sup" >>,197384},                       {<< "0.159.0" >>,88632},                       {<< "Erl_prim_loader" >>,88552},                       {<< "Error_logger" >>,75904},                       {<< "Init" >>,67896},                       {<< "0.45.0" >>,55064}]}, {bin_memory,[{<< "Kernel_sup" >>,396661},                           {<< "Erl_prim_loader" >>,27958},                           {<< "0.26.0" >>,7408},                           {<< "0.159.0" >>,5527},                           {<< "0.45.0" >>,1264},                           {<< "Application_controller" >>,947},                           {<< "User" >>,852},                           {<< "Recon_server" >>,454},                           {<< "Lager_event" >>,278},                           {<< "Cowboy_clock" >>,203}]}, {reductions,[{<< "Recon_server" >>,43125661},                           {<< "Erl_prim_loader" >>,1328265},                           {<< "0.159.0" >>,243664},                           {<< "Code_server" >>,196114},                           {<< "Application_controller" >>,56899},                           {<< "Timer_server" >>,53145},                           {<< "Kernel_sup" >>,48774},                           {<< "Cowboy_clock" >>,30740},                           {<< "File_server_2" >>,24547},                           {<< "Init" >>,17949}]}, {total_heap_size,[{<< "Application_controller" >>,75112},                                {<< "Recon_server" >>,46421},                                {<< "0.26.0" >>,46421},                                {<< "Code_server" >>,35462},                                {<< "Kernel_sup" >>,24503},                                {<< "0.159.0" >>,10958},                                {<< "Erl_prim_loader" >>,10957},                                {<< "Error_logger" >>,9358},                                {<< "Init" >>,8370},                                {<< "0.45.0" >>,6771}]}]}

3.5 According to the above memory, Bin_memory,reductions, Total_heap_size draw:

3> Recon_web_status:get_recon_info (port). [ {port_summary,[{<< "Efile" >>,5},                {<< "tcp_inet" >>,2},                { << "2/2" >>,1},                {<< "tty_sl-c-E" >>,1}]}

3.6. Draw according to Port_summary:

4> Recon_web_status:get_recon_info (inet_count). [ {inet_count,[{sent_oct,[]},              {recv_oct,[{<< "Port0.4012" >>,1205},{<< "Port0.3695" > >,0}]}, {              sent_cnt,[]},              {recv_cnt,[{<< Port0.4012 >>,72},{<< Port0.3695 ">>,0}]}"}]

3. 7. According to Sent_oct, Recv_oct, sent_cnt, recv_cnt draw:

5>Recon_web_status:get_recon_info (alloc_memory). [{used,20804344}, {allocated,32247216}, {unused,11269856}, {allocated_types,[{binary_alloc,2786160}, {driver_alloc,164720}, {eheap_alloc,6763376}, {ets_alloc,1475440}, {fix_alloc,426864}, {ll_alloc,19923784}, {sl_alloc,164720}, {std_alloc,934768}, {temp_alloc,655960}]}, {allocated_instances,[{0,9094640},                       {1,6305264},                       {2,1246704},                       {3,15664624},                       {4,984560}]}]

3.8 Draw According to Alloc_memory:

6> Recon_web_status:get_recon_info (cache_hit_rates). [ {cache_hit_rates,[{<< "Instance1" >>,[602,1113]},                   {<< "Instance3" >>,[ 148,213]},                   {<< "Instance0" >>, "OV"},                   {<< "Instance2" >>,[7,13 ]},                   {<< "Instance4" >>,[0,0]}]}]

3.9 is drawn according to Cache_hit_rates:

4. Reference documents

Cowboy Establish websocket:http://ninenines.eu/docs/en/cowboy/head/guide/ws_handlers/

highcharts:http://www.highcharts.com/

--------------------------------------------------------------------------------------------------------------- ------

Inside the beam scheduler

[ERLANG_QUESTION33] using recon to view Erlang running status from a Web page