Are you starting out on your journey toward observability? Do you have a mandate from management, or are you a lone warrior in the matrix? From your starting point, how will you make the right decisions about how to implement changes to your logging and aim for the right path through the various choices in front of you?

Greetings, fellow o11ynaut! You may recall a post we shared here about two months ago that told tales of the themes we felt best represented our recent release of the Framework for an Obsersvability Maturity Model. Well, the o11y maturity model was once again the primary topic and focus of Honeycomb’s most recent Observability Roundtable event held in San Francisco in mid August.

Does your organization have an on-call rotation? Several members of the Honeycomb engineering team recently hosted a live webcast about why they never feel alone when on-call at Honeycomb.

This guest post is from Evan Shaw, Lead Engineer at vendhq.com. GraphQL is a query language for APIs. It allows you to expose all your data through a single queryable graph. Compared to RESTful APIs, GraphQL brings greater flexibility in how your data is exposed, a more structured schema for type safety, and fewer round trips to your server for better latency. When we introduced a GraphQL at Vend, the feedback from our frontend engineers was clear: “This is a game-changer.”

“Nines don’t matter when users aren’t happy” is something you may have heard a time or two from folks here at Honeycomb. We often emphasize the fact that while your system can look healthy at a high level, deep down something is likely broken in ways that cause pain for users. If you are empowered to ask detailed questions about your services, you can find and understand these problems more easily.

AWS bills are notoriously complicated, and the Amazon Cost Explorer doesn’t always make it easy to understand exactly where your money is going. When we embarked on our journey to reduce our AWS bill, we wanted more than just the Cost Explorer to help us figure out where to optimize — and when all you have is a hammer, every problem sure looks like it can be solved with Honeycomb!

At Honeycomb, we’ve often discussed the value of making software deployments early and often, and being able to understand your code as it runs in production. However, these principles aren’t specific to only your customer-facing software. Configuration-as-code, such as Terraform, is in fact code that needs to go through a release process as well. Lacking formal process around Terraform deployment means a de-facto process that generates reliability risk.

We are excited to announce a new version of the Honeycomb Beeline for Ruby! This new version solidifies our Ruby support, providing out-of-the-box automatic instrumentation for additional frameworks and enhanced support for our currently supported frameworks. The goods: For Rails applications we now have a generator that creates a configuration file for the Beeline. This generates a configuration file in config/initializers/honeycomb.rb with the Beeline pre-configured for your Rails application:

The Velocity conference happened recently, and as part of it we (Honeycomb) hosted a sort of reverse-panel discussion, where you talked, and we listened. You may be aware that we’re in the process of developing a maturity model for the practice of observability–and we’re taking every opportunity we have to ask questions and get feedback from those of you who are somewhere along the path.