{"id":4830,"date":"2023-04-06T07:00:00","date_gmt":"2023-04-06T07:00:00","guid":{"rendered":"http:\/\/www.sumologic.com\/blog\/opentelemetry-open-standard-observability"},"modified":"2025-06-17T10:41:29","modified_gmt":"2025-06-17T18:41:29","slug":"opentelemetry-open-standard-observability","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/blog\/opentelemetry-open-standard-observability","title":{"rendered":"OpenTelemetry: Why community and conversation are foundational to this open standard"},"content":{"rendered":"\n
\n
\n
\n
\n
\"Open<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

While many of the popular tools for observability<\/a> in software are open source, one thing they lack is open design. Most of these solutions, from Nagios<\/a> to Prometheus<\/a>, started as a product with an opinionated design, which happened to work well for many people. These became the de facto standards. That position of de facto standard is what every open-source project and every commercial product tries to be.<\/p>\n\n\n\n

Open design and the public conversation<\/h2>\n\n\n\n

The word “open” does a lot of work here. Open source, open design, open telemetry: but what do we mean by open design? Open design doesn’t start with an opinion; it starts with a conversation. An open standard takes a lot of time to develop and requires hearing from many people to understand many kinds of use cases and perspectives.<\/p>\n\n\n\n

OpenTelemetry is a solution built in the open. The history of OpenTelemetry<\/a> is rooted in two prior projects, OpenCensus<\/a>, which focused on metrics collection, and OpenTracing<\/a>, which focused on tracing, both of which owe their origins to Google (Census<\/a> and Dapper<\/a>, respectively). These two projects merged to become OpenTelemetry,<\/a> which seeks to unify the collection of metrics, tracing, and logs into a single system.<\/p>\n\n\n\n

A unified standard<\/h2>\n\n\n\n

This unification of the different types of observability data could only happen late in the history of observability. Previous de facto standards were good at handling one kind of telemetry<\/a> at a time \u2014 metrics, tracing, etc.\u2014 but these standards rarely worked together to coordinate various observations. Users had to integrate disconnected tools, and everyone approached this differently.<\/p>\n\n\n\n

OpenTelemetry’s vast array of existing integrations<\/a> is a strength. There are already hundreds of integrations built around OpenTelemetry, including most of the major services you’d want to observe.<\/p>\n\n\n\n

All of this comes together to provide a compelling user experience around observability. With OpenTelemetry, you can collect and ingest all<\/em> types of telemetry using a single technology and handle each with best-in-class tooling. Instead of choosing between logs, metrics, or traces, you can bring them together under a single pane of glass. This dramatically simplifies the user experience of running complex real-world observability workloads, but that is not the unique quality that makes OpenTelemetry important.<\/p>\n\n\n\n

What makes OpenTelemetry unique is how the unified design was achieved through open conversation, open governance<\/a>, and the many decades of wisdom and experience from those involved in that conversation. Decades of previous open source efforts shape the process of implementing integrations for this new model. <\/p>\n\n\n\n

What’s needed is a design that brings everything into a single standard. And that design could only happen through public conversation and experience, where we have a good enough understanding of the range of needs. <\/p>\n\n\n\n

In this case, we saw two mature projects, OpenCensus and OpenTracing, do what rarely happens in the Open Source world \u2013 merge and evolve their designs and teams into a unified project. While this is impressive technologically, it\u2019s more impressive as a feat of human-to-human collaboration<\/a>. Instead of competing and diverging, they chose to join forces and create something more significant than either project. The resulting product of that collaboration proves that it is a winning strategy.<\/p>\n\n\n\n

Portable investments vs vendor lock-in<\/h2>\n\n\n\n

OpenTelemetry brings portability to your observability implementation. Vendors have a vested interest in building technology that only works with itself. It locks you into their platform, making leaving difficult because you’d have to rebuild your observability infrastructure to change vendors. That’s not a choice to make lightly, and it carries a measurable cost!<\/p>\n\n\n\n

OpenTelemetry, specifically, the adoption of OpenTelemetry as a standard, breaks down those walls. As a customer of one of the many OpenTelemetry-based vendor products, you can easily move to another vendor and bring all that work with you rather than starting over from scratch every time. You can also more easily work with multiple vendors at once through the common bus of OpenTelemetry. That means you can get the best of all worlds rather than making compromises by choosing one vendor over another, making these products better and your life easier as a customer.<\/p>\n\n\n\n

Community support and hackable code<\/h2>\n\n\n\n

<\/p>\n\n\n\n

Another essential aspect of OpenTelemetry is that it is entirely open source and benefits from a vast community of independent developers and bought-in vendors who are busily building solutions and sharing that for free. By comparison, if you need help with the DataDog agent or want it to do something differently, the only people you can ask about that is DataDog. But with OpenTelemetry, you can ask anyone in the community for help.<\/p>\n\n\n\n

Because it’s open source, if you need to change its behavior you can modify it and submit a patch when you’re done. In fact, with OpenTelemetry’s very flexible decomposed architecture, it’s easy to fit custom solutions into it without the need to change the other parts of your system.<\/p>\n\n\n\n

As with any solution that involves custom code, security is a core concern and OpenTelemetry has been built with that in mind from the start. For example, OpenTelemetry includes support for secure transport protocols like HTTPS and gRPC-TLS, and provides mechanisms for securing sensitive data like authentication tokens and encryption keys.<\/p>\n\n\n\n

OpenTelemetry is something that our industry has sorely needed for a long time now. It’s finally coming into its own, with most major vendors building it into their products. It comes from a place of wisdom but also one of audacity. OpenTelemetry shows that building an observability solution<\/a> in the open, based on public conversation rather than opinionated craftsmanship, will ultimately create something better and more valuable than any single vendor’s product.<\/p>\n\n\n\n

OpenTelemetry humbly suggests that an open standard will be better and more effective than the existing de facto standards and will upset that position in the most gentle, compassionate and graceful way possible. And it has.<\/p>\n\n\n\n

More to come from Sumo Logic<\/h2>\n\n\n\n

We are excited about OpenTelemetry and eager to continue supporting it on our platform. We’ve built our distribution of the OpenTelemetry collector<\/a> to ingest logs, metrics, and traces into Sumo Logic. We are bringing first-class support for this to Sumo Logic’s web-based experience.<\/p>\n\n\n\n

If you\u2019re ready to get started, follow this guide to using the common OpenTelemetry demo application with Sumo Logic<\/a> and read our guide to OpenTelemetry<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/section>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":303,"featured_media":0,"template":"","meta":{"_acf_changed":false,"show_custom_date":false,"custom_date":"","featured":false,"featured_image":0,"learn_more_label":"","image_alt_text":"","learn_more_type":"","show_popup":false,"learn_more_link_file":0,"event_date":false,"event_start_date":"","event_end_date":"","place_holder_image_url":"","post_reading_time":"4","notification_enabled":false,"notification_text":"","notification_logo":"","notification_expiration_time":0,"is_enable_transparent_header":false,"selected_taxonomy_terms":{"blog-category":[125],"blog-tag":[]},"selected_primary_terms":[],"learn_more_link":[],"featured_page_list":[],"notification_enabled_post_list":[],"_gspb_post_css":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"4668,71369,71176","_relevanssi_noindex_reason":"","inline_featured_image":false,"footnotes":""},"blog-category":[125],"blog-tag":[],"class_list":["post-4830","blog","type-blog","status-publish","hentry","blog-category-devops-it-operations"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/blog\/4830","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/users\/303"}],"version-history":[{"count":3,"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/blog\/4830\/revisions"}],"predecessor-version":[{"id":26883,"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/blog\/4830\/revisions\/26883"}],"wp:attachment":[{"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/media?parent=4830"}],"wp:term":[{"taxonomy":"blog-category","embeddable":true,"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/blog-category?post=4830"},{"taxonomy":"blog-tag","embeddable":true,"href":"https:\/\/www.sumologic.com\/wp-json\/wp\/v2\/blog-tag?post=4830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}