W3C Trace Context Specification: What it Means for You

Since the first days of Google Cloud Platform (GCP), Google has been at the forefront of making your applications more observable. Beyond Stackdriver, our most visible impact in this space is OpenTelemetry, which we initiated in 2017 (as OpenCensus) and has grown into a huge community that includes the majority of APM / monitoring vendors and cloud platforms.

While OpenTelemetry allows developers to easily capture distributed traces and metrics from their own services, there’s also a need to trace requests as they propagate through components that developers don’t directly control, like managed services, load balancers, network hardware, etc. To solve this we co-defined a prototype HTTP header that these components can rely on, gathered partners, and moved the work into the W3C.

This work is now complete, and the W3C Trace Context format is now an official standard. Once implemented in GCP, this will make our services even easier to manage, both with Stackdriver and other third party distributed tracing tools. We explain more in the official post on the W3C blog, which I’ve copied below:

The W3C Distributed Tracing working group has moved the Trace Context specification to the next maturity level. The specification is already being adopted and implemented by many platforms and SDKs. This article describes the Trace Context specification and how it improves troubleshooting and monitoring of modern distributed apps.

W3C Trace Context specification defines the format for propagating distributed tracing context between services. Distributed tracing makes it easy for developers to find the causes of issues in highly-distributed microservices applications by tracking how a single interaction was processed across multiple services. Each step of a trace is correlated through an ID that is passed between services, and W3C Trace Context now defines a standard for these context propagation headers.

Until now, different tracing systems have defined their own headers. Examples include Zipkin’s B3 format and X-Google-Cloud-Trace. Adopting a common context propagation format has been long desired by developers, APM vendors, and cloud platform hosts, as compatibility provides numerous benefits:

• Web and RPC frameworks that use this standard to provide context propagation out of the box will also offer cross-service log correlation, even for developers who haven’t set up distributed tracing.
• API producers can record the trace IDs of requests from API consumers and provide additional spans or metadata to their customers for a given traced request. Producers can also correlate customer trace IDs to internal traces when debugging technical issues raised by consumers.
• Networking infrastructure (proxies, load balancers, routers, etc.) can both ensure that context propagation headers are not removed from requests passing through them, and can record spans or logs for a given trace, without having to support multiple vendor-specific formats. Potential examples of these include router appliances, cloud load balancers, and sidecar proxies like Envoy.
• Instrumentation can be further decoupled from a developer’s choice of APM vendor. For example, using both OpenTelemetry and a given vendor’s agents, a developer can instrument different services in an application, and traces will flow through the system and be processed correctly by the vendor’s backend.
• Web browsers and other clients can use these identifiers to correlate their telemetry with traces collected from backend services. This functionality is currently being defined.

To address this effort, a group of cloud providers, open source contributors, and APM vendors started defining a standard HTTP context propagation header that would replace their homegrown formats. This specification has been discussed and iterated on over the past two years, and the group working on it has grown significantly over that time. Sponsors include Google, Microsoft, Dynatrace, and New Relic (W3C members), and the group was officially moved into the W3C in 2018 for the work to proceed under the guidance of an official standards body and to spur even greater adoption.

TraceContext has since been adopted by OpenTelemetry (which enables it by default and also serves as the reference implementation), Azure services, Dynatrace, Elastic, Google Cloud Platform, Lightstep, and New Relic. We are tracking adoption in this list.

This first phase of work has focused on HTTP, as it is commonly used and has no built-in affordances for trace context propagation (gRPC and some newer RPC systems do). The same group of committee members are also working to define trace context propagation in other formats, starting with AMQP and MQTT for IoT; other upcoming topics include context propagation from clients and web browsers.

By Morgan McLean, OpenTelemetry + Stackdriver

Announcing Google Summer of Code 2020!

Google Open Source is proud to announce Google Summer of Code (GSoC) 2020—the 16th year of the program! We look forward to introducing the 16th batch of student developers to the world of open source and matching them with open source projects, while earning a stipend so they can focus their summer on their project.

Over the last 15 years GSoC has provided over 15,000 university students, from 109 countries, with an opportunity to hone their skills by contributing to open source projects during their summer break.

And the ‘special sauce’ that has kept this program thriving for 16 years: the mentorship aspect of the program. Participants gain invaluable experience working directly with mentors who are dedicated members of these open source communities; mentors help bring students into their communities while teaching them, guiding them and helping them find their place in the world of open source.

We’re excited to keep the tradition going! Applications for interested open source project organizations open on January 14, 2020, and student applications open March 25.

Are you an open source project interested in learning more? Visit the program site and read the mentor guide to learn more about what it means to be a mentor organization, how to prepare your community and create appropriate project ideas, and tips for preparing your application. We welcome all types of organizations—large and small—and are very eager to involve first time projects. For 2020, we hope to welcome more organizations into GSoC than ever before and are looking to accept 40-50 new organizations into their first GSoC.

Are you a university student interested in learning how to prepare for the 2020 GSoC program? It’s never too early to start thinking about your proposal or about what type of open source organization you may want to work with. You should read the student guide for important tips on preparing your proposal and what to consider if you wish to apply for the program in mid-March. You can also get inspired by checking out the 200+ organizations that participated in Google Summer of Code 2019, as well as the projects that students worked on.

We encourage you to explore other resources and you can learn more on the program website.

By Stephanie Taylor, Google Open Source

Blockly Summit 2019: Rendering, Accessibility, and More!

It has been over eight years since we started work on Blockly, an open source library for building drag-and-drop block coding apps. In that time, the team has grown from a single developer to a small team and a large community. Blockly is now a standard in the CS education space, used by Scratch, MakeCode, AppInventor, and hundreds of other developers to enable tens of millions of kids around the world to create and express themselves with code.

But Blockly isn't only used for education. The library provides everything an app developer needs to create rich block coding languages and is highly customizable and extensible. This means Blockly is also used by hobbyists and commercial companies alike for business logic, computer games, virtual reality, robotics, and just about anything else you can do with code.


The work we do on Blockly wouldn't be possible without the many folks who contribute back with code, suggestions, and support on the forums. As such, we were very excited to welcome around 30 members of the Blockly open source community to our second annual Blockly User Summit and to be able to make all of the talks available online!

The summit spanned two days in October and included 16 talks, over half of which were given by external contributors, and a Q&A with the Blockly team. The talks covered everything from Blockly's brand new rendering framework and building custom fields to explorations in performance and debugging block code. Check out the full playlist.

We also held a hackathon on the second day of the summit, with quick start guides for using our new rendering and accessibility APIs. If you're new to Blockly and you'd like a good starting point, take a look at our CodeLab and if you build your own cool demo let us know on our forums.



By Erik Pasternak, Kids Coding Team