1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
use crate::;
use Cow;
use Error;
use SystemTime;
/// The interface for a single operation within a trace.
///
/// Spans can be nested to form a trace tree. Each trace contains a root span,
/// which typically describes the entire operation and, optionally, one or more
/// sub-spans for its sub-operations.
///
/// The span `name` concisely identifies the work represented by the span, for
/// example, an RPC method name, a function name, or the name of a subtask or
/// stage within a larger computation. The span name should be the most general
/// string that identifies a (statistically) interesting class of spans, rather
/// than individual span instances while still being human-readable. That is,
/// `"get_user"` is a reasonable name, while `"get_user/314159"`, where `"314159"` is
/// a user ID, is not a good name due to its high cardinality. _Generality_
/// should be prioritized over _human-readability_.
///
/// For example, here are potential span names for an endpoint that gets a
/// hypothetical account information:
///
/// | Span Name | Guidance |
/// | ----------------- | ------------ |
/// | `get` | Too general |
/// | `get_account/42` | Too specific |
/// | `get_account` | Good, and account_id=42 would make a nice Span attribute |
/// | `get_account/{accountId}` | Also good (using the "HTTP route") |
///
/// The span's start and end timestamps reflect the elapsed real time of the
/// operation.
///
/// For example, if a span represents a request-response cycle (e.g. HTTP or an
/// RPC), the span should have a start time that corresponds to the start time
/// of the first sub-operation, and an end time of when the final sub-operation
/// is complete. This includes:
///
/// * receiving the data from the request
/// * parsing of the data (e.g. from a binary or json format)
/// * any middleware or additional processing logic
/// * business logic
/// * construction of the response
/// * sending of the response
///
/// Child spans (or in some cases events) may be created to represent
/// sub-operations which require more detailed observability. Child spans should
/// measure the timing of the respective sub-operation, and may add additional
/// attributes.
/// `SpanKind` describes the relationship between the [`Span`], its parents, and
/// its children in a trace.
///
/// `SpanKind` describes two independent properties that benefit tracing systems
/// during analysis:
///
/// The first property described by `SpanKind` reflects whether the span is a
/// "logical" remote child or parent. By "logical", we mean that the span is
/// logically a remote child or parent, from the point of view of the library
/// that is being instrumented. Spans with a remote parent are interesting
/// because they are sources of external load. Spans with a remote child are
/// interesting because they reflect a non-local system dependency.
///
/// The second property described by `SpanKind` reflects whether a child span
/// represents a synchronous call. When a child span is synchronous, the parent
/// is expected to wait for it to complete under ordinary circumstances. It can
/// be useful for tracing systems to know this property, since synchronous spans
/// may contribute to the overall trace latency. Asynchronous scenarios can be
/// remote or local.
///
/// In order for `SpanKind` to be meaningful, callers should arrange that a
/// single span does not serve more than one purpose. For example, a server-side
/// span should not be used directly as the parent of another remote span. As a
/// simple guideline, instrumentation should create a new span prior to
/// extracting and serializing the SpanContext for a remote call.
///
/// Note: there are complex scenarios where a `SpanKind::Client` span may have a
/// child that is also logically a `SpanKind::Client` span, or a
/// `SpanKind::Producer` span might have a local child that is a
/// `SpanKind::Client` span, depending on how the various libraries that are
/// providing the functionality are built and instrumented. These scenarios,
/// when they occur, should be detailed in the semantic conventions appropriate
/// to the relevant libraries.
///
/// To summarize the interpretation of these kinds:
///
/// | `SpanKind` | Synchronous | Asynchronous | Remote Incoming | Remote Outgoing |
/// |---|---|---|---|---|
/// | `Client` | yes | | | yes |
/// | `Server` | yes | | yes | |
/// | `Producer` | | yes | | maybe |
/// | `Consumer` | | yes | maybe | |
/// | `Internal` | | | | |
/// The status of a [`Span`].
///
/// These values form a total order: Ok > Error > Unset. This means that setting
/// `Status::Ok` will override any prior or future attempts to set a status with
/// `Status::Error` or `Status::Unset`.
///
/// The status should remain unset, except for the following circumstances:
///
/// Generally, instrumentation libraries should not set the code to
/// `Status::Ok`, unless explicitly configured to do so. Instrumentation
/// libraries should leave the status code as unset unless there is an error.
///
/// Application developers and operators may set the status code to
/// `Status::Ok`.
///
/// When span status is set to `Status::Ok` it should be considered final and
/// any further attempts to change it should be ignored.
///
/// Analysis tools should respond to a `Status::Ok` status by suppressing any
/// errors they would otherwise generate. For example, to suppress noisy errors
/// such as 404s.
///
/// Only the value of the last call will be recorded, and implementations are
/// free to ignore previous calls.