|
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