You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zipkin.apache.org by Jordi Polo Carres <jc...@mdsol.com> on 2018/12/15 05:44:21 UTC
headers in response
Hi,
Multiple times I've been asked in my company about adding the zipkin
headers to responses.
Mostly by testers who want to know and search trace ids in logs but they
are doing some manual test and it is difficult for them to generate unique
ids and add them to the headers.
As this is not a case that happens in real production environment, I never
wanted to do it.
What do other libraries do? Is this something you can relate to?
Thanks
--
*Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
<http://www.mdsol.com/>
Api bundle: api-bundle@mdsol.com
API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
Re: headers in response
Posted by Jordi Polo Carres <jc...@mdsol.com>.
For automation we create traceIDs at the origin. It is for manual testing
of APIs which people are sending requests mainly using the Postman
application and they get an unexpected response, they want something to
easily find details in logs and traceid is good. But creating new traceids
not ggood and reusing the same one even worse.
On Sat, Dec 15, 2018 at 9:58 AM José Carlos Chávez <jc...@gmail.com>
wrote:
> Just my 2p:
>
> We have some E2E automatic tests on CI for some framework libraries and
> one day Adrian suggested that we could pass the traceID on beforehand and
> then check traces are actually instead of them being generated, we have
> something like that in our E2E automated tests at my company so instead of
> trying to get the traceID we generate them in the test.
>
> Den lør. 15. des. 2018, 17:24 skrev Andriy Redko <drreta@gmail.com:
>
>> Hi Jordi,
>>
>> We also do this in Apache CXF, for all our integrations. I don't
>> recall this feature being requested but it indeed helps to debug
>> some issues. The presence of the trace headers in the response does
>> not hurt much I think (since they are present in request anyway). But
>> I don't have the proof it is useful actually yet.
>>
>> Best Regards,
>> Andriy Redko
>>
>> JPC> Not particularly arguing we should do it in general. If most of the
>> JPC> implementations do not have this, means they did not encounter this
>> problem.
>> JPC> Meaning, testers in my company are doing something unusual and we
>> need to
>> JPC> rethink our side.
>>
>> JPC> If other people are seeing this, that means the Ruby implementation
>> is
>> JPC> behind and we should just implement it.
>> JPC> In the Ruby case it is simple as the middleware sits there for both
>> request
>> JPC> and response. I'm not worried about the implementation being tough
>> but if
>> JPC> it would be the correct thing to do.
>>
>> JPC> As I said, there is no reason in production to need this. From
>> upstream
>> JPC> services traces are already there. This is only an issue when you
>> call
>> JPC> using Postman or other testing tool.
>>
>>
>> JPC> On Fri, Dec 14, 2018 at 10:03 PM Adrian Cole <
>> adrian.f.cole@gmail.com>
>> JPC> wrote:
>>
>> >> This topic has come up many times. Somebody named Jordi raise this
>> >> over 2 years ago I think :)
>>
>> >>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openzipkin_b3-2Dpropagation_issues_4&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=0uNEtmQGBarTGjZm759EZIFgOHFjQAMAr_M2rfsOCl4&e=
>>
>> >> The best solution I can think of is to have the user opt into a
>> >> response header. This is what kamon does and I think some libraries
>> >> could follow:
>> >>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kamon-2Dio_Kamon_blob_master_kamon-2Dcore_src_main_resources_reference.conf-23L350&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=1XJFVwGQNbQynTx8Ws_o_16YdvyyCKyrXdb895wWVj0&e=
>>
>> >> main downside besides leaking the ID is that most instrumentation are
>> >> not currently trying to mutate http response headers. At any rate, in
>> >> a lot of middleware someone can do this any way by adding a filter
>> >> that peeks at the current span.
>>
>> >> hope this helps!
>> >> -A
>> >> On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jc...@mdsol.com>
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > Multiple times I've been asked in my company about adding the zipkin
>> >> > headers to responses.
>> >> >
>> >> > Mostly by testers who want to know and search trace ids in logs but
>> they
>> >> > are doing some manual test and it is difficult for them to generate
>> >> unique
>> >> > ids and add them to the headers.
>> >> >
>> >> > As this is not a case that happens in real production environment, I
>> >> never
>> >> > wanted to do it.
>> >> >
>> >> > What do other libraries do? Is this something you can relate to?
>> >> >
>> >> > Thanks
>> >> >
>> >> > --
>> >> > *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
>> >> > <http://www.mdsol.com/>
>> >> > Api bundle: api-bundle@mdsol.com
>> >> > API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
>> >> For additional commands, e-mail: dev-help@zipkin.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
>> For additional commands, e-mail: dev-help@zipkin.apache.org
>>
>>
--
*Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
<http://www.mdsol.com/>
Api bundle: api-bundle@mdsol.com
API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
Re: headers in response
Posted by José Carlos Chávez <jc...@gmail.com>.
Just my 2p:
We have some E2E automatic tests on CI for some framework libraries and one
day Adrian suggested that we could pass the traceID on beforehand and then
check traces are actually instead of them being generated, we have
something like that in our E2E automated tests at my company so instead of
trying to get the traceID we generate them in the test.
Den lør. 15. des. 2018, 17:24 skrev Andriy Redko <drreta@gmail.com:
> Hi Jordi,
>
> We also do this in Apache CXF, for all our integrations. I don't
> recall this feature being requested but it indeed helps to debug
> some issues. The presence of the trace headers in the response does
> not hurt much I think (since they are present in request anyway). But
> I don't have the proof it is useful actually yet.
>
> Best Regards,
> Andriy Redko
>
> JPC> Not particularly arguing we should do it in general. If most of the
> JPC> implementations do not have this, means they did not encounter this
> problem.
> JPC> Meaning, testers in my company are doing something unusual and we
> need to
> JPC> rethink our side.
>
> JPC> If other people are seeing this, that means the Ruby implementation is
> JPC> behind and we should just implement it.
> JPC> In the Ruby case it is simple as the middleware sits there for both
> request
> JPC> and response. I'm not worried about the implementation being tough
> but if
> JPC> it would be the correct thing to do.
>
> JPC> As I said, there is no reason in production to need this. From
> upstream
> JPC> services traces are already there. This is only an issue when you call
> JPC> using Postman or other testing tool.
>
>
> JPC> On Fri, Dec 14, 2018 at 10:03 PM Adrian Cole <adrian.f.cole@gmail.com
> >
> JPC> wrote:
>
> >> This topic has come up many times. Somebody named Jordi raise this
> >> over 2 years ago I think :)
>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openzipkin_b3-2Dpropagation_issues_4&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=0uNEtmQGBarTGjZm759EZIFgOHFjQAMAr_M2rfsOCl4&e=
>
> >> The best solution I can think of is to have the user opt into a
> >> response header. This is what kamon does and I think some libraries
> >> could follow:
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kamon-2Dio_Kamon_blob_master_kamon-2Dcore_src_main_resources_reference.conf-23L350&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=1XJFVwGQNbQynTx8Ws_o_16YdvyyCKyrXdb895wWVj0&e=
>
> >> main downside besides leaking the ID is that most instrumentation are
> >> not currently trying to mutate http response headers. At any rate, in
> >> a lot of middleware someone can do this any way by adding a filter
> >> that peeks at the current span.
>
> >> hope this helps!
> >> -A
> >> On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jc...@mdsol.com>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Multiple times I've been asked in my company about adding the zipkin
> >> > headers to responses.
> >> >
> >> > Mostly by testers who want to know and search trace ids in logs but
> they
> >> > are doing some manual test and it is difficult for them to generate
> >> unique
> >> > ids and add them to the headers.
> >> >
> >> > As this is not a case that happens in real production environment, I
> >> never
> >> > wanted to do it.
> >> >
> >> > What do other libraries do? Is this something you can relate to?
> >> >
> >> > Thanks
> >> >
> >> > --
> >> > *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
> >> > <http://www.mdsol.com/>
> >> > Api bundle: api-bundle@mdsol.com
> >> > API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> >> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
Re: headers in response
Posted by Andriy Redko <dr...@gmail.com>.
Hi Jordi,
We also do this in Apache CXF, for all our integrations. I don't
recall this feature being requested but it indeed helps to debug
some issues. The presence of the trace headers in the response does
not hurt much I think (since they are present in request anyway). But
I don't have the proof it is useful actually yet.
Best Regards,
Andriy Redko
JPC> Not particularly arguing we should do it in general. If most of the
JPC> implementations do not have this, means they did not encounter this problem.
JPC> Meaning, testers in my company are doing something unusual and we need to
JPC> rethink our side.
JPC> If other people are seeing this, that means the Ruby implementation is
JPC> behind and we should just implement it.
JPC> In the Ruby case it is simple as the middleware sits there for both request
JPC> and response. I'm not worried about the implementation being tough but if
JPC> it would be the correct thing to do.
JPC> As I said, there is no reason in production to need this. From upstream
JPC> services traces are already there. This is only an issue when you call
JPC> using Postman or other testing tool.
JPC> On Fri, Dec 14, 2018 at 10:03 PM Adrian Cole <ad...@gmail.com>
JPC> wrote:
>> This topic has come up many times. Somebody named Jordi raise this
>> over 2 years ago I think :)
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openzipkin_b3-2Dpropagation_issues_4&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=0uNEtmQGBarTGjZm759EZIFgOHFjQAMAr_M2rfsOCl4&e=
>> The best solution I can think of is to have the user opt into a
>> response header. This is what kamon does and I think some libraries
>> could follow:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kamon-2Dio_Kamon_blob_master_kamon-2Dcore_src_main_resources_reference.conf-23L350&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=1XJFVwGQNbQynTx8Ws_o_16YdvyyCKyrXdb895wWVj0&e=
>> main downside besides leaking the ID is that most instrumentation are
>> not currently trying to mutate http response headers. At any rate, in
>> a lot of middleware someone can do this any way by adding a filter
>> that peeks at the current span.
>> hope this helps!
>> -A
>> On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jc...@mdsol.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > Multiple times I've been asked in my company about adding the zipkin
>> > headers to responses.
>> >
>> > Mostly by testers who want to know and search trace ids in logs but they
>> > are doing some manual test and it is difficult for them to generate
>> unique
>> > ids and add them to the headers.
>> >
>> > As this is not a case that happens in real production environment, I
>> never
>> > wanted to do it.
>> >
>> > What do other libraries do? Is this something you can relate to?
>> >
>> > Thanks
>> >
>> > --
>> > *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
>> > <http://www.mdsol.com/>
>> > Api bundle: api-bundle@mdsol.com
>> > API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
>> For additional commands, e-mail: dev-help@zipkin.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org
Re: headers in response
Posted by Tommy Ludwig <to...@gmail.com>.
Particularly since it isn't meant for production, logging a warning on
startup when it is enabled seems like a decent precaution to me.
We have also had developers want this for investigating issues in non prod
environments specifically. Some even went so far as to add the trace ID in
their default API error response body, configurable at runtime and turned
off in production.
2018年12月15日(土) 15:10 Jordi Polo Carres <jc...@mdsol.com>:
> Not particularly arguing we should do it in general. If most of the
> implementations do not have this, means they did not encounter this
> problem.
> Meaning, testers in my company are doing something unusual and we need to
> rethink our side.
>
> If other people are seeing this, that means the Ruby implementation is
> behind and we should just implement it.
> In the Ruby case it is simple as the middleware sits there for both request
> and response. I'm not worried about the implementation being tough but if
> it would be the correct thing to do.
>
> As I said, there is no reason in production to need this. From upstream
> services traces are already there. This is only an issue when you call
> using Postman or other testing tool.
>
>
> On Fri, Dec 14, 2018 at 10:03 PM Adrian Cole <ad...@gmail.com>
> wrote:
>
> > This topic has come up many times. Somebody named Jordi raise this
> > over 2 years ago I think :)
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openzipkin_b3-2Dpropagation_issues_4&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=0uNEtmQGBarTGjZm759EZIFgOHFjQAMAr_M2rfsOCl4&e=
> >
> > The best solution I can think of is to have the user opt into a
> > response header. This is what kamon does and I think some libraries
> > could follow:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kamon-2Dio_Kamon_blob_master_kamon-2Dcore_src_main_resources_reference.conf-23L350&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=1XJFVwGQNbQynTx8Ws_o_16YdvyyCKyrXdb895wWVj0&e=
> >
> > main downside besides leaking the ID is that most instrumentation are
> > not currently trying to mutate http response headers. At any rate, in
> > a lot of middleware someone can do this any way by adding a filter
> > that peeks at the current span.
> >
> > hope this helps!
> > -A
> > On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jc...@mdsol.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > Multiple times I've been asked in my company about adding the zipkin
> > > headers to responses.
> > >
> > > Mostly by testers who want to know and search trace ids in logs but
> they
> > > are doing some manual test and it is difficult for them to generate
> > unique
> > > ids and add them to the headers.
> > >
> > > As this is not a case that happens in real production environment, I
> > never
> > > wanted to do it.
> > >
> > > What do other libraries do? Is this something you can relate to?
> > >
> > > Thanks
> > >
> > > --
> > > *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
> > > <http://www.mdsol.com/>
> > > Api bundle: api-bundle@mdsol.com
> > > API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> > For additional commands, e-mail: dev-help@zipkin.apache.org
> >
> >
>
> --
> *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
> <http://www.mdsol.com/>
> Api bundle: api-bundle@mdsol.com
> API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
>
Re: headers in response
Posted by Jordi Polo Carres <jc...@mdsol.com>.
Not particularly arguing we should do it in general. If most of the
implementations do not have this, means they did not encounter this problem.
Meaning, testers in my company are doing something unusual and we need to
rethink our side.
If other people are seeing this, that means the Ruby implementation is
behind and we should just implement it.
In the Ruby case it is simple as the middleware sits there for both request
and response. I'm not worried about the implementation being tough but if
it would be the correct thing to do.
As I said, there is no reason in production to need this. From upstream
services traces are already there. This is only an issue when you call
using Postman or other testing tool.
On Fri, Dec 14, 2018 at 10:03 PM Adrian Cole <ad...@gmail.com>
wrote:
> This topic has come up many times. Somebody named Jordi raise this
> over 2 years ago I think :)
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openzipkin_b3-2Dpropagation_issues_4&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=0uNEtmQGBarTGjZm759EZIFgOHFjQAMAr_M2rfsOCl4&e=
>
> The best solution I can think of is to have the user opt into a
> response header. This is what kamon does and I think some libraries
> could follow:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kamon-2Dio_Kamon_blob_master_kamon-2Dcore_src_main_resources_reference.conf-23L350&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=SSUfWLb5WieUWPIaxv7eRSvhcKTbhgb4_mC4bqUFLnI&s=1XJFVwGQNbQynTx8Ws_o_16YdvyyCKyrXdb895wWVj0&e=
>
> main downside besides leaking the ID is that most instrumentation are
> not currently trying to mutate http response headers. At any rate, in
> a lot of middleware someone can do this any way by adding a filter
> that peeks at the current span.
>
> hope this helps!
> -A
> On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jc...@mdsol.com>
> wrote:
> >
> > Hi,
> >
> > Multiple times I've been asked in my company about adding the zipkin
> > headers to responses.
> >
> > Mostly by testers who want to know and search trace ids in logs but they
> > are doing some manual test and it is difficult for them to generate
> unique
> > ids and add them to the headers.
> >
> > As this is not a case that happens in real production environment, I
> never
> > wanted to do it.
> >
> > What do other libraries do? Is this something you can relate to?
> >
> > Thanks
> >
> > --
> > *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
> > <http://www.mdsol.com/>
> > Api bundle: api-bundle@mdsol.com
> > API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
> For additional commands, e-mail: dev-help@zipkin.apache.org
>
>
--
*Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
<http://www.mdsol.com/>
Api bundle: api-bundle@mdsol.com
API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
Re: headers in response
Posted by Adrian Cole <ad...@gmail.com>.
This topic has come up many times. Somebody named Jordi raise this
over 2 years ago I think :)
https://github.com/openzipkin/b3-propagation/issues/4
The best solution I can think of is to have the user opt into a
response header. This is what kamon does and I think some libraries
could follow: https://github.com/kamon-io/Kamon/blob/master/kamon-core/src/main/resources/reference.conf#L350
main downside besides leaking the ID is that most instrumentation are
not currently trying to mutate http response headers. At any rate, in
a lot of middleware someone can do this any way by adding a filter
that peeks at the current span.
hope this helps!
-A
On Sat, Dec 15, 2018 at 1:44 PM Jordi Polo Carres <jc...@mdsol.com> wrote:
>
> Hi,
>
> Multiple times I've been asked in my company about adding the zipkin
> headers to responses.
>
> Mostly by testers who want to know and search trace ids in logs but they
> are doing some manual test and it is difficult for them to generate unique
> ids and add them to the headers.
>
> As this is not a case that happens in real production environment, I never
> wanted to do it.
>
> What do other libraries do? Is this something you can relate to?
>
> Thanks
>
> --
> *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide
> <http://www.mdsol.com/>
> Api bundle: api-bundle@mdsol.com
> API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@zipkin.apache.org
For additional commands, e-mail: dev-help@zipkin.apache.org