> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-4-34-opentelemetry-trace.md).
# Day 4/34 OpenTelemetry Trace
Activating OTel tracing in your application is straightforward. Ensure your application complies with the OTel SDK or links with the OTel library during start-up. The OTel SDK captures incoming and outgoing signals for each API call, triggering the OTel trace log.
Moreover, the OTel SDK automatically adds code to attach the OTel structure to REST or messaging headers when your application communicates with another application. The receiving OTel SDK extracts this data from the header, making it available throughout the application process. This auto-instrumentation process eliminates the need for manual code adjustments in your application.
🥑 The OTel context consists of three essential components:
* Trace ID: A unique identifier representing the entire trace flow, generated at the start and carried throughout.
* Span ID: A distinct identifier for each step in the trace flow, acting as a fingerprint for individual actions.
* Parent ID: Referring to the previous step's span ID, it establishes the sequence of spans within the trace flow.
In essence, the trace ID originates at the trigger point, propagates through the trace flow, each step receives a unique span ID, and the parent ID links these steps in the correct sequence
The trace ID, a simple numerical identifier, lacks inherent meaning. Enhancing the trace log's significance involves enriching it with additional business keys. For instance, utilizing the device ID for user identification or the process function key for specific function tracking. This manual-instrumentation process leverages the OTel API functions to inject business metadata into the trace log.
It is essential to add these business keys only at the trigger point to prevent bloating the trace log and affecting performance. Unnecessary keys in each span can impede efficiency.
Distinguishing between span attributes and baggage is crucial. Span attributes allow extra information directly in the trace log, while baggage facilitates passing additional data across different spans within the same trace flow. The key disparity lies in baggage data not being automatically logged. Therefore, utilize span attributes for incorporating extra information into the trace log and baggage for sharing data between spans without log visibility.
In complex organizational setups with numerous services across multiple hosts and environments exchanging messages over event meshes, diagnosing issues solely based on error messages or application logs becomes impractical. Such systems require a solution capable of seamlessly tracking events from the sending application, across event brokers, to the receiving application.
## 🚀 Let's Connect Beyond GitBook!
If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms:
* **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/).
* **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/).
***
#### 📬 Stay Ahead of the Curve
Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week.
👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-4-34-opentelemetry-trace.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
