Glossary of key Axiom terms

The glossary explains the key concepts in Axiom.

A B C D E F G H I K L M N O P Q R S T W X Y Z​

A

Anomaly monitor

Anomaly monitors allow you to aggregate your event data and compare the results of this aggregation to what can be considered normal for the query. When the results are too much above or below the value that Axiom expects based on the event history, the monitor enters the alert state. The monitor remains in the alert state until the results no longer deviate from the expected value. This can happen without the results returning to their previous level if they stabilize around a new value. An anomaly monitor sends you a notification each time it enters or exits the alert state.

For more information, see Anomaly monitors.

API

The Axiom API allows you to ingest structured data logs, handle queries, and manage your deployments.

For more information, see Introduction to Axiom API.

API token

See Tokens.

App

Axiom’s dedicated apps enrich your Axiom organization by integrating into popular external services and providing out-of-the-box features such as prebuilt dashboards.

For more information, see Introduction to apps.

Axiom

Axiom represents the next generation of business intelligence. Designed and built for the cloud, Axiom is an event platform for logs, traces, and all technical data. Axiom efficiently ingests, stores, and queries vast amounts of event data from any source at a fraction of the cost. The Axiom platform is built for unmatched efficiency, scalability, and performance.

Axiom Processing Language (APL)

The Axiom Processing Language (APL) is a query language that is perfect for getting deeper insights from your data. Whether logs, events, analytics, or similar, APL provides the flexibility to filter, manipulate, and summarize your data exactly the way you need it.

For more information, see Introduction to APL.

B

Bring Your Own Bucket (BYOB)

Axiom enables you to store data in your own storage with the Bring Your Own Bucket (BYOB) feature. You provide your own S3-compatible object storage, and the Axiom control plane handles ingest, query execution, and all other background tasks. This is not an on-premises solution, but it enables you to maintain control over your data at rest.

C

CLI

Axiom’s command line interface (CLI) is an Axiom tool that lets you test, manage, and build your Axiom projects by typing commands on the command-line. You can use the command line to ingest data, manage authentication state, and configure multiple organizations.

For more information, see Introduction to CLI.

D

Dashboard

Dashboards allows you to visualize collections of queries across multiple datasets in one place. Dashboards are easy to share, benefit from collaboration, and bring separate datasets together in a single view.

For more information, see Introduction to dashboards.

Dashboard element

Dashboard elements are the different visual elements that you can include in your dashboard to display your data and other information. For example, you can track key metrics, logs, and traces, and monitor real-time data flow.

For more information, see Introduction to dashboard elements.

Dataset

Axiom’s datastore is tuned for the efficient collection, storage, and analysis of timestamped event data. An individual piece of data is an event, and a dataset is a collection of related events. Datasets contain incoming event data.

For more information, see Datasets.

Destination

To transform and route data from an Axiom dataset to a destination, you need to set up a destination. This is where data is routed. Once you set up a destination, it can be used in any flow.

For more information, see Manage destinations.

E

Event

An event is a granular record capturing a specific action or interaction within a system, often represented as key-value pairs. It’s the smallest unit of information detailing what occurred, who or what was involved, and potentially when and where it took place. In Axiom’s context, events are timestamped records, originating from human, machine, or sensor interactions, providing a foundational data point that informs a broader view of activities across different business units, from product to security to marketing.

F

Flow

Flow provides onward event processing, including filtering, shaping, and routing. Flow works after persisting data in Axiom’s highly efficient queryable store, and uses APL to define processing.

A flow consists of three elements:

• Source: This is the Axiom dataset used as the flow origin.
• Transformation: This is the APL query used to filter, shape, and enrich the events.
• Destination: This is where events are routed.

For more information, see Introduction to Flow.

L

Log

A log is a structured or semi-structured data record typically used to document actions or system states over time, primarily for monitoring, debugging, and auditing. Traditionally formatted as text entries with timestamps and message content, logs have evolved to include standardized key-value structures, making them easier to search, interpret, and correlate across distributed systems. In Axiom, logs represent historical records within engineering contexts, designed for consistent capture, storage, and collaborative analysis, allowing for real-time visibility and troubleshooting across services.

M

Match monitor

Match monitors allow you to continuously filter your log data and send you matching events. Axiom sends a notification for each matching event. By default, the notification message contains the entire matching event in JSON format. When you define your match monitor using APL, you can control which event attributes to include in the notification message.

For more information, see Match monitors.

Metric

A metric is a quantitative measurement collected at specific time intervals, reflecting the state or performance of a system or component. Metrics focus on numeric values, such as CPU usage or memory consumption, enabling aggregation, trend analysis, and alerting based on thresholds. Within Axiom, metrics are data points associated with timestamps, labels, and values, designed to monitor resource utilization or performance. Metrics enable predictive insights by identifying patterns over time, offering foresight into system health and potential issues before they escalate.

Monitor

A monitor is a background task that periodically runs a query that you define. For example, it counts the number of error messages in your logs over the previous 5 minutes. A notifier defines how Axiom notifies you about the monitor output. For example, Axiom can send you an email.

You can use the following types of monitor:

• Anomaly monitors aggregate event data over time and look for values that are unexpected based on the event history. When the results of the aggregation are too high or low compared to the expected value, Axiom sends you an alert.
• Match monitors filter for key events and send them to you.
• Threshold monitors aggregate event data over time. When the results of the aggregation cross a threshold, Axiom sends you an alert.

For more information, see Introduction to monitors.

N

Notifier

A monitor is a background task that periodically runs a query that you define. For example, it counts the number of error messages in your logs over the previous 5 minutes. A notifier defines how Axiom notifies you about the monitor output. For example, Axiom can send you an email.

For more information, see Introduction to notifiers.

O

Observability

Observability is a principle in software engineering and systems monitoring that focuses on the ability to understand and diagnose the internal state of a system by examining the data it generates, such as logs, metrics, and traces. It goes beyond traditional monitoring by giving teams the power to pinpoint and resolve issues, optimize performance, and understand user behaviors across complex, interconnected services. Observability leverages various types of event data to provide granular insights that span everything from simple log messages to multi-service transactions (traces) and performance metrics.

Traditionally, observability has been associated with three pillars:

• Logs capture individual events or errors.
• Metrics provide quantitative data over time, like CPU usage.
• Traces represent workflows across microservices.

However, modern observability expands on this by aggregating diverse data types from engineering, product, marketing, and security functions, all of which contribute to understanding the deeper “why” behind user interactions and system behaviors. This holistic view, in turn, enables real-time diagnostics, predictive analyses, and proactive issue resolution.

In essence, observability transforms raw event data into actionable insights, helping organizations not only to answer “what happened?” but also to delve into “why it happened” and “what might happen next.”

P

Personal access token (PAT)

See Tokens.

Playground

The Axiom Playground is an interactive sandbox environment where you can quickly try out Axiom’s capabilities.

To try out Axiom, go to the Axiom Playground.

Q

Query

In Axiom, a query is a specific, structured request used to get deeper insights into your data. It typically involves looking for information based on defined parameters like keywords, date ranges, or specific fields. The intent of a query is precision: to locate, analyze, or manipulate specific subsets of data within vast data structures, enhancing insights into various operational aspects or user behaviors.

Querying enables you to filter, manipulate, extend, and summarize your data. As opposed to searching which relies on sampling, querying allows you to explore all your event data. For this reason, querying is the modern way of making sense of your event data.

Query-hours

When you run queries, your usage of the Axiom platform is measured in query-hours. The unit of this measurement is GB-hours which reflects the duration (measured in milliseconds) serverless functions are running to execute your query multiplied by the amount of memory (GB) allocated to execution. This metric is important for monitoring and managing your usage against the monthly allowance included in your plan.

For more information, see Query costs.

R

Role-based access control (RBAC)

Role-based access control (RBAC) allows you to manage and restrict access to your data and resources efficiently.

For more information, see Access.

S

Search

Most observability solutions rely on search to seek information within event data. In contrast, Axiom’s approach is query. Unlike search that only gives you approximate results because it relies on sampling, a query is precise because it explores all your data. For this reason, querying is the modern way of making sense of your event data.

T

Threshold monitor

Threshold monitors allow you to periodically aggregate your event data and compare the results of this aggregation to a threshold that you define. When the results cross the threshold, the monitor enters the alert state. The monitor remains in the alert state until the results no longer cross the threshold. A threshold monitor sends you a notification each time it enters or exits the alert state.

For more information, see Threshold monitors.

Token

You can use the Axiom API and CLI to programmatically ingest and query data, and manage settings and resources. For example, you can create new API tokens and change existing datasets with API requests. To prove that these requests come from you, you must include forms of authentication called tokens in your API requests. Axiom offers two types of tokens:

• API tokens let you control the actions that can be performed with the token. For example, you can specify that requests authenticated with a certain API token can only query data from a particular dataset.
• Personal access tokens (PATs) provide full control over your Axiom account. Requests authenticated with a PAT can perform every action you can perform in Axiom.

For more information, see Tokens.

Trace

A trace is a sequence of events that captures the path and flow of a single request as it navigates through multiple services or components within a distributed system. Utilizing trace IDs to group-related spans (individual actions or operations within a request), traces enable visibility into the lifecycle of a request, illustrating how it progresses, where delays or errors may occur, and how components interact. By connecting each event in the request journey, traces provide insights into system performance, pinpointing bottlenecks and latency.