The latest articles on DEV Community by Max (@max_19). https://dev.to/max_19 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3879874%2F66171fc3-cf7a-4a92-9798-22b9f42fe78a.png https://dev.to/max_19 en Max Mon, 03 Aug 2026 13:36:42 +0000 https://dev.to/max_19/why-does-debugging-one-opentelemetry-trace-feel-so-complicated-24h7 https://dev.to/max_19/why-does-debugging-one-opentelemetry-trace-feel-so-complicated-24h7 <h1> Why Does Debugging One OpenTelemetry Trace Feel So Complicated? </h1> <p>When working with OpenTelemetry, one thing always bothered me during local development.</p> <p>I would make a small change, run the application, generate a request, and then realize I needed to start additional infrastructure just to inspect a trace.</p> <p>A typical local setup often looked like this:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Application │ ▼ OpenTelemetry SDK │ ▼ OpenTelemetry Collector │ ▼ Jaeger / Zipkin / Grafana / Vendor Backend </code></pre> </div> <p>There is absolutely nothing wrong with this architecture. It's designed for production observability and scales well.</p> <p>But for local development, I usually wasn't trying to monitor an entire distributed system.</p> <p>I simply wanted answers to questions like:</p> <ul> <li>Did my span get created?</li> <li>Why is this request slow?</li> <li>Which service made this database call?</li> <li>What logs belong to this trace?</li> <li>Why didn't this metric get exported?</li> </ul> <p>Starting multiple services just to answer those questions felt like unnecessary friction.</p> <h2> The idea </h2> <p>That led me to build <strong>OpenTelemetry for VS Code</strong>.</p> <p>Instead of sending telemetry to an external backend, the extension embeds an <strong>OTLP receiver directly inside VS Code</strong>.</p> <p>Applications can export telemetry directly to the editor, where it can be inspected immediately.</p> <p>No Jaeger.</p> <p>No Zipkin.</p> <p>No OpenTelemetry Collector.</p> <p>No Docker containers.</p> <p>Just start the receiver, run your application, and begin debugging.</p> <h2> What the extension can do </h2> <p>The extension currently provides:</p> <ul> <li>Embedded OTLP receiver supporting both gRPC and HTTP</li> <li>Log viewer with filtering and search</li> <li>Navigate directly from logs to source code</li> <li>Distributed trace viewer with waterfall visualization</li> <li>Metrics explorer</li> <li>Service dependency map</li> <li>Automatic OTLP endpoint injection for applications launched from VS Code</li> <li>Instrumentation snippets for Java, .NET, Go, Node.js, Python, Rust, and other OTLP-compatible SDKs</li> </ul> <p>It also works well with <strong>.NET Aspire</strong>, allowing Aspire applications to export telemetry directly into VS Code for local debugging.</p> <h2> Why keep everything inside the editor? </h2> <p>One of the biggest advantages is context.</p> <p>Instead of constantly switching between your IDE, browser, dashboards, and terminals, everything is available in one place.</p> <p>A typical workflow becomes:</p> <ol> <li>Start debugging.</li> <li>Generate a request.</li> <li>Open the trace waterfall.</li> <li>Find the slow or failing span.</li> <li>Inspect related logs.</li> <li>Jump directly to the source code.</li> <li>Fix the issue.</li> <li>Run again.</li> </ol> <p>Keeping the feedback loop inside the editor makes local debugging much faster.</p> <h2> This isn't a replacement for production observability </h2> <p>Production platforms like Jaeger, Grafana, Tempo, Azure Monitor, and others solve a very different problem.</p> <p>They provide long-term storage, distributed analysis, alerting, dashboards, and team collaboration.</p> <p>This extension focuses on a different use case:</p> <p><strong>Making local development and debugging as simple as possible.</strong></p> <h2> What's next? </h2> <p>I'm currently exploring features such as:</p> <ul> <li>Persistent storage</li> <li>Live telemetry streaming</li> <li>Metric charts</li> <li>More advanced search and filtering</li> <li>Richer service-map analytics</li> <li>Trace comparison</li> <li>Exporting collected telemetry</li> </ul> <p>I'm also interested in hearing what the community would find most useful.</p> <h2> I'd love your feedback </h2> <p>If you're using OpenTelemetry—or especially if you're working with <strong>.NET Aspire</strong>—I'd love to know how you currently debug telemetry during development.</p> <p>Does your workflow involve a Collector and Jaeger?</p> <p>Do you use the Aspire dashboard?</p> <p>Would an IDE-native experience fit into your daily workflow?</p> <p>The project is open source, and feedback, issues, and contributions are always welcome.</p> <p><strong>GitHub:</strong> <a href="https://github.com/sukanta1991/opentelemetry" rel="noopener noreferrer">https://github.com/sukanta1991/opentelemetry</a></p> <p><strong>VS Code Marketplace:</strong> <a href="https://marketplace.visualstudio.com/items?itemName=SukantaSaha.opentelemetry" rel="noopener noreferrer">https://marketplace.visualstudio.com/items?itemName=SukantaSaha.opentelemetry</a></p> opentelemetry vscode observability programming Max Wed, 15 Apr 2026 06:49:03 +0000 https://dev.to/max_19/i-built-a-vs-code-extension-to-avoid-messy-git-merges-mergeguard-1pia https://dev.to/max_19/i-built-a-vs-code-extension-to-avoid-messy-git-merges-mergeguard-1pia <p>If you’ve worked with Git long enough, you’ve probably had <em>that</em> moment.</p> <p>You pull the latest changes, try to merge, and suddenly your editor is full of conflict markers. Files you didn’t even touch are now broken, and you’re left figuring out what went wrong.</p> <p>I’ve been there more times than I’d like to admit.</p> <h2> The problem </h2> <p>Most merge conflicts don’t actually come out of nowhere.<br> They happen because multiple people are working on the same parts of the codebase—but we usually don’t realize it <em>until it’s too late</em>.</p> <p>By the time Git tells you there’s a conflict, you’re already in damage control mode.</p> <h2> The idea </h2> <p>I started wondering:</p> <blockquote> <p>What if I could know <em>before</em> merging that something is likely to break?</p> </blockquote> <p>That’s what led me to build <strong>MergeGuard</strong> — a small extension for Visual Studio Code that tries to surface potential merge risks earlier in your workflow.</p> <h2> What MergeGuard does </h2> <p>The goal isn’t to replace Git or do anything magical.<br> It simply gives you a heads-up when something looks risky.</p> <p>Some things it focuses on:</p> <ul> <li>Highlighting areas that are likely to cause conflicts</li> <li>Helping you notice overlapping changes early</li> <li>Encouraging cleaner, more predictable merges</li> </ul> <p>It’s meant to be lightweight and stay out of your way.</p> <h2> Why I built it </h2> <p>Honestly, this came from frustration.</p> <p>I didn’t want to:</p> <ul> <li>Waste time resolving avoidable conflicts</li> <li>Break working code during merges</li> <li>Or feel uncertain every time I pulled changes</li> </ul> <p>This was my attempt to make that experience a bit smoother.</p> <h2> Try it out </h2> <p>If this sounds useful, you can check it out here:<br> <a href="https://marketplace.visualstudio.com/items?itemName=SukantaSaha.mergeguard" rel="noopener noreferrer">https://marketplace.visualstudio.com/items?itemName=SukantaSaha.mergeguard</a></p> <h2> I’d love your feedback </h2> <p>This is still early, and I’m sure there’s a lot of room to improve.</p> <p>If you try it:</p> <ul> <li>Let me know what feels useful</li> <li>What’s annoying</li> <li>Or what you wish it did instead</li> </ul> <p>Even small suggestions would help shape where this goes next 🙌</p> <p>Thanks for reading!</p> vscode git productivity opensource