Sie sind auf Seite 1von 3

Home > Webmachine

Webmachine Debugging
Having trouble with your Webmachine resource? Try debugging it with the Webmachine trace utility!

Basic Use
To get started, first change your resource's i i / function to return { r c , P t }instead of o . For example: nt1 tae ah k ii(ofg ntCni) > {tae "tp} Cni} % dbgigcd {rc, /m", ofg. % eugn oe %{k Cni} %o, ofg. % rglrcd % eua oe Rebuild and reload the module, then in your Webmachine application's shell, type: wtaersuc:d_ipthrl(wtae,"tp) mrc_eoreaddsac_ue"mrc" /m". Now issue the HTTP request that you're trying to debug. Once it has finished, point your browser at h t : / O R H S / m r c / tp/YU_OTwtae. You'll see one or more trace files available for inspection. Click on one of them to navigate to the trace inspection utility, which will look something like this:

The example above is a trace of a resource that responded to a GET of the root path (as you can see in the Detail Panel), and ran all the way to a 200 response code (as you can see in the Decision Graph). The graph starts small, so you can get a quick view of the path your resource took through it. You can zoom in and out of the Decision Graph by using the Zoom Controls. The path your resource took through the graph is highlighted with a dark grey line. Hovering your mouse over the outlined decision points along that line will pop up a tool tip with the name of the decision, and the names of the functions in your resource that were called at that point. Clicking on a decision will flip the Detail Panel to the Decision Tab, where information about that decision will be displayed. If your resource traversed the graph all the way to one of the standard, non-error return codes, the box for that return code will be outlined. If your resource instead returned a non-standard or error code, a red circle will be drawn next to the last decision point your resource reached. Clicking on either of these types of endpoints will flip the Detail Panel to the Response Tab, where information about the response will be displayed. The Detail Panel has three tabs: Request (labeled Q), Response (labeled R), and Decision (labeled D). Clicking each of these will show information about the request, response, or current decision, respectively.

The Request Tab shows details about what the client requested. The method and path are displayed at the top, headers below that, and body (if available) at the bottom.

The Response Tab shows details about how your resource responded. The response code is displayed at the top, headers below that, and body (if available) at the bottom.

The Decision Tab shows details about the currently selected decision. The decision's name is displayed in a dropdown at the top (changing this dropdown or clicking on a decision in the graph will change which decision is displayed). The list of the functions called in the resource's module is displayed in a dropdown below the decision. The arguments with which the function was called are displayed just below the function's name, and the return value of the function is displayed at the bottom of the panel. The Detail Panel can be resized by clicking and dragging the tabs or the dark grey border to the left or right. Clicking the border will toggle the panel's visibility.

Configuration Details
The Webmachine trace tool is divided into two parts: one produces the trace logs, while the other produces the visualization. Trace Log Production Configuration You may configure the path under which trace files are stored by specifying that path as the Path part of your resource module's i i / return value. Every time a request is made to that resource, a new trace file will be created in the specified directory. nt1 Warning: Trace files can be large. It is advised that you do not leave tracing enabled on a large-content-producing or high-hit-rate resource. The path may be either absolute: ii(ofg ntCni) > {tae "tptae",Cni} % aslt pt /m/rcs {rc, /m/rcs} ofg. % boue ah tptae Or relative to your application's root:

ii(ofg ntCni) > {tae "rcs} Cni} % "rcs drcoyi apiainsro {rc, tae", ofg. % tae" ietr n plcto' ot Trace Viewer Configuration The viewer is configured by its entry in the dispatch list. Two functions make modifying that entry easy: w t a e r s u c : d _ i p t h r l / and w t a e r s u c : e o e d s a c _ u e / . mrc_eoreaddsac_ue2 mrc_eorermv_ipthrls0 Call a d d s a c _ u e 2with the HTTP-exported path, and the path to the trace files. For example, to expose the viewer at d_ipthrl/ h t : / O R H S / e / m r c /and point it at the trace files in / m / r c s type in your application's erlang shell: tp/YU_OTdvwtae tptae, wtaersuc:d_ipthrl(dvwtae,"tptae". mrc_eoreaddsac_ue"e/mrc" /m/rcs) If you know that you always want the viewer enabled and configured in a specific way, you can also add a line like the following to your application's dispatch list: {"e" "mrc" '',wtaersuc,[taedr "tptae"] [dv, wtae, *] mrc_eore {rc_i, /m/rcs}} To disable all trace viewer resources at any point, just execute w t a e r s u c : e o e d s a c _ u e / in your mrc_eorermv_ipthrls0 application's erlang shell.

Trace Log Format


The trace file is fairly straightforward, if you want to read it with l s : es { e i i n X . indicates that a decision point was reached dcso, } { t e p , M d l , F n t o , A g } indicates that a call to M d l : u c i n A g )was made. atmt oue ucin rs. oueFnto(rs { e u t M d l , F n t o , R s l } indicates that the call to M d l : u c i n A g )returned Result . rsl, oue ucin eut. oueFnto(rs { o _ x o e , M d l , F n t o , A g } indicates that M d l : u c i n A g )would have been called, but it was nteprd oue ucin rs. oueFnto(rs not exported (or not defined) by the module

The format should be such that a f l : o s l / will give you a list of the lines as erlang terms. iecnut1

Special Handling for Funs and Pids


Funs and Pids don't roundtrip through file serialization very well (f l : o s l / will blow up on a fun or pid written to a file with iecnut1 i : o m t " p , [ u O P d ) To deal with this, the trace logger prints a recognizable tuple translation instead of the fun or pid. o f r a ( ~ " F n r i ] ). Fun Translation Funs you might see in Erlang source as fun i : o m t 2will appear in a trace log as: ofra/ {WTAEECPDFN,{ouei} 'MRC_SAE_U'[mdl,o, {aefra} nm,omt, {rt,} aiy2, {yeetra}} tp,xenl] Those that would be in Erlang source as f n ) - o end will appear in a trace log as: u( > k {WTAEECPDFN,{ouesmltaersuc} 'MRC_SAE_U'[mdl,aperc_eore, {ae't_tl2fn0', nm,-ohm/-u--} {rt,} aiy0, {yelcl] tp,oa}} Pid Translation Pids are simply logged in a marked tuple, after being run through e l n : i _ o l s / : ragpdt_it1 {WTAEECPDPD,<.40" 'MRC_SAE_I'"07.>}

Basho Technologies, Inc. 485 Massachusetts Avenue Suite 300 Cambridge, MA 02139 (617) 714-1700 This work is licensed under a Creative Commons Attribution 3.0 Unported License. Copyright 2012 Basho Technologies, Inc. All rights reserved.