opencensus-jaeger 0.2.1

data/thrift/gen-rb/zipkin/zipkincore_types.rb

@@ -0,0 +1,223 @@
+#
+# Autogenerated by Thrift Compiler (0.11.0)
+#
+# DO NOT EDIT UNLESS YOU ARE SURE THAT YOU KNOW WHAT YOU ARE DOING
+#
+
+require 'thrift'
+
+module Zipkin
+  module AnnotationType
+    BOOL = 0
+    BYTES = 1
+    I16 = 2
+    I32 = 3
+    I64 = 4
+    DOUBLE = 5
+    STRING = 6
+    VALUE_MAP = {0 => "BOOL", 1 => "BYTES", 2 => "I16", 3 => "I32", 4 => "I64", 5 => "DOUBLE", 6 => "STRING"}
+    VALID_VALUES = Set.new([BOOL, BYTES, I16, I32, I64, DOUBLE, STRING]).freeze
+  end
+
+  # Indicates the network context of a service recording an annotation with two
+# exceptions.
+# 
+# When a BinaryAnnotation, and key is CLIENT_ADDR or SERVER_ADDR,
+# the endpoint indicates the source or destination of an RPC. This exception
+# allows zipkin to display network context of uninstrumented services, or
+# clients such as web browsers.
+  class Endpoint
+    include ::Thrift::Struct, ::Thrift::Struct_Union
+    IPV4 = 1
+    PORT = 2
+    SERVICE_NAME = 3
+    IPV6 = 4
+
+    FIELDS = {
+      # IPv4 host address packed into 4 bytes.
+# 
+# Ex for the ip 1.2.3.4, it would be (1 << 24) | (2 << 16) | (3 << 8) | 4
+      IPV4 => {:type => ::Thrift::Types::I32, :name => 'ipv4'},
+      # IPv4 port
+# 
+# Note: this is to be treated as an unsigned integer, so watch for negatives.
+# 
+# Conventionally, when the port isn't known, port = 0.
+      PORT => {:type => ::Thrift::Types::I16, :name => 'port'},
+      # Service name in lowercase, such as "memcache" or "zipkin-web"
+# 
+# Conventionally, when the service name isn't known, service_name = "unknown".
+      SERVICE_NAME => {:type => ::Thrift::Types::STRING, :name => 'service_name'},
+      # IPv6 host address packed into 16 bytes. Ex Inet6Address.getBytes()
+      IPV6 => {:type => ::Thrift::Types::STRING, :name => 'ipv6', :binary => true, :optional => true}
+    }
+
+    def struct_fields; FIELDS; end
+
+    def validate
+    end
+
+    ::Thrift::Struct.generate_accessors self
+  end
+
+  # An annotation is similar to a log statement. It includes a host field which
+# allows these events to be attributed properly, and also aggregatable.
+  class Annotation
+    include ::Thrift::Struct, ::Thrift::Struct_Union
+    TIMESTAMP = 1
+    VALUE = 2
+    HOST = 3
+
+    FIELDS = {
+      # Microseconds from epoch.
+# 
+# This value should use the most precise value possible. For example,
+# gettimeofday or syncing nanoTime against a tick of currentTimeMillis.
+      TIMESTAMP => {:type => ::Thrift::Types::I64, :name => 'timestamp'},
+      VALUE => {:type => ::Thrift::Types::STRING, :name => 'value'},
+      # Always the host that recorded the event. By specifying the host you allow
+# rollup of all events (such as client requests to a service) by IP address.
+      HOST => {:type => ::Thrift::Types::STRUCT, :name => 'host', :class => ::Zipkin::Endpoint, :optional => true}
+    }
+
+    def struct_fields; FIELDS; end
+
+    def validate
+    end
+
+    ::Thrift::Struct.generate_accessors self
+  end
+
+  # Binary annotations are tags applied to a Span to give it context. For
+# example, a binary annotation of "http.uri" could the path to a resource in a
+# RPC call.
+# 
+# Binary annotations of type STRING are always queryable, though more a
+# historical implementation detail than a structural concern.
+# 
+# Binary annotations can repeat, and vary on the host. Similar to Annotation,
+# the host indicates who logged the event. This allows you to tell the
+# difference between the client and server side of the same key. For example,
+# the key "http.uri" might be different on the client and server side due to
+# rewriting, like "/api/v1/myresource" vs "/myresource. Via the host field,
+# you can see the different points of view, which often help in debugging.
+  class BinaryAnnotation
+    include ::Thrift::Struct, ::Thrift::Struct_Union
+    KEY = 1
+    VALUE = 2
+    ANNOTATION_TYPE = 3
+    HOST = 4
+
+    FIELDS = {
+      KEY => {:type => ::Thrift::Types::STRING, :name => 'key'},
+      VALUE => {:type => ::Thrift::Types::STRING, :name => 'value', :binary => true},
+      ANNOTATION_TYPE => {:type => ::Thrift::Types::I32, :name => 'annotation_type', :enum_class => ::Zipkin::AnnotationType},
+      # The host that recorded tag, which allows you to differentiate between
+# multiple tags with the same key. There are two exceptions to this.
+# 
+# When the key is CLIENT_ADDR or SERVER_ADDR, host indicates the source or
+# destination of an RPC. This exception allows zipkin to display network
+# context of uninstrumented services, or clients such as web browsers.
+      HOST => {:type => ::Thrift::Types::STRUCT, :name => 'host', :class => ::Zipkin::Endpoint, :optional => true}
+    }
+
+    def struct_fields; FIELDS; end
+
+    def validate
+      unless @annotation_type.nil? || ::Zipkin::AnnotationType::VALID_VALUES.include?(@annotation_type)
+        raise ::Thrift::ProtocolException.new(::Thrift::ProtocolException::UNKNOWN, 'Invalid value of field annotation_type!')
+      end
+    end
+
+    ::Thrift::Struct.generate_accessors self
+  end
+
+  # A trace is a series of spans (often RPC calls) which form a latency tree.
+# 
+# The root span is where trace_id = id and parent_id = Nil. The root span is
+# usually the longest interval in the trace, starting with a SERVER_RECV
+# annotation and ending with a SERVER_SEND.
+  class Span
+    include ::Thrift::Struct, ::Thrift::Struct_Union
+    TRACE_ID = 1
+    NAME = 3
+    ID = 4
+    PARENT_ID = 5
+    ANNOTATIONS = 6
+    BINARY_ANNOTATIONS = 8
+    DEBUG = 9
+    TIMESTAMP = 10
+    DURATION = 11
+    TRACE_ID_HIGH = 12
+
+    FIELDS = {
+      TRACE_ID => {:type => ::Thrift::Types::I64, :name => 'trace_id'},
+      # Span name in lowercase, rpc method for example
+# 
+# Conventionally, when the span name isn't known, name = "unknown".
+      NAME => {:type => ::Thrift::Types::STRING, :name => 'name'},
+      ID => {:type => ::Thrift::Types::I64, :name => 'id'},
+      PARENT_ID => {:type => ::Thrift::Types::I64, :name => 'parent_id', :optional => true},
+      ANNOTATIONS => {:type => ::Thrift::Types::LIST, :name => 'annotations', :element => {:type => ::Thrift::Types::STRUCT, :class => ::Zipkin::Annotation}},
+      BINARY_ANNOTATIONS => {:type => ::Thrift::Types::LIST, :name => 'binary_annotations', :element => {:type => ::Thrift::Types::STRUCT, :class => ::Zipkin::BinaryAnnotation}},
+      DEBUG => {:type => ::Thrift::Types::BOOL, :name => 'debug', :default => false, :optional => true},
+      # Microseconds from epoch of the creation of this span.
+# 
+# This value should be set directly by instrumentation, using the most
+# precise value possible. For example, gettimeofday or syncing nanoTime
+# against a tick of currentTimeMillis.
+# 
+# For compatibilty with instrumentation that precede this field, collectors
+# or span stores can derive this via Annotation.timestamp.
+# For example, SERVER_RECV.timestamp or CLIENT_SEND.timestamp.
+# 
+# This field is optional for compatibility with old data: first-party span
+# stores are expected to support this at time of introduction.
+      TIMESTAMP => {:type => ::Thrift::Types::I64, :name => 'timestamp', :optional => true},
+      # Measurement of duration in microseconds, used to support queries.
+# 
+# This value should be set directly, where possible. Doing so encourages
+# precise measurement decoupled from problems of clocks, such as skew or NTP
+# updates causing time to move backwards.
+# 
+# For compatibilty with instrumentation that precede this field, collectors
+# or span stores can derive this by subtracting Annotation.timestamp.
+# For example, SERVER_SEND.timestamp - SERVER_RECV.timestamp.
+# 
+# If this field is persisted as unset, zipkin will continue to work, except
+# duration query support will be implementation-specific. Similarly, setting
+# this field non-atomically is implementation-specific.
+# 
+# This field is i64 vs i32 to support spans longer than 35 minutes.
+      DURATION => {:type => ::Thrift::Types::I64, :name => 'duration', :optional => true},
+      # Optional unique 8-byte additional identifier for a trace. If non zero, this
+# means the trace uses 128 bit traceIds instead of 64 bit.
+      TRACE_ID_HIGH => {:type => ::Thrift::Types::I64, :name => 'trace_id_high', :optional => true}
+    }
+
+    def struct_fields; FIELDS; end
+
+    def validate
+    end
+
+    ::Thrift::Struct.generate_accessors self
+  end
+
+  class Response
+    include ::Thrift::Struct, ::Thrift::Struct_Union
+    OK = 1
+
+    FIELDS = {
+      OK => {:type => ::Thrift::Types::BOOL, :name => 'ok'}
+    }
+
+    def struct_fields; FIELDS; end
+
+    def validate
+      raise ::Thrift::ProtocolException.new(::Thrift::ProtocolException::UNKNOWN, 'Required field ok is unset!') if @ok.nil?
+    end
+
+    ::Thrift::Struct.generate_accessors self
+  end
+
+end

data/thrift/jaeger.thrift

@@ -0,0 +1,86 @@
+# Copyright (c) 2016 Uber Technologies, Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+namespace cpp jaegertracing.thrift
+namespace java io.jaegertracing.thriftjava
+namespace php Jaeger.Thrift
+namespace netcore Jaeger.Thrift
+namespace rb Jaeger.Thrift
+
+# TagType denotes the type of a Tag's value.
+enum TagType { STRING, DOUBLE, BOOL, LONG, BINARY }
+
+# Tag is a basic strongly typed key/value pair. It has been flattened to reduce the use of pointers in golang
+struct Tag {
+  1: required string  key
+  2: required TagType vType
+  3: optional string  vStr
+  4: optional double  vDouble
+  5: optional bool    vBool
+  6: optional i64     vLong
+  7: optional binary  vBinary
+}
+
+# Log is a timed even with an arbitrary set of tags.
+struct Log {
+  1: required i64       timestamp
+  2: required list<Tag> fields
+}
+
+enum SpanRefType { CHILD_OF, FOLLOWS_FROM }
+
+# SpanRef describes causal relationship of the current span to another span (e.g. 'child-of')
+struct SpanRef {
+  1: required SpanRefType refType
+  2: required i64         traceIdLow
+  3: required i64         traceIdHigh
+  4: required i64         spanId
+}
+
+# Span represents a named unit of work performed by a service.
+struct Span {
+  1:  required i64           traceIdLow   # the least significant 64 bits of a traceID
+  2:  required i64           traceIdHigh  # the most significant 64 bits of a traceID; 0 when only 64bit IDs are used
+  3:  required i64           spanId       # unique span id (only unique within a given trace)
+  4:  required i64           parentSpanId # since nearly all spans will have parents spans, CHILD_OF refs do not have to be explicit
+  5:  required string        operationName
+  6:  optional list<SpanRef> references   # causal references to other spans
+  7:  required i32           flags        # a bit field used to propagate sampling decisions. 1 signifies a SAMPLED span, 2 signifies a DEBUG span.
+  8:  required i64           startTime
+  9:  required i64           duration
+  10: optional list<Tag>     tags
+  11: optional list<Log>     logs
+  12: optional bool          incomplete   # indicates whether this is the final span or an intermediate (incomplete) span
+}
+
+# Process describes the traced process/service that emits spans.
+struct Process {
+  1: required string    serviceName
+  2: optional list<Tag> tags
+}
+
+# Batch is a collection of spans reported out of process.
+struct Batch {
+  1: required Process    process
+  2: required list<Span> spans
+}
+
+# BatchSubmitResponse is the response on submitting a batch.
+struct BatchSubmitResponse {
+    1: required bool ok   # The Collector's client is expected to only log (or emit a counter) when not ok equals false
+}
+
+service Collector  {
+    list<BatchSubmitResponse> submitBatches(1: list<Batch> batches)
+}

data/thrift/zipkincore.thrift

@@ -0,0 +1,345 @@
+# Copyright 2012 Twitter Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#      http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+namespace cpp twitter.zipkin.thrift
+namespace java com.twitter.zipkin.thriftjava
+#@namespace scala com.twitter.zipkin.thriftscala
+namespace rb Zipkin
+namespace php Jaeger.Thrift.Agent.Zipkin
+namespace netcore Jaeger.Thrift.Agent.Zipkin
+namespace netcore Jaeger.Thrift.Agent.Zipkin
+
+#************** Annotation.value **************
+/**
+ * The client sent ("cs") a request to a server. There is only one send per
+ * span. For example, if there's a transport error, each attempt can be logged
+ * as a WIRE_SEND annotation.
+ *
+ * If chunking is involved, each chunk could be logged as a separate
+ * CLIENT_SEND_FRAGMENT in the same span.
+ *
+ * Annotation.host is not the server. It is the host which logged the send
+ * event, almost always the client. When logging CLIENT_SEND, instrumentation
+ * should also log the SERVER_ADDR.
+ */
+const string CLIENT_SEND = "cs"
+/**
+ * The client received ("cr") a response from a server. There is only one
+ * receive per span. For example, if duplicate responses were received, each
+ * can be logged as a WIRE_RECV annotation.
+ *
+ * If chunking is involved, each chunk could be logged as a separate
+ * CLIENT_RECV_FRAGMENT in the same span.
+ *
+ * Annotation.host is not the server. It is the host which logged the receive
+ * event, almost always the client. The actual endpoint of the server is
+ * recorded separately as SERVER_ADDR when CLIENT_SEND is logged.
+ */
+const string CLIENT_RECV = "cr"
+/**
+ * The server sent ("ss") a response to a client. There is only one response
+ * per span. If there's a transport error, each attempt can be logged as a
+ * WIRE_SEND annotation.
+ *
+ * Typically, a trace ends with a server send, so the last timestamp of a trace
+ * is often the timestamp of the root span's server send.
+ *
+ * If chunking is involved, each chunk could be logged as a separate
+ * SERVER_SEND_FRAGMENT in the same span.
+ *
+ * Annotation.host is not the client. It is the host which logged the send
+ * event, almost always the server. The actual endpoint of the client is
+ * recorded separately as CLIENT_ADDR when SERVER_RECV is logged.
+ */
+const string SERVER_SEND = "ss"
+/**
+ * The server received ("sr") a request from a client. There is only one
+ * request per span.  For example, if duplicate responses were received, each
+ * can be logged as a WIRE_RECV annotation.
+ *
+ * Typically, a trace starts with a server receive, so the first timestamp of a
+ * trace is often the timestamp of the root span's server receive.
+ *
+ * If chunking is involved, each chunk could be logged as a separate
+ * SERVER_RECV_FRAGMENT in the same span.
+ *
+ * Annotation.host is not the client. It is the host which logged the receive
+ * event, almost always the server. When logging SERVER_RECV, instrumentation
+ * should also log the CLIENT_ADDR.
+ */
+const string SERVER_RECV = "sr"
+/**
+ * Message send ("ms") is a request to send a message to a destination, usually
+ * a broker. This may be the only annotation in a messaging span. If WIRE_SEND
+ * exists in the same span, it follows this moment and clarifies delays sending
+ * the message, such as batching.
+ *
+ * Unlike RPC annotations like CLIENT_SEND, messaging spans never share a span
+ * ID. For example, "ms" should always be the parent of "mr".
+ *
+ * Annotation.host is not the destination, it is the host which logged the send
+ * event: the producer. When annotating MESSAGE_SEND, instrumentation should
+ * also tag the MESSAGE_ADDR.
+ */
+const string MESSAGE_SEND = "ms"
+/**
+ * A consumer received ("mr") a message from a broker. This may be the only
+ * annotation in a messaging span. If WIRE_RECV exists in the same span, it
+ * precedes this moment and clarifies any local queuing delay.
+ *
+ * Unlike RPC annotations like SERVER_RECV, messaging spans never share a span
+ * ID. For example, "mr" should always be a child of "ms" unless it is a root
+ * span.
+ *
+ * Annotation.host is not the broker, it is the host which logged the receive
+ * event: the consumer.  When annotating MESSAGE_RECV, instrumentation should
+ * also tag the MESSAGE_ADDR.
+ */
+const string MESSAGE_RECV = "mr"
+/**
+ * Optionally logs an attempt to send a message on the wire. Multiple wire send
+ * events could indicate network retries. A lag between client or server send
+ * and wire send might indicate queuing or processing delay.
+ */
+const string WIRE_SEND = "ws"
+/**
+ * Optionally logs an attempt to receive a message from the wire. Multiple wire
+ * receive events could indicate network retries. A lag between wire receive
+ * and client or server receive might indicate queuing or processing delay.
+ */
+const string WIRE_RECV = "wr"
+/**
+ * Optionally logs progress of a (CLIENT_SEND, WIRE_SEND). For example, this
+ * could be one chunk in a chunked request.
+ */
+const string CLIENT_SEND_FRAGMENT = "csf"
+/**
+ * Optionally logs progress of a (CLIENT_RECV, WIRE_RECV). For example, this
+ * could be one chunk in a chunked response.
+ */
+const string CLIENT_RECV_FRAGMENT = "crf"
+/**
+ * Optionally logs progress of a (SERVER_SEND, WIRE_SEND). For example, this
+ * could be one chunk in a chunked response.
+ */
+const string SERVER_SEND_FRAGMENT = "ssf"
+/**
+ * Optionally logs progress of a (SERVER_RECV, WIRE_RECV). For example, this
+ * could be one chunk in a chunked request.
+ */
+const string SERVER_RECV_FRAGMENT = "srf"
+
+#***** BinaryAnnotation.key ******
+/**
+ * The value of "lc" is the component or namespace of a local span.
+ *
+ * BinaryAnnotation.host adds service context needed to support queries.
+ *
+ * Local Component("lc") supports three key features: flagging, query by
+ * service and filtering Span.name by namespace.
+ *
+ * While structurally the same, local spans are fundamentally different than
+ * RPC spans in how they should be interpreted. For example, zipkin v1 tools
+ * center on RPC latency and service graphs. Root local-spans are neither
+ * indicative of critical path RPC latency, nor have impact on the shape of a
+ * service graph. By flagging with "lc", tools can special-case local spans.
+ *
+ * Zipkin v1 Spans are unqueryable unless they can be indexed by service name.
+ * The only path to a service name is by (Binary)?Annotation.host.serviceName.
+ * By logging "lc", a local span can be queried even if no other annotations
+ * are logged.
+ *
+ * The value of "lc" is the namespace of Span.name. For example, it might be
+ * "finatra2", for a span named "bootstrap". "lc" allows you to resolves
+ * conflicts for the same Span.name, for example "finatra/bootstrap" vs
+ * "finch/bootstrap". Using local component, you'd search for spans named
+ * "bootstrap" where "lc=finch"
+ */
+const string LOCAL_COMPONENT = "lc"
+
+#***** BinaryAnnotation.key where value = [1] and annotation_type = BOOL ******
+/**
+ * Indicates a client address ("ca") in a span. Most likely, there's only one.
+ * Multiple addresses are possible when a client changes its ip or port within
+ * a span.
+ */
+const string CLIENT_ADDR = "ca"
+/**
+ * Indicates a server address ("sa") in a span. Most likely, there's only one.
+ * Multiple addresses are possible when a client is redirected, or fails to a
+ * different server ip or port.
+ */
+const string SERVER_ADDR = "sa"
+/**
+ * Indicates the remote address of a messaging span, usually the broker.
+ */
+const string MESSAGE_ADDR = "ma"
+
+/**
+ * Indicates the network context of a service recording an annotation with two
+ * exceptions.
+ *
+ * When a BinaryAnnotation, and key is CLIENT_ADDR or SERVER_ADDR,
+ * the endpoint indicates the source or destination of an RPC. This exception
+ * allows zipkin to display network context of uninstrumented services, or
+ * clients such as web browsers.
+ */
+struct Endpoint {
+  /**
+   * IPv4 host address packed into 4 bytes.
+   *
+   * Ex for the ip 1.2.3.4, it would be (1 << 24) | (2 << 16) | (3 << 8) | 4
+   */
+  1: i32 ipv4
+  /**
+   * IPv4 port
+   *
+   * Note: this is to be treated as an unsigned integer, so watch for negatives.
+   *
+   * Conventionally, when the port isn't known, port = 0.
+   */
+  2: i16 port
+  /**
+   * Service name in lowercase, such as "memcache" or "zipkin-web"
+   *
+   * Conventionally, when the service name isn't known, service_name = "unknown".
+   */
+  3: string service_name
+  /**
+   * IPv6 host address packed into 16 bytes. Ex Inet6Address.getBytes()
+   */
+  4: optional binary ipv6
+}
+
+/**
+ * An annotation is similar to a log statement. It includes a host field which
+ * allows these events to be attributed properly, and also aggregatable.
+ */
+struct Annotation {
+  /**
+   * Microseconds from epoch.
+   *
+   * This value should use the most precise value possible. For example,
+   * gettimeofday or syncing nanoTime against a tick of currentTimeMillis.
+   */
+  1: i64 timestamp
+  2: string value                  // what happened at the timestamp?
+  /**
+   * Always the host that recorded the event. By specifying the host you allow
+   * rollup of all events (such as client requests to a service) by IP address.
+   */
+  3: optional Endpoint host
+  // don't reuse 4: optional i32 OBSOLETE_duration         // how long did the operation take? microseconds
+}
+
+enum AnnotationType { BOOL, BYTES, I16, I32, I64, DOUBLE, STRING }
+
+/**
+ * Binary annotations are tags applied to a Span to give it context. For
+ * example, a binary annotation of "http.uri" could the path to a resource in a
+ * RPC call.
+ *
+ * Binary annotations of type STRING are always queryable, though more a
+ * historical implementation detail than a structural concern.
+ *
+ * Binary annotations can repeat, and vary on the host. Similar to Annotation,
+ * the host indicates who logged the event. This allows you to tell the
+ * difference between the client and server side of the same key. For example,
+ * the key "http.uri" might be different on the client and server side due to
+ * rewriting, like "/api/v1/myresource" vs "/myresource. Via the host field,
+ * you can see the different points of view, which often help in debugging.
+ */
+struct BinaryAnnotation {
+  1: string key,
+  2: binary value,
+  3: AnnotationType annotation_type,
+  /**
+   * The host that recorded tag, which allows you to differentiate between
+   * multiple tags with the same key. There are two exceptions to this.
+   *
+   * When the key is CLIENT_ADDR or SERVER_ADDR, host indicates the source or
+   * destination of an RPC. This exception allows zipkin to display network
+   * context of uninstrumented services, or clients such as web browsers.
+   */
+  4: optional Endpoint host
+}
+
+/**
+ * A trace is a series of spans (often RPC calls) which form a latency tree.
+ *
+ * The root span is where trace_id = id and parent_id = Nil. The root span is
+ * usually the longest interval in the trace, starting with a SERVER_RECV
+ * annotation and ending with a SERVER_SEND.
+ */
+struct Span {
+  1: i64 trace_id                  # unique trace id, use for all spans in trace
+  /**
+   * Span name in lowercase, rpc method for example
+   *
+   * Conventionally, when the span name isn't known, name = "unknown".
+   */
+  3: string name,
+  4: i64 id,                       # unique span id, only used for this span
+  5: optional i64 parent_id,       # parent span id
+  6: list<Annotation> annotations, # all annotations/events that occured, sorted by timestamp
+  8: list<BinaryAnnotation> binary_annotations # any binary annotations
+  9: optional bool debug = 0       # if true, we DEMAND that this span passes all samplers
+  /**
+   * Microseconds from epoch of the creation of this span.
+   *
+   * This value should be set directly by instrumentation, using the most
+   * precise value possible. For example, gettimeofday or syncing nanoTime
+   * against a tick of currentTimeMillis.
+   *
+   * For compatibilty with instrumentation that precede this field, collectors
+   * or span stores can derive this via Annotation.timestamp.
+   * For example, SERVER_RECV.timestamp or CLIENT_SEND.timestamp.
+   *
+   * This field is optional for compatibility with old data: first-party span
+   * stores are expected to support this at time of introduction.
+   */
+  10: optional i64 timestamp,
+  /**
+   * Measurement of duration in microseconds, used to support queries.
+   *
+   * This value should be set directly, where possible. Doing so encourages
+   * precise measurement decoupled from problems of clocks, such as skew or NTP
+   * updates causing time to move backwards.
+   *
+   * For compatibilty with instrumentation that precede this field, collectors
+   * or span stores can derive this by subtracting Annotation.timestamp.
+   * For example, SERVER_SEND.timestamp - SERVER_RECV.timestamp.
+   *
+   * If this field is persisted as unset, zipkin will continue to work, except
+   * duration query support will be implementation-specific. Similarly, setting
+   * this field non-atomically is implementation-specific.
+   *
+   * This field is i64 vs i32 to support spans longer than 35 minutes.
+   */
+  11: optional i64 duration
+  /**
+   * Optional unique 8-byte additional identifier for a trace. If non zero, this
+   * means the trace uses 128 bit traceIds instead of 64 bit.
+   */
+  12: optional i64 trace_id_high
+}
+
+# define TChannel service
+
+struct Response {
+    1: required bool ok
+}
+
+service ZipkinCollector {
+    list<Response> submitZipkinBatch(1: list<Span> spans)
+}