htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raam Rosh-Hai <r...@findhotel.net>
Subject Re: [DISCUSS] Attic podling Apache HTrace?
Date Thu, 31 Aug 2017 08:32:01 GMT
Thank you Colin for your response,
I was actually referring to Adrian's comment on making Htrace and Zipkin
play more nicely together, I have been using Htrace with zipkin for a while
now and I am doing pretty well but I was wondering if there are some
glaring pain points that should be attended.

On 30 August 2017 at 23:41, Colin McCabe <cmccabe@apache.org> wrote:

> On Mon, Aug 21, 2017, at 02:09, Raam Rosh-Hai wrote:
> > I tend to agree that zipkin should be used as a frontend and I am pretty
> > sure I will have some time to advance that in the coming weeks if one of
> > the experts could create a few tasks.
>
> Hi Raam,
>
> If you're interested in this, check out the Zipkin trace sink.  That
> allows you to send HTrace spans to Zipkin.
>
> >
> > I think no one touched the obvious thing that tracing lacks any kind of
> > hype, it's just not glamours and in order to want to use such a framework
> > you need to be versed in this world and to actually suffer from
> > distributed
> > debugging.
>
> Yeah, I think this is an area where some publicity and outreach would be
> a good thing :)
>
> It would help a lot if we could identify some core use-cases, like Stack
> said, and make sure everything works great for those.
>
> Colin
>
>
> >
> > so yes, I think this project deserves one last push before putting it in
> > the attic and I would be happy to complete a few issues in order to make
> > this happen.
> >
> >
> >
> > On 19 August 2017 at 03:55, Adrian Cole <adrian.f.cole@gmail.com> wrote:
> >
> > > > Thanks Adrian for the editorial on the landscape. Helps, especially
> > > coming
> > > > from yourself.
> > > we aim to please
> > >
> > > > Given current state of the project, a retrofit to come up on OT is
> not
> > > the
> > > > solution to the topic-at-hand (and besides I have a colored opinion
> on
> > > > taking on the API of another after spending a bunch of time recently
> > > > undoing our mistake letting third-party Interfaces and Classes show
> > > through
> > > > in hbase).
> > > sensible for any api highly disconnected from the ecosystem,
> > > especially without practice yet.
> > >
> > > > I appreciate the higher-level point made by Andrew, that it is hard
> to
> > > > thread a cross-cutting library across the Hadoop landscape whether
> > > because
> > > > releases happen on the geologic time scale or that there is little
> by way
> > > > of coordination.
> > > I think this is indeed leading a path towards focus, eg the H in
> Htrace :)
> > >
> > > > Can we do a focused 'win' like Colin suggests? E.g. hook up hbase and
> > > hdfs
> > > > end-to-end with connection to a viewer (zipkin? Or text dumps in a
> > > > webpage?). A while back I had a go at the hbase side but it was
> burning
> > > up
> > > > the hours just getting it hooked up w/ tests to scream if any spans
> were
> > > > broken in a refactor. I had to put it aside.
> > > Incidentally, I wouldn't necessarily say Zipkin is ready out of box
> > > because htrace UI and query is more advanced (in some ways due to some
> > > data storage options we have available). So, something like this could
> > > be a move of focus which would require investment on the other side to
> > > avail features needed, or discuss how to upgrade into them (ex if
> > > using hbase storage, certain queries would work). It is fair to say
> > > zipkin has  a great devops pipeline, we are good at fixing things. At
> > > the same time, we are imperfect in impl and inexperienced in hadoop
> > > ecosystem. Having some way to join together could be really
> > > beneficial, at the cost of up-front effort (due to model, UI and
> > > storage differences). I would be happy to direct time, though would
> > > need some help because of my irrelevance in the data services space
> > > (something this might correct!)
> > >
> > > > Like the rest of you, my time is a little occupied elsewhere these
> times
> > > so
> > > > I can't revive the project, not at the moment at least.
> > > ack
> > >
>

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