search

openzipkin / zipkin-gcp

Reporters and collectors for use in Google Cloud Platform
https://cloud.google.com/trace/docs/zipkin
Apache License 2.0
91 stars 54 forks source link

Consider synchronizing integration approach with other projects in zipkin #36

Open codefromthecrypt opened 7 years ago

codefromthecrypt commented 7 years ago

Most zipkin integrations do not require a custom build, rather custom assembly. For example, zipkin-aws and zipkin-azure layer autoconfiguration on top of the base server. This allows people to mix and match things, for example using a kafka collector, but a google cloud storage. Importantly, this allows people to compose servers in their tool of choice, albeit docker, puppet, chef or doit.sh without a custom build.

One example of composition is amazon SQS here:

https://github.com/openzipkin/zipkin-aws/tree/master/autoconfigure/collector-sqs#running

You can see that this allows you to decorate properties on top of the builtin ones from Zipkin.

There's only one catch to this, which is that the maven setting (module) used there has been removed in spring boot 1.5 (https://github.com/openzipkin/zipkin-aws/issues/32). Across all projects we would need a similar remedy to that.

See #33 for a discussion about restructuring. Restructuring is good, but I think it would be better to restructure similarly to other zipkin integrations such that support is easier.

codefromthecrypt commented 7 years ago

I opened a similar issue in spring-cloud-sleuth which is the other source of custom builds https://github.com/spring-cloud/spring-cloud-sleuth/issues/555

codefromthecrypt commented 7 years ago

related to integrations.. our other clouds have a "sender" which might be appropriate here. This would allow apps who already use zipkin-reporter-java implicitly (like spring-cloud-sleuth, brave, wingtips, jaeger) to plug directly into stackdriver if they want. Those using spring would not need a custom server, unless they need to intermediate. See #37 for a longer chat on multi-cloud