This glossary is intended to be a comprehensive, standardized list of Honeycomb terminology. It includes Honeycomb-specific product terms, plus general terms that provide useful context.
A Honeycomb feature that presents a collection of queries and their resulting data visualizations displayed together on a page. Query results on a board can be displayed as graphs/charts, tables, or lists.
A Honeycomb feature that assists in debugging by automatically detecting commonalities that deviate from established baselines.
A dependent span upon a parent span.
The process of scaling an application by increasing or decreasing the number of instances running that application.
A collection of messages that records what has happened in a system. Most logs include contextual information, such as the time an event occurred. Structured log messages follow a rigid structure to enforce uniformity, while unstructured log messages do not follow a consistent pattern.
A quantifiable measure of system resources, health, or performance. Some examples of metrics include memory or CPU resource consumption, available disk space, and run duration.
The ability to ask arbitrary questions about your environment without having to know ahead of time what you wanted to ask. “Observability” is commonly shortened to “o11y” because there are 11 letters in between the ‘o’ and ‘y’ in ‘observability’. Learn more
A span with a parent.id field and dependent child events.
The first span in a trace, and does not have a parent span or a parent.id value.
The process of taking a subset of elements from a larger, complete set of elements. The purpose of sampling is to use a smaller, more manageable set of elements to summarize and better represent the complete population of elements.
In regards to observability and performance monitoring, logs, traces, and events can be sampled to summarize information about a service or activity. When sampling your information, there is a constant trade off between granularity, system-representative accuracy, performance, relevancy. It is important to properly configure and understand your systems’ sampling strategies so that you have an accurate view of your systems.
A goal for how “available” a system, product, or service is to its users.
In Honeycomb, a Service Level Objective (SLO) is a way for engineering teams to track how well they are maintaining their system availability goals. Someone on your team will set the goal percentage and time period (for example, “we expect some aspect of our system to be available 99.5% of the time over a seven-day period”), and then Honeycomb’s SLO feature will track actual system availability to see whether or not you are meeting your goal. If it looks like you are on track to drop below your goal, we can alert you, so you can proactively fix any problems.
A single piece of instrumentation from a single location in your code, and represents a single unit of work done by a service. Learn more
A timestamped structured log, or event, without a duration. It occurs during the course of a Span and can be thought of as an annotation on the Span. Learn more
A connection between a span to one or more spans or traces, which are causally related. It can point to another span within the same trace or within a different trace. Learn more
Data that tracks a user’s experience through the journey of an application request as it moves through a system. A trace that tracks that experience across multiple services is a “distributed” trace.
Traces record how long each application component takes to process a request and pass the result to the next component; they can also identify which parts of an application trigger an error. They allow you to profile and observe systems, especially containerized applications, serverless architectures, or microservices architecture. Learn more
The process of scaling an application by increasing available resources (for example, installing more memory or disk drives) in a relatively static architecture.
