Ever had your application look completely flawless in the terminal while the frontend is giving you absolutely nothing? I spent two full hours pulling my hair out trying to figure out why my AI agent was returning empty strings, even though my console was proudly spit-firing 200 OK *success statuses. In this post, I'll show you how a lazy coding shortcut completely blinded me to what was going wrong, and how setting up an *OpenTelemetry service SigNoz saved my project from an absolute disaster.
I initially hooked up OpenTelemetry and SigNoz just to watch my API latency and see how fast my agent loops were running. I wanted to have some nice, professional-looking graphs. Everything worked fine during early development. But as I started adjusting the UI layout, I kept running into minor network timeouts that would crash my local server.
Problem was in a small try-except code block
except Exception: pass. It is a literal black hole for errors.
A little later, I ran a heavy automated testing script to see how the backend handled complex prompts under simulated load.
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
export OTEL_RESOURCE_ATTRIBUTES=service.name=college-ai-backend
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
opentelemetry-instrument uvicorn main:app --reload
I booted up my SigNoz dashboard and navigated straight to the Exceptions tab. Right there, staring back at me, was a massive, bright red spike of errors.
What I Learned / Takeaways
"I'll fix it later" is a trap: Shorthand error handling like except Exception: pass is dangerous. If you must catch all exceptions temporarily to prevent crashes during design tweaks, at least print them to the console or log them properly.
Telemetry sees through bad code: The biggest benefit of using an open-source standard like OpenTelemetry is that auto-instrumentation captures the actual behavior of the underlying runtimes
Top comments (1)
💥💥