---
title: InfluxDB Logs
slug: telemetry-pipeline/influxdb-logs
docTags: 
createdAt: 2025-04-21T01:01:00.483Z
---

 InfluxDB Logs Sink

## Overview

The **InfluxDB Logs sink** enables worker to deliver **log event data** into **InfluxDB**. It supports both **InfluxDB v2.x** (bucket + org + token) and legacy **InfluxDB v0.x/v1.x** (database + optional retention policy and username/password authentication).

This sink is useful when you want to store logs in InfluxDB for correlation with time-series telemetry and querying with InfluxDB’s native tooling.

## Supported Input Types

- Logs 

## Prerequisites

Ensure the following prerequisites are satisfied before using this sink:

- A reachable InfluxDB endpoint over HTTP or HTTPS 
- Appropriate credentials depending on your InfluxDB version: 
  - **InfluxDB v2.x+**: token authentication and organization access 
  - **InfluxDB v0.x/v1.x**: database access, optionally username/password 
- The target destination exists: 
  - **v2.x+**: bucket exists in the specified organization 
  - **v0.x/v1.x**: database exists, and retention policy exists if specified 

## Core Configuration Parameters

### Endpoint

Defines the target InfluxDB HTTP endpoint where worker sends log data.

The endpoint must be a full HTTP URI including scheme, host, and port.

### InfluxDB v2.x Parameters

Use these parameters when writing to InfluxDB **v2.x and above**:

Bucket

Specifies the bucket where log data will be written.

Organization

Specifies the organization that owns the target bucket.

Token

The authentication token used to write data into the organization and bucket.

### InfluxDB v0.x/v1.x Parameters

Use these parameters when writing to InfluxDB **v0.x/v1.x**:

Database

Specifies the database where log data will be written.

Retention Policy Name

Optionally targets a specific retention policy for writes.
 This is useful when different retention periods are configured at the database level.

Consistency

Optionally sets the write consistency level for the target cluster.
 This only applies to legacy InfluxDB versions where consistency levels are configurable.

Username and Password

Optional credentials for basic authentication when required by the InfluxDB deployment.

## Measurement Mapping

### Measurement

Controls the InfluxDB measurement name that receives the log entries.

This is important for organizing log streams and supporting predictable queries and retention strategies.

### Namespace

This field is deprecated and should not be used for new deployments.
 Use **measurement** instead.

## Log Schema Field Mapping

### Host Key

Controls which event field is treated as the hostname.
 If not set explicitly, worker uses the configured log\_schema.host\_key value (commonly host).

### Message Key

Controls which event field is treated as the log message payload.
 If not set explicitly, worker uses the configured log\_schema.message\_key value (commonly message).

### Source Type Key

Controls which event field is treated as the source type.
 If not set explicitly, worker uses the configured log\_schema.source\_type\_key value (commonly source\_type).

These mappings allow you to align worker's events with your existing log conventions without restructuring upstream data producers.

## Tagging Strategy

### Tags

Defines which log fields are promoted into **InfluxDB tags**.

Tags are indexed and are typically used for dimensions such as:

- host 
- service name 
- namespace 
- environment 
- region 
- source type 

Because tags influence index cardinality, you should choose tag fields carefully to avoid excessive cardinality growth.

By default, worker adds:

- metric\_type 
- the configured host key field 
- the configured source type key field 

## Event Serialization Controls

### Encoding

The sink supports selective serialization controls via:

- Including only specific fields 
- Excluding specific fields 
- Timestamp format control 

This is useful for:

- Reducing payload size 
- Ensuring consistent timestamp representation 
- Removing noisy fields before persistence 

## Request Behavior Controls

### Request Tuning

The sink exposes outbound request tuning options to control behavior under load, including:

- Concurrency controls 
- Rate limits 
- Retry strategy and retry timing 
- Request timeouts 

These settings are typically used to align the sink’s sending behavior with InfluxDB’s ingestion capacity and to protect the pipeline during transient failures.

## TLS Configuration

### TLS

TLS options control secure transport to the InfluxDB endpoint, including:

- Custom CA trust configuration 
- Client certificate authentication (mTLS) if required 
- Hostname and certificate verification behavior 

TLS should be used for production deployments, especially when sending data across networks you do not fully control.

## Typical Use Cases

Common scenarios for the InfluxDB Logs sink include:

- Storing logs alongside time-series metrics in InfluxDB for unified querying 
- Enabling infrastructure-level correlation between logs and telemetry 
- Long-term retention of structured logs using InfluxDB retention and bucket policies 
- Lightweight log persistence for edge deployments already standardized on InfluxDB 

## Summary

The **InfluxDB Logs sink** provides a direct path for delivering worker log events into InfluxDB. It supports both modern (v2.x+) and legacy (v0.x/v1.x) deployments, allows flexible mapping of message/host/source fields, supports tagging for efficient querying, and includes fine-grained controls for request behavior and TLS security.