---
title: GreptimeDB Logs
slug: telemetry-pipeline/greptimedb-logs
docTags: 
createdAt: 2025-04-21T01:00:02.687Z
---

# GreptimeDB Logs Sink

## Overview

The **GreptimeDB Logs sink** writes **log and metric events** to **GreptimeDB** using its HTTP ingestion interface.
 It is designed for **time-series–oriented observability workloads**, combining structured logs and metrics within a single analytical database.

This sink is commonly used when GreptimeDB serves as:

- a unified backend for logs and metrics, 
- a high-performance time-series analytics engine, 
- or a long-term observability storage platform. 

## Supported Input Types

- Logs 
- Metrics 

## Connection Configuration

### Endpoint (required)

Specifies the **HTTP endpoint** of the GreptimeDB server.

The endpoint must:

- include the protocol (HTTP or HTTPS), 
- point to a GreptimeDB ingestion-compatible service, 
- be reachable from the worker runtime environment. 

### Database Name

Defines the **GreptimeDB database** used for ingestion.

Key characteristics:

- Defaults to the public database if not specified. 
- Databases must already exist in GreptimeDB. 
- In managed GreptimeDB (GreptimeCloud), the database name must match the instance configuration. 

Dynamic database selection is supported using per-event values when required.

### Table (required)

Specifies the **target table** into which data is written.

Important considerations:

- The table must exist before ingestion. 
- Schema design directly impacts query performance and storage efficiency. 
- Dynamic table selection can be used for multi-tenant or multi-workload scenarios. 

## Authentication

### Username and Password

Authentication credentials are required **only if authentication is enabled** on the GreptimeDB instance.

When configured:

- credentials are sent with each ingestion request, 
- access control is enforced by GreptimeDB, 
- credentials should be scoped to ingestion-only permissions where possible. 

## Delivery Shaping

### Batch Behavior

Controls how events are grouped before being sent to GreptimeDB.

Batching parameters influence:

- write amplification, 
- ingestion throughput, 
- delivery latency. 

Default behavior favors **small batches** to balance ingestion latency and request overhead.

### Buffering Behavior

Defines how events are temporarily stored when ingestion throughput is constrained.

Supported buffer types:

- **Memory buffering** for high throughput with lower durability. 
- **Disk buffering** for increased durability across restarts or failures. 

When buffers are full:

- blocking behavior applies backpressure upstream, 
- or newest events can be dropped if continuity is prioritized over completeness. 

## Payload Optimization

### Compression

Controls HTTP payload compression.

Supported compression methods:

- gzip 
- zstd 
- snappy 
- zlib 
- none 

Compression reduces network usage and improves throughput, especially in high-volume log ingestion scenarios.

### Encoding Controls

Field-level transformations can be applied before sending data to GreptimeDB:

- include only selected fields, 
- exclude unnecessary or high-cardinality fields, 
- normalize timestamp formats. 

These controls are essential for:

- schema stability, 
- cost optimization, 
- query performance tuning. 

## Pipeline Metadata

### Pipeline Name

Defines the **logical pipeline identity** applied to ingested logs.

Use cases include:

- preserving original log structure, 
- tagging logs by ingestion pipeline, 
- distinguishing multiple worker deployments writing to the same database. 

### Pipeline Version

Specifies a **pipeline version identifier**.

This is useful for:

- schema evolution tracking, 
- rollout verification, 
- ingestion debugging across configuration changes. 

## Network and Transport Controls

### Custom Headers

Allows adding or overriding HTTP headers on ingestion requests.

Typical use cases:

- tenant identification, 
- gateway-based routing, 
- integration with API management layers. 

### Query Parameters

Custom query parameters can be appended to ingestion requests.

Used primarily for:

- advanced GreptimeDB routing, 
- experimental ingestion features, 
- deployment-specific extensions. 

### Request Behavior

Advanced request controls are available to manage delivery under load:

- adaptive or fixed concurrency, 
- rate limiting, 
- retry strategies with backoff, 
- request timeouts. 

These settings are typically tuned in:

- high-ingestion environments, 
- constrained network conditions, 
- multi-sink topologies sharing outbound capacity. 

### TLS Configuration

Supports secure communication using TLS.

Capabilities include:

- custom CA certificates, 
- client certificates and keys, 
- server name verification, 
- strict hostname validation. 

TLS should be enabled whenever GreptimeDB is accessed over untrusted networks.