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 Mon, 21 Aug 2017 09:09:01 GMT
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.

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.

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