Re: DocDB support for zipkin

[Adrian Cole]

Hi, Praveen.

Sorry my notification settings were a bit off, so replying late.

So, here's what I think we could do for DocumentDb.

Firstly, I'd suggest this go into a new repository: zipkin-azure, with io.zipkin.azure:zipkin-storage-documentdb being one of the components. Reason is that there are likely other azure services that would follow (particularly transport), and they would end up sharing code (at least auth) and have similar users and developers.

To do that, it would look similar to https://github.com/openzipkin/zipkin-aws which is independently run. In other words, if you are keen, I could help setup the scaffolding needed such that you can develop and release at will (while still making it possible for others in openzipkin to help).

For the implementation, I think it would be best if we used something like what we are doing for zipkin-elasticsearch-http. This uses OkHttp as the client, which allows us to do things like self-tracing pretty easily and keeps dependency count low. It also keeps the code familiar which makes it easier for others to help. Regardless of library, the implementation would need to supply an alternate URL so that unit tests that mock the azure service can be used.

I've written azure api services in the past (ex I did a lot of development in jclouds for blobstore and the azure compute service), so I'm pretty familiar with the generalities of plumbing. That said, I don't know the semantics of the document store. So, basically I could help you with plumbing, code reviews and general setup, but the bulk of the effort would be on you.

Lemme know how you'd like to proceed!

-Adrian

On Friday, October 21, 2016 at 2:38:31 AM UTC+8, Praveen Barli wrote:

Hi,

 Our team is looking into adding support for DocumentDb This is to allow our customers using Microsoft Azure services to take advantage of tracing capabilities. 

 I spoke earlier on this and put the conversation below. 

 I want to know little more details on the typical process and any challenges to support new storage. I am putting few steps I foresee through which I could achieve this but please add more details.

  1) Pull the latest source from Openzipkin (https://github.com/openzipkin/zipkin/)

  2) Add DocDb specific implementation classes for StorageComponent interface.

  3) Ensure the test case in SpanStoreTest pass for StorageCompnonet and also, of course, all existing test cases.

  4) Test UI by sending traces through any existing instrumentation libraries.

      

Could you shed some more light on work in terms of development, setup/testing efforts needed to support the new storage. Also, please mention any specific email id's we could contact for support.

Regards,

Praveen

Gitter conversation:

In response to my question - How much effort it is to support other databases like DocumentDB, SQL Server.

Adrian Cole @adriancole

@barpr01_twitter probably a decent amount of effort. there's some queries that don't work in all DBs

I don't know anything about docdb

a lot of the effort is getting setup and tested. for example, we've had a fair amount of folks ask for postgresql, but we're likely to have that in a separate repo as it is fair amount of effort to maintain a new storage backend. Plus it makes all of our conversations about evolving more difficult.

basically I don't expect us to add another datastore to core, but a separate repo could exist if someone had time and effort to do it