|
1 | 1 | ## Example
|
2 | 2 |
|
3 |
| -This example has a flask client and server and shows they can trace requests |
4 |
| -both within and between the two sites using the flask_opentracing extension and |
| 3 | +This example has a flask client and server and shows how to trace the requests |
| 4 | +to a webserver from a client using the flask_opentracing extension and |
5 | 5 | a concrete variant of an OpenTracing tracer. To run, make sure that you run pip
|
6 |
| -install for flask, opentracing, and lightstep (although you will not be able to |
7 |
| -view the lightstep traces unless you have an access token). |
| 6 | +install for flask, opentracing, jaeger_client. |
8 | 7 |
|
9 |
| -Open two terminals and navigate to this directory. Run the following commands in |
10 |
| -each terminal: |
| 8 | +### Set up Jaeger: |
11 | 9 |
|
12 |
| -First window: |
| 10 | +First, we'll have to download and run our Jaeger instance. It collects and displays |
| 11 | +traces in neat graphical format. |
13 | 12 |
|
14 |
| -``` |
15 |
| -> export FLASK_APP=server.py |
16 |
| -> flask run |
| 13 | +If you already have Docker installed, run this: |
| 14 | + |
| 15 | +``` |
| 16 | +docker run -d -e \ |
| 17 | + COLLECTOR_ZIPKIN_HTTP_PORT=9411 \ |
| 18 | + -p 5775:5775/udp \ |
| 19 | + -p 6831:6831/udp \ |
| 20 | + -p 6832:6832/udp \ |
| 21 | + -p 5778:5778 \ |
| 22 | + -p 16686:16686 \ |
| 23 | + -p 14268:14268 \ |
| 24 | + -p 9411:9411 \ |
| 25 | + jaegertracing/all-in-one:latest |
17 | 26 | ```
|
18 | 27 |
|
19 |
| -Second window: |
| 28 | +You should be able to see a web interface by browsing to http://localhost:16686/search |
20 | 29 |
|
21 |
| -``` |
22 |
| -> export FLASK_APP=client.py |
23 |
| -> flask run --port=0 |
| 30 | + |
| 31 | + |
| 32 | +Now, open two terminals and navigate to this directory. Run the following commands in |
| 33 | +each terminal: |
| 34 | + |
| 35 | +First window: |
| 36 | + |
| 37 | +``` |
| 38 | +> python3 server.py |
24 | 39 | ```
|
25 | 40 |
|
26 |
| -To test the traces, check what port the client is running on and load |
27 |
| -localhost:port. If you have a lightstep tracer token, you |
28 |
| -should be able to view the trace data on the lightstep interface. |
29 |
| -(NOTE: if you wish to use a different OpenTracing tracer, simply replace |
30 |
| -`ls_tracer` with the OpenTracing tracer instance of your choice.) |
| 41 | +Give it few seconds to start and run this in second window: |
31 | 42 |
|
32 |
| -### Trace a request: |
| 43 | +``` |
| 44 | +> python3 client.py |
| 45 | +``` |
33 | 46 |
|
34 |
| -Navigate to `/request/simple/<int:numrequests>` where numrequests is the number |
35 |
| -of requests you want to send to the page. This will send a request to the server |
36 |
| -app, and the trace will include a span on both the client and server sides. This |
37 |
| -occurs automatically since both the client and server functions are decorated |
38 |
| -with @tracer.trace(). |
| 47 | +To see the traced requests, go to Jaeger web interface. |
| 48 | +Select your service name from dropdown on the left (it's |
| 49 | +"jaeger_opentracing_example" in our case) and press Find traces button at the bottom of the page. |
39 | 50 |
|
40 |
| -Result for `/request/simple/1`: |
41 | 51 |
|
42 |
| - |
| 52 | + |
43 | 53 |
|
44 |
| -### Log something to a request: |
45 | 54 |
|
46 |
| -Navigate to `/log`. This will log a message to the server-side span. The client |
47 |
| -span is created automatically through the @tracer.trace() decorator, while the |
48 |
| -logging occurs within the function by accessing the current span as follows: |
| 55 | +(NOTE: if you wish to use a different OpenTracing tracer instead of Jaeger, simply replace |
| 56 | +`jaeger_tracer` with the OpenTracing tracer instance of your choice.) |
49 | 57 |
|
50 |
| -```python |
51 |
| -span = tracer.get_span() |
52 |
| -span.log_event("hello world") |
53 |
| -``` |
54 |
| -Result for `/log`: |
| 58 | +### Trace a request from browser: |
55 | 59 |
|
56 |
| - |
| 60 | +Browse to http://localhost:5000/log and compare the trace in Jaeger. |
| 61 | +The last one has 2 spans instead of 3. The span of webserver's GET method is missing. |
| 62 | +That is because in client.py we pass already existing span over the wire, whereas the request from your browser has to tracing data in it. |
57 | 63 |
|
58 | 64 | ### Add spans to the trace manually:
|
59 | 65 |
|
60 |
| -Navigate to `/request/childspan/<int:numrequests>`. This will send a request to |
61 |
| -the server app, and the trace will include a span on both the client and server |
62 |
| -sides. The server app will additionally create a child span for the server-side |
63 |
| -span. This example demonstrates how you can trace non-RPC function calls in your |
64 |
| -app, through accessing the current span as follows: |
| 66 | +In log function of the server app, we are creating current_span. This is done to |
| 67 | +trace the work that is being done to render the response to /log. Suppose there's |
| 68 | +a database connection happening. By creating a separate span for it, you'll be able |
| 69 | +to trace the DB request separately from rendering or the response. This gives a |
| 70 | +lot of flexibility to the user. |
| 71 | + |
| 72 | +Following code shows how to create a span based on already existing one. |
65 | 73 |
|
66 | 74 | ```python
|
67 | 75 | parent_span = tracer.get_span()
|
68 |
| -child_span = ls_tracer.start_span("inside create_child_span", parent_span) |
| 76 | +child_span = jaeger_tracer.start_span("inside create_child_span", parent_span) |
69 | 77 | ... do some stuff
|
70 |
| -child_span.finish() |
| 78 | +child_span.finish() |
71 | 79 | ```
|
72 |
| -Result for `/request/childspan/2`: |
73 | 80 |
|
74 |
| - |
| 81 | + |
0 commit comments