Meet the Honeycomb Beeline for Ruby. Like our Beelines for Go and Node, it understands the common packages you’re using and automatically instruments them to send useful events to Honeycomb. Then once you’ve got a chance to explore your app’s behavior, you can add custom fields specific to your app with just one line of code.

We’re excited to introduce Honeycomb Tracing! Now, you can both: Visualize individual traces to deeply understand request execution, and Break down, filter, and aggregate trace data to uncover patterns, find outliers, and understand historical trends.

Serverless apps are growing in popularity, thanks to tools like AWS API Gateway and Lambda, and a growing number of powerful frameworks that simplify development and deployment. Complex applications are still complex, however, and regardless of your platform you’ll still need to think about observability.

Whenever you run a Honeycomb query, you’re directed to the permalink for the results. Returning to this URL always supplies the same data without re-running the query, which is important when sharing links to make sure that everybody is looking at the same thing. However, there may be cases where you want a link not to a specific set of results, but to a set of query parameters which are re-run automatically. Further, you may want to generate these links without relying on the Honeycomb UI.

When we announced support for ingesting AWS Elastic Load Balancer access logs to Honeycomb, one of the first follow-up requests was for us to add support for AWS Application Load Balancer as well (which, alongside the Network Load Balancer, represents ELBv2). Given the list of features that ALB supports, it’s not difficult to see why. Who doesn’t want microservice-friendly path routing, native HTTP/2 support, tight integration with Amazon’s container-related services, and more?

Want magical per-request instrumentation to roll effortlessly out of your Go app without even looking like you’re trying? Meet the Honeycomb Beeline for Go!

When it comes to observing systems, it helps to have tools that quickly and efficiently allow you to highlight events, anomalies, or simply changes to the code base. Enter Markers.

If you’re feeling too busy or overwhelmed to instrument your code, we are here for you. We’ve talked many times about the value of instrumentation, and how it’s necessary to instrument your code properly to have access to the kind of data you need to get real observability. Instrumenting your code can mean a lot of things, but in particular it means you have to augment it in many different places, which is time-consuming.

You’ve always been able to get observability for your Ruby apps by instrumenting them with our SDK, affectionately known as libhoney. Unfortunately, instrumenting code you’ve already written is nobody’s favourite job. If only there were some way to automate the repetitive parts, so you could get instant insight into what your app is doing in production, and then focus your effort on augmenting that insight with the information that’s unique to your app!

If you think about it, mobile apps are among the production services most in need of real observability: nearly countless hardware platforms and operating systems in combination with your app’s code result in a dizzying matrix of possible sources for any given issue, which means you need the power of true high-cardinality search to solve your problems.