{"slug": "opentelemetry", "name": "OpenTelemetry", "category": "observability", "category_name": "Monitoring and analytics", "description": "Vendor-neutral open standard and SDKs for collecting traces, metrics, and logs.", "recommenders": 5, "commenters": 11, "warners": 1, "score": 4.737, "rising": -0.31, "first": "2025-12-15", "latest": "2026-10-22", "why": "Liked as a single cross-language telemetry standard that feeds many backends, including Grafana's LGTM stack, SigNoz, and ClickHouse.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 5, "neutral": 4, "compare": 1, "warn": 1}, "spark": [0, 1, 0, 0, 2, 1, 0, 0, 0, 1, 0, 0], "listed": true, "loved": ["Backend flexibility", "Low-maintenance setup"], "caveat": "Prescriptive SDKs", "short_quote": "I love OpenTelemetry, and using it in Rust has been mostly great.", "icon": true, "domain": "opentelemetry.io", "github_repo": null, "official_url": "https://opentelemetry.io/", "pricing": "open source", "aliases": ["OpenTelemetry"], "verdict": [{"text": "Liked as a single cross-language telemetry standard", "cites": [{"id": 757949216, "item_id": 47371826, "url": "https://news.ycombinator.com/item?id=47371826", "by": "wise0wl", "date": "2026-03-13", "stance": "recommend", "quote": "I love OpenTelemetry, and using it in Rust has been mostly great.", "excerpt": "The OpenTelemetry spec is absolutely what folks have been waiting for for as long as I've been in computing (~20 years). A single standard that is implemented in nearly every popular language with very close feature parity. It's honestly wonderful to work with compared to the old vendor supplied frameworks. I took it upon myself to write a library for my current employer (4yrs ago now?) that abstracted and standardiz", "context": "~20 years in computing, Rust services at employer", "use_case": "metrics and tracing in Rust services", "switched_from": "vendor supplied frameworks", "story": "OpenTelemetry for Rust Developers"}]}, {"text": " that feeds many backends, including Grafana's LGTM stack, SigNoz, and ClickHouse.", "cites": [{"id": 756826416, "item_id": 47301651, "url": "https://news.ycombinator.com/item?id=47301651", "by": "verdverm", "date": "2026-03-08", "stance": "recommend", "quote": "OTEL & LGTM, the same stack I use for monitoring everything", "excerpt": "OTEL & LGTM, the same stack I use for monitoring everything, on a technical level. Some of the things you mention are more often addressed by guardrails. Some of the others (quality) require some evaluation for that measure, but results can go into the same monitory stack.", "context": "", "use_case": "monitoring AI agents", "switched_from": "", "story": "Ask HN: How are you monitoring AI agents in production?"}, {"id": 790428839, "item_id": 49401802, "url": "https://news.ycombinator.com/item?id=49401802", "by": "losingthefight", "date": "2026-08-22", "stance": "neutral", "quote": "taking in OTEL and scraping logs", "excerpt": "I run OSS Grafana with Loki, Prometheus, and Tempo. I use an Alloy sidecar taking in OTEL and scraping logs.feom my Go services and selfhost the stack. Once you need to scale it gets a bit more complicated but it's all still OSS. The biggest challenge I have is that each data source needs it's own query language, which DD and the like don't. That's why at my day job they went with DD despite the costs. Still OTEL but", "context": "", "use_case": "telemetry collection", "switched_from": "", "story": "OTel isn\u2019t going well"}, {"id": 740483137, "item_id": 46280196, "url": "https://news.ycombinator.com/item?id=46280196", "by": "gaurav12342345", "date": "2025-12-15", "stance": "recommend", "quote": "we use OTEL end-to-end", "excerpt": "A single agent request can fan out across sub-agents, tools, model calls, retries, and external APIs. When something goes wrong, logs aren\u2019t enough and raw traces aren\u2019t very helpful unless you can actually understand them. The hard part isn\u2019t emitting OpenTelemetry spans. That\u2019s easy. The hard part is turning high-cardinality agent traces into something a human can reason about. In our agent framework at Inkeep, we ", "context": "works at Inkeep on an AI agent framework", "use_case": "agent tracing instrumentation", "switched_from": "", "story": "We built OTEL observability directly into our AI agent framework"}, {"id": 790361920, "item_id": 49397620, "url": "https://news.ycombinator.com/item?id=49397620", "by": "clintonb", "date": "2026-08-22", "stance": "recommend", "quote": "", "excerpt": "(I\u2019m not the person you replied to, but have experience here.) I follow the [gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/). Everything sends telemetry to our gateway, which exports to ClickHouse (formerly Datadog). We use Node.js, so all we need to do is run a script initializing Otel before running the app. We set this up following the docs a few years ago, and haven\u2019t had to c", "context": "", "use_case": "telemetry gateway collector", "switched_from": "", "story": "OTel isn\u2019t going well"}]}, {"text": " Complaints are scattered rather than common: some find the SDKs too prescriptive,", "cites": [{"id": 790487792, "item_id": 49405487, "url": "https://news.ycombinator.com/item?id=49405487", "by": "mnming", "date": "2026-08-23", "stance": "warn", "quote": "I also think OTel SDKs are a tad bit too prescriptive", "excerpt": "I also think OTel SDKs are a tad bit too prescriptive, but at the same time I can't envision what a better version would look like. The core of logs and spans are just wide events with some inter-connections, those SDKs and OTel docs make them less obvious. (I maintain o11ylite https://github.com/o11ylite/o11ylite)", "context": "", "use_case": "observability instrumentation", "switched_from": "", "story": "OTel isn\u2019t going well"}]}, {"text": " raw traces hard to interpret,", "cites": [{"id": 740483137, "item_id": 46280196, "url": "https://news.ycombinator.com/item?id=46280196", "by": "gaurav12342345", "date": "2025-12-15", "stance": "recommend", "quote": "we use OTEL end-to-end", "excerpt": "A single agent request can fan out across sub-agents, tools, model calls, retries, and external APIs. When something goes wrong, logs aren\u2019t enough and raw traces aren\u2019t very helpful unless you can actually understand them. The hard part isn\u2019t emitting OpenTelemetry spans. That\u2019s easy. The hard part is turning high-cardinality agent traces into something a human can reason about. In our agent framework at Inkeep, we ", "context": "works at Inkeep on an AI agent framework", "use_case": "agent tracing instrumentation", "switched_from": "", "story": "We built OTEL observability directly into our AI agent framework"}]}, {"text": " and self-built pipelines and exporters a real time investment.", "cites": [{"id": 765123698, "item_id": 47820231, "url": "https://news.ycombinator.com/item?id=47820231", "by": "chickensong", "date": "2026-04-18", "stance": "recommend", "quote": "maybe some kind of OTel, wide log, ClickHouse, Grafana thing", "excerpt": "Are you asking about other 3rd party solutions, or thinking of DIY? AFAIK, Datadog is still the best/most expensive. Any provider offering AI analysis is just going to add to your cost. > I love putting time into this stuff > like the reason for using Heroku - I have a lot of other stuff I need to focus on You probably need to pick a side here. Building a robust solution with even a fraction of Datadog and Sentry fea", "context": "promotes DIY", "use_case": "DIY observability stack", "switched_from": "", "story": "Observability Stack \u2013 AI First?"}, {"id": 757956400, "item_id": 47372275, "url": "https://news.ycombinator.com/item?id=47372275", "by": "pooper", "date": "2026-03-13", "stance": "neutral", "quote": "I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app.", "excerpt": "Speaking of opentelemetry, I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app. I don't have the required corporate background in opentelemetry. I had to write my own file log exporter. I didn't write it myself -- I used Claude to write it for me in jsonl format which seemed like a good way to have each row in json and for the console app, I get a file something", "context": "personal projects, no corporate OTel background", "use_case": "logs, metrics, traces", "switched_from": "", "story": "OpenTelemetry for Rust Developers"}]}], "praise": [{"label": "Backend flexibility", "summary": "Commenters send OTel data to a range of backends, from Grafana LGTM and SigNoz to ClickHouse after leaving Datadog.", "quotes": [{"id": 756826416, "item_id": 47301651, "url": "https://news.ycombinator.com/item?id=47301651", "by": "verdverm", "date": "2026-03-08", "stance": "recommend", "quote": "OTEL & LGTM, the same stack I use for monitoring everything", "excerpt": "OTEL & LGTM, the same stack I use for monitoring everything, on a technical level. Some of the things you mention are more often addressed by guardrails. Some of the others (quality) require some evaluation for that measure, but results can go into the same monitory stack.", "context": "", "use_case": "monitoring AI agents", "switched_from": "", "story": "Ask HN: How are you monitoring AI agents in production?"}, {"id": 790428839, "item_id": 49401802, "url": "https://news.ycombinator.com/item?id=49401802", "by": "losingthefight", "date": "2026-08-22", "stance": "neutral", "quote": "taking in OTEL and scraping logs", "excerpt": "I run OSS Grafana with Loki, Prometheus, and Tempo. I use an Alloy sidecar taking in OTEL and scraping logs.feom my Go services and selfhost the stack. Once you need to scale it gets a bit more complicated but it's all still OSS. The biggest challenge I have is that each data source needs it's own query language, which DD and the like don't. That's why at my day job they went with DD despite the costs. Still OTEL but", "context": "", "use_case": "telemetry collection", "switched_from": "", "story": "OTel isn\u2019t going well"}, {"id": 790361920, "item_id": 49397620, "url": "https://news.ycombinator.com/item?id=49397620", "by": "clintonb", "date": "2026-08-22", "stance": "recommend", "quote": "", "excerpt": "(I\u2019m not the person you replied to, but have experience here.) I follow the [gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/). Everything sends telemetry to our gateway, which exports to ClickHouse (formerly Datadog). We use Node.js, so all we need to do is run a script initializing Otel before running the app. We set this up following the docs a few years ago, and haven\u2019t had to c", "context": "", "use_case": "telemetry gateway collector", "switched_from": "", "story": "OTel isn\u2019t going well"}]}, {"label": "Low-maintenance setup", "summary": "Setup following the docs needed little change for years, and emitting spans is described as easy.", "quotes": [{"id": 790361920, "item_id": 49397620, "url": "https://news.ycombinator.com/item?id=49397620", "by": "clintonb", "date": "2026-08-22", "stance": "recommend", "quote": "", "excerpt": "(I\u2019m not the person you replied to, but have experience here.) I follow the [gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/). Everything sends telemetry to our gateway, which exports to ClickHouse (formerly Datadog). We use Node.js, so all we need to do is run a script initializing Otel before running the app. We set this up following the docs a few years ago, and haven\u2019t had to c", "context": "", "use_case": "telemetry gateway collector", "switched_from": "", "story": "OTel isn\u2019t going well"}, {"id": 740483137, "item_id": 46280196, "url": "https://news.ycombinator.com/item?id=46280196", "by": "gaurav12342345", "date": "2025-12-15", "stance": "recommend", "quote": "we use OTEL end-to-end", "excerpt": "A single agent request can fan out across sub-agents, tools, model calls, retries, and external APIs. When something goes wrong, logs aren\u2019t enough and raw traces aren\u2019t very helpful unless you can actually understand them. The hard part isn\u2019t emitting OpenTelemetry spans. That\u2019s easy. The hard part is turning high-cardinality agent traces into something a human can reason about. In our agent framework at Inkeep, we ", "context": "works at Inkeep on an AI agent framework", "use_case": "agent tracing instrumentation", "switched_from": "", "story": "We built OTEL observability directly into our AI agent framework"}]}, {"label": "Cross-language standard", "summary": "Praised as one standard with close feature parity across languages, nicer than old vendor frameworks.", "quotes": [{"id": 757949216, "item_id": 47371826, "url": "https://news.ycombinator.com/item?id=47371826", "by": "wise0wl", "date": "2026-03-13", "stance": "recommend", "quote": "I love OpenTelemetry, and using it in Rust has been mostly great.", "excerpt": "The OpenTelemetry spec is absolutely what folks have been waiting for for as long as I've been in computing (~20 years). A single standard that is implemented in nearly every popular language with very close feature parity. It's honestly wonderful to work with compared to the old vendor supplied frameworks. I took it upon myself to write a library for my current employer (4yrs ago now?) that abstracted and standardiz", "context": "~20 years in computing, Rust services at employer", "use_case": "metrics and tracing in Rust services", "switched_from": "vendor supplied frameworks", "story": "OpenTelemetry for Rust Developers"}]}], "caveats": [{"label": "Prescriptive SDKs", "summary": "One maintainer finds the SDKs and docs too prescriptive and obscuring that logs and spans are wide events.", "quotes": [{"id": 790487792, "item_id": 49405487, "url": "https://news.ycombinator.com/item?id=49405487", "by": "mnming", "date": "2026-08-23", "stance": "warn", "quote": "I also think OTel SDKs are a tad bit too prescriptive", "excerpt": "I also think OTel SDKs are a tad bit too prescriptive, but at the same time I can't envision what a better version would look like. The core of logs and spans are just wide events with some inter-connections, those SDKs and OTel docs make them less obvious. (I maintain o11ylite https://github.com/o11ylite/o11ylite)", "context": "", "use_case": "observability instrumentation", "switched_from": "", "story": "OTel isn\u2019t going well"}]}, {"label": "Hard-to-read traces", "summary": "Raw high-cardinality traces are hard for humans to reason about without extra tooling.", "quotes": [{"id": 740483137, "item_id": 46280196, "url": "https://news.ycombinator.com/item?id=46280196", "by": "gaurav12342345", "date": "2025-12-15", "stance": "recommend", "quote": "we use OTEL end-to-end", "excerpt": "A single agent request can fan out across sub-agents, tools, model calls, retries, and external APIs. When something goes wrong, logs aren\u2019t enough and raw traces aren\u2019t very helpful unless you can actually understand them. The hard part isn\u2019t emitting OpenTelemetry spans. That\u2019s easy. The hard part is turning high-cardinality agent traces into something a human can reason about. In our agent framework at Inkeep, we ", "context": "works at Inkeep on an AI agent framework", "use_case": "agent tracing instrumentation", "switched_from": "", "story": "We built OTEL observability directly into our AI agent framework"}]}, {"label": "DIY effort", "summary": "Building a self-hosted pipeline is a significant time sink, and one user had to create their own file log exporter.", "quotes": [{"id": 765123698, "item_id": 47820231, "url": "https://news.ycombinator.com/item?id=47820231", "by": "chickensong", "date": "2026-04-18", "stance": "recommend", "quote": "maybe some kind of OTel, wide log, ClickHouse, Grafana thing", "excerpt": "Are you asking about other 3rd party solutions, or thinking of DIY? AFAIK, Datadog is still the best/most expensive. Any provider offering AI analysis is just going to add to your cost. > I love putting time into this stuff > like the reason for using Heroku - I have a lot of other stuff I need to focus on You probably need to pick a side here. Building a robust solution with even a fraction of Datadog and Sentry fea", "context": "promotes DIY", "use_case": "DIY observability stack", "switched_from": "", "story": "Observability Stack \u2013 AI First?"}, {"id": 757956400, "item_id": 47372275, "url": "https://news.ycombinator.com/item?id=47372275", "by": "pooper", "date": "2026-03-13", "stance": "neutral", "quote": "I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app.", "excerpt": "Speaking of opentelemetry, I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app. I don't have the required corporate background in opentelemetry. I had to write my own file log exporter. I didn't write it myself -- I used Claude to write it for me in jsonl format which seemed like a good way to have each row in json and for the console app, I get a file something", "context": "personal projects, no corporate OTel background", "use_case": "logs, metrics, traces", "switched_from": "", "story": "OpenTelemetry for Rust Developers"}]}, {"label": "Uneven backend support", "summary": "Sentry was not originally designed for OTel, leaving rough edges.", "quotes": [{"id": 784669842, "item_id": 49041865, "url": "https://news.ycombinator.com/item?id=49041865", "by": "dabinat", "date": "2026-07-24", "stance": "neutral", "quote": "I use both SigNoz and Sentry with OpenTelemetry.", "excerpt": "I\u2019d recommend self-hosting because most SaaS providers charge or limit by usage and it can add up fast. I use both SigNoz and Sentry with OpenTelemetry. Why both? SigNoz has great dashboards and trace and metrics monitoring, but its alerting system isn\u2019t great. Sentry is great at alerting me to new issues and it also has other features like JS session replays that are nice. They just added metrics monitoring which I ", "context": "", "use_case": "instrumentation", "switched_from": "", "story": "Ask HN: What are your current favorite monitoring and observability solutions?"}]}, {"label": "Browser log viewing", "summary": "A long-time grep user dislikes scanning logs in a browser and built a file-based alternative.", "quotes": [{"id": 803123840, "item_id": 50195240, "url": "https://news.ycombinator.com/item?id=50195240", "by": "aivarsk", "date": "2026-10-22", "stance": "compare", "quote": "While OTEL adds some nice things, I hate using my browser to scan through the logs.", "excerpt": "I am old and grumpy developer, I used to grep, split and join logs for decades and grep/awk to extract some stats out of that. While OTEL adds some nice things, I hate using my browser to scan through the logs. During SREcon EMEA observed how vendors compete to ingest more, reduce storage size and price. I decided to try another way and create an old-grumpy-dev version of OTEL that is simple and just stores everythin", "context": "old developer who greps logs", "use_case": "log observability", "switched_from": "", "story": null}]}], "who": [{"by": "chickensong", "context": "promotes DIY", "url": "https://news.ycombinator.com/item?id=47820231", "date": "2026-04-18"}, {"by": "pooper", "context": "personal projects, no corporate OTel background", "url": "https://news.ycombinator.com/item?id=47372275", "date": "2026-03-13"}, {"by": "wise0wl", "context": "~20 years in computing, Rust services at employer", "url": "https://news.ycombinator.com/item?id=47371826", "date": "2026-03-13"}, {"by": "gaurav12342345", "context": "works at Inkeep on an AI agent framework", "url": "https://news.ycombinator.com/item?id=46280196", "date": "2025-12-15"}], "tags": ["self-hostable", "for Rust services", "for Node.js apps", "for AI agent tracing", "for .NET projects"], "use_cases": ["log observability", "observability instrumentation", "telemetry collection", "telemetry gateway collector", "metrics for alerting", "instrumentation"], "compared": [{"slug": "signoz", "name": "SigNoz", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "datadog", "name": "Datadog", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "grafana", "name": "Grafana", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "clickhouse", "name": "ClickHouse", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "sentry", "name": "Sentry", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49391553", "title": "OTel isn\u2019t going well", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=47321579", "title": "OpenTelemetry for Rust Developers", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50195239", "title": "item 50195239", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49386249", "title": "Show HN: Interactive PostgreSQL Permissions", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49041446", "title": "Ask HN: What are your current favorite monitoring and observability solutions?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47819461", "title": "Observability Stack \u2013 AI First?", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"recommend": 1}, "2026-01": {}, "2026-02": {}, "2026-03": {"recommend": 2, "neutral": 1}, "2026-04": {"recommend": 1}, "2026-05": {}, "2026-06": {}, "2026-07": {"neutral": 1}, "2026-08": {"neutral": 2, "recommend": 1, "warn": 1}, "2026-09": {}, "2026-10": {"compare": 1}}, "quotes": [{"id": 803123840, "item_id": 50195240, "url": "https://news.ycombinator.com/item?id=50195240", "by": "aivarsk", "date": "2026-10-22", "stance": "compare", "quote": "While OTEL adds some nice things, I hate using my browser to scan through the logs.", "excerpt": "I am old and grumpy developer, I used to grep, split and join logs for decades and grep/awk to extract some stats out of that. While OTEL adds some nice things, I hate using my browser to scan through the logs. During SREcon EMEA observed how vendors compete to ingest more, reduce storage size and price. I decided to try another way and create an old-grumpy-dev version of OTEL that is simple and just stores everythin", "context": "old developer who greps logs", "use_case": "log observability", "switched_from": "", "story": null}, {"id": 790487792, "item_id": 49405487, "url": "https://news.ycombinator.com/item?id=49405487", "by": "mnming", "date": "2026-08-23", "stance": "warn", "quote": "I also think OTel SDKs are a tad bit too prescriptive", "excerpt": "I also think OTel SDKs are a tad bit too prescriptive, but at the same time I can't envision what a better version would look like. The core of logs and spans are just wide events with some inter-connections, those SDKs and OTel docs make them less obvious. (I maintain o11ylite https://github.com/o11ylite/o11ylite)", "context": "", "use_case": "observability instrumentation", "switched_from": "", "story": "OTel isn\u2019t going well"}, {"id": 790428839, "item_id": 49401802, "url": "https://news.ycombinator.com/item?id=49401802", "by": "losingthefight", "date": "2026-08-22", "stance": "neutral", "quote": "taking in OTEL and scraping logs", "excerpt": "I run OSS Grafana with Loki, Prometheus, and Tempo. I use an Alloy sidecar taking in OTEL and scraping logs.feom my Go services and selfhost the stack. Once you need to scale it gets a bit more complicated but it's all still OSS. The biggest challenge I have is that each data source needs it's own query language, which DD and the like don't. That's why at my day job they went with DD despite the costs. Still OTEL but", "context": "", "use_case": "telemetry collection", "switched_from": "", "story": "OTel isn\u2019t going well"}, {"id": 790361920, "item_id": 49397620, "url": "https://news.ycombinator.com/item?id=49397620", "by": "clintonb", "date": "2026-08-22", "stance": "recommend", "quote": "", "excerpt": "(I\u2019m not the person you replied to, but have experience here.) I follow the [gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/). Everything sends telemetry to our gateway, which exports to ClickHouse (formerly Datadog). We use Node.js, so all we need to do is run a script initializing Otel before running the app. We set this up following the docs a few years ago, and haven\u2019t had to c", "context": "", "use_case": "telemetry gateway collector", "switched_from": "", "story": "OTel isn\u2019t going well"}, {"id": 790294432, "item_id": 49393402, "url": "https://news.ycombinator.com/item?id=49393402", "by": "hardbyte", "date": "2026-08-21", "stance": "neutral", "quote": "I'm pushing opentelemetry metrics which we use for alerting.", "excerpt": "ty. I'm pushing opentelemetry metrics which we use for alerting. I had thought about emitting PolicyReports from the operator too", "context": "", "use_case": "metrics for alerting", "switched_from": "", "story": "Show HN: Interactive PostgreSQL Permissions"}, {"id": 784669842, "item_id": 49041865, "url": "https://news.ycombinator.com/item?id=49041865", "by": "dabinat", "date": "2026-07-24", "stance": "neutral", "quote": "I use both SigNoz and Sentry with OpenTelemetry.", "excerpt": "I\u2019d recommend self-hosting because most SaaS providers charge or limit by usage and it can add up fast. I use both SigNoz and Sentry with OpenTelemetry. Why both? SigNoz has great dashboards and trace and metrics monitoring, but its alerting system isn\u2019t great. Sentry is great at alerting me to new issues and it also has other features like JS session replays that are nice. They just added metrics monitoring which I ", "context": "", "use_case": "instrumentation", "switched_from": "", "story": "Ask HN: What are your current favorite monitoring and observability solutions?"}, {"id": 765123698, "item_id": 47820231, "url": "https://news.ycombinator.com/item?id=47820231", "by": "chickensong", "date": "2026-04-18", "stance": "recommend", "quote": "maybe some kind of OTel, wide log, ClickHouse, Grafana thing", "excerpt": "Are you asking about other 3rd party solutions, or thinking of DIY? AFAIK, Datadog is still the best/most expensive. Any provider offering AI analysis is just going to add to your cost. > I love putting time into this stuff > like the reason for using Heroku - I have a lot of other stuff I need to focus on You probably need to pick a side here. Building a robust solution with even a fraction of Datadog and Sentry fea", "context": "promotes DIY", "use_case": "DIY observability stack", "switched_from": "", "story": "Observability Stack \u2013 AI First?"}, {"id": 757956400, "item_id": 47372275, "url": "https://news.ycombinator.com/item?id=47372275", "by": "pooper", "date": "2026-03-13", "stance": "neutral", "quote": "I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app.", "excerpt": "Speaking of opentelemetry, I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app. I don't have the required corporate background in opentelemetry. I had to write my own file log exporter. I didn't write it myself -- I used Claude to write it for me in jsonl format which seemed like a good way to have each row in json and for the console app, I get a file something", "context": "personal projects, no corporate OTel background", "use_case": "logs, metrics, traces", "switched_from": "", "story": "OpenTelemetry for Rust Developers"}, {"id": 757949216, "item_id": 47371826, "url": "https://news.ycombinator.com/item?id=47371826", "by": "wise0wl", "date": "2026-03-13", "stance": "recommend", "quote": "I love OpenTelemetry, and using it in Rust has been mostly great.", "excerpt": "The OpenTelemetry spec is absolutely what folks have been waiting for for as long as I've been in computing (~20 years). A single standard that is implemented in nearly every popular language with very close feature parity. It's honestly wonderful to work with compared to the old vendor supplied frameworks. I took it upon myself to write a library for my current employer (4yrs ago now?) that abstracted and standardiz", "context": "~20 years in computing, Rust services at employer", "use_case": "metrics and tracing in Rust services", "switched_from": "vendor supplied frameworks", "story": "OpenTelemetry for Rust Developers"}, {"id": 756826416, "item_id": 47301651, "url": "https://news.ycombinator.com/item?id=47301651", "by": "verdverm", "date": "2026-03-08", "stance": "recommend", "quote": "OTEL & LGTM, the same stack I use for monitoring everything", "excerpt": "OTEL & LGTM, the same stack I use for monitoring everything, on a technical level. Some of the things you mention are more often addressed by guardrails. Some of the others (quality) require some evaluation for that measure, but results can go into the same monitory stack.", "context": "", "use_case": "monitoring AI agents", "switched_from": "", "story": "Ask HN: How are you monitoring AI agents in production?"}, {"id": 740483137, "item_id": 46280196, "url": "https://news.ycombinator.com/item?id=46280196", "by": "gaurav12342345", "date": "2025-12-15", "stance": "recommend", "quote": "we use OTEL end-to-end", "excerpt": "A single agent request can fan out across sub-agents, tools, model calls, retries, and external APIs. When something goes wrong, logs aren\u2019t enough and raw traces aren\u2019t very helpful unless you can actually understand them. The hard part isn\u2019t emitting OpenTelemetry spans. That\u2019s easy. The hard part is turning high-cardinality agent traces into something a human can reason about. In our agent framework at Inkeep, we ", "context": "works at Inkeep on an AI agent framework", "use_case": "agent tracing instrumentation", "switched_from": "", "story": "We built OTEL observability directly into our AI agent framework"}]}