|
| 1 | +# 🚀 **Module 5: Using Red Hat build of OpenTelemetry** |
| 2 | + |
| 3 | +**Technology Stack:** |
| 4 | + |
| 5 | +- Python |
| 6 | +- OpenTelemetry |
| 7 | + |
| 8 | +--- |
| 9 | + |
| 10 | +## 🎯 **Scenario** |
| 11 | + |
| 12 | +We will explore the Kubernetes Sidecar design pattern which deploys an agent sidecar container within an application pod that sends traces to a centralized Grafana Tempo. The application will send tracing data to a collector agent (sidecar) that offloads responsibility by sending the data to a storage backend, in our case, the central Grafana Tempo instance. |
| 13 | + |
| 14 | +Instrumentation is the process of adding observability code to an application. Auto instrumentation creates this tracing framework without significant code changes by automatically injecting and configuring auto-instrumentation libraries in a variety of supported languages. Auto instrumentation of .NET sends data on port 4318 via the OTLP/HTTP protocol. |
| 15 | + |
| 16 | +Inside your workspace is a Python Application that listens at `/api/check` for web requests and returns an HTTP 200 or 500 status code based on the payload. |
| 17 | + |
| 18 | +From the Terminal, deploy the Python Application in your project using: |
| 19 | + |
| 20 | + ```sh |
| 21 | + oc new-build --binary --name workshop-<your username> |
| 22 | + oc start-build workshop-<your username> --from-dir=. |
| 23 | + oc new-app workshop-<your username> --name workshop-<your username> |
| 24 | + ``` |
| 25 | + |
| 26 | +**NOTE: Please keep your application name unique from others in the workshop, otherwise you won’t be able to find your web requests in Jaeger UI.** |
| 27 | + |
| 28 | +--- |
| 29 | + |
| 30 | +## 🐾 **Guided Walkthrough** |
| 31 | + |
| 32 | +1. Deploy the sidecar with the OpenTelemetryCollector sidecar manifest: |
| 33 | + |
| 34 | + ```sh |
| 35 | + oc apply -f manifests/sidecar.yaml |
| 36 | + ``` |
| 37 | + |
| 38 | +2. Create an Instrumentation manifest in the project that will be used by the OpenTelemetry operator: |
| 39 | + |
| 40 | + ```sh |
| 41 | + oc apply -f manifests/instrumentation.yaml |
| 42 | + ``` |
| 43 | + |
| 44 | +3. Configure your deployment with annotations for .NET auto instrumentation: |
| 45 | + |
| 46 | + ```sh |
| 47 | + oc edit deployment workshop-<your username> |
| 48 | + |
| 49 | + spec: |
| 50 | + template: |
| 51 | + metadata: |
| 52 | + annotations: |
| 53 | + .. |
| 54 | + instrumentation.opentelemetry.io/inject-python: "true" |
| 55 | + sidecar.opentelemetry.io/inject: sidecar |
| 56 | + ``` |
| 57 | + |
| 58 | +--- |
| 59 | + |
| 60 | +## 🧩 **Challenge** |
| 61 | + |
| 62 | +- [ ] There is a cronjob at `curl-cron/cronjob.yaml` that will poll the application at service port 5000 every minute. |
| 63 | + - Modify the environment variable `ENDPOINT` to match the service name `workshop-<your username>` and deploy it with `oc apply -f curl-cron/cronjob.yaml` |
| 64 | +- [ ] A centralized Grafana Tempo instance has been deployed for the workshop. In OpenShift web console, navigate to the Applications Menu -> Jaeger UI to view the web requests. |
| 65 | +- [ ] The cronjob polling the application returns an HTTP 500. Fix the application so that it returns HTTP 200. |
| 66 | +- [ ] (Optional) To generate additional web traffic, without waiting 1 minute for the cronjob to kickoff, we have provided a shell script that will randomly generate 20 HTTP POST requests to your service. To run this in the terminal of your Dev Space, run the following: |
| 67 | + |
| 68 | + ```sh |
| 69 | + sh traffic-generator.sh workshop-<your username>:5000 |
| 70 | + ``` |
| 71 | + |
| 72 | +- [ ] You can create a new build of the application with the following command: |
| 73 | + |
| 74 | + ```sh |
| 75 | + oc start-build workshop-<your username> --from-dir=. |
| 76 | + ``` |
| 77 | + |
| 78 | +--- |
| 79 | + |
| 80 | +## 🥚 **Easter Eggs!** |
| 81 | + |
| 82 | +- [ ] There is an easter egg in Jaeger |
| 83 | + |
| 84 | +--- |
| 85 | + |
| 86 | +## ✅ **Key Takeaways** |
| 87 | + |
| 88 | +- Explored Kubernetes Sidecar design pattern |
| 89 | +- Auto-instrumented application to collect tracing data |
| 90 | +- Generated application traffic to produce tracing data |
| 91 | +- Used tracing data to troubleshoot application |
0 commit comments