search

openzipkin / zipkin-support

repository for support questions raised as issues
4 stars 2 forks source link

Accept hostnam in endpoints #17

Closed rmannibucau closed 4 years ago

rmannibucau commented 4 years ago

Currently zipkin only accepts ip (4 or 6) in endpoints.

This is really troublesome in environments where IP are (highly) dynamic and potentially a short live thing. Even if hostname is not something unique it gives more sense in such environments (basically cause IP does not give you any information as an user in this case).

Is it possible to relax the validation to accept hosts or add a new entry to be able to set the host instead of the ip?

Romain

jcchavezs commented 4 years ago

I faced this in the past when tried to understand a clockdrift among hosts. IP wasn't easy to chase down so we ended up adding a tag called "instance_id". This was a good enough solution for us. The way to enable it is using something like "default tags" in different instrumentations. This option is also available in some tracers. No strong feelings about adding or not adding this field into the local endpoint.

On Fri, 19 Jun 2020, 14:35 Romain Manni-Bucau, notifications@github.com wrote:

Currently zipkin only accepts ip (4 or 6) in endpoints.

This is really troublesome in environments where IP are (highly) dynamic and potentially a short live thing. Even if hostname is not something unique it gives more sense in such environments (basically cause IP does not give you any information as an user in this case).

Is it possible to relax the validation to accept hosts or add a new entry to be able to set the host instead of the ip?

Romain

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzipkin/zipkin-support/issues/17, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXOYAWE2JY2T75E6WOOWD3RXNLQ3ANCNFSM4OCWBYWQ .

rmannibucau commented 4 years ago

It is what i'm using currently but the UI (I should say UIs ;)) is not designed for that and it leads to too much work IMHO a built-in field could simplify. Until I'm missing something, ip/port is mainly to track the particular instance so when there is another identifier for that it should be usable no - thinking to k8s names for ex under some network setup?

codefromthecrypt commented 4 years ago

top level fields require changing the entire ecosystem in order to support (literally all language libraries, json+proto formats, jobs, server and the UI). otherwise certain things will delete the field because the codec doesnt support it.

there are existing tags in various namespace already so let's start with thinking about tag.

there is a discussion around an http specific (possibly TLS specific) host/authority tag. if this was http specific but the UI still addressed it, would that work?

On Fri, Jun 19, 2020, 9:32 PM Romain Manni-Bucau notifications@github.com wrote:

It is what i'm using currently but the UI (I should say UIs ;)) is not designed for that and it leads to too much work IMHO a built-in field could simplify. Until I'm missing something, ip/port is mainly to track the particular instance so when there is another identifier for that it should be usable no - thinking to k8s names for ex under some network setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzipkin/zipkin-support/issues/17#issuecomment-646637786, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPVVYZZUEEWS2PI5CHPHTRXNSHLANCNFSM4OCWBYWQ .

codefromthecrypt commented 4 years ago

also IP is not required though it is helpful to implement clock skew within a trace.

in other words the most important part is the service name. if IP:port doesnt help you this data can be dropped.

On Sat, Jun 20, 2020, 7:29 AM Adrian Cole adrian.f.cole@gmail.com wrote:

top level fields require changing the entire ecosystem in order to support (literally all language libraries, json+proto formats, jobs, server and the UI). otherwise certain things will delete the field because the codec doesnt support it.

there are existing tags in various namespace already so let's start with thinking about tag.

there is a discussion around an http specific (possibly TLS specific) host/authority tag. if this was http specific but the UI still addressed it, would that work?

On Fri, Jun 19, 2020, 9:32 PM Romain Manni-Bucau notifications@github.com wrote:

It is what i'm using currently but the UI (I should say UIs ;)) is not designed for that and it leads to too much work IMHO a built-in field could simplify. Until I'm missing something, ip/port is mainly to track the particular instance so when there is another identifier for that it should be usable no - thinking to k8s names for ex under some network setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzipkin/zipkin-support/issues/17#issuecomment-646637786, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPVVYZZUEEWS2PI5CHPHTRXNSHLANCNFSM4OCWBYWQ .

rmannibucau commented 4 years ago

My main issue is to get help from the ui. If tags can be ordered/layout in the ui it is ok for me

codefromthecrypt commented 4 years ago

there's a large effort already here about the host info, so let's see about this. Currently, the UI doesn't leverage any tags except "error", but we can discuss this after the tag is in.

https://github.com/openzipkin/zipkin/issues/2167