 So we'll get the show on the road, but you don't lose time. Okay, hey everyone, thank you for joining us today and welcome to conduct. And then I'll hand over to Reese Lee, Developer Relations Engineer at New Relic. A few housekeeping items before we get started. During the webinar, you're not able to speak as an attendee, but there's a chat box on the right-hand side of your screen. Please feel free to drop your questions there and we will get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct and please be respectful of all of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF online programs page at community.cncf.io under online programs. They are also available via your registration link you used to join today and the recording will also be available on our online programs YouTube playlist. With that, I will hand things over to Reese to kick off today's presentation. So take it away. Thank you so much, Libby. Hello, hello. I hope everyone's summer is off to a great start. I hope it's not too hot or too wet where you are. Please stay safe. Of course, I'm saying happy summer as I'm in a sweater. I'm in the Northwest. So welcome to today's CNCF Live webinar hosted by me, Reese Lee. And thank you so much for being here or if you're watching the recording, thank you so much for doing so. I gotta say I'm very excited about my title. Oh, tell me all about open telemetry, the current and future state, navigating the projects and getting involved. You are likely familiar with it, but hotel is sure hand for open telemetry which is why I'm so stoked on the session title. So to start, I'm going to take you through our agenda for the session. I will first kick things off with a few introductions and then we will get into the current and future state of the projects, navigating the projects and finally getting involved with the project. We should also have some time at the end for some Q and A for any lingering questions about what we've covered today. So if you have any questions, feel free to pop them into the chat as Libby said at any time and then I will circle back to it during the Q and A session at the end. So the very first introduction I'm going to do is for myself. My name is Riesli. I am a developer relations engineer on the open telemetry community team at New Relic where I am based in Vancouver, Washington. I previously worked directly with observability end users as a technical support engineer and that's something that I really, really enjoyed and I'm glad that I get to continue working with end users in this role. I also enjoy learning from and working with project contributors. So I am very excited to share this presentation with you today. Also, real quick, I have a tendency to talk fast. So if you need me to slow down, please feel free to write it in the chat. That will also be a reminder for me to slow down. So please do so if you need me to slow down. Before we get into the meat of this webinar, I just want to set the stage for the why behind it. So having worked with end users directly for some time now and also seeing what came up from discussions and meetings at EuroCubeCon that was just held in Spain last month in May, two things are very clear. One, people are very excited about open telemetry. They want to learn about it. They want to know how to use it. They want to actually use and adopt it within the organization and allow them want to get involved in some way or another. However, most people don't really know how to navigate the community and the project. For example, where to go to get help or how to contribute or even what to contribute. Two, the project and community can use quite a bit of help and I'll cover this in more detail later on in this session including not just how to contribute but also why you might want to contribute. So therefore the purpose for this webinar is twofold to help end users navigate the community and the project and also to encourage contributions to the project. All right, so if you're watching this today you likely already at least know what open telemetry is. So I'll just do a brief refresher intro here but then I am gonna get into a little bit more detail about some of its architectural components to help you solidify your understanding and knowledge during the navigating the project section. So what is the open telemetry project? It is a collection of tools, APIs and SDKs that you can use to instrument, generate, collect and export telemetry data so metrics, logs and traces to help you analyze your software's performance and behavior. It was first developed in 2019 with the merging of two competing open source instrumentation projects Open Tracing and Open Source, Open Tracing and Open Cessus and it is now the second most active CNCF project after Kubernetes. So that should give you an idea of its popularity. Also, as important as it is to know what open telemetry is it is also important to know what it is not. Open telemetry is not a backend or storage solution. It's not an observability platform. It's an observability framework. See, this is what I mean when I talk too fast. Okay, I'm gonna consciously slow down now. Open telemetry provides instrumentation standards for generating telemetry data but it's not an observability solution by itself. It doesn't include visualizations, alerts, queries or storage capabilities to provide business value for your organization or just to see how your service is performing you need to send the raw data to a backend to be analyzed. Of course, there are multiple open source backends available such as Yeager, Zipkin, Prometheus and numerous observability platforms such as New Relic, Honeycomb, LightStep, Datadog and so on. All right, now let's take a look at the current and future state of open telemetry by answering these two questions. First, what is the current state of the project? And next, what is new and upcoming? So I wanna start by stating that the development of open telemetry occurs on a signal by signal basis. And what I'm referring to you as signals is just traces, metrics, logs, baggage. Signals are built on top of context propagation which is a mechanism for correlating data across distributed systems. Each signal consists of four components, APIs, SDKs, OTLP and the collector as well as contrib components. To get updates on the statuses of the project on the main hotel site, visit opensillometry.io slash status. Okay, now let's look at a high level overview status report for traces, metrics and logs. This table was shared during the open telemetry community day that just took place in Austin, Texas on the 20th. If you had the opportunity to attend, that is awesome. If you did not, I wanna give a shout out to Paul Bruce who is an AliFest organizer and who is very passionate about observability. He put together a pretty detailed rundown of the event on his blog, paulesbruce.io slash blog and I just realized I did not include that in the slide but let me know if you need the link again and I'll share it with you at the end. But again, that's paulesbruce.io slash blog. So as you can see and as I'm sure you're aware traces has been G8 for a while now, metrics is quickly getting there with a current number of five release candidates and this is just since it was announced back in May. And also earlier I showed a link to the status page on the main website. So that's great for getting high level updates but it is recommended that you check the read me in the specific GitHub repos for more detailed information. I also mentioned baggage earlier. It's not included in this table. It is still considered a signal and it is now completely stable. Baggage is not an observability tool. It's a system for attaching arbitrary keys and values to a transaction so that downstream services may access them. So this is why there's no OTP or collector component to baggage. Just wanted to give a little bit of background on that since I did mention baggage. What's new and upcoming? So as I mentioned, metrics release candidate and general availability or JReleases profiles are being added as a new signal. This was I believe also just announced at Hotel Community Day. Logging GA is targeted for next year. So that's pretty exciting. And I have written down here instrumentation, availability and quality. So there is an effort to expand the availability and quality of open telemetry instrumentation. I believe it's scheduled for this summer but of course things are subject to change. So I would keep an eye on the documentation for updates. So this work includes providing instrumentation for a wider variety of important libraries as well as providing testing and CI CD tools for writing and verifying instrumentation quality. This next one here, Community Demo Application SIG. This began, I wanna say last month in May. So very new, but the goal is to develop a standardized demo application that is jointly written in stages starting with producing metrics and traces. This is, so the reason this SIG came about with my understanding is as the project matures and customers are increasingly looking for more onboarding guides so they can try the tools themselves. There's a lot of demo applications by multiple vendors but there isn't a standardized one provided by the community. And so that's what the SIG aims to do. If you're interested in helping that out, I recommend checking out the SIG meetings which I'll cover a little bit later on how to do that if you're not aware of how to do so. And speaking of end users, the end user working group has been working hard to get feedback from end users with the goal of providing a space for all of you to get together and talk about your experiences and share feedback with each other and challenges that you faced with using open telemetry, whether in your organization or just on your own. Stay tuned for more information about this as it is still being developed. But again, I'll cover this a little bit more later as well. Okay, so I got distracted by the chat, okay. Okay, so now we're going to move into the section of navigating the project where I will go over the following. Core concepts and components, the community and a few of its components, SIGs, governance committee, technical committee. And I'm going to touch a bit on documentation as well. And finally a bonus section about OTEPs, oh snap, okay. So there are a lot of moving parts in open telemetry. So I want to take some time to kind of break them down by answering the question, what are some of the various open telemetry concepts and components? The terms I've listed here are ones you will hear and see frequently as you learn about and use open telemetry. Understanding what each one refers to will help cement your knowledge and enable you to effectively navigate the project. The open telemetry API, you'll hear APN SDK a lot. And so I want to kind of differentiate the two. So the open telemetry API provides a standard way to collect instrumentation data. It's used by app developers and library authors to instrument their code to generate telemetry data. The API defiance interface with which you work with data, but it also requires an implementation that does effectively nothing. This minimal implementation has very low overhead and no side effects. So the API defaults to a no op provider, provider here being referred to as the SDK. If no provider is loaded when an app starts. This means that without the SDK, the API call simply become no ops. In other words, an SDK has to be loaded so that we can use the API. The open telemetry SDK provides standard ways to configure what happens or what we want to do with the instrumentation data that's collected by the API. Essentially, the SDK is the implementation of the API or how we utilize the API. Generally resource creation and configuration occurs in the SDK, app developers use it to configure open telemetry for their environment. Semantic conventions. So these are conventional attributes that describe common software operations, technologies, events, protocols. Its power lies in bringing uniform needs to data, which allows backends to then easily parse and identify relevant information. So for example, HTTP or database calls are consistent regardless of which platform or language is being used. So if a Python application calls a Donut application, you can rest assured that both of those applications will conform to HTTP conventions. For example, the HTTP dot method attribute, which is used to specify how the call was made. For example, I get a post or put. These will be uniform across the Python and Donut applications. For example, the open telemetry specification or spec provides blueprints for all of the above to bring standardization across all languages. For example, the spec defines a standardized data model for what a trace is, what an exporter should do and what is required to create a resource. Anyone implementing open telemetry can expect the behavior to be the same across different language SDKs they are using. The caveat here is that because the project is still evolving, actual behavior may vary depending on the level of maturity within each specific language. The collector, it is a standalone service provided by open telemetry. It is a highly configurable system for processing data that you can use as part of your observability strategy with open telemetry. It is made up of three main components that access the telemetry. You've got receivers, processors and exporters. Some of the things that a collector can be configured to do are sampling, collecting host metrics and scrubbing data of sensitive information. I do want to note that to export telemetry that's generated from services to a backend vendor, you can either one use the SDK to configure and export it to send data directly to your backend or use the collector, which is also great for centralizing configuration and performing additional data processing. Finally, we have OTLP or open telemetry line protocol. It is a description of how each data signal should be encoded and transferred over open telemetry's exchange protocol. The OTLP spec defines how OTLP is implemented over the open source GRPC protocol and HTTP 1.1 transport and also specifies protocol buffer schema that is used for the payloads. Okay, I hope everyone is doing well so far. I'm gonna continue on with talking about the SIGs. So what are the SIGs? The community is organized into multiple SIGs or special interest groups. They exist to improve the workflow and to more efficiently manage a community project. Each SIG meets regularly over Zoom. And if you're unable to attend any meeting notes as well as recordings are available. And there exists a SIG for just about every component of the project. There are language SIGs, some of which are broken down into more specific ones. For example, there's a SIG for both Java, SDK and instrumentation as well as JVM metrics. .NET has one for instrumentation and then another one for the SDK. There are also SIGs for instrumentation, the specification, communications, which handles like the blogs and the website and more. There are two governing bodies for open telemetry. The first one is, well, I guess I know a particular order. The first one is government's committee, all positions on this committee are elected and its role is to be a live responsive body that can refactor and reform as necessary to adapt to a changing project and community. The next one is the technical committee. The technical committee is responsible for all technical development within the open telemetry project. And I will list a few here, setting release dates, quality standards for releases, technical direction, GitHub repo management and et cetera. So the technical committee recognizes that maintainers of specific languages or sub-projects have significant autonomy over their SIG and implementations. So the committee's focus is on cross-project or disputed concerns. The primary goal is to see consensus to develop an appropriate technical solution. What about documentation? So documentation as you will hear in just a bit is actually one of the biggest areas that the community needs help in. The SIG that oversees documentation is the communication SIG. If you have checked out the docs before but haven't looked in a while, I recommend doing so as there's already been a lot of improvements to the structure and docs themselves over the last couple of months. I also want to note that since each language has its own maturity level and contributors, you will find that some languages have more comprehensive documentation than others. However, there is currently work being done by the communication SIG to standardize the docs, one of which is creating a getting started template. And of course, if you're sending your open telemetry instrumented data to a backend vendor, those backend vendors will also have their own documentation that might be helpful for you. Bonus, what are OTEPs? So OTEPs, open telemetry enhancement proposal, I wanted to include this because I personally found them quite interesting. Open telemetry uses the OTEP process for proposing changes to the open telemetry specification. A requirement for submitting an OTEP is that it must be a cross-cutting change that either introduces new behavior, changes desired behavior, or otherwise modifies requirements. And cross-cutting just means that it's applicable across languages and implementations. Some examples that an OTEP should be used for are additions to SPAN data, new metric types, new tracer configuration options. On the other hand, they do not need to be used for things like bug fixes, rephrasing grammatical fixes, typos, et cetera, refactoring, as well as things that only affect a single language or implementation. A few OTEPs that are currently open are support real user monitoring events in open telemetry, add sensitive data labels, and add remote sampling. So just to kind of give you an idea of what has been proposed. There are guidelines in the Hub repo on how to submit an OTEP if anyone here is interested. Okay, so now that you have learned about the various parts of the project and the community, let's talk about getting involved. We'll answer these two questions here. How do I get help with using open telemetry? And what areas need help? And why should, slash, how can I contribute? I probably could have broken that up now that I'm presenting, but anyways, we're gonna go with this. So all right, you have been using open telemetry, you are running some issues, and now you're asking, how do I get help with using open telemetry? So there are many options available to you. CNC of Slack is a great way to interact with the community and other end users. You will have to sign up for an account with Slack if you don't already have one yet to join the CNCF workspace. Once you are in, you can search for the general open telemetry channel, or if you're looking for assistance with a specific component, just type in otel- and a bunch of options will pop up. For example, you have otel-python, otel-sampling, otel-collector, and people are generally pretty responsive from what I've seen in there. There are also vendor-specific channels if you're having trouble with your open telemetry and instrument data in the backend vendor you are sending your data to. For example, there's otel-neuralic or they might have their own community Slack. So for example, Honeycomb has their own community Slack as well. Alternatively, you can also go to otel-vendor. GitHub. So I believe most of you are probably familiar with how to utilize GitHub. I personally like heading there to search for issues to see if anyone else has encountered the same or similar issue that I'm facing or to open an issue if it hasn't been brought up before or also just to get specific component updates. One more that I wanted to bring up. Earlier I mentioned that the end user working group has been hard at work developing a space for end users to meet and discuss their experiences and challenges with each other, with each other. The plan is for it to be a space where discussion topics are generated and democratically selected by the group at the start of the meeting. At this point in time, an invite is required to join the channel. Please reach out to either Rin Mancuso or myself. You can find us both in CNCF Slack or at LinkedIn. And because things are subject to change and delays, keep an eye out in Slack or feel free to reach out to one of us or anyone in the otel-user-research channel. Okay. So this next section is gonna be divided into three parts that answers this three part question that I really should have just broken out. Anyways, we will see real quotes from people who have contributed to the project, both regular contributors as well as end users. First, what areas need help? So honestly, everything could use some help. There is so much to do within the community. I spoke with Tide Young who is a co-founder of OpenTelemetry and documentation, as I had mentioned previously is in need of a lot of love. So if you wanna do non-code contributions, that's a great way to get involved with the project. The PHP SIG also could use a lot of help. And he also mentioned instrumentation, but specifically defining semantic conventions and maintaining contributed instrumentation where areas that need the most help. Okay. And why should I contribute, you're probably thinking. So I can sit here and tell you why you should contribute with like a bullet point list or something, but instead I'm going to share some quotes from project contributors. The first one I'm gonna share is one I like a lot. It sums up my opinion as well and demonstrates why I'm so personally passionate about working with end users within the OpenTelemetry community. So Tide Young, as I mentioned, he is a co-founder of OpenTelemetry. He's also the director of developer education at LightStep. He says, implementers have one view of the universe and end users have another. We need more end users to speak up and have a voice in the project. And I really don't even have anything to add there. It kind of just sums it up real nice. I also talked to Jurasi Crowling who is a maintainer on the OpenTelemetry project and works at Grafana. He had an interesting perspective that I really appreciate and I'm excited to share with you all. So he said, instead of listing out reasons why people should contribute, he would rather try to convince companies to encourage their collaborators to contribute on company time. So for him, the biggest advantage is that companies can help shape the project's direction according to their needs. And I don't mean it in a bad way at all. A lot of times the project maintainers make decisions based on what they think users would want. Sometimes we have data or requests from actual customers but it's not the same thing. Having the opinions of a diverse user base is essential for the project's success. So that last bit kind of ties in with what the first quote that I shared, right? So the quote continues, but one thing I see companies doing wrong is just telling their folks to contribute without a strategy in mind. So my advice is to focus on the areas that matter to the company where they plan and strategic direction. If they can get measurable goals attached to the company's own goal, so much the better. This way their open source contributions become relevant to the company. I also want to add here that he is aware that open source contribution isn't for everyone. There are of course gonna be developers who are not comfortable with having their work being visible in the open and companies should respect that as well. And next I have a two-part choice quote from Daniel Dyla, who is a JavaScript maintainer as well as a government's committee member. He is a senior open source architect at Dynatrace. So he says, I love working in open source because it's global nature exposes me to a very diverse set of people, ideas and opinions that would otherwise be difficult to tap into. We love that by the way. And he goes on to say, I also especially love the community feeling in open telemetry where vendors and platforms who would ordinarily be considered competitors can work together to improve the state of the ecosystem for everybody involved. Here is a quotes from an end user who has also contributed to the Ruby open telemetry project as well as helps this company adopt open telemetry at GitHub, Arielle Valentin. So he says that as the rest of the world embraces remote work and ascent collaboration, participating and contributing to open source software helps hone your skills. If you have not worked for a remote first company before, joining an open source software project will help you gain real world of experience, which I think is a really great point to add, especially for those of you, as he mentioned, who hasn't worked for a remote first company or just kind of wants to stick their teeth into a new and exciting project. Here is a quote from an end user who has also contributed to the PHP open telemetry project. He had a few points to make here. It was a great way to learn about PHP stuff from experienced people, given that he had little. It also helped me learn more about open telemetry and the observability space as a whole. And it was a fun gateway to other open telemetry channels to learn even more and be aware of more people too. Okay, I'm gonna finish it out with one last one. I hope you all are enjoying these quotes. This one is from Henrik Rexed, and I think it sums it all up pretty well. By contributing to an open source project, you will learn a lot from amazing engineers, be at the forefront of innovation. And if the project is a success, being proud of all the work done. Okay, so maybe I have intrigued you or you're already interested in contributing. How can you contribute? How can you do so? So there are multiple ways to contribute. It really comes down to what you're interested in. Of course, it has to be sustainable as something that works for you. And also how you think you can best help. I do wanna mention that the community welcomes both code and non-code contributions. Some examples of non-code contributions are documentation, blog posts, and as Jurasi from early pointed out, there isn't only space for code contributions. Most projects would love a more professional project management as well. So if you're interested in contributing to a specific part of the projects, I would recommend that you join the appropriate SIG. You can also send it from mailing lists and also attend community meetings, which are available on the Google public calendar. They also have other two other public calendars if you don't like Google calendar, but the link will be at the end of this presentation. Another way to contribute is simply by sharing your feedback and experiences about using OpenTelemetry with the community. I've listed two channels here, hotel-user-research, wow, I will learn to talk someday, you guys, which is public. And there is also an invite-only channel that I mentioned earlier. We talked to myself or Rin Mancuso. I believe the slide deck will be available after this. In any case, the recording will be, so if you need to go back, or feel free to ask in the channel, oh, okay, perfect, Libby said yes. So the slide deck will be available after this as well. And apparently I did talk quite fast because I see that we have reached the Q&A. So what else would you like to know? I will go ahead and check out the chat section in a bit, but yes, the slide deck will be available via the registration link as well as cncf.io. Okay, let's see, oh, actually, let me leave you all with this, leave the slide up so that you can kind of see. Although you know what, I just realized that you can actually click the links. So anyways, I'm just gonna keep it here and if you have questions, feel free to pop them in. Okay, so first one is from Florence. Florence, why are logs behind in the roadmap? Jack Berg has answered, oh, thank you so much. .NET and Java have stable metrics releases. Logs are behind a bit because Open Solometry was the results of the merging of open traces, open tracing and open sets, which were comprised of the trace and metric signals. Logs are net new and it was natural to focus on metrics and traces first. Oh, and Alan West says, added on to that. That said, .NET and Java too have some pretty solid support for logs with some of their common logging frameworks. Thank you. And okay, where is the collector running? App are back inside. And Tyler Helmuth, also, I just want to mention that answering, thank you all so much. This is so great. So Tyler says, the collector is a standalone solution. It can be run many different ways, but is never part of the app itself. It runs somewhere and collects data either by applications sending it data or by it reaching out and asking for data. The closest it can get to the app would be a sidecar or a separate process running on the same machine as the application, but it is always its own process. So Florence, hopefully that answered your question. And I think that was all that we have so far. You can always feel free to reach back out to me if you think of anything after this, which I know often happens to me. And otherwise, I guess I'll hang around for another few minutes to see if anyone has any other questions or I guess everyone can- Yeah, y'all definitely pop something in the chat if you have any questions for Reese. Oh, thank you, Love Will Smith. You know, I debated about using this because of the whole Chris Rock fiasco, but it was like the perfect image to use for this age. I'm glad someone loves Will Smith still. Does anyone else have any more questions for Reese? Or also, if you have like anything to add to what I have covered, that's also very welcome. Oh, thank you. I'm so afraid to pronounce your name because I don't wanna ruin it because it looks very cool. Maruan, Marianne. Okay, I hope that was close. I know. I hope it was not. But thank you so much for being here and thank you and you're welcome. All right, well, if no one has any other questions, we will give everyone a few minutes back. And again, all of this will be posted on cncf.io on our YouTube channel. You'll be able to link to it through your registration link. And thank you again, Reese, so much for your presentation and for your time. And thank you all for joining us for another cncf live webinar. We'll see you again next week and be looking soon for Q3 calendar openings. So everyone stay tuned and we'll see you next time. Thank you again, Reese. Oh, no, thank you so much. And thank you real quick to Gerardo and Cadiz Soran. Oh my gosh, I hope I got your name right. Thank you. All right, thanks everyone. Have a great day. Bye.