Cloud Native Computing Foundation Cloud Native + Open Source Virtual Summit China 2020, 11 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Intro: OpenTelemetry SDK Design and Implementation Values - Sergey Kanzhelev, Google

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Intro: OpenTelemetry SDK Design and Implementation Values - Sergey Kanzhelev, Google

OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools. OpenTelemeetry is now in beta. Different platforms chose different values developing software system. This talk describes the principles OpenTelemetry values the most building the best telemetry solution. It explains how hard it may be to keep it simple, yet performant and expressive. Finally, you will learn how you can contribute.

https://sched.co/cpAP

A

Hello, you are at the maintenance track open telemetry session at cloud native and open source, virtual assignment china 2020.

A

We will talk about software design and implementation values that will follow in open telemetry.

A

My name is sergey kangel. I have more than 15 years experience in application monitoring, I'm a technical and governance committee, member for open telemetry and currently working at google on google kubernetes engine.

A

You can find me on github, twitter and linkedin at sergey kanjima.

A

Today we will talk about different topics, but the main goal of this talk is to introduce you to open, telemetry and explain how you can get involved.

A

I also will talk about goals and aspirations that open telemetry project has started with its core values that we follow thoroughly.

A

First, let me introduce you to open telemetry. I will approach it answering three questions: what what is open telemetry?

A

Why why we need open telemetry at all and how how open solemnity can solve the problem that I will explain.

A

Let's explore the aspirational goal of open telemetry that you can find on our website. It is to make robust, portable telemetry a built-in feature of cloud native software.

A

We believe that every application needs to be transparent to its owner in terms of troubleshooting, monitoring and observability.

A

It shouldn't matter. If you developed this application yourself or simply compiled it as a binary from different components from numerous teams, there should be a single way to get observability signals.

A

Standard output is a good example of that approach, no matter which component you use, no matter which library your application calls. There is a pretty good chance that this library can't uh can lock something to send it out, and you can find most of troubleshooting information there.

A

Given the right, verbosity opencl takes standard output approach to the very next level. It provides a single set of apis and wire protocols, alongside the collector service to ana, to collect and analyze all the signals that your application produces.

A

It is extremely easy to enable open telemetry on this slide. I show dot net code, how to do it on dot net.

A

You know what uh you can notice that in dotnet you simply specify which signals you want to collect signals from isp.net framework signals from http library and where to send the signals to, in this case, to zipkin, and you can see results in zika dashboard.

A

Note there are seven lines of code to enable very rich functionality to track your application uh distributed tracing and we keep simplifying this code and hopefully very soon like in java in python already today, there'll be no code, enablement for open telemetry and diagnosis.

A

With java and python we're releasing auto instrumentation packages that simply that can enable monitoring on any application. Even if it's already running in production again with open telemetry, we are making sure that all components are instrumented with open, telemetry one way or another, and you simply enable it monitoring and start collecting the signal.

A

And it is a true future of monitoring according to gartner analytics firm, pretty soon, majority of applications will use oss instrumentation, not a vendor specific one.

A

You may be skeptical and no trust analysts. You may say it's marketing hype.

A

In this case, I shall explain why we need opencl imaging and how it was born.

A

Let me tell you a story about checkbox competition.

A

Only a few years back, there was a handful of app development platforms and database choices. Only few and every choice we had was developed quite slow.

A

It was typical to have a release cycle of one year or more, and then one software is released once next version is released, you're waiting for service pack, maybe for second service pack, and only then you install it into production.

A

So a few companies that were doing my working on monitoring tools can easily catch up with the number of platforms and the tools developers were using one supported platform for the company, one checkbox in the list of supported platforms, customers, the choosing companies monitoring companies based on the price for sure, but also based on the list of check boxes, checked for this particular company.

A

Now, let's go back into the current days, know the cncf landscape. It's only open source components that people use in day and day out doesn't include all the vendor-specific uh uh platforms.

A

It doesn't include some proprietary platforms and all this software, including vendor and proprietary platforms. Moving with a high velocity, you have releases every quarter, you have releases every month and nobody can keep up with the pace of development that we observe these days.

A

So this change in landscape explain answers the question: why we need open telemetry why there was a need to end this checkbox competition and work together to build a better monitoring. Can observation too.

A

There is simply too many things to support for every single company, but how open telemetry can succeed. So, let's get to the how question.

A

The answer is, you want to build it in into every single library and platform, so they all will be pre-instrumented, and to do that, you need two things. First, you need to build a great set of apis and sdks that everybody love and enjoy.

A

Then people will be ready to take dependency on it and build it into their software and, secondly, you need to build a community of people who ready to work on this open, telemetry project together and spread. The word.

A

And we have truly amazing community amongst all cncf projects, only in single year, open telemetry get to the second highest amount of github activity.

A

Github activity includes things like commenting and discussing issues, making pull requests, commenting on pull requests, writing documentation.

A

And in less than one year we get to the second place, it explains it tells how many people are excited about this project and how many people want to collaborate.

A

You may note also also that there is no single company that overwhelms the space. Contributions are quite spread out across many many companies. Some companies only contributed a little. Some companies contributed a lot, but there is no single company that dominates the space and dictates the rules, and this is very important for the project like that, since there were so many companies from a get-go, we needed to make sure that projects has a project. Has a good and fair governance model.

A

And for governance model we came with approach. The bigger your contributions are the more influence you have in a project beyond the project vision through governance, open telemetry also defines a technical committee to oversee and direct all the development in the project.

A

So next, let's make uh take a look at how we make decisions on where to go with open telemetry and why? Let's talk about values.

A

In this section, I will talk about software design, values in general. What people may choose to uh as a as their radio, we'll talk about open, telemetry, specific and think what examples we have in open telemetry, where these values were.

A

A

This slide was heavily inspired by brian cantrell, a talk where he was talking about. I think rust development.

A

This slide lists number of characteristics. Your application or piece of software may have that you may be interested in pursuing and develop when you develop a piece of software. You definitely want your software to be robust and resilient.

A

You think about simplicity of, and transparency of apis. You pay attention on operability of your software, so everybody can trouble troubleshoot if something goes wrong.

A

This list on the slide outlines a small set of characteristics your application might have, and it's not prioritized in any way it's just an alphabetical order.

A

So you develop a piece of software. Oh such a sweet feeling, you're crafting it you're an artist. You want it to be. The best piece of software ever know that every artist has its own style and you are not an exception.

A

Some engineers want to concentrate on performance. Another engineer wants to concentrate on something else and many times characteristics from this table. You pick goes into conflict with each other.

A

Let's say you want to create a new api and to make it more elegant, you want to require an allocation of an object, not a big deal. You would say, but allocation on a critical path. It definitely hurts performance, and if you set performance as a main goal, you wouldn't probably go with this allocation.

A

I'm not saying that single allocation is compromising performance. I just saying that making this decision towards elegance of elegancy of api, you declare your value. You declare that this value is a little bit more important than that.

A

Sometimes, decisions like that are very straightforward and not controversial at all, but it escalates rather quickly as software piece grows and pretty soon it's full of trade-offs, explicit and implicit.

A

Some is the case and software pieces may be developed for heavy weight. Back-Ends. Let's say you write an sdk for that.

A

You probably would prefer to your sdk and api to be as expressive and simple to use as possible. So you always know which data you want to extract from this heavyweight uh backhand. You don't want to your back end to work for nothing and you want it to be as performed as possible.

A

You also will probably invest into operability of your api. So if anything goes wrong, you know about it right away and you probably want to do it on very high velocity. So any back-end changes are reflected in sdk right away.

A

Or you may be developing a different api, this api may maybe library for quick access to some very small resources.

A

You probably will want your implementation to be no lock on read. You may want to make it highly available and you clearly want to be as secure and simple as possible. So those may be your values you see, depending on what you develop, the values will be different.

A

So let's take a look at open, telemetry values in the previous section about what why and how of open telemetry, we discussed the values of we discussed. What office element is and why it came this way. So here are some values that inherited from that uh from those goals: open telemetry values, stability, resiliency compatibility and performance.

A

Let's explore these values in details.

A

Computability is perhaps the most important value of open telemetry with a number of stakeholders and supported scenarios. It is clear we require clear specifications and follow as many standards as possible.

A

It is very important to embrace like standards like we did with w3c trace context. It's important to develop via protocols in aliens with everybody.

A

So open telemetry does support all the standards out of the box and embrace them. Furthermore, we even built open telemetry apis inside a.net, with some compromises on specification, but nevertheless it minimizes dependency.

A

People need to take to be compatible with open intervention, and increased compatibility is valid way more for our project than some other alternative implementations.

A

Next value is stability.

A

With the libraries taking dependency on open telemetry, you want your apis and sdk to be as stable as possible, so there will be no questions whether library want to take dependency or not.

A

That's why some apis prefer name value attributes instead of strongly typed objects, and we don't support many complicated cases which are one-offs in favor of simple scenarios that that can cover those complicated cases in more elaborate way.

A

Then we value resiliency, open telemetry have to be robust as any system library. It is designed to work in critical conditions and collect telemetry from application distress, but not only that open telemetry is also needs to be developed resilient to critical and adapt to critical conditions.

A

So it's okay to drop silencing. If you don't crash application on high memory pressure scenario, it is okay to send only critical events and lose some of them. If your application is about to terminate and crash.

A

So resiliency is an important feature and finally, performance performance is a fourth value that I want to talk about. It's very critical because up the open telemetry will be on critical paths of libraries.

A

Sometimes we compromise on performance in favor of other values that I listed before, but whenever we can get to this, it's a high high priority.

A

Values are driven by people, so every single person coming to the project brings his own uh view and open telemetry values are held by people, maintaining the project and contributing to it, and while it's doing that, it attracts more people with the same values creating self-reinforcement cycle of values.

A

If you have opinions of what other values you want to bring into open telemetry and what values may be, not that important join us, and this is how you can join our community.

A

It's a very last section, and uh I want to talk about how you can use open, telemetry and give feedback how easy it is to contribute and some projects that you run around translation of documentation.

A

Open telemetry is a set of libraries, so we have, we don't have any way to collect telemetry out of our users.

A

So if you use open telemetry, you gave it a try. You like it, you don't like, like it, give us a feedback tell which environment your application was running into, tell which scenarios you love the most and which didn't work for you. What is missing?

A

It's all very valuable feedback, and because we we don't have any other means to collect it. So please come and tell us. We are friendly, our community if you decided that you want to fix a bug yourself or simply contribute in most cases it's trivial in many cases, sdks and apis are very scoped projects.

A

They're very easy unit, testable so some in many cases you only need to download it and run a test command. You don't need to have complicated environment and there is always room for improvement. Even for small one, as performance is our one of our core values. There is always a piece of code that can be improved and made faster, so please come and help us uh make open telemetry better.

A

If you're not interested in making open telemetry better, there is another way to contribute.

A

You can go to library and instrument that library with open telemetry. This will help community tremendously, because more libraries natively support open telemetry. Better monitoring can observability. We can provide our users.

A

There's also non-code participation options. You can share your thoughts via blogs and events. You can reach out to more people and tell them about this project. You can help develop website join our website seek special interest group. You can plan and triage work. You can do reviews, you can file issues, numerous ways to contribute and there is even translation projects. If you don't want to change the communication, just translate it to your native tongue.

A

You already started two projects, one to translate the uh documentation to chinese and another to japanese, and this project wasn't started by open, celebrity core maintainers. It was just started by some people who just wanted to contribute.

A

So if you want to contribute to this project, welcome, if you want to start your own, please do it it's easy.

A

Thank you. Thank you for your attention. Thank you for coming to this talk. I really appreciate you um seeing this video or attending this talk. If you have any questions, feel free to reach out to me, or anybody in the open, telemetry, community and happy monitoring, bye.