Adding the client/server.instanceid tag

[marcingrzejszczak]

• without this tag it's impossible to discern from which server was the given span originated
• with this change we're adding a tag in which we're passing the contents of the spring.application.instanceid value to define the id of the given instance

fixes #369

cc @dsyer @adriancole

[codefromthecrypt]

I don't think you need to add this twice, if you think about how it is used.

For example, are you going to search for a client whose instanceid is this? or anything whose instanceid is this? In the normal dual-host span model, the span detail screen would show the servicename and IP address who reported the instanceid (which would also match any other client-related tags). In any future "single-host span" model, this clarifier will become even more redundant. In other words, unless there's a very good reason to qualify this as client/server I'd just leave it as a normal tag like "spring.application.instanceid" or shorter like "spring.instanceid" id there's not likely an instanceid that isn't an application

[marcingrzejszczak]

I see one issue with this (but maybe actually I'm wrong then there's no issue at all ;) ). If both the client and the server put the same tag with 2 different values, won't it be broken on the Zipkin UI in the RPC span?

[codefromthecrypt]

it will show up twice, once for each value (for each tracer)

[marcingrzejszczak]

Awesome! So indeed I'll prefer to simplify things 👍

[marcingrzejszczak]

Non Cloud Foundry execution:

Cloud Foundry

[marcingrzejszczak]

fixed in 5b442e9