@@ -144,16 +144,14 @@ _automatically_ collected and exported to analysis tools with _no additional wor
144
144
### Setup
145
145
146
146
- For local setup, use the instructions here:
147
- < https://github.com/MaterializeInc/materialize/tree/main/misc/opentelemetry > to setup a local OpenTelemetry collector
148
- and ui to view traces.
149
- - TODO(guswynn): cloud honeycomb setup when its available
150
- - TODO(guswynn): link to demo video
147
+ < https://github.com/MaterializeInc/materialize/tree/main/misc/monitoring > to setup a local OpenTelemetry collector
148
+ (Tempo) and UI (Grafana) to view traces.
151
149
152
150
### Span visualization
153
151
154
- OpenTelemetry UI's like the [ Jaeger ] one in the local setup _ are extraordinarly powerful tools for debugging_ . They allow you to visualize
152
+ OpenTelemetry UI's like the Grafana/Tempo one in the local setup _ are extraordinarly powerful tools for debugging_ . They allow you to visualize
155
153
and inspect the exact control flow graph of your service, including the latency of each operation, and contextual recorded fields. See
156
- [ Best Pratices ] ( #best-practices ) for more information.
154
+ [ Best Practices ] ( #best-practices ) for more information.
157
155
158
156
### Distributed tracing
159
157
[ OpenTelemetry] allows us to associate ` tracing ` spans _ from distributed services_ with each other, allowing us to not only visualize
@@ -224,6 +222,52 @@ and `mz_ore::tracing::OpenTelemetryContext::attach_as_parent()` on the receiving
224
222
- ` TRACE ` :
225
223
- exceedingly verbose information intended only for local debugging/tracing
226
224
225
+ ## Accessing Tracing Data Locally
226
+
227
+ To setup trace collection locally, start the ` ../../misc/monitoring ` composition. It will spin up Tempo to
228
+ automatically start storing traces, and Grafana to visualize them.
229
+
230
+ Then start ` ./bin/environmentd --monitoring ` .
231
+
232
+ ### Setting the Trace Filter
233
+
234
+ By default, ` ./bin/environmentd ` will only emit ` INFO ` -level spans. The filter is controlled through the
235
+ ` opentelemetry_filter ` system variable and can be toggled dynamically:
236
+
237
+ ```
238
+ > psql -U mz_system -h localhost -p 6877
239
+
240
+ mz_system=> ALTER SYSTEM SET opentelemetry_filter="debug";
241
+ ```
242
+
243
+ Or on startup:
244
+
245
+ ```
246
+ ./bin/environmentd --reset --monitoring -- --system-parameter-default='opentelemetry_filter=debug'
247
+ ```
248
+
249
+ More details on [ the filter syntax] can be found in Notion.
250
+
251
+ ### Trace ID Notices
252
+
253
+ It's often valuable to see the traces associated with specific queries. This can be done
254
+ by setting the session variable:
255
+
256
+ ```
257
+ SET emit_trace_id_notice = true;
258
+ ```
259
+
260
+ Then each subsequent query will emit a NOTICE containing the trace ID for its execution:
261
+
262
+ ```
263
+ materialize=> SELECT 1;
264
+ NOTICE: trace id: 65e87c160063307a9d1221f78ae55cf8
265
+ ```
266
+
267
+ This trace ID can then be plugged into Grafana's TraceQL lookup for an exact match:
268
+
269
+ ![ grafana tempo trace id lookup] ( ./assets/grafana-tempo-trace-id-lookup.png )
270
+
227
271
228
272
229
273
@@ -240,6 +284,6 @@ and `mz_ore::tracing::OpenTelemetryContext::attach_as_parent()` on the receiving
240
284
[ many crates ] : https://docs.rs/tracing/latest/tracing/#related-crates
241
285
[ OpenTelemetry ] : https://opentelemetry.io/
242
286
[ here ] : https://docs.rs/tracing/latest/tracing/struct.Span.html#in-asynchronous-code
243
- [ Jaeger ] : https://www.jaegertracing.io/
244
287
[ `tracing::Span` ] : https://docs.rs/tracing/latest/tracing/struct.Span.html
245
288
[ the docs ] : https://dev.materialize.com/api/rust/mz_ore/tracing/struct.OpenTelemetryContext.html
289
+ [ the filter syntax ] : https://www.notion.so/materialize/Filtering-Logs-and-Traces-6e8fcce8f39e4b45b94ea2923cce05dc?pvs=4
0 commit comments