---
title: Humio Logs
slug: telemetry-pipeline/humio-logs
docTags: 
createdAt: 2025-04-21T01:00:42.686Z
---

# Humio Logs Sink

## Overview

The **Humio Logs sink** enables worker to deliver **log event data** into a **Humio** backend using an **ingestion token**. Worker sends events in **batches**, and Humio can apply a **parser** at ingest time based on the configured event type.

This sink is a good fit when you want to push logs from Worker into Humio repositories (including cloud-hosted or self-managed deployments) and control how they are parsed/indexed at the destination.

## Supported Input Types

- Logs 

## Prerequisites

Before configuring this sink, you typically need:

- A reachable Humio base URL (cloud or on-prem) 
- A Humio **ingest token** 
- (Optional) A target repository (index) that matches the ingest token’s scope (especially for public-facing APIs) 
- (Optional) A known Humio parser name if you want Humio to parse events in a specific way 

## Core Configuration Parameters

### Token (required)

The Humio **ingestion token** used for authentication.
 This is the primary credential used by Worker to send events into Humio.

### Endpoint (optional)

The **base URL** of the Humio instance (must include the scheme, e.g., https\://).
 No path should be included, since worker uses the fixed ingestion paths.

If omitted, worker targets Humio cloud by default (as shown in the docs snippet).

### Index (optional)

The repository name to ingest into.

- In **public-facing** Humio APIs, if index is set it typically must match the repository associated with the ingest token. 
- In **private cluster** deployments, Humio can be configured to allow token repository and ingest repository to differ. 

Use index when you want explicit repository selection (and your Humio deployment allows it).

### Event Type (optional)

Sets the **event type** for the events sent to Humio. Humio uses this as the **parser name** to apply at ingest time.

If you don’t set it, Humio defaults it to none (Humio’s default behavior).

Because it is **templateable**, you can drive parser selection dynamically per event (for example based on source/service).

### Source (optional)

The **source** associated with events sent to Humio, typically representing the original filename or origin identifier.

This maps to Humio’s @source.

Since it is **templateable**, you can encode useful origin metadata (pod name, container name, file path, etc.) consistently into Humio.

## Field Handling and Indexing Controls

### Indexed Fields (optional)

A list of event fields that are promoted into Humio’s “extra fields”.

This is the key control for deciding which log attributes become searchable/indexed as structured fields in Humio.

It also supports tagging behavior by specifying fields starting with # (Humio convention), allowing you to attach tags derived from the event content.

### Host Key (optional)

Overrides the log field used to retrieve the hostname to send to Humio.

- Defaults to .host 
- Behavior differs slightly depending on whether events are Legacy namespaced or using semantic meanings (Worker's schema mode) 

Use this when your log events use a non-standard host field name.

### Timestamp Keys (optional)

Humio supports explicit timestamps in events:

- **timestamp\_key**: overrides the field used to retrieve the timestamp sent to Humio 
  - If set to "", a timestamp is not set in the events (Humio will rely on ingest time or other defaults) 
  - Default is .timestamp 
- **timestamp\_nanos\_key**: overrides the field used for nanosecond-enabled timestamps 
  - Default is @timestamp.nanos 

Use these when:

- you want Humio timelines to reflect the *true* event time (not ingestion time), 
- your source timestamps are stored under different field names, 
- you need higher timestamp precision. 

## Payload Encoding

### Encoding (required)

Controls how worker serializes each event into bytes before sending.

Because Humio ingestion is sensitive to structure and parsing, encoding is where you decide:

- JSON vs text vs other codecs (depending on what your Humio parser expects), 
- how timestamps are formatted, 
- which fields are included/excluded to reduce noise or avoid schema collisions. 

Key controls include:

- include-only field lists 
- exclude field lists 
- timestamp format selection 

## Compression

### Compression (optional)

Controls compression applied to outbound payloads. Options include:

- gzip, snappy, zlib, zstd, none 

Use compression when bandwidth is constrained or when pushing high-volume logs over WAN links. If CPU is more constrained than bandwidth, disabling compression may improve throughput.

## Buffering and Backpressure

### Buffer (optional)

Configures how events are buffered before being sent to Humio.

This lets you choose between:

- **memory buffering** (higher performance, less durable) 
- **disk buffering** (more durable, can survive restarts/crashes after flush-to-disk) 

You also control what happens when buffers are full (e.g., block vs drop-newest), which affects loss vs backpressure behavior.

## Batching Behavior

### Batch (optional)

Controls how events are grouped into batches before send.

Typical batch tuning knobs:

- maximum bytes per batch 
- maximum events per batch 
- maximum time a batch can wait before flushing 

Batch sizing is one of the most important levers for throughput and cost:

- Larger batches reduce HTTP overhead and can improve throughput. 
- Smaller batches reduce latency and may reduce worst-case retry duplication. 

## Proxy Support

### Proxy (optional)

Allows routing Humio traffic through HTTP/HTTPS proxies, including:

- separate proxies for HTTP vs HTTPS 
- bypass rules (no\_proxy) to avoid proxying specific hosts/IP ranges 

This is useful in enterprise environments where outbound traffic must traverse controlled egress paths.

## TLS Configuration

### TLS (optional)

TLS settings control secure transport to Humio, including:

- custom CA trust bundles 
- client certificates (mTLS) if required 
- certificate verification and hostname verification controls 

Use TLS for production deployments, especially when Humio is remote or cloud-hosted.

## Common Usage Patterns

- **Repo-aware routing**: use index (when allowed) to route specific workloads into specific Humio repositories. 
- **Parser selection**: use event\_type to control which Humio parser processes the events at ingestion time. 
- **Searchable dimensions**: use indexed\_fields to make a controlled subset of attributes searchable without exploding cardinality. 
- **Accurate timelines**: configure timestamp\_key / timestamp\_nanos\_key to preserve event-time ordering. 

## Summary

The **Humio Logs sink** sends worker log events to Humio using an ingest token, with flexible controls for destination selection (index), ingest parsing (event\_type), structured search fields (indexed\_fields), and timestamp mapping (timestamp\_key). You can tune performance via batching, buffering, and compression, and align with enterprise constraints via proxy and TLS settings.