 Hi, everyone. Good morning. It's nice to see a nice full room, especially for open telemetry. So today's session on the project is to give you an update on the open telemetry project, what's happening on the project, what's completed, give you kind of an overview of some of the key areas that the project has been working towards and then open it up for the audience to actually ask the maintainers and the active contributors to the project questions. So with that said, I'm Alulita Sharma. I'm part of the Open Telemetry Governance Committee. I've also been involved on the project working on metrics, OTLP to Prometheus, interoperability, and as well as recently been working on LLM semantic conventions for open telemetry and the spec, of course. With that said, again, I'd like to introduce the others who are on the from the GC today. So, Severin. Yeah, good morning, everyone. I'm Severin Neumann, based out of Germany. I work for Cisco at the open source program office there and I'm as well part of the Governance Committee. I'm also one of the co-mentainers of the Open Telemetry documentation. So if you have any questions about that, you can send me an issue on github and I can help you there. And I give it over to Trask. Thanks. Hi, I'm Trask Stallnaker. I'm a software engineer at Microsoft and a maintainer of the Open Telemetry Java Instrumentation Project. Good morning. My name is Daniel Gomez Blanco. I'm a principal engineer at Sky Scanner and I was super happy to have been elected to be part of the Governance Committee as an end user and trying to bridge that gap between end users and maintainers and making sure that we adopt open telemetry scale. Good morning. There's some seats available up front if people want them. I'm Austin Parker, director of open source at honeycomb.io. I've been a contributor to open telemetry since before it was open telemetry. I was an open tracing maintainer. Shout out to all my open tracing heads out in the audience. Tough crowd. I'm also, thank you, I'm from North America and I'm a maintainer of the Open Telemetry demo, among other responsibilities in the project. All right. So with that said, again, I'll hand it over to our first presenter, Severin. And then we'll take turns. Awesome. Okay, so let me move this a little bit. Before we talk about us, we want to talk about you. So I'm curious, who of you is a real end user of open telemetry? So using open telemetry in their production, in their operations? Oh yeah, that's really great to see. Because there's a big, an important company missing on that slide. That's your company, right? So we really want you to ask you to reach out to us and let us know like, hey, we're using open telemetry. We have a blog post maybe even about our usage of open telemetry, or maybe you did a talk about using open telemetry. We want to make the slide fuller and fuller every year. And there's another slide we want to make even fuller than that. You can use open telemetry as an end user, but you can also integrate open telemetry in your project. So once again, maybe you're contributing to any of those projects. I'm really curious who of you is working in an open source project or in a commercial product? And are you integrating open telemetry? So let me see your hands. Awesome. There's some of you. Yeah, thank you for integrating open telemetry. And again, we want to hear about that. So we have a list of integrations also on our website nowadays. So let us know how you integrate open telemetry into your product, into your project. So you see a lot of CNCF projects here. You see a lot of Apache projects here. We are super excited about that. And we're also excited if you say like, hey, we have a commercial product and we use open telemetry because we think open telemetry should be everywhere. It is everywhere. Yeah. And one last slide from me, because I think this is always also important, talking about metrics. Last month, we had the first month where we had more than 25,000 contributions to our project. So yet another milestone we broke. So yeah, thanks to everybody who contributed. And with that, I give it over back to Alulita. All right. So I think that what we're going to do is cover different areas of, you know, work that's ongoing in the project. And this is about logging. As most of you know, logging has been stable. It was declared when open telemetry went GA in November at the previous KubeCon we had in Chicago. Again, logging SDKs were already starting to get stable. So C++.net went first and then Java and PHP now are also done. So we'll continue, you know, again, works continuing on the other languages also. But that's work in progress. This is stable. Experimental logging SDKs, as you can see is Go, Go is in progress, JS, JavaScript, Python, Rust, and Erlang. There's also experimental logging bridges for C++, because again, many of these languages have inherent logging support, which then open telemetry also leverages Java with log4j and log back, JavaScript with Bunyan and Winston.net with iLogger, PHP with monologue, Python and Rust with Tokyo tracing. Right. So again, wherever there is native or, you know, standardized logging available, that's also been leveraged. The spec is also stable at this point. So that's another call out. But keep this, you know, keep, please stay involved. If there's a language that is not, you don't see on this list yet, please ask, please ask one of us. With that, again, I'll switch over to Trask. And Trask, please tell us more about SNET conventions. Thank you. So now that logs, traces, metrics have been declared stable, one of the next big frontiers is semantic conventions, which is defining the shape of the telemetry within those signals. The having semantic conventions for HTTP databases, and many others is critical. Otherwise, because of the number of libraries, languages, platforms, if everyone was emitting telemetry and calling URL.path something different, then on your back end, you're looking at your telemetry, you're going to have a hard time stitching things together, correlating data. And so a lot of work is going into semantic convention definitions, and finally moving semantic conventions to stability. We did declare HTTP semantic conventions stable in November, which was a big milestone for us, our first semantic conventions that we declared stable. A lot of work went into just even what the definition of stable is for semantic conventions. But this will pave the way for having stable telemetry that you can rely on, that you can alert on, that won't change underneath you going forwards. The current efforts are underway across a lot of different semantic conventions. There's specifically SIGs that are focused on database semantic conventions, messaging, system, and most recently, LLM semantic convention SIG has started up, and I will, I know that's a topic that interests, if that is a topic that interests you, I will point you to Alelita, she is helping to drive that group. And we did recently, we are trying to get to stability on database semantic conventions. We recently extended that effort by another six weeks, and probably will take a little bit longer, but we think that's really valuable work. And semantic conventions are a great way to get involved. If there's semantic conventions that are important to you, and what you are doing, we have a weekly SIG, we have a repo, we invite people to join and contribute. Hello. So now that we've got current stable signals for metrics, traces, and logs, we've been focusing on how we understand the applications that we deploy in complex systems and how we the experience that we provide with those applications. But now it's time to extend the remit of open telemetry and to start to correlate those signals back to the user experience. So start to work on the client side instrumentation, there's a bunch of work that was done in that front. And also now linking it down to profiling as well. So we're able to get code level insights that are linked to the traces, the metrics, and the logs that our applications produce. So the big announcement from profiling is that the data model spec was finally merged, and profiling implementations are ready for takeoff. And this is not just me talking about from SkyScanner being a travel agent, but a travel company. But it's going to provide an easy way for us to use profiling, a universal model to all languages. So the profiling profiles are represented equally in all languages. And of course, being part of open telemetry being vendor neutral. But most importantly is the correlation with other signals from trace context with trace ID and span ID correlating back to profiles. And that basically allows the metrics and logs as well to be correlated, but also from those two individual profiles as well. And of course, as part of the resource correlation, because all that telemetry emanates from a single resource, we can then as well understand the relationships between these signals. And we're really glad to report as well that we have two donation proposals currently in progress, and that will kick-start the implementations for profiling. So that one is from Elastic, an EBPF-based profiling agent, and Splunk with Netbase profiler. But these new signals as well, and this new tooling comes with new challenges. On the client side, for example, that's been a lot of work to stabilize the events API to, for example, talk about concepts that we hadn't considered before. Like how do we represent user sessions? How is that tied to resource attributes, for example? And how do we propagate context from the client side all the way to the back end and back again to the client sometimes? And last but not least, we are finding the concepts like resource attributes that are now basically refining challenges and how that correlates to how we can support use cases for client side, for example, when we're thinking about how our resource changes over time. And what are the identifying attributes in that resource? So it's a new set that has just been formed to define the concept of an entity as a producer of telemetry and better represent the changes of entities over time. And with this, I'll hand over to Austin. All right. So one last thing is that if you follow the TOC repo, we have formally applied for graduation as a project. What does this mean to you as an end user, as a contributor? Let's look back. We originally applied to move into sandbox stage in 2019. We went into incubation in 2021. So we're right along the glide path to using our travel pun to continue to grow and mature the project. We believe that we've achieved a lot in five years, right? Not just the ability, not just our core mission of unifying, tracing, logging and metrics in one nice package, but also around our governance processes, our tooling, our APIs and our configuration. We're rolling out, we have a new security SIG that's putting together standards and software build material principles and applying those across the org. We're nearing version one of the collector, which is an incredibly important core component. And as you yourself can attest, open telemetry is used in production worldwide at hundreds and probably even thousands of organizations. So thank you. Graduation is a strong signal to the rest of the world that this project is here for the long haul. It's stable and will be something they can rely on for many years into the future. We've formally applied this month. So starting next month, we'll be kicking off third party security audits in conjunction with the CNCF to audit our core repositories. Over the summer, those audits will continue along with best practices, audits and remediation this fall that should complete. And we will publish the results of all these audits and fixes. And then they'll vote. And then we're going to have a really cool party in Salt Lake City, probably. And result, better open telemetry for everyone within the sound of my voice. So thank you all so much for your support. We would not be here without all of you as contributors and users. So before we move into questions, I want to talk about if for some reason you're here and you're wondering what this open telemetry thing is all about. Best way to learn is to go to our website, open telemetry.io. Check us out on github, our organization's open dash telemetry. You can find us on YouTube. We have a demo that you can download and install. We have an end user working group who runs a lot of feedback sessions and other things. And we have a booth, the open telemetry observatory. It's not part of the project, it's kind of set off to the side. If you go into the expo floor and go to the left, you will see it. But we're going to be there all day and all week with various feedback sessions and ways to meet the maintainers and ask questions and get help. So I hope to see you all there. With that said, let's move on to some Q&A. If you would like to ask a question, we have a microphone right here. So please stand up, get in the line. If you're a maintainer and you want to come up to the stage to answer questions, we would love to have you. So yeah, if Jurassic is here, any other GC members here? I think Anthony is here. Yeah, he all can come up. But let's go ahead and get to the questions. So hello. I have a simple question. We are here at KubeCon. And from my understanding, you cannot get full Kubernetes observability with the core open-elementary binary. And you need the hotel-contrib version. Can you tell us more about that? And regarding also the graduation process, the Kubernetes observability, is it part of the GA or is it as part of the country outside of the primitive? Anyone want to? I guess that's fine. Sure. So the Kubernetes components, they're not part of the core. They're only part of contrib. Contrib is not on scope for graduation. So it's not going to go into the security audit. But we see those components as essential for use cases like that. So we have a proposal for the collector in expanding the number of distributions that we have. So we have to first come up with rules. And with those rules, then we can start making other distributions. So it's likely that we are going to have a distribution for Kubernetes observability or for getting time through data from Kubernetes. But each individual component from the collector can also be consumed on your own distribution. So you can build your own distribution with the only components that you need that you want. So each one of those, they have also stability markers. So we can say that the Kubernetes events receiver is stable or it's off or it's better. And you can then consume that downstream distribution. Thank you. Also, I forgot to mention, TC members, please come on up if you want to be a part of the hotel party. Hi. I have a question actually about multi-tenancy, general multi-tenancy support. So this is something which we've kind of run into as a need, let's say, as we've started to adopt the collector more widely. Just an example, we use SPANOS. So tenancy is communicated via headers. And at the moment there's kind of a disconnect between the header setter, which requires a context or metadata information, and information which we can get from the pipeline. So I guess the question is, is there a SIG for multi-tenancy? Should there be? And if not, can we kind of, let's say, focus on multi-tenancy support or what would be your, that's the GC, what would your view be on future support for multi-tenancy and what we can do there? Who wants it? Ted? Yeah. So I would divide that into two pieces. One is what technical changes might you need to the collector just to support headers or other things you need to do what you're doing right now. The second thing would be, like separate from that, some kind of multi-official multi-tenancy support from open telemetry, the open telemetry way to do multi-tenancy. My only concern with that second approach is multi-tenancy is already a thing people do. And I would worry a bit about us saying, here is the square hole for you guys to bang all your different pegs through. I think there need to be some research done first about how realistic some universal approach to multi-tenancy would be. But I'm certainly saying in the meantime, go ahead and like join the collector SIG and especially if you're willing to do some depth work on the front. I don't think the collector SIG would be opposed to better header support. We actually have an experiment that we are trying to have and to end for that specific case. So tunnels work the same way as Loki and I had Loki in mind when designing that thing. But we're still, I guess the problem is we have a mismatch between what comes in which is a request context, like individual requests can have different headers and the data that goes out which they may be matched and the original request context is lost when we're matching, right? So we need ways to do matching based on context. I think we have that part in place already but we still need to run an end-to-end test to see if we can propagate properly the header that we received to the outgoing HTTP call with the proper header. I think we are missing one or two parts to that. So that solution is close to completion but perhaps not quite there. So if you have specific issues, open issues on for the collector and we can take a look. But on the second point, I think it's even more complicated because multi-tenancy is done differently by different companies, by different works. I would encourage you to start at least a working group perhaps to design or to document how it can be accomplished, how it can be done, so that other people when looking at multi-tenancy can follow your steps. Thank you. All right, next and again if you have questions please come get in line. I have a couple of questions. The first one was from the gentleman who spoke before Austin. So you had a slide just before the graduation slide. You're talking about there will be new signals and there will be new propagation headers? Yes, so I think that's something that's been was currently in progress but if you're like one of the challenges of client size, well propagating context from client side is that when you're opening a page there is no SDK being initialized. So you need to be able to propagate that context back from the server side. So the client side so you can link your initial navigation from the browser to the to the to the actual trace that loaded your that got the page look right. So that's something that's currently being discussed and I think you're as he is involved in this as well. So he's probably going to know more about that than me. But yes, how do we link that for example options being like server time and response headers and in your ways that you can actually link the trace that you start from the back end to the initial navigation from your browser? Okay, so this is an extension to the W3C header. There's a new version to W3C trace context the V3 and the V3 adds trace response to the W3C. So we have trace parent and we now are going to have a trace response. Trace response wouldn't be propagated back to the to the caller but the problem that we are having right now is if we establish a new header browsers are going to block that by default because those the headers that are propagated back to the client or what clients can read it's white listed fine. So it's it's a selection list and there are headers that we can make use of like the server timing header which is the one that we are proposing to use instead of a new header so so that we can piggyback on that. Okay thank you. It's the other one so I have I'm one of those 20,000 people who have made a contribution so I understand the I understand the request the response could be PRs are welcome but so now the specs are mature. We have the implementations of say I'm probably looking more at the collector contract here I think but the the plugins for tracing are pretty mature yeah like the loans have been done first and now we're supporting metrics for example some of those plugins are less mature or just metrics aren't supported at all in certain in certain plugins. Is there a broad roadmap of like I'll be just keeping doing new plugins or stopping to like make sure metrics of first-class citizens specifically for the collector or are you talking about like instrumentation packages? So like collected so my exact example it's not really important what it was but it was an exporter and there was a feature where you could if you if you're exporter if the capital exporter and you can petition metrics according to their trace ID so that's fine and it's not supported in format it's not supported for logs for example so but you know the fact is capital is not important but I can do same with tracing I can build a pipeline for tracing that won't work at the moment with logs and metrics so it sounds like the load balancing exporter? Yes yeah um and the load balancing exporter was made for for traces first like so that's the problem we were trying to solve or tell safely and so on then people came out and said yeah so we have this service map service a spent metrics processor and we need to do the same kind of routing based on the service name and so on I think it is supported for logs but perhaps just not just for trace IDs perhaps and also for attributes I don't know but I guess to the basic of the question actually reduce the question to the main point we have a collector view one group working on on establishing what we need to do to achieve GA for a collector what what does it look like to be GA for a collector we are having discussions and we I think I think we have a plan right now and we're following that plan and we are once we have the one then let's start let's make it stable for other components as well right but um at the very beginning we need to to make the core of the collector plus a few components like the hotel for the receiver and exporter we need to make them stable but if you have concerns about specific components of an issue for a collector in general that's the idea so we have a plan for a few components and we want to get good observability for them we want to get good documentation for them because those are things that are missing for some components and then finally call the collector if you want so that we can move on and you know start doing the same things for other things for other components and have people have a view of what is required to be stable yeah I do just to add on you had a general point about contrib that I want to point out which is open telemetry is not staffed sufficiently to maintain contrib across the board we are staffed to build the spec and the semantic conventions and define kind of how everything should work across different languages and across different instrumentation packages and we try our best to maintain a priority queue what we think are you know the most widely used packages but this is like an actual people power issue that the project currently has like it's not realistic for the core maintainers like the SDK maintainers in each language to also maintain all the instrumentation packages it's not realistic for us to be experts in every single library or framework or workflow that people need so this is an area where open telemetry really needs active contributors so if you make use of any particular packages in contrib consider stepping up to becoming a maintainer of that package we're happy to have you thank you can I ask since we have five minutes left just one question each thank you I will try to be brief um you may have actually just addressed it for your point about contrib I was I'm relatively new to hotel quite excited about the things that can sort of help enable us do more stuff and do more decoupley stuff um I was excited to read about the client site of telemetry and in my mind that's really around um like service libraries and things that services might want to shift to other people has there been any effort to reach out to some of the projects like open API to see if we can get some of that integrated within their library generation because I think a lot of these libraries for a lot of organizations especially bigger ones tend to be auto generated so we can auto generate libraries that come with hotel batteries included at the box that feels like might be used so I appreciate it's probably a prime contrib thing but I wasn't sure if anybody had thoughts about that what was it were broadly yes yeah we've we've had those conversations so I think I can respond to there's two parts one how we reached out to all these organizations no um but uh you mentioned uh instrumentation being embedded this is actually something we're very very very interested in we've um held off on I'm pushing this concept because we wanted to make sure enough semantic conventions and other things were stable before we asked people to natively instrument but open telemetry has been designed from the start to allow instrumentation to be embedded directly into libraries long term we see this as not just a solution to the contrib problem but a paradigm shift we would like to see in the industry currently people in general are very good about testing right and writing tests when they're developing software we would like to see that extended to observability thinking about the runtime characteristics of your library and using the open telemetry apis as a way to directly represent that and have a conversation if you're a library maintainer with with your end users uh about runtime characteristics so we think that's very important you probably hear a squawking about that a lot more uh in the future when it's one of the semantic conventions become stable awesome thank you thank you uh maybe one or two more so hey uh so regarding the browser we're user monitoring how is the timeline looking for like vieta and stabilize it this year or next year around any official what uh functionality will be included in let's say let's say q4 maybe yeah we are we do have a a client from sick uh it's been quite a backlog of work because uh clients are very event based um they do have traces right like when you're communicating with the server and that's very important but a lot of what you're doing is getting events spit out by the various like frameworks and runtimes so we first had to do some work to understand how we were going to represent events with an open telemetry that work is finally done uh so you will see uh the client groups starting to spit out a lot more semantic conventions around the browser and having a browser specific uh SDK uh come out soon as well so yeah like i said probably like later this year to get something in people's hands it's also the one that i mentioned to represent entities as like producers of telemetry this is a bit different on the client side we're like if you've got a resource attribute for example that may change over time like you change from wi-fi to 5g and that is you know something that you need to change to keep a history of that as well and yeah there's some work that needs to happen as a prerequirement for for things to get stable right on the client side and one thing that i've mentioned before and applies here as well if you're an expert i mean street expert in the topic join the series all right we are being people to help us we're being gonged off so um if you have any further questions please look for us at the open telemetry observatory thank you all for coming and have a great cube con