Operations | Monitoring | ITSM | DevOps | Cloud

Starting today, you can use more of Honeycomb than ever before for free. That means more teams can start building up production excellence with features that were previously only available for paid subscribers.

When Charity and I started pitching Honeycomb, we had a “bit” we would do, on the importance of building for teams: I’d identify her as the {Kafka, Mongo, insert tech-of-the-moment here} expert on the team, identify myself as the newcomer, and pantomime awkwardly leaning over her shoulder to see how she debugged some unexpected behavior.

“It turns out,” said Liz, “it was not a giant pile of work to start adding those rich instrumentation spans as you need them.” Liz Fong-Jones was telling dev.to’s Molly Struve about an error she encountered while trying to update her dev.to profile. When she entered honeycomb.io into the Employer URL field, the app responded with an angry red box...

I was excited to attend DevOpsDays in New York City in March of 2020, but then again, who wouldn’t be? A whole week in the Big Apple with Liz Fong and Christine Yen, yes, please! I joined Honeycomb as a product designer in January of 2020, making this my first event as a Honeycomb employee. In addition to meeting our users, it was a chance for me to talk with people just starting their observability journey. As a product designer, my focus is on improving the overall user experience.

“When things broke,” Molly explained, “you’re mad scrambling—jumping from website to website to website, trying to put the pieces together.” Molly was able to use Honeycomb to fix things up: “It makes my job easier as an SRE.” Getting started with Honeycomb doesn’t require a lot of work: at dev.to, they used the Ruby Beeline to get it going: “I didn’t do that much,” she said.

This is a guest post by Ryan Ordway, DevOps Engineer at Oregon State University. At Oregon State University Libraries & Press (OSULP) we have been using Honeycomb for about 18 months. We were in the beginnings of automating our infrastructure and needed an APM solution that we could scale with. New Relic was becoming too expensive, and we couldn’t afford to monitor our whole infrastructure and trace all of our applications anymore. Thus began our Observability journey.

A few months ago, Honeycomb released our SLO — Service Level Objective — feature to the world. We’ve written before about how to use it and some of the use scenarios. Today, I’d like to say a little more about how the feature has evolved, and what we did in the process of creating it. (Some of these notes are based on my talk, “Pitfalls in Measuring SLOs;” you can find the slides to that talk here, or view the video on our Honeycomb Talks page).

We’re really big fans of OpenTelemetry at Honeycomb. As we’ve blogged about before, OpenTelemetry is the next phase of the OpenTracing and OpenCensus projects. Instead of working on separate but similar efforts, those two projects have merged to create OpenTelemetry. This is wonderful for the larger community as it gives people a clear way to instrument their code for metrics and traces that isn’t specific to any tool or vendor. OpenTelemetry is a CNCF sandbox project.

At re:Invent in December, Amazon announced the AWS Graviton2 processor and its forthcoming availability powering Amazon EC2 M6g instances. While the first-generation Graviton processor that powered A1 instances was better suited to less compute-intensive workloads, this processor is intended to offer AWS customers a compelling alternative to conventional x86-powered instances on both performance and cost.

“Sociotechnical” — I learned this word from Liz Fong-Jones recently, and it immediately entered my daily lexicon. You know exactly what it means as soon as you hear it, and then you wonder how you ever lived without it. Our systems are sociotechnical systems. This is why technical problems are never just technical problems, and why social problems are never just social problems. I work on a company, Honeycomb, which develops next-gen observability tooling.