Pierre Tessier [Sales Engineer|Honeycomb]:
In this video, we’re going to go over what’s an event in Honeycomb. Events are the individual units of data that you send into the platform and they are also the things that you query back out in order to do your analytics and ultimately observe your application. So let’s spend some time and go over what’s an event in Honeycomb.
We define them as a unit of work and this can mean dozens of things in dozens of different contexts. It can be as simple as a bit flip change or an entire round trip for an HTTP request. Ultimately, events fall into two kinds of categories in Honeycomb. They’re either log entries or they’re tracing spans. Let’s dive into each one of these in more detail.
Starting with structured logs and log entries. In Honeycomb, we’ve always worked with log entries, things like a simple one like this, where you define an endpoint, you got the status return code, the duration of this entry of this request, maybe even some payload information, we would call this a simple log entry because it doesn’t contain a lot of detail. In Honeycomb, you’re encouraged to do wide entries and include a lot of detail about what happened for that request. Things like the user agent, fields of really high cardinality like user ID, but more so include items to tell us about that request. How many items are requested? What type of category was it? Or even the source address. All of these are important for you to understand and observe your applications because you don’t know what you need to know until you need to know it. So when it comes to log entries, one log entry equals one event in Honeycomb. That’s pretty simple to do.
Distributed tracing makes this a little bit more complicated. This is much more widely used now thanks to microservices. Changes the dynamics of how we really understand a request because as it is serviced, each microservice that is using that request will add another entry to that trace.
These entries are called spans and in Honeycomb, each span is an event. Let’s look at this in some detail. Say I’ve got a service expose on an API for exporting some tickets. Let’s talk about what that life cycle looks like to service this request.
We’re going to go ahead and hit the API service but before API can do much, it’s going to do a couple of checks first. First, one’s going to go through the rate limit service and this will make a request over to the cash service. Once that’s done, the next thing the API service is going to do is go through authentication service, to authenticate that user, pull down their permissions. Authentication will need to go to MySQL to go get that data.
Finally, we’re able to service this request. So API will call the ticket service to go do what it needs to do and the ticket service will also call into our MySQL or data service. And finally, before we turn the results, we’re going to do one more fraud check, calling into their fraud service to make sure everything is okay. And finally, we returned the results of the end-user, and to do all this, actually took eight different steps or eight spans.
Inside of Honeycomb, we’ll render that to look like this, a waterfall chart, which really helps you understand how long you spent in each span or step of that trace. You can see all eight of our services listed right here as well.
So when it comes to counting an event, one request going into your platform is going to be one or more events or spans going into Honeycomb. So if you want to understand how many events per day, generally speaking, you know the number of requests per day for your service and you can multiply that by the average number of spans per request. So if we take this example of our ticket exports and we know we have 25,000 requests per day on that service, at an average of eight spans per request, in the end, we’re going to end up with about 200,000 events per day into Honeycomb.
That is, in a nutshell, events; either log entries or spans from a distributed trace.
If you see any typos in this text or have any questions, reach out to email@example.com.