<?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>Observability on Giedrius Statkevičius</title><link>https://giedrius.blog/categories/observability/</link><description>Recent content in Observability on Giedrius Statkevičius</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sun, 22 Jun 2025 10:56:40 +0000</lastBuildDate><atom:link href="https://giedrius.blog/categories/observability/feed.xml" rel="self" type="application/rss+xml"/><item><title>OpenTelemetry-go makes it hard to migrate to exponential histograms</title><link>https://giedrius.blog/2025/06/22/opentelemetry-go-makes-it-hard-to-migrate-to-exponential-histograms/</link><pubDate>Sun, 22 Jun 2025 10:56:40 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=1240</guid><description>&lt;p&gt;&lt;em&gt;github.com/prometheus/client_golang&lt;/em&gt; has a nice feature where a histogram can simultaneously be both an exponential (native) histogram and a classic (explicit bucket) one. Then, depending on what formats are accepted by the scraper, either both the native histogram version and the classical one are exposed, or just the classical one (text format). There has been an initiative to expose native histograms in text format, but it hasn&amp;rsquo;t yet solidified.&lt;/p&gt;
&lt;p&gt;Unfortunately, in the OpenTelemetry standards, a histogram at any point can only have either explicit buckets or exponential buckets. From &lt;a href="https://opentelemetry.io/docs/specs/otel/metrics/data-model/#model-details"&gt;https://opentelemetry.io/docs/specs/otel/metrics/data-model/#model-details&lt;/a&gt;:&lt;/p&gt;</description></item><item><title>Jsonnet is not so bad</title><link>https://giedrius.blog/2025/03/24/jsonnet-is-not-so-bad/</link><pubDate>Mon, 24 Mar 2025 20:36:30 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=1236</guid><description>&lt;p&gt;Okay, jsonnet does not have such a bad experience nowadays - there is a pretty good LSP server implementation thanks to the team at Grafana, there&amp;rsquo;s jsonnetfmt that makes the jsonnet code style the same across projects, and we have LLMs that make it much easier to learn any new language.&lt;/p&gt;
&lt;p&gt;Also, since it is an interpreted language that simply yields JSON, it is very easy to prototype and test changes. This was especially apparent during the recent hackathon where our team used jsonnet to implement a &amp;ldquo;dynamic dashboard generator&amp;rdquo; in Grafana, and we won the prize. Since all Grafana dashboards are JSONs, it is very to generate them with a language specifically geared towards it.&lt;/p&gt;</description></item></channel></rss>