> 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-8-34-what-really-need-to-be-logged-on-the-trace-log.md).
# Day 8/34 What really need to be logged on the trace log?
🔍 OpenTelemetry Tracing & Sensitive Data: What’s Really Logged?\
In my last post, I explained why we must filter sensitive information from trace logs.
Today, let’s go one level deeper and look at what type of information is automatically recorded in trace span logs — and why that matters.
📌Manual vs Auto Instrumentation\
For applications, our main concern is manual instrumentation, not auto‑instrumentation.\
Why?
Because manual instrumentation gives developers the freedom to add custom attributes into trace spans. While this is powerful, it also introduces a higher risk of unintentionally logging sensitive or security‑critical data.
⚠️ Vendor‑Generated Trace Logs\
Vendor‑generated trace logs require extra caution.\
In most production environments:\
🚫 You cannot fully control or configure what data gets logged\
🔍 You must carefully review the content being emitted by default\
Blindly trusting vendor telemetry can expose far more than you expect.
🌐 Common Data Logged by an API Gateway\
Typical trace span attributes include:\
REST details (host, path, etc.)\
Port number\
Request ID\
OpenTelemetry library name & version\
Product name & version\
IP address
📨 Common Data Logged by a Message Bus\
Similarly, message‑based systems often log:\
Topic name\
Client name\
Deliverable mode\
Product name & version\
IP address
🤔 The Key Question\
Do you really need product names and version numbers in your trace logs?\
While this information can be useful for troubleshooting, it’s also a treasure trove for attackers:\
Helps fingerprint your technology stack\
Reveals version‑specific vulnerabilities\
Lowers the effort needed for targeted attacks
✅ Takeaway\
Observability is critical — but observability without discipline creates risk.\
👉 Always review trace data\
👉 Minimize unnecessary attributes\
👉 Treat telemetry as sensitive production data\
Good tracing improves reliability. Smart tracing protects your system.
## 🚀 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 following URL with the `ask` and `goal` query parameters:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-8-34-what-really-need-to-be-logged-on-the-trace-log.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
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.
