|
| 1 | +# Overview |
| 2 | + |
| 3 | +This package implements a number of translators that help translate spans to and from OpenCensus format to a number of other supported formats such as Jaeger Proto, Jaeger Thrift, Zipkin Thrift, Zipkin JSON. This document mentions how certain non-obvious things should be handled. |
| 4 | + |
| 5 | +## Links: |
| 6 | + |
| 7 | +* [OpenTracing Semantic Conventions](https://github.com/opentracing/specification/blob/master/semantic_conventions.md) |
| 8 | + |
| 9 | +## Status Codes and Messages |
| 10 | + |
| 11 | +### OpenCensus |
| 12 | + |
| 13 | +OpenCensus protocol has a special field to represent the status of an operation. The status field has two fields, an int32 field called `code` and a string field called `message`. When converting from other formats, status field must be set from the relevant tags/attributes of the source format. When converting from OC to other formats, the status field must be translated to appropriate tags/attributes of the target format. |
| 14 | + |
| 15 | + |
| 16 | +### Jaeger to OC |
| 17 | + |
| 18 | +Jaeger spans may contain two possible sets of tags that can possibly represent the status of an operation: |
| 19 | + |
| 20 | +- `status.code` and `status.message` |
| 21 | +- `http.status_code` and `http.status_message` |
| 22 | + |
| 23 | +When converting from Jaeger to OC, |
| 24 | + |
| 25 | +1. OC status should be set from `status.code` and `status.message` tags if `status.code` tag is found on the Jaeger span. Since OC already has a special status field, these tags (`status.code` and `status.message`) are redundant and should be dropped from resultant OC span. |
| 26 | +2. If the `status.code` tag is not present, status should be set from `http.status_code` and `http.status_message` if the `http.status_code` tag is found. HTTP status code should be mapped to the appropriate gRPC status code before using it in OC status. These tags should be preserved and added to the resultant OC span as attributes. |
| 27 | +3. If none of the tags are found, OC status should not be set. |
| 28 | + |
| 29 | + |
| 30 | +### Zipkin to OC |
| 31 | + |
| 32 | +In addition to the two sets of tags mentioned in the previous section, Zipkin spans can possibly contain a third set of tags to represent operation status resulting in the following sets of tags: |
| 33 | + |
| 34 | +- `census.status_code` and `census.status_description` |
| 35 | +- `status.code` and `status.message` |
| 36 | +- `http.status_code` and `http.status_message` |
| 37 | + |
| 38 | +When converting from Zipkin to OC, |
| 39 | + |
| 40 | +1. OC status should be set from `census.status_code` and `census.status_description` if `census.status_code` tag is found on the Zipkin span. These tags should be dropped from the resultant OC span. |
| 41 | +2. If the `census.status_code` tag is not found in step 1, OC status should be set from `status.code` and `status.message` tags if the `status.code` tag is present. The tags should be dropped from the resultant OC span. |
| 42 | +3. If no tags are found in step 1 and 2, OC status should be set from `http.status_code` and `http.status_message` if either `http.status_code` tag is found. These tags should be preserved and added to the resultant OC span as attributes. |
| 43 | +4. If none of the tags are found, OC status should not be set. |
| 44 | + |
| 45 | + |
| 46 | +Note that codes and messages from different sets of tags should not be mixed to form the status field. For example, OC status should not contain code from `http.status_code` but message from `status.message` and vice-versa. Both fields must be set from the same set of tags even if it means leaving one of the two fields empty. |
| 47 | + |
| 48 | + |
| 49 | +### OC to Jaeger |
| 50 | + |
| 51 | +When converting from OC to Jaeger, if the OC span has a status field set, then |
| 52 | + |
| 53 | +* `code` should be added as a `status.code` tag. |
| 54 | +* `message` should be added as a `status.message` tag. |
| 55 | + |
| 56 | +### OC to Zipkin |
| 57 | + |
| 58 | +When converting from OC to Zipkin, if the OC span has the status field set, then |
| 59 | + |
| 60 | +* `code` should be added as a `census.status_code` tag. |
| 61 | +* `message` should be added as a `census.status_description` tag. |
| 62 | + |
| 63 | +In addition to this, if the OC status field represents a non-OK status, then a tag with the key `error` should be added and set to the same value as that of the status message falling back to status code when status message is not available. |
| 64 | + |
| 65 | +### Note: |
| 66 | + |
| 67 | +If either target tags (`status.*` or `census.status_*`) are already present on the span, then they should be preserved and not overwritten from the status field. This is extremely unlikely to happen within the collector because of how things are implemented but any other implementations should still follow this rule. |
| 68 | + |
| 69 | + |
| 70 | +## Converting HTTP status codes to OC codes |
| 71 | + |
| 72 | +The following guidelines should be followed for translating HTTP status codes to OC ones. https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto |
| 73 | + |
| 74 | +This is implemented by the `tracetranslator` package as `HTTPToOCCodeMapper`. |
0 commit comments