Liudmila Molkova
Staff Developer Advocate at Grafana Labs, Member of the OpenTelemetry Technical Committee
Actions
Liudmila Molkova is a Developer Advocate at Grafana Labs working on OpenTelemetry. She is a member of the OpenTelemetry Technical Committee and a maintainer of the Semantic Conventions. Previously, she led observability efforts for Azure client libraries at Microsoft. Liudmila co-authored distributed tracing implementations across the .NET ecosystem, including HTTP client instrumentation and Azure Functions. She is also the author of Modern Distributed Tracing in .NET: A Practical Guide to Observability and Performance Analysis for Microservices
Badges
GenAI Observability: Keeping GenAI Honest Without Oversharing
Generative AI is non-deterministic, and as an industry we are still learning how to use it. This makes observability especially important for AI applications. Beyond typical performance and usage telemetry, AI systems require capturing conversation data to ensure responsible behavior and meaningful results.
Conversation history, however, is verbose and often contains sensitive information, which introduces extra challenges and costs.
In this session, we’ll show you how to instrument your AI applications with OpenTelemetry following the Generative AI Semantic Conventions.
Through a live demo, we’ll demonstrate how to record conversation history alongside performance-related telemetry, and how to separate sensitive data for compliance and cost-saving purposes. We’ll also explore options for running evaluations and recording results based on telemetry data.
Behind the Proposals: How OpenTelemetry Designs Take Shape
Design proposals are at the heart of how open source projects evolve, and OpenTelemetry is no exception. This panel brings together contributors with a range of roles in the project, including governance and technical committee members, specification sponsors, and implementation maintainers. We will explore how OpenTelemetry handles design through OTEPs (OpenTelemetry Enhancement Proposals), semantic convention proposals, and new feature additions, both in the specification and implementations. The discussion will cover prototyping, design review, community engagement, and communicating changes. While focused on OpenTelemetry, many of the lessons and challenges such as building consensus, maintaining momentum, and balancing innovation with stability apply broadly to any open source project.
Using native OpenTelemetry instrumentation to make client libraries better
We usually think about observability as a feature intended for application developers. Client library authors provide observability as an afterthought to improve developer experience and reduce support burden. But native instrumentation intended for end users is extremely valuable for library authors as well during development process.
In this session I will show how we leverage native instrumentation when stress and load testing Azure client libraries and how it helps us optimize performance, detect and fix reliability issues.
I'll provide a few examples of such issues we were able to detect: the unnecessary HTTP requests we could avoid, transient issues we didn't retry, memory we over-allocated, thread pools we didn't configure.
Client library authors don't usually have expertise in observability. I'll show how stress testing helps us bridge this gap and find good observability signals for the end users and ourselves.
Telemetry that matches your model, verified live
OpenTelemetry Semantic Conventions define how telemetry should look, but do instrumentations actually follow them in practice? Your organization might define additional conventions - but how do you ensure instrumentations stay up to date as conventions evolve?
What if you could get a comprehensive report on the actual telemetry your application produces, checked against your conventions model?
We’re excited to share OpenTelemetry Weaver’s live check: a validation tool that listens to telemetry in real time and analyzes its compatibility against formally defined conventions. We’ll show you how to run live checks in your CI/CD pipelines to catch instrumentation issues before they hit production - no more guessing whether your telemetry matches your model.
Beyond basic model compliance, we’ll also demonstrate how to write Rego policies to enforce organization-specific checks and best practices.
Optimizing LLM performance in Kubernetes with OpenTelemetry
Large Language Models are increasing in popularity and their deployments on Kubernetes have steadily increased. LLM applications bring new usage patterns that the industry does not have the expertise in. At the same time, there is a lack of observability in these deployments which makes it difficult to debug performance issues. We will present an end to end walkthrough of how you can leverage client and server LLM observability using Open Telemetry based on the recent efforts in the Kubernetes and Open Telemetry communities to standardize these across LLM clients and model servers. We will also demonstrate how to troubleshoot a real-world performance issue in your LLM deployment and how to optimize your LLM server setup for better performance on Kubernetes.
We'll show how to use Kubernetes autoscaling based on custom model server metrics and demonstrate how they offer a superior alternative to using GPU utilization metrics for such deployments.
No Dependencies. No Plugins. Just Native OpenTelemetry
The best telemetry starts at the source—inside the client libraries.
But in most cases, that means taking a dependency on the OpenTelemetry API from your library. And while it’s stable, minimal, reliable, and safely no-op unless configured—transitive dependencies are still the bane of any library developer’s existence, and most of us try to avoid them.
To work around this, people reach for abstractions, plugins, bridges, or even OTel forks that break context propagation. The result? A poor user experience. Users must find the right plugin, install it, wire it up—and still hit the diamond dependency problem, now it just affects a subset of users.
But what if you could take a truly optional dependency? If OpenTelemetry is on the classpath, instrumentation kicks in. If it’s not, no harm done.
How hard is that to pull off? How reliable? How performant?
Let’s explore that—through the lens of the next generation of Azure SDKs for Java. Spoiler: it’s easy and fast, and as a side-bonus, we can fall back to logs-based tracing if OTel is not found.
Enhancing Asynchronous Communication Observability with OpenTelemetry
OTel community has been working on standardizing semantic conventions to correlate telemetry data from various systems. The Messaging SemConv aims to solve it for commonly used queues like Kafka, RabbitMQ, and others systems. OTel instrumentations are adopting these conventions, but the end users still face challenges with async messaging observability at scale. They struggle with questions like "how to trace message flow?", "how to correlate metrics with traces?", "how to do capacity planning and cost optimizations based on telemetry data?". The end-to-end visibility often remains a black box!
In this session, through a demo, we'll delve deeper into async architecture to address these questions, demonstrate context propagation within queues, and show how to correlate traces and client or broker-side metrics. Participants will gain hands-on experience with messaging instrumentation, learning how to achieve observability in both simple and complex asynchronous messaging scenarios.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top