Blueprints for OTel Success: Standardizing Observability at Scale with Dan Gomez Blanco

And this is really why we're here today, because in my world, also Brian, both of us, we work with end users, organizations that are trying to implement observability and whether they're using agents or open telemetry, most of them obviously are now moving into the world of open telemetry, they always ask questions.

So how do I do this right? I know the documentation.

I've played around with AstroShop, with the different demo apps.

I understand how to collect the log.

I understand how to set up a single collector and send it to any type of backend.

But how do I basically get this into an enterprise scale? And how do I get beyond the honeymoon phase of I've done a POC and a demo towards scaling this for real? So I would like to learn from you the a background about these blueprints, about these reference implementations, and how we can also encourage more people to share their lessons learned and their learnings with you and your community.

Yeah, so I think I should probably say

first that blueprints or OTL blueprints is what's called an initiative or a project within OpenTelemetry.

So this is something that allows us as a community to bring together people from multiple backgrounds multiple special interest groups, multiple sex, multiple backgrounds, and now we even got end users involved in this initiative.

So it allows us to basically publicize some work that we want the community to feed back into.

With O2L Blueprints, this is something that's been in my mind for a long time to basically put together some common patterns, common design patterns and common challenges that companies and organizations find when they adopt OTEL and also a way for the community to talk about these best practices.

I think it can be useful as well for maintainers to understand what are the friction points and then what we can improve as a project.

so yeah and that was opened that was approved as a project we kicked it off maybe i think two or three months ago and then we've had people like um co-leads there in that in that project like lucas and tiffany that working with me in auto blueprints and we've made making some really good progress

I've got a question for you.

In your day work at New Relic and we in our day work at Dynatrace, it is sometimes hard to get our users to publicly talk about how they're adopting Do you think this is easier with open telemetry because it's open source or do you still have to go through similar hoops to get these organizations to publicly say, because you have three, right? You have Adobe, you have Mastodon, you have Skyscanner, I'm sure there's more coming.

Is it easier or more challenging? It's easier.

I think it's easier.

Because we are very clear as well when we, and by the way, if you're an end user

and you're

listening to this, we are calling out for end users to share the reference architectures.

And then we don't, in fact, we don't want to talk about anything that relates to the back end.

So if you use Dynatrace or if you use New Relic or if you use whatever, Grafana, it's okay.

But we don't want to talk about that in the reference implementation.

It's not applicable to the scope of a hotel.

What we're interested in is the open telemetry scope.