{"action":"created","issue":{"url":"https://api.github.com/repos/opentracing/opentracing.github.io/issues/116","repository_url":"https://api.github.com/repos/opentracing/opentracing.github.io","labels_url":"https://api.github.com/repos/opentracing/opentracing.github.io/issues/116/labels{/name}","comments_url":"https://api.github.com/repos/opentracing/opentracing.github.io/issues/116/comments","events_url":"https://api.github.com/repos/opentracing/opentracing.github.io/issues/116/events","html_url":"https://github.com/opentracing/opentracing.github.io/issues/116","id":172336182,"number":116,"title":"Introduce peer.hostPort standard tag","user":{"login":"yurishkuro","id":3523016,"avatar_url":"https://avatars.githubusercontent.com/u/3523016?v=3","gravatar_id":"","url":"https://api.github.com/users/yurishkuro","html_url":"https://github.com/yurishkuro","followers_url":"https://api.github.com/users/yurishkuro/followers","following_url":"https://api.github.com/users/yurishkuro/following{/other_user}","gists_url":"https://api.github.com/users/yurishkuro/gists{/gist_id}","starred_url":"https://api.github.com/users/yurishkuro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yurishkuro/subscriptions","organizations_url":"https://api.github.com/users/yurishkuro/orgs","repos_url":"https://api.github.com/users/yurishkuro/repos","events_url":"https://api.github.com/users/yurishkuro/events{/privacy}","received_events_url":"https://api.github.com/users/yurishkuro/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-08-21T19:18:09Z","updated_at":"2016-08-22T17:22:15Z","closed_at":null,"body":"We currently have a series of [standard peer tags](http://opentracing.io/data/#peer-tags) like `peer.ipv4`, `peer.hostname`, `peer.port`, etc. I've discovered that quite often the RPC libraries being instrumented with OT do not actually know the exact format of `\"host:port\"` string they are given, because they just pass it to lower-level networking libraries. Therefore when RPC libraries need to identify the peer via peer tags, they often have to duplicate the same parsing code, for example [here](https://github.com/uber/tchannel-go/pull/488).\r\n\r\nI would like to propose a standard tag `peer.hostPort` (string) which can take a variety of different formats and let the tracer implementation deal with parsing it (or even send it off to collection tier to process later).  Specifically, the tag value could be one of these forms:\r\n  * `host:port` (port must be a number)\r\n  * `host` (no port)\r\n  * where `host` can be\r\n    * host name, e.g.\r\n      * `\"myhost\"`\r\n      * `\"webserver.mydomain.com\"`\r\n      * `\"ip-12-34-56-78.us-west-2.compute.internal\"`\r\n    * IPv4 address, e.g. `\"10.20.30.40\"`\r\n    * IPv6 address in brackers `[]`, e.g. `\"[2001:0db8:85a3:0000:0000:8a2e:0370:7334]\"`\r\n\r\ncc @bensigelman @dkuebric "},"comment":{"url":"https://api.github.com/repos/opentracing/opentracing.github.io/issues/comments/241485087","html_url":"https://github.com/opentracing/opentracing.github.io/issues/116#issuecomment-241485087","issue_url":"https://api.github.com/repos/opentracing/opentracing.github.io/issues/116","id":241485087,"user":{"login":"yurishkuro","id":3523016,"avatar_url":"https://avatars.githubusercontent.com/u/3523016?v=3","gravatar_id":"","url":"https://api.github.com/users/yurishkuro","html_url":"https://github.com/yurishkuro","followers_url":"https://api.github.com/users/yurishkuro/followers","following_url":"https://api.github.com/users/yurishkuro/following{/other_user}","gists_url":"https://api.github.com/users/yurishkuro/gists{/gist_id}","starred_url":"https://api.github.com/users/yurishkuro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yurishkuro/subscriptions","organizations_url":"https://api.github.com/users/yurishkuro/orgs","repos_url":"https://api.github.com/users/yurishkuro/repos","events_url":"https://api.github.com/users/yurishkuro/events{/privacy}","received_events_url":"https://api.github.com/users/yurishkuro/received_events","type":"User","site_admin":false},"created_at":"2016-08-22T17:22:15Z","updated_at":"2016-08-22T17:22:15Z","body":"@bensigelman `address` sounds quite different from `hostPort`, given what you said about resolution. For example, if you're instrumenting a plain HTTP client, I don't think it will work with `address` that needs resolution, but it will work with all the variants of `hostPort` I showed above, and that `hostPort` will be eventually available in the user code after resolution step.\r\n\r\nIt's certainly useful to capture resolvable `address`, but I would do it as a separate tag from `hostPort`. Also, resolvable `address` probably isn't going to differentiate between the instances of the target service, whereas `hostPort` will (unless there's additional routing like haproxy)."}}
{"actor":{"display_login":"yurishkuro"}}