PANEL: OpenTelemetry Technical Committee Panel - Josh Suereth, Reiley Yang, Rynn Mancuso, Jack Berg
Summary
TLDRThe 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
😀 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.
😇 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.
🔍 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.
🛠️ 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.
🌐 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.
🛡️ 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.
📈 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.
Mindmap
Keywords
💡Open Telemetry
💡Technical Committee (TC)
💡Observability
💡Trace Context
💡Semantic Conventions
💡
💡SDK
💡Configuration
💡Instrumentation
💡Metrics
💡Entity and Resource Specification
💡Context Propagation
💡Collector
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]
Weitere ähnliche Videos ansehen
OpenTelemetry Governance Panel - Reese Lee, Juraci Paixao Krohling, Alolita Sharma & Daniel Dyla
Welcome + Opening Remarks - Austin Parker, OTel Community Day Event Chair
Behind the Code: Design Choices in OpenTelemetry .NET Metrics API and SDK - Cijo Thomas, Microsoft
Fine-Tuning Auto-Instrumentation - Jamie Danielson, Honeycomb
Leverage Microsoft Project for the web with the Project Accelerator
"Code is the Easy Part" by Evan Czaplicki
5.0 / 5 (0 votes)