htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin McCabe <cmcc...@alumni.cmu.edu>
Subject Re: Few general notes on using htrace, the cmd-line interface, and htraced
Date Tue, 20 Jan 2015 21:36:31 GMT
On Tue, Jan 20, 2015 at 6:32 AM, Stack <stack@duboce.net> wrote:

> I'll make issues Colin. Dumping here for now in case any one else has
> input.
>
> If I pass '--help' to htraced it does this:
>
> kalashnikov-17:go stack$ ./build/htraced --help
> 2015/01/20 06:26:39 LevelDB failed to open /tmp/htrace1/db: IO error: lock
> /tmp/htrace1/db/LOCK: Resource temporarily unavailable
> 2015/01/20 06:26:39 Error creating shard /tmp/htrace1/db: IO error: lock
> /tmp/htrace1/db/LOCK: Resource temporarily unavailable
> 2015/01/20 06:26:39 Error creating datastore: IO error: lock
> /tmp/htrace1/db/LOCK: Resource temporarily unavailable
>
> I want to see what options are available to me. I'd expect a message on
> how-to-config to be dumped out at this point with a few of the more
> important basic options showing.
>
>
Yeah, a usage message for htraced would be nice.


> The builds dir shouldn't be under src, right?  Should be under target or at
> same level as target?  i.e. no pollution of src tree by built product.
>
> This seems less important to me... the important thing is that we've
clearly separated the build directory from the source directory.  But we
can move stuff around (and probably should...).  Agree that it's a little
weird to have src/build, should probably have just target/ and src/ instead.

Colin


> St.Ack
>
>
>
>
>
> On Mon, Jan 19, 2015 at 10:46 PM, Colin McCabe <cmccabe@alumni.cmu.edu>
> wrote:
>
> > On Mon, Jan 19, 2015 at 10:30 PM, Stack <stack@duboce.net> wrote:
> >
> > > Here is help for htrace:
> > >
> > > kalashnikov-17:go stack$ ./build/htrace --help
> > > usage: htrace [<flags>] <command> [<flags>] [<args>
...]
> > >
> > > The HTrace tracing utility.
> > >
> > > Flags:
> > >   --help               Show help.
> > >   --addr=0.0.0.0:9095  Server address.
> > >
> > > Commands:
> > >   help [<command>]
> > >     Show help for a command.
> > >
> > >   version
> > >     Print the version of this program.
> > >
> > >   serverInfo
> > >     Print information retrieved from an htraced server.
> > >
> > >   findSpan --id=ID
> > >     Print information about a trace span with a given ID.
> > >
> > >   findChildren --id=ID [<flags>]
> > >     Print out the span IDs that are children of a given span ID.
> > >
> > >   writeSpans --json=JSON
> > >     Write spans to the server in JSON form.
> > >
> > >
> > > What is a little odd to me is that required arguments are done as
> > 'options'
> > > or 'flags'.  For example, findSpan requires that you pass an id but the
> > id
> > > is passed with the '--id=ID' format.  Shouldn't it be 'findSpan ID'
> with
> > > flags and options  passed with '--...' format?
> > >
> >
> > Good idea.  We could make 'ID' the first positional argument.  The
> argument
> > parsing library we're using supports that pretty easily, I think.  Open a
> > JIRA?
> >
> >
> > > When I start htraced, it should print version and the port it is
> > listening
> > > on.
> > >
> > >
> > Yeah
> >
> >
> > > It looks like the serverInfo is gotten by doing a GET on /server/info
> > yet I
> > > write spans at /writeSpans.  Shouldn't the span writing and seaching be
> > > under a subdir at /spans: e.g. to write spans you'd do /spans/write and
> > to
> > > find you'd do /spans/find ?
> > >
> >
> > I think the current paradigm for "find" is GET /$SPAN_ID, where SPAN_ID
> is
> > the hex ID of the span.
> > I'd be fine with moving that to "GET /spans/$SPAN_ID".  Then we could
> move
> > writing spans to "PUT /spans/write" for consistency.
> >
> > When I send spans to htraced, it logs each it receives. Can I turn this
> > > off?  Can I turn on logging even more info like the total REST request
> > > (optionally)?
> > >
> > > I've been looking at making htraced logging a big more configurable.
> > Well, ok... configurable at all :) I should have something up on that
> soon.
> >
> > Colin
> >
> >
> > > St.Ack
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message