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.

A lot of product marketing is about telling people to throw away what they have in favor of something entirely new. Sometimes that is the right answer–sometimes what you have has completely outlived its usefulness and you need to put something better in its place–but a lot of the time, what’s realistic is to make incremental improvements. If you’ve been tasked with starting, or growing your observability practice, it may seem a long journey from here to there.

(Field notes from O’Reilly’s Velocity 2019 Show, San Jose.) It was steamy hot in San Jose during O’Reilly’s Velocity show and the normally frigid AC temps in the expo hall were welcomed by all attendees, escaping the 104 degree temps. It got so bad, Charity Majors labeled it Satan Jose and the nearby Marriott hotel experienced a power outage for almost two full days, leaving guests hot under more than just their collars.

Observability-driven development requires both rich query capabilities and sufficient instrumentation in order to capture the nuances of developers’ intention and useful dimensions of cardinality. When our systems are running in containers, we need an equivalent to our local debugging tools that is as easy to use as Printf and as powerful as gdb.

This year was my third in a row attending (and now speaking at!) Monitorama. Because the organizers do a great job of turning introverts into extroverts for three days straight, it’s always a fun and exhausting time—but one of my favorite parts is how much folks continue talking about and sharing the content, days or weeks after it’s over. So, to continue the drumbeat, here were some of my highlights from this year.

Tracing is one of the key tools that Honeycomb offers to make sense of data. Over the last few weeks, we’ve made a number of improvements to our tracing interface — and, put together, those changes let you think about traces in a whole new way! Tracing makes it easier to understand control flow within a distributed system. We render traces with waterfall diagrams, which capture the execution history of individual requests.

Access to observability is becoming critical to organizations shipping software, running modern infrastructures in production, and to understanding how users are experiencing their service. To achieve success in delivering a complex service, it’s no longer optional to instrument for real visibility and ease of troubleshooting, to optimize alerting to enable a focused response, to do what is needed to drive toward real understanding and ownership of the code we deliver.