This is an experience report for my future reference (and yours). The OpenTelemetry Collector is useful for receiving trace data in whatever format and exporting it to the back-end of your choice for storage and querying. For instance, I wanted to receive traces over HTTP/JSON from this sneaky browser extensionLINK and send them to Honeycomb. …
What is happening in production? Distributed tracing can help you find out. But it’s one thing to instrument, another to use it. Here’s a short (6m) video that asks “Why is this so slow?” See three quick ways to get answers in Honeycomb. If you want to follow along and play with the same data …
In our Rails app, installing the Honeycomb beeline magically gave us traces of all HTTP requests, with dozens of useful fields like ‘request.path’ and ‘response.status_code’. I really wanted the request verb (GET or POST) and I couldn’t find that. (It’s there, in ‘request.method’, I missed it. But still, it’s useful to know how to a …
Read moreAdding custom fields to Honeycomb traces in Rails by writing a Rack middleware
Honeycomb made it suuuuuper easy to see traces of HTTP requests hitting my app. Right from my computer! We installed one gem, did one rails generate from a cut-and-paste their dataset creation page gave me. Start up rails server, hit http://localhost:3000, and boom! A thing on a graph in Honeycomb! That was cool. Except, um, …
Read moreHoneycomb in Rails with separate dev and production events
Today we hooked up Honeycomb to an app for the first time! It was easy and fun! Then we configured it so that we don’t have to commit our apikey. It’s a public repo. Anyone could grab our API key and send spurious events to our Honeycomb datasets, screwing up our information and costing us …