PANEL: OpenTelemetry Technical Committee Panel - Josh Suereth, Reiley Yang, Rynn Mancuso, Jack Berg

Summary

The OpenTelemetry Technical Committee panel, led by Ren Manuso, discusses the members' journeys and goals for the project. Jack Berg from New Relic focuses on configuration improvements, Lilla from Microsoft emphasizes semantic conventions, and Riley Yang of Microsoft aims to enhance the Matrix API SDK. Josh Seret from Google Cloud highlights the importance of community involvement and the Entity SIG's work on resource detection. The panel addresses balancing developer experience across languages and the project's growth, emphasizing community empowerment and the evolution of OpenTelemetry.

Takeaways

• 😀 The OpenTelemetry Technical Committee (TC) consists of diverse members with different backgrounds and areas of expertise, all contributing to the project's growth and development.
• 🔧 Jack Berg, a maintainer for OpenTelemetry Java, aims to stabilize the log signal and metrics, and is currently working on file-based configuration for OpenTelemetry to improve expressiveness and ease of use.
• 🎤 Lilla, from Microsoft, has been involved in observability since 2016, focusing on library instrumentations and messaging scenarios, and is excited about semantic conventions and their role in standardizing data collection practices.
• 🛠️ Riley Yang, who has been with OpenTelemetry since its inception, is focused on the Matrix API SDK specification and improving the reliability and performance of OpenTelemetry for large-scale enterprise applications.
• 🤔 Josh Seret from Google Cloud emphasizes the importance of community involvement and the role of the TC in facilitating and supporting community-led projects and initiatives.
• 🔄 OpenTelemetry's development process requires prototypes in different languages to ensure a wide range of feedback and to avoid language-specific idioms in its specifications.
• 👥 The TC plays a crucial role in reviewing and stabilizing specifications, ensuring consistency across languages, and resolving conflicts when necessary.
• 💡 The TC is focused on empowering individuals within Special Interest Groups (SIGs) to lead and drive projects, rather than trying to manage every aspect themselves.
• 🛡️ Security is a key concern for OpenTelemetry, with the TC actively involved in addressing vulnerabilities and coordinating fixes across repositories.
• 🌐 OpenTelemetry is designed to be vendor-agnostic, providing a common API for telemetry data, and the TC is working to ensure that the project remains true to this vision.
• 📈 The future of OpenTelemetry includes a focus on refining context propagation, enhancing the developer experience for customizing telemetry, and potentially evolving the APIs to better leverage the foundational concepts of causality and context.

Q & A

What is the role of the Open Telemetry Technical Committee (TC)?

The Open Telemetry TC is responsible for guiding the project's technical direction, maintaining the specification repository, reviewing donation proposals, and ensuring cross-language consistency and stability in the implementation of Open Telemetry features.

Why did Jack Berg get involved with Open Telemetry?

Jack Berg joined Open Telemetry to reduce the time developers had to choose between using an open-source software piece that wasn't ready, like logs and metrics, and to accelerate the stability of these components within the project.

What is Jack Berg currently working on in Open Telemetry?

Jack Berg is working on configuration file-based configuration for Open Telemetry, aiming to provide a balance between programmatic configuration and environment variable-based configuration.

What brought Lilla to the Open Telemetry project?

Lilla was interested in library instrumentations and messaging scenarios, which led her to her current team at Microsoft, where she works on the AZ SDK and is involved with Open Telemetry.

What is Lilla's focus for the year in Open Telemetry?

Lilla is focused on stabilizing semantic conventions for messaging and databases within Open Telemetry, aiming to make the process less painful than HTTP.

How did Riley Yang get involved with Open Telemetry?

Riley Yang started as a C++ compiler developer and eventually worked on debugger profiling. He became involved with Open Telemetry through his work on the W3C Trace Context standard and later as a maintainer of the OpenTracing project.

What is Riley Yang's main focus as a TC member?

Riley Yang's main focus is on the Matrix API SDK specification and making Open Telemetry more reliable and performant for large-scale enterprise applications.

What is Josh Seret's background and how did it influence his involvement with Open Telemetry?

Josh Seret comes from the Scala language community and has a passion for open-source projects. His experience with observability in Scala and the strong community around Open Telemetry led him to join the project.

What is the process for stabilizing a new feature in Open Telemetry?

A new feature in Open Telemetry starts as experimental and requires implementation in a variety of languages before it can reach stability. The TC reviews these implementations across languages to ensure consistency and address any issues.

How does the TC ensure a balance between developer experience and cross-language consistency?

The TC involves experts from different languages in the specification process, reviews language implementations, and facilitates discussions to find a balance between idiomatic language use and cross-language consistency.

What is the role of a 'spec sponsor' in the Open Telemetry community?

A 'spec sponsor' is a trusted collaborator who can sponsor projects and has a meaningful approver role in the specification process. They help lead projects and contribute significantly to the Open Telemetry community.

How does the TC handle security vulnerabilities in Open Telemetry?

The TC takes security seriously. When a security vulnerability is reported, the TC works secretly with the reporter to understand the impact and scope, coordinates fixes across repositories, and ensures that patches are applied before making the vulnerability public.

What are some future improvements or refactorings that the TC is considering for Open Telemetry?

The TC is considering improvements around context propagation, leveraging the foundation of causality and context in Open Telemetry, and potentially revisiting the span events API for a more unified events approach.

Outlines

00:00

😀 Introduction to the OpenTelemetry Technical Committee Panel

The video script introduces the OpenTelemetry Technical Committee panel with Ren Manuso as the host. Ren works in the end user working group and facilitates the introduction of the panel members: Jack Berg, Lilla, Josh Serth, and Riley Yang. Each member shares their journey to the technical committee and their excitement for working on OpenTelemetry in the current year. Jack Berg, from New Relic, discusses his involvement with the Java project and his goal to stabilize the open-source software. He is currently focused on configuration file-based configuration for OpenTelemetry.

05:01

😇 Panel Members' Backgrounds and Contributions to OpenTelemetry

Lilla from Microsoft talks about her start in observability and her focus on library instrumentations and messaging scenarios. She expresses excitement about semantic conventions and her recent involvement in the technical committee. Riley Yang, also from Microsoft, shares his transition from C++ compiler development to working on the tracing protocol and his contributions to various OpenTelemetry projects. He discusses his current focus on the Matrix API SDK specification and the challenges of high cardinality issues in telemetry. Josh Seret from Google Cloud humorously recounts his less memorable path to the TC but emphasizes his passion for open source and his contributions to the metrics data model and semantic conventions.

10:01

🔍 Balancing Developer Experience Across Languages in OpenTelemetry

The panel discusses the challenge of maintaining a consistent developer experience across different languages while ensuring each language's unique idioms are respected. They highlight the importance of having a diverse group of technical committee members who can provide feedback on language-specific implementations. The process of stabilizing specifications involves原型 in multiple languages and reviews by TC members to ensure consistency and adherence to OpenTelemetry's overall direction.

15:04

🛠️ Specification Development and the Role of Technical Committee

The panel elaborates on the difficulties of specification development, especially in observability where users demand high performance with minimal overhead. They explain the technical committee's role in reviewing and stabilizing specifications, ensuring they are practical and effective across various languages. The TC also helps alleviate friction in wording that may be too restrictive, learning from different language implementations to find a balanced approach.

20:04

🌐 Empowering SIGs and Contributors in OpenTelemetry's Growth

As OpenTelemetry grows, the technical committee discusses strategies for empowering Special Interest Groups (SIGs) and individuals within them. The TC aims to set examples for efficient community work, delegate tasks, and focus on aligning work streams with OpenTelemetry's overall mission. They also mention the introduction of 'spec sponsors' to help lead projects and specifications, indicating a move towards community-driven growth.

25:05

🛡️ Security and Review Processes in OpenTelemetry

The panel touches on the technical committee's role in handling security vulnerabilities and the review process for language maintainers. They emphasize the importance of security, especially as OpenTelemetry aims for CNCF graduation, and the TC's responsibility to coordinate fixes across repositories. Additionally, they encourage language maintainers to seek TC reviews for their implementations to ensure alignment with OpenTelemetry specifications.

30:07

📈 Future Directions and Opportunities in OpenTelemetry

The panelists contemplate the future of OpenTelemetry, discussing the importance of context propagation and the potential for a more unified approach to telemetry customization. They also consider the evolution of the project, moving towards more value-added processing at the collector level and the possibility of local decision-making in distributed systems. The panel concludes by inviting contributors to engage with the TC through community meetings, Slack, or by creating CVEs for immediate attention.

Keywords

💡Open Telemetry

Open Telemetry is an open-source observability framework for cloud-native software. It provides a set of APIs, libraries, agents, and instrumentation to capture distributed traces and metrics from applications. In the video, Open Telemetry is the central theme, with the technical committee discussing its development and future directions.

💡Technical Committee (TC)

The Technical Committee in the context of Open Telemetry is a group of members responsible for overseeing the project's technical direction and specifications. The script features several TC members sharing their experiences and contributions to Open Telemetry.

💡Observability

Observability in software refers to the ability to understand the internal state of a system through external outputs. It is a key concept in the video, as the panelists discuss their work on improving observability through Open Telemetry, including the challenges and solutions in this domain.

💡Trace Context

Trace context is a standard for managing and propagating context information in distributed systems. It is mentioned in the script when discussing the development of a distributed tracing protocol and the efforts to converge existing systems with the W3C Trace Context standard.

💡Semantic Conventions

Semantic conventions in Open Telemetry are standardized ways of defining what data to collect and how to instrument code. The panelists discuss the importance of semantic conventions for ensuring consistency and reliability in telemetry data across different languages and platforms.

💡

💡SDK

SDK stands for Software Development Kit, which in the context of Open Telemetry refers to the tools and libraries provided for developers to implement observability features in their applications. The script discusses the need for SDKs to be reliable, performant, and consistent across languages.

💡Configuration

Configuration in the script refers to how Open Telemetry can be set up and customized. One panelist discusses their work on file-based configuration, which aims to provide a balance between expressiveness and ease of use compared to programmatic or environment variable-based configurations.

💡Instrumentation

Instrumentation in this context is the process of adding monitoring and telemetry capabilities to an application. The panelists talk about the challenges and future work in making instrumentation easier and more standardized for developers.

💡Metrics

Metrics in observability are quantitative measurements that provide insights into the behavior and performance of a system. The script mentions metrics as one of the areas where Open Telemetry aims to provide stability and standardization.

💡Entity and Resource Specification

The Entity and Resource Specification is a part of Open Telemetry that defines how to represent and identify entities and resources in telemetry data. The script discusses the need for a refactoring of this specification to improve resource detection and compliance across SDKs.

💡Context Propagation

Context propagation is the mechanism by which context information, such as trace IDs, is passed between services in a distributed system. The panelists identify this as a critical area for future development within Open Telemetry to better leverage the context for observability.

💡Collector

In Open Telemetry, a collector is a component responsible for gathering, processing, and exporting telemetry data. The script suggests that the collector will play an increasingly important role in the future of Open Telemetry, particularly for processing data close to the source.

Highlights

Introduction of the Open Telemetry Technical Committee members and their backgrounds.

Jack Berg's involvement with Open Telemetry through the Java project and his goal to stabilize logs and metrics.

Lilla's focus on library instrumentations and messaging scenarios, and her work on semantic conventions.

Riley Yang's transition from C++ compiler development to working on Open Telemetry and his focus on the Matrix API SDK specification.

Josh Seret's experience with observability in the Scala language community and his contribution to the metrics data model specification.

The importance of configuration file-based configuration for Open Telemetry discussed by Jack Berg.

Lilla's interest in stabilizing messaging and databases within Open Telemetry.

Riley's emphasis on making Open Telemetry more reliable and performant for large scale enterprise applications.

Josh's work on the Entity Sig to address problems with resource detection in Open Telemetry.

The role of the Technical Committee in balancing developer experience across different languages.

The process for stabilizing specifications and features in Open Telemetry.

The challenge of ensuring cross-language consistency while maintaining language-specific idioms.

The importance of community involvement and contribution to the success of semantic conventions in Open Telemetry.

The TC's strategy for empowering SIGs and individuals to extend the work of Open Telemetry.

The introduction of 'spec sponsors' to support and expand the work within Open Telemetry.

The future direction of Open Telemetry, focusing on context propagation and leveraging causality.

The need for a more unified way for users to customize telemetry data.

The potential evolution of Open Telemetry towards more value-added processing at the collector level.

Transcripts

hello and welcome to um the open

Telemetry technical committee panel I'm

Ren manuso um I work in the end user

working group and you today we're going

to meet the members of the technical

committee um Jack Berg lud Milla um your

was so new I don't know her last name

Josh surth and Riley

Yang and um I'm going to let them

introduce themselves um with our first

question which is what brought you to be

on the technical committee how did you

make this journey and what are you most

excited about working on this year in

open

Telemetry all right I'll start us off

I'm Jack uh I work for New Relic and I

got involved with open Telemetry through

the the Java project I'm a maintainer

for open Telemetry Java um I joined that

project maybe three years ago or

something like that and um so my my kind

of goal when I got into open Telemetry

was to uh reduce the amount of time that

you know you uh you you had to choose

between using an open source piece of

software and um that that wasn't really

kind of ready like logs and metrics and

were not stable when I joined the

project there were still ideas and so I

wanted to accelerate the the stability

of those and that's uh that's what I did

I I I worked on the log signal and the

metrics extensively uh and kind of drove

the implementations for those along with

some other folks in in Java and that led

me to the technical committee eventually

so oh I guess yeah the the followup for

the question was what are you most

interested in uh working on this year

I'm working on uh configuration file

based configuration uh for open

Telemetry so you know uh programmatic

configuration is right now your options

are programmatic configuration or

environment variable based configuration

and programmatic is very Hands-On and

and environment variable is not very

expressive so file configuration is the

best of both worlds it's supposed to be

expressive and exhaustive but

declarative so you don't have to you

know go write code in in a language to

to express what you need to your SDK to

do so I'll pass it on

now okay thank you hi uh you met me I'm

Lilla I gave a talk earlier um I work at

Microsoft I work on AZ SDK I started

working on observability in 2016 I think

uh my manager asked me okay you just

came back with uh from the service

development what is the hardest problem

and I told him okay log correlation and

I think I still work on it uh what eight

years after um so uh we've done some non

up on Telemetry non up on Tracing Our

custom thing in uh Microsoft for a while

but then uh there we went part of open

senses and eventually you were very

happy that um open Telemetry came out of

the result of it um so I was very

interested uh in library

instrumentations and messaging scenarios

and stuff like that uh so this brought

me to my current team uh and I'm still

super interested uh the more we look

into this the more uh things are not

there at like semantic conventions like

what I actually collect how do we

instrument and stuff and this is what

I'm really excited about that's what I'm

driving I've just joined TC thank you

for inviting me I'm super excited about

it um and I really want to continue

working in the space of semantic

conventions we're going to stabilize

messaging and databases this year I hope

everything looks like we should be able

to do this uh I hope it will be less

painful than http

um and yeah and then maybe we will see

there are so many other areas in up

Teter the semantic conventions just like

tras mentioned recently if it's

something about computers it's in the

semantic

conventions uh so I hope all people will

contribute we definitely need your

expertise um yeah thank

you hey everyone my name is Riley and I

work for Microsoft so I started as a C++

compiler developer and eventually work

on debugger profiling until I realized

uh the word need a tracing protocol so I

kind of invented my own distrib tracing

protocol and after that I start to

regret and I spend years trying to work

with the w3a trace context standard

trying to embrace that and and use that

to converge all the existing things that

we have and after that I work uh in the

open sensus project as a python open

sensus maintainer so I like I moved to

open time Tre on the first day so has

been there actually working it's been

five years and uh I worked on many open

Telemetry projects including open

Telemetry uh donet

C++ and open time Python and and I help

the semantic convention especially the

the donation of the elastic common

schema to open time Tre semantic

convention the convergence there and my

main reason now becoming a technical

Committee Member was The Matrix API SDK

specification because after tracing me

being stuck there and I volunteer to

help and just to answer a question

mentioned earlier this morning about do

you have to be a TC member to make

progress I feel I probably made more

progress before being a TC member cuz

after after being a TC member I try to

help people and I just realized there

are too many things happening and I

don't have the domain expertise so I'm

more willing to help people to be more

successful instead of drain my own

agenda and regarding my focus I I think

we have a reasonable set of Matrix

offerings but it's not done yet if you

look at how people use Matrix cdk for

high cardinality issue or uh are we done

with like the best practice and do we

have the best performing metrix I see

you probably know like recently we have

one TC member who's the father of Jer

he's trying to switch from premises cl

to open Telemetry client and is noticing

performance job so we know the bond

instrument we've been working on and we

haven't just made that to the SP I feel

my immediate Focus would be getting open

time Tre more reliable and performant

for the large scale Enterprise

applications to take a bet on then there

are many additional things I want to

explore for example uh how do we help

the open t Tre solution to be available

for extreme cases like the embedded

devices or super large scale

applications and in addition I think

more importantly when you think like how

open t Tre started we started by saying

people don't have an API that is vendor

agnostic they don't trust that like they

have to pick a vendor specific thing and

only send data to that place but then we

have the API we have a stable and

performant reasonably performant SDK

then have the problem of it's a like it

makes it possible for people to

instrument application but we don't have

the same language people will just send

whatever data they want and you won't be

able to interpret the data and this is

why we made progress on semantic

convention and with being successful

with the API semantic convention now we

have libraries like mea Shar this

morning the libraryies Frameworks

operating system they start to generate

lry and you as a developer with single

line of configuration can enable it now

we have a real problem we've made it so

easy for people to enable Telemetry and

I've seen customers like writing a

single line of code that's costing $3

million per day or like they can easily

enable tet Tre so they got privacy issue

they got security credential leak so now

it's time for us to think about how we

help people to collect TM Tre in a

reasonable way that is efficient that's

cost effective and yet compliant so so

so we bring this like it's very hard to

get Telemetry to a place where it's very

easy to get Telemetry and maybe overuse

it now it's time for me to think about

how we can actually control the balance

and and make people's life

easier thank

you so I'm uh Josh seret um I think uh I

don't actually remember how I got on the

TC and no one has noticed yet that I'm

still there so it's working out for me

um uh I I currently work at Google Cloud

I do observability there but I uh I come

from the Scala language community and I

just love open source so actually open

telary was a project where um I I

literally joined the team at Google

because I had an opportunity to work

here and I saw that the community was

strong that it had lots of vendors and

I'm like this is a project that's going

to succeed and I really want to get

behind it um so that's kind of what led

me to that I had a little bit of

experience with observability for Scala

because uh

if you don't know we reinvented every

single library in Java but in Scala

because Scala and uh we needed to

observe our you know thread system that

we had designed and we had designed it

to be as performant as possible which

means there is no

observability um so it was it was

wonderful trying to figure that out um

we ended up doing Java agent tricks and

stuff anyway so I got into observability

from that um within the TC uh you know I

did uh an initial I I was responsible

for the metrics data model specification

protocol and I did the initial

implementation in Java that Jack cleaned

up for me um started the semantic

convention group with Riley kicked off a

bunch of processes which L Milla cleaned

up for me

um so I I don't know what the next thing

I'm going to do whoever wants to clean

up entity Sig let me know um yeah but

that that's kind of the next thing I'm

I'm uh F TIG and I are working on this

entity Sig where um there's a lot of

problems with resource detection right

now

um I don't know if many of you know this

but every single SDK is not compliant

with a

specification by need right the

specification actually isn't something

you can Implement and have a good user

experience and so we want to fix that um

The Entity Sig is trying to figure out

how to fix that really dive into that

problem deeply and kind of solve it um

I'm also excited about semantic

inventions but you've heard about that

from everybody so far so I I don't feel

like we need to dive into it but I will

make a shout out to the Weaver project

which is a about code genning your

instrumentation I really think that the

future of otel right now is on tackling

the problem of instrumentation and

making all of the people who are

adopting it have a good experience and

really enjoy their life we don't want

people to adopt open Telemetry and then

realize there's a whole bunch of flaws

or problems or that sort of thing and

and and run into unsolvable problems so

like Riley said there's a lot of issues

with instrumentation and I really think

semantic conventions is that needed

component that we had to kick off and

stabilize to get stable instrumentation

but I also want to give a shout out to

this community because um semantic

conventions would not succeed without

you we have 12 active groups in it right

now um of which if you look at the four

of us kind of involved um here there's

no way we could be leading 12 efforts

that just doesn't happen right um I

think the GC was mentioned this before

the reason we're able to take on 12

individual semantic invention groups is

because we have so many people in this

community that are putting work into the

community and making it better right and

that's actually what I'm most excited

about with open Telemetry is like the

the energy and the vibe and everyone

kind of getting involved and trying to

make changes our job here is to make

sure you're successful we barely have

time to really do anything ourselves

it's mostly coordinating anyway I think

that's it for me

hello um so GC was asked a question

earlier that we said was dangerously

close to a technical committee question

so we're going to answer it um that

question was and I'm working for my

memory so I apologize if this is not

precise but how does the project find a

balance in terms of developer experience

between having a great experience for

each language and having the same

experience for each language so it's

easier for folks to learn across

languages um what is your role in this

balance as a technical Committee Member

and how do you wish that other

contributors from other sigs would help

you in that

balance uh I can start us off maybe

other people can add to this but I think

Daniel mentioned a lot of good content

earlier so um you know we write the

specifications in a in a generic way we

try to avoid language that would suggest

any sort of language specific idioms um

and uh we I I think probably the the

most important thing that we do is we

bring a lot of people to the table that

have expertise in different languages

and can kind of call us if we're doing

something in like a too uh like

objectoriented manner uh or or too much

of a functional manner we just kind of

steer clear of that and and and kind of

raise the language up um and then the

other thing we do is we have this kind

of we have this maturity life cycle of

any sort of specification feature um

where you know things start off is

experimental and then they have to be uh

implemented in a variety of languages

before they reach stability and we

typically require that the those those

implementations the language

implementations are you know across

languages that are quite different from

each other so you know it's not that

interesting that net and Java both

Implement uh you know a particular

feature we don't learn much about any of

the uh the kind of sharp edges we might

encounter because those languages are so

similar so um yeah that's what I'll say

about

that yeah so in addition to what Jack

said I I can share some of the things

I've seen in the past so first in order

for any spec to get to stable State we

require two or three prototypes in

different languages and as Jack

mentioned we decided that we're not

going to pick similar languages so for

example if we pick Java then we'll say

we have to pick something not a compiled

language and that makes sure we get

enough feedback the second thing is for

each individual language to uh stabilize

their API SDK for the public interface

we have a process they can seek help

from the TC review so the technical

committee will send a member there I've

been doing review for like go and PHP

and another language I've forgot maybe

python uh so so when you go through that

process you kind of see the similar

problem like do you want the language to

sit as idiomatic as possible or you want

to have some consistency and because the

TC member typically they work across

multiple projects they very familiar

with spec so we tend to be more pushing

from having that consistency and and

also people have experience working in

the industries they understand they have

the empathy that language should be

different so I expect the language

maintainers to take more position from

hey this is what we think the best for

the language and this is what we heard

from our users and the TC play a kind of

rule uh uh from the different angle so

we're saying this is a cross language

consistency then people will will look

into particular issue and they will

probably take some debate and this will

help to have a reasonable balance and I

will say uh as maybe Daniel mentioned

this morning it's a spectrum you can see

some people coming from the pure

academic background they want Purity

they want everything to be as uh close

to the language idiomatic way well from

other people who come from the back

background of I just learned open tary

Java I want to use open Telemetry

JavaScript I think they should be 100%

the same so we we probably try to cover

uh the Spectrum as much as possible

knowing that we won't be able to make

100% of the user based habit so always

say something like 80 20% is a typical

balance problem engineering and we're no

different in

that so I'm going to add one last thing

which is that I think um the

specification development is just really

hard in general it's a hard problem um

if you were to ask someone an

observability user right what they want

in terms of performance they want zero

memory usage they want zero CPU overhead

right they want 100% observability of

everything and everything collected

right that's like your ideal that's not

realistic so you try to go as small as

possible the other thing is what are

some of the most important moments of

observability when the app is crashing

you have to get the data out right so

you have to design that SDK so that when

everything's crashing and everything

else is failing you still work and so

the way that we try to do this across

the different languages um if you look

at how the tracing spec was written

it if if you read it by the letter of

the spec you'll see a Java interface but

if you read it by the spirit of the spec

right what you see is a set of methods

and utilities and conventions that

people should think about but really the

the verbage is loose enough for you to

do what you need to do in your language

to deal with those hard scenarios

because actually the language author is

in the hardest spot compared to a spec

author because of all of those crazy

complications that they're being forced

to deal with they need to make it look

like goel they need to make it look like

their language and they have to deal

with some of the hardest situations and

environments in software in my opinion

so like it's it's just it's a hard

bounce what you've seen us do when we

stabilize a spec is generally alleviate

friction in wording that is too

restrictive from the initial prototypes

and I think that's kind of the approach

we've taken right now is we might start

a little more restrictive and then

loosen as we need to based on what we

learn from different languages and we're

trying to not if you look at the metric

spec versus is the trace spec we started

a bit lighter with metrics and I think

logging is kind of similar in that vein

like we're now starting with looser

specs um because we've learned a better

starting

point I have one last remark to add uh

so most of the users would be happy if

they don't need to write any open

Telemetry code they just enable it and

it works and in this sense I think uh

what my focus is is that the dat they

get does not depend on the language as

much as possible uh so they can come

from net uh world and they can start

monitoring and debugging their Java

applications and understand what's going

on there without knowing much about Java

and this is how they can learn the

Technologies behind that they use so

they can switch One messaging library to

another and still be successful uh in

using this Library

so we're about halfway through the panel

and um we've got one more pocket

question and then we're going to open it

up to questions from all of you um so

obviously the Project's been growing

really fast over the last several years

and we folks who were around when the TC

started will remember that the initial

model was we'll have divide all the sigs

between the TC members and make sure

somebody's attending every Sig well each

of you could attend 10 sigs spend 10

hours of your week going to open

Telemetry meetings and still not attend

all the sigs at this point so how is the

TC planning to empower the sigs and

individuals within the sigs to support

and extend the work of harmonizing the

across the languages of open

Telemetry yeah so I I feel like Josh

sish and I briefly covered that during

the self- introduction so one thing you

you will see TC uh doing more and that's

something we've been doing is will help

to start something will help to

facilitate something uh but we're not

going to like spend all the time trying

to move every single project we try to

grow the community members by

identifying the project leaders and what

we really want is number one the TC

should set example for people how to

work efficiently with the community and

for people who are not very familiar

with open class country but they have

domain expertise we're happy to have

them like jump started and then like

we're very willing to delegate and give

people certain support and power so they

can actually help and drive things and

the TC is more emphasizing or focusing

on making sure that particular work

stream is aligned with the overall open

Telemetry Direction instead of like two

different Sig trying to invent competing

thing or some Sig trying to prioritize

their uh work without understanding the

overall open time Mission so things can

still be connected and make sense so in

that shell uh the TC is more willing to

help people to be more successful

instead of us driving each individual TC

member's

agenda uh so I was like as there's a

question earlier to the GC which is like

what does the GC do and I was just

thinking myself what does the TC do and

so it's it's good to reflect on that so

it's written down in the community

repository some somewhere what actual

roles and responsibilities are but um

you know in my own words it's there's

the specification repository we're

maintainers of that we have merge rights

to that so that's like a concrete thing

that we do um another thing that we do

is we review donation proposals we do

all the due diligence on that so if

anybody wants to add to the scope of the

open Telemetry project the GC

the the possible additions to the scope

and then the TC does due diligence

that's another concrete thing um we also

uh what was I gonna say

uh we vote when there's conflicts so

okay so when when when things go wrong

and a Sig can't come to uh an agreement

on a particular problem on its own uh

the TC there's this escalation process

where you can ask the TC to intervene

and we don't like to do that like we we

really only want to do that in in a

worst case scenario um when all other

options have been exhausted um and so uh

you know if you actually one thing that

that GC mentioned earlier is like how do

we add members to the TC and when I

think about the conrete responsibilities

I I think you know do we need to add to

the TC or do we need to properly Empower

people to be effective without

necessarily having that TC like title

and uh we just added this new role in

the community it's called Uh a spec

sponsor and I'm hoping that it start

starts to solve some of these issues so

a spec sponsor you know we we have these

projects that the GC talked about

projects and sigs spin up and they

require people to lead them they require

GC Le aison and they require like a TC

sponsor and so we're going to open that

up we're going to say it's not just the

TC that can sponsor it's also these

other spec sponsors spec sponsors is

this expanded group of like trusted

collaborators they've been around the

project for a long time they speak the

language they know the vocabulary and

they've done a lot of significant things

and we want to we want to you know

Empower them to continue to do those

great things and and and take on

additional scope and so you know spec

sponsors can sponsor projects they can

uh they have a a very meaningful uh uh

approver role in the specification they

they got that green check boox which you

know you get two of those and you can

merge as spec PR so um and spec PRS have

the the ability to impact 11 different

language imple implementation so there's

a lot of trust that goes into that so um

I'm hoping that you know and I don't I

don't think we've talked about this

formally but uh I'm hoping we more isn't

necessarily the answer but like you know

delegation is is is the answer

so just add to what Jack mentioned I

think there are two other concrete

things that TC has been doing one is as

open Telemetry is trying to get cncf

graduation State uh we take security

seriously and for some security

vulnerabilities reported uh the TC will

look into them secretly with the

reporter and to understand the Impact

scope and coordinate uh across multiple

repositories to make proper fix

sometimes it could mean we will secretly

provide the fix and work with the major

vendors and users to apply the patch for

making the vulnerability public uh

publicly available the second thing I

already mentioned is for individual

language maintainers when they finish

the implementation they can always look

for the TC to help to review their

implementation and we'll send someone

who's familiar with the language and

also more familiar with the spec to look

across the board making sure things got

well

aligned I'll also say for The Language

Reviews um you know I used Earl Lang

once in college I just huffed I didn't

really you know inhale um but anyway uh

I got to review erlang and it was like

enlightening like this is actually

something if you're interested in open

Telemetry you want to learn a little bit

right um go review the STK

implementations across languages because

there's some interesting things you find

out and there's some really cool things

that like people were doing out of the

box I think erlang was the one that

taught me that we should have a default

uu ID in every SDK that we provide out

of the box that's a thing our Lang does

um and that's where we started trying to

push service instance ID which again

actually jassi cleaned up for me um

after I kicked it off in in tradition of

my hotel contributions

anyway okay so we've got time for a

couple of audience questions um anybody

five minutes okay we've got five

minutes anybody

yes

jassi anybody else have a question

before jassi

since go for

it perhaps for Josh um I see the

entities and um resource S as the first

big refactoring that we have in a

project um once that is done what is the

next one

I'm sure other people will uh jump in

but um so I'm G

to we only have five minutes I'll try to

be brief um I think the foundation of

open Telemetry is context actually the

foundation is causality what caused

something that's what you're trying to

figure out that's why we pass Trace IDs

to actually link causality context is

core context is King context is how you

start an SDK it's the most important

initial implementation you look for and

that's when you do a code review of an

SDK that's the first thing you actually

follow to make sure it works right one

thing that we have failed to do because

we specified things incrementally is

blend all the signals together and

really leverage the fact that we have

context and do really cool things with

context I think um the uh baggage is one

of I think the biggest travesties you

can't interact with it out of the box by

default without manually changing

instrumentation right we tried to push a

little bit on that in the metric spec

and we got some push back I think that

you know the next missing or or like

refactoring that needs to happen is

basically around context propagation and

leaning more into the fact that we now

have a foundation for otel and the kind

of observability and causal

relationships we can derive from

that anyone

else do you have I have oh

sorry yeah uh so uh I think to add to

what Josh just said uh we do a great job

with Auto instrumentations and we can do

a better job uh but what is hard is for

users to enrich this Telemetry or to

change it in different ways to fine-tune

it and is uh with the new convenience

development experience uh project I hope

we can start tackling this problems like

how users can customize this Telemetry

in a uniform way and how they can add

their application context uh or data

into the Telemetry that's already

collected for them by the

libraries I have to talk about span

events so uh we have like we have a

language problem so we have you know I

think Josh talked about incremental

development of the project would we

still have a span events API if we were

starting from scratch today I don't I

don't think so I think we would have an

events API um and you know you would

correlate those logs to those to to the

spans um and so uh a lot of people are

thinking about this thing we just got to

get the ball over the finish line so

Ted we're looking at

you you don't need to be on the TC to

get stuff done we talked about how it

actually hurts your productivity

I I I feel as we're getting more success

in open tet with more instrumentation

libraries we'll start to see more and

more overly observed uh like services or

applications and one important thing

when you look at like how our body works

we don't observe everything like if I

look at maybe then I have my focus on

him everything else seem blurry but I

know what's happening like generally so

I I feel like open time will eventually

be in that state and the the center of

the gravity is open tetri collector so

the key thing is you're able to process

the data close to the source and you

only send maybe highly aggregated or the

summary data to the next hub then you

have efficiency so I feel like the more

investment we're going to see from from

different layers of processing instead

of just collect all the data and send

all of them to the back end and then

make a central control there especially

when you think that's this word is

distributed by Nature like why would you

decide to stop a deployment in a local

data center by sending all the Telemetry

to a central place and then have the

central place tiing the local data

center to stop deployment you should be

able to decide that within the local

data center even if you don't have

internet connectivity to the global

instance so so this is how I I feel like

open Telemetry will eventually evolve

the apis SDK is more like the foundation

and eventually we'll see more value add

it on the collector and injection

side we're almost at the end so I'm

going to ask one more question where can

contributors go to ask you more

questions to learn about what the TC is

working

on so all the TC members are pretty

active uh you can either see them in

some open Telemetry meetings uh if they

drve by particular s or I I I believe

like all of them are monitoring like

slack actively so if you want to reach

out to any of them first you can go to

the open tary Community page so you see

a list of all the TC members then you

can reach out to them on slack worst

case if you haven't heard from any TC

member you can just create a cve and

they'll get alerted on day one

thank you everyone that's our panel for

the day

[Applause]