Axiom

Axiom Sink

Overview

The Axiom sink delivers observability events from worker to Axiom, a cloud-native analytics platform designed for high-cardinality, high-volume telemetry. The sink supports logs, metrics, and traces, allowing worker to act as a unified ingestion layer for Axiom-backed observability workflows.

Events are sent over HTTPS in batches and stored in Axiom datasets, where they can be queried, visualized, and analyzed with low latency.

Supported Input Types

This sink supports logs, metrics, and traces.

Prerequisites

Before configuring this sink, you need:

An Axiom account An API token with permission to write to the target dataset A target dataset name inside Axiom

If you are using a personal API token, you may also need the Axiom organization ID.

Core Configuration Parameters

Dataset (required) Specifies the Axiom dataset where events are written. All incoming events handled by this sink are stored under this dataset.

Datasets act as the primary logical container in Axiom and are typically aligned with environments, services, or teams.

Token (required) The Axiom API token used to authenticate requests. This token authorizes worker to ingest data into the specified dataset.

Organization ID (optional) Required only when using personal API tokens. This value identifies the Axiom organization that owns the dataset.

Regional and Endpoint Selection

Region (optional) Specifies the Axiom regional edge domain used for ingestion. When set, events are sent to the regional endpoint closest to your deployment, reducing latency.

This option should contain only the domain name, without scheme or path.

URL (optional) Allows explicitly defining the full ingestion endpoint. If provided, this takes precedence over the region setting.

This option is typically used for advanced routing, custom endpoints, or backward compatibility scenarios.

Event Encoding and Compression

Compression (optional) Controls the compression algorithm applied to outbound payloads. Compression reduces bandwidth usage and improves efficiency when sending large volumes of data.

Zstandard is used by default, offering a good balance between compression ratio and CPU overhead.

Encoding (implicit) Events are serialized in a format compatible with Axiom ingestion. Field-level filtering and timestamp formatting can be applied upstream if schema control is required.

Batching Behavior

Batch (optional) Controls how events are grouped before being sent to Axiom.

Batch sizing directly impacts throughput and ingestion efficiency. Larger batches reduce request overhead, while smaller batches reduce latency and limit the impact of retries.

Buffering and Backpressure

Buffer (optional) Defines how events are buffered before delivery.

Memory buffering provides higher throughput but does not survive restarts. Disk buffering offers durability during restarts or temporary connectivity issues.

When buffers are full, worker can either apply backpressure to upstream components or drop newer events, depending on the chosen policy.

Proxy Support

Proxy (optional) Allows routing ingestion traffic through HTTP or HTTPS proxies.

This is useful in environments with restricted outbound connectivity, enterprise firewalls, or mandatory egress inspection.

Request Behavior and Reliability

Request Settings (optional) Controls concurrency, rate limiting, retries, and timeouts for outbound HTTP requests.

Adaptive concurrency can dynamically adjust request parallelism based on observed latency, helping stabilize ingestion under varying network or service conditions.

Retries follow a backoff strategy to reduce pressure on Axiom during transient failures.

Transport Security

TLS (optional) Controls TLS behavior for secure communication with Axiom, including certificate verification, custom certificate authorities, and hostname validation.

TLS should be enabled for all production deployments to ensure confidentiality and integrity of observability data in transit.

Common Usage Patterns

The Axiom sink is commonly used for high-cardinality observability workloads, such as Kubernetes logs, distributed traces, and detailed application metrics.

It pairs well with worker's filtering and transformation capabilities to reduce noise, control schema shape, and route different telemetry streams into separate datasets.

Using regional ingestion endpoints helps optimize latency for globally distributed deployments.