OpenTelemetry Launchers: What they solve and why we need them

Exciting times in Otel land! OpenTelemetry is close to GA and v1.0 in a number of languages. We are close to finalizing the specificationspecification. Release candidates before the end of the year are looking very likely.

OpenTelemetry + Lightstep

Ever since BenBen and I co-founded the OpenTelemetry project by merging our prior project (OpenTracing) with its sibling (OpenCensus), we’ve been pushing hard at Lightstep to help make OpenTelemetry a reality. It has been reaffirming to see the beta take off, and watch OpenTelemetry implementations work their way into production.

Based on beta feedback, we now consider PythonPython, NodeJSNodeJS, JavaJava and GoGo to be ready for adoption. I am so happy to announce that Lightstep is officially making OpenTelemetry our recommended choice for getting started in these four languages. OpenTelemetry is real, and you can use it today.

However, there is one issue which still needs to be addressed: a way to encapsulate setup and configuration.

To explain: OpenTelemetry is a framework. It was designed to be modular and extensible, more like a toolkit and a platform for innovation than a one-size-fits-all solution. And while a flexible framework with a clear separation of concerns has many advantages, it does come with a drawback: complexity. Without encapsulation, the modularity can end up looking like a bucket of legos. That’s great if you want to build new observability tools (or create adapters to work with existing ones), less great if you just want to get started with the tools we have already built.

Without encapsulation, OpenTelemetry looks intimidating to set up. The code below represents the minimum configuration needed to get started today with OpenTelemetry and connect it to Lightstep with the correct configuration.

func main() {
	// configure headers
	headers := map[string]string{
		"lightstep-access-token": "ls-access-token",
	}
	// configure TLS credentials
	secureOption := otlp.WithTLSCredentials(credentials.NewClientTLSFromCert())

	//configure an OTLP exporter
	exporter, err := otlp.NewExporter(
		secureOption,
		otlp.WithAddress("ingest.lightstep.com:443")
		otlp.WithHeaders(headers),
	)

	// deal with the error
	if err != nil {
		log.Fatalf("failed to create exporter: %w", err)
	}

	// configure resources
	resources := resource.New(
		kv.String("service.name","my-service"),
		kv.String("service.version","1.2.3"),
		kv.String("library.language","go"),
		kv.String("library.version","0.0.1"),
	)

	// then configure a trace provider
	tp, err := trace.NewProvider(
		trace.WithConfig(trace.Config{DefaultSampler: trace.AlwaysSample{}}),
		trace.WithSyncer(exporter),
		trace.WithResource(resources),
	)

	// more errors
	if err != nil {
		log.Fatalf("failed to create trace provider: %w", err)
	}

	// set the global trace provider
	global.SetTraceProvider(tp)
}

To say the least, this has way more ✨ than using the lower-level APIs directly.

OpenTelemetry Launchers

We have made launchers for PythonPython, JavaJava, NodeJSNodeJS, and GoGo. We hope to see the launchers (or something like them) baked into OpenTelemetry core. Please try them out and give us feedback.

These launchers can also serve as an example for anyone seeking to build a custom OpenTelemetry distribution. Many existing analysis tools(and future experimental ones) will require specific configuration options and plugins in order to work correctly. Sampling is a good example of a feature where existing tools take wildly different (and incompatible) approaches, and there is still a lot of active development. Another example is which instrumentation libraries to include: some distributions may want to include every library available on the internet, others may want to only include libraries vetted via a security process. Still others may require non-standard plugins which only apply to specific environments.

OpenTelemetry Community

I see the community developing a healthy ecosystem of OpenTelemetry distributions: easy to discover, simple to swap with each other. Once OpenTelemetry core is complete, this type of packaging is one area where I would like to turn our attention.

In related news, I’ve also started work on a new knowledge base. If you look around opentelemetry.lightstep.comopentelemetry.lightstep.com, you will find links to getting started guides in GoGo, PythonPython, JavaJava, and JavascriptJavascript. This is only the beginning (the website isn’t even finished, lol). You can expect to see more guides, best practices, and tutorials in the coming months. Keep checking back in, or follow me on TwitterTwitter if you want to know when new content is published. My goal is to make this the best resource available for learning about OpenTelmetry, distributed tracing, and observability in general. Please check it out, and let me know what kind of content you’d like to see.

It’s been a great adventure so far. First and foremost, open source is about the people. I’d like to thank Kay, Andrew, Mitch, Steven, Alex, Matt, Carlos, Austin and Josh for all the work they have put in as core contributors, OpenTelemetry language maintainers, and Technical Committee members. Special shout out to Eric for making the docs site a reality.

From here to GA, it is going to be a blast.🚀✨

Interested in joining our team? See our open positions herehere.