<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Metrics on Tech Notes - A Developer's Journal</title><link>https://oypron.com/tags/metrics/</link><description>Recent content in Metrics on Tech Notes - A Developer's Journal</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 08 Mar 2026 11:45:00 +0000</lastBuildDate><atom:link href="https://oypron.com/tags/metrics/index.xml" rel="self" type="application/rss+xml"/><item><title>Observability with OpenTelemetry: What's Worth It and What Isn't</title><link>https://oypron.com/posts/observability-with-opentelemetry/</link><pubDate>Sun, 08 Mar 2026 11:45:00 +0000</pubDate><guid>https://oypron.com/posts/observability-with-opentelemetry/</guid><description>&lt;p&gt;I&amp;rsquo;ve adopted OpenTelemetry on three different services over the last two years, with varying success. This post is the honest version of what I&amp;rsquo;ve learned: where it pays off, where the friction lives, and what I would do differently next time.&lt;/p&gt;
&lt;h2 id="the-three-signals-ranked-by-effort-vs-payoff"&gt;The three signals, ranked by effort vs payoff&lt;/h2&gt;
&lt;p&gt;OTel covers traces, metrics, and logs. They are not equally easy to adopt and they don&amp;rsquo;t deliver equal value.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Traces — high payoff, moderate effort.&lt;/strong&gt; The first time you see a flame graph showing exactly where a slow request spent its 800ms, all the instrumentation work feels worth it. Auto-instrumentation libraries cover most of what you need (HTTP, database, Redis, gRPC) so the upfront cost is mostly: install SDK, configure exporter, deploy. Worth doing first.&lt;/p&gt;</description></item></channel></rss>