> 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-12-34-alerting.md). # Day 12/34 Alerting 🚨 Alerting Is Not the Scope of OpenTelemetry (OTel)\ OpenTelemetry provides observability data—logs, metrics, and traces—for monitoring and troubleshooting. 👉 Alerting itself is intentionally out of scope.\ Alerting should be handled by downstream APM or observability platforms that consume OTel data and trigger alerts based on defined conditions. Logs vs Metrics for Alerting\ Regardless of which APM tools you use, alerts can be generated from logs and metrics. However:\ Logs in OpenTelemetry are often delayed due to their high volume and payload size\ Metrics are lightweight and near real-time\ ✅ For operational alerting, metrics are far more effective than logs 🚀 Moving Beyond Traditional Alerting\ Traditional alerts are often triggered by a single metric threshold. In many critical scenarios, this approach is too late or not enough. Example: Message Bus Alerting\ Consider a message bus with the following metrics:\ Message spool size\ Queue connection (queue bind count)\ Now consider a more subtle but critical case:\ A publisher sends control messages to a middleware application via an exclusive queue\ That application must fan out messages to multiple downstream client systems immediately\ The queue shows:\ Spool message count = 1\ Queue bind count = 0\ Even though traditional thresholds are not breached, this situation clearly indicates a potential application health issue.\ 👉 The APM should trigger an alert so operations can investigate immediately. ✅ Key Takeaway: Advanced Alerting\ Alerts should be triggered based on multiple conditions, not a single metric.\ 💡 Modern APM platforms should allow developers to:\ Define alerts using multiple metrics\ Correlate system behavior across components\ Detect early warning signs, not just failures 🔍 A Note on OpenTelemetry Sampling\ We’ve discussed OTel sampling before, and a common question comes up:\ Are metrics sampled like traces? 📌 Answer:\ Sampling applies only to traces\ Logs and metrics are always full‑fidelity\ Metrics cannot be sampled\ This makes metrics even more critical for reliable, real-time alerting.
## 🚀 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-12-34-alerting.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.