<?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>OpenTelemetry on svrnm :: Severin Neumann</title>
    <link>https://svrnm.com/tags/opentelemetry/</link>
    <description>Recent content in OpenTelemetry on svrnm :: Severin Neumann</description>
    <generator>Hugo -- 0.146.0</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 23 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://svrnm.com/tags/opentelemetry/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Adjusting load generators for realistic traffic simulation</title>
      <link>https://svrnm.com/blog/adjusting-load-generators-for-realistic-traffic-simulation/</link>
      <pubDate>Mon, 23 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/adjusting-load-generators-for-realistic-traffic-simulation/</guid>
      <description>&lt;p&gt;Throughout my jobs in the observability space, I created or contributed to various demo and sample applications, which often follow the same premise: there is a &amp;ldquo;normal state&amp;rdquo; in which the application is running, and with a trigger, it moves into a &amp;ldquo;deviated state&amp;rdquo;. For example, there is the &lt;code&gt;placeOrder&lt;/code&gt; transaction on a webshop that performs just fine, and orders and money are flowing into our hypothetical e-commerce company. However, with the click of a button (or a CLI command), an issue is injected into the application, and the &lt;code&gt;placeOrder&lt;/code&gt; transaction stops working as expected. Orders go down, money stops flowing, hypothetical customers get angry!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Are metrics the bestrics?</title>
      <link>https://svrnm.com/blog/metrics-are-bestrics/</link>
      <pubDate>Tue, 10 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/metrics-are-bestrics/</guid>
      <description>&lt;p&gt;&amp;ldquo;What&amp;rsquo;s your favorite telemetry signal&amp;rdquo; has been the last question of the Humans of OpenTelemetry
series for the last few years. At &lt;a href=&#34;https://opentelemetry.io/blog/2024/humans-of-otel-eu-2024/#5--whats-your-favorite-telemetry-signal&#34; target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;KubeCon EU 2024&lt;/a&gt; my answer to this was &lt;em&gt;&amp;ldquo;profiling, because I think this is really closing a big gap that was missing in observability&amp;rdquo;&lt;/em&gt;. But, today, I found out that my answer has changed, and I am leaning more toward what &lt;a href=&#34;https://www.linkedin.com/in/vjsamuel/&#34; target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Vijay Samuel&lt;/a&gt; gave as an answer: &amp;ldquo;&lt;em&gt;I feel metrics are the most powerful signal!&lt;/em&gt;&amp;rdquo;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Can you get Observability without Telemetry?</title>
      <link>https://svrnm.com/blog/can-you-get-observability-without-telemetry/</link>
      <pubDate>Thu, 18 Dec 2025 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/can-you-get-observability-without-telemetry/</guid>
      <description>&lt;p&gt;People always say there are no stupid questions, and then you read the title of this post and you&amp;rsquo;re not so sure anymore. You start to doubt my sanity, or at least suspect that I&amp;rsquo;m a troll. However, as it is with most apparently stupid questions, there is something to learn from the answer if you explore it. To spare you from reading the rest of this, the short answer is &amp;ldquo;Yes, but&amp;hellip;&amp;rdquo; and the long answer is more of a theoretical observation with some linguistic subtleties. So if you&amp;rsquo;re not interested in that, &lt;a href=&#34;https://correlation-factory.vercel.app/&#34; target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;you can leave and do something fun&lt;/a&gt;, otherwise don&amp;rsquo;t say I didn&amp;rsquo;t warn you!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Splitting out a monolith into multiple services in OpenTelemetry</title>
      <link>https://svrnm.com/blog/splitting-out-a-monolith-into-multiple-services-in-opentelemetry/</link>
      <pubDate>Tue, 25 Nov 2025 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/splitting-out-a-monolith-into-multiple-services-in-opentelemetry/</guid>
      <description>&lt;p&gt;I did an experiment on splitting out a monolithic application into multiple &amp;ldquo;virtual services&amp;rdquo; in OpenTelemetry to have modules visualized independently on service maps.&lt;/p&gt;
&lt;p&gt;I am not sure if this is a good idea and something you should replicate in practice, since it might violate some best practices. However, I wanted to see how I can do it. Since (as far as I know) all otel backends are only able to provide such a map/graph visualization using &lt;code&gt;service.name&lt;/code&gt; from the resource attributes, I tried out what happens if I create one TracerProvider per module with module-specific &lt;code&gt;service.*&lt;/code&gt; attributes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What is context propagation, why do I need it, and what does it have to do with metrics?</title>
      <link>https://svrnm.com/blog/what-is-contaxt-propagation-why-do-i-need-it/</link>
      <pubDate>Fri, 31 Oct 2025 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/what-is-contaxt-propagation-why-do-i-need-it/</guid>
      <description>&lt;p&gt;When you’re heads-down in your own area of expertise, it’s easy to forget that what’s obvious to you might not be to others. As you might have seen in previous posts, I learned that for me using pen and paper from time to time helps uncover unknown knowns in my head. Last time, it was &lt;a href=&#34;../thank-you-three-pillars-of-observability-you-served-us-well/&#34;&gt;why the three pillars need to go&lt;/a&gt;. This time, it’s context propagation, and its surprising relationship to metrics.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Thank you, three pillars of Observability. You served us well.</title>
      <link>https://svrnm.com/blog/thank-you-three-pillars-of-observability-you-served-us-well/</link>
      <pubDate>Thu, 02 Oct 2025 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/thank-you-three-pillars-of-observability-you-served-us-well/</guid>
      <description>&lt;p&gt;I just read another post introducing traces, metrics, and logs using that analogy, which reminded me to re-share that excellent piece by Ted Young on The New Stack from a few years ago:&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://thenewstack.io/modern-observability-is-a-single-braid-of-data/&#34; target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Modern Observability Is a Single Braid of Data&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Ted argued the pillars are no longer load‑bearing and suggests a better framing: the &amp;ldquo;Single Braid of Data&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;So let’s wheel the pillars into the museum, rope off the exhibit, and hang a small plaque: “Historic framing.” As we do with once‑cherished pillars that are no longer load‑bearing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Expanding the observable universe</title>
      <link>https://svrnm.com/blog/expand-the-observable-universe/</link>
      <pubDate>Mon, 19 May 2025 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/blog/expand-the-observable-universe/</guid>
      <description>&lt;p&gt;I have a confession to make: I struggled for a long time with the statement: “Observability helps you uncover unknown unknowns.”&lt;/p&gt;
&lt;p&gt;It never quite sat right with me. If you can uncover an “unknown unknown” using Observability, wasn’t it always, in some sense, a known unknown? Or perhaps even an unknown known you just hadn’t noticed?&lt;/p&gt;
&lt;p&gt;That logical loop kept bothering me.&lt;/p&gt;
&lt;p&gt;Recently, I realized where my understanding failed, and thought this might be worth sharing:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Tutorial: Exploring the Power of OpenTelemetry on Kubernetes</title>
      <link>https://svrnm.com/videos/tutorial-exploring-the-power-of-opentelemetry-on-kubernetes/</link>
      <pubDate>Mon, 01 May 2023 00:00:00 +0000</pubDate>
      <guid>https://svrnm.com/videos/tutorial-exploring-the-power-of-opentelemetry-on-kubernetes/</guid>
      <description>&lt;p&gt;Deploying an end-to-end observability system comes with many challenges. The organization has to decide how data will be collected, what data formats will be used, sampling strategies, filter sensitive data (a.k.a. PII), and ultimately send data to the observability platform of their choice. In this session, we will teach you how to roll out end-to-end observability data collection on Kubernetes using the OpenTelemetry project. You will learn how to effectively instrument applications using auto-instrumentation, deploy the OpenTelemetry collector, and collect traces, metrics, and logs. You will gain the knowledge needed to tackle the mentioned challenges. After this session, you will be able to understand and use OpenTelemetry instrumentation libraries, collector and Kubernetes operator.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
