Log export methods

SigNoz accepts logs via OTLP (OpenTelemetry Protocol) or HTTP. This doc explains the different paths your logs can take to reach SigNoz and helps you understand the trade-offs of each approach.

For step-by-step setup guides, see Send Logs to SigNoz.

Quick Decision Guide

Path 1: SDK OTLP Export

Your application uses an OpenTelemetry SDK to send logs directly to SigNoz via OTLP.

┌─────────────────────┐         OTLP          ┌─────────────────────┐
│   Your Application  │ ───────────────────▶  │       SigNoz        │
│   (OTel SDK)        │                       │                     │
└─────────────────────┘                       └─────────────────────┘

Benefits:

• ✅ Trace-log correlation — Automatic trace_id and span_id injection
• ✅ Structured logs with rich application context
• ✅ No additional infrastructure needed

Trade-offs:

• ❌ Logs are in-process — if app crashes, buffered logs may be lost
• ❌ Requires code changes or runtime configuration

Language Guides

Path 2: HTTP API

Send logs directly to SigNoz over HTTP using a simple JSON payload.

┌─────────────────────┐         HTTP          ┌─────────────────────┐
│   Your Application  │ ───────────────────▶  │       SigNoz        │
│   (HTTP Client)     │                       │                     │
└─────────────────────┘                       └─────────────────────┘

Benefits:

• ✅ Language-agnostic — works with any language that can make HTTP requests
• ✅ Simple integration for custom log sources

Trade-offs:

• ❌ Manual implementation required
• ❌ No automatic trace correlation (include trace context fields manually if needed)

→ HTTP Logs API Guide

Path 3: Write to File + OTel Collector

Your application writes logs to stdout/file. The OpenTelemetry Collector reads these files and sends logs to SigNoz.

┌─────────────────────┐         ┌─────────────────────┐         ┌─────────────────────┐
│   Your Application  │ ──────▶ │   Log File/stdout   │ ──────▶ │   OTel Collector    │ ──────▶ SigNoz
│   (any language)    │  write  │                     │  read   │   (filelog recv)    │  OTLP
└─────────────────────┘         └─────────────────────┘         └─────────────────────┘

Benefits:

• ✅ More reliable than SDK — logs persist to disk even if app crashes
• ✅ Preprocessing — filter, enrich, and transform logs before sending
• ✅ Add metadata — inject Kubernetes labels, host info, etc.
• ✅ No code changes to your application
• ✅ Common pattern for Kubernetes and Docker environments

Trade-offs:

• ❌ No automatic trace correlation (unless you include trace context fields in log output)
• ❌ Requires running an OTel Collector

Platform Guides

Path 4: OTel Collector Receivers

The OpenTelemetry Collector has native receivers for many log sources. These receivers connect directly to services and pull logs without needing file-based collection.

┌─────────────────────┐                       ┌─────────────────────┐
│   Log Source        │ ───────────────────▶  │   OTel Collector    │ ──────▶ SigNoz
│   (CloudWatch,      │   Native receiver     │                     │  OTLP
│    Kafka, etc.)     │                       └─────────────────────┘
└─────────────────────┘

Benefits:

• ✅ Native integration with many services
• ✅ No intermediate file storage needed
• ✅ Preprocessing and filtering in the collector

Available Receivers

Path 5: Log Processors

If you already have FluentBit, Fluentd, Logstash, or Vector in your infrastructure, you can forward logs to SigNoz.

┌─────────────────────┐         ┌─────────────────────┐         ┌─────────────────────┐
│   Your Application  │ ──────▶ │   FluentBit/Fluentd │ ──────▶ │       SigNoz        │
│                     │         │   Logstash/Vector   │  OTLP   │                     │
└─────────────────────┘         └─────────────────────┘         └─────────────────────┘

Benefits:

• ✅ Use existing log infrastructure
• ✅ No changes to current logging setup

Trade-offs:

• ❌ Extra hop in the pipeline
• ❌ No automatic trace correlation

Forwarder Guides

Cloud & Platform Scenarios

Different cloud platforms and deployment models support multiple collection paths. This section helps you understand which paths apply to your specific scenario.

AWS

Azure

GCP

PaaS Platforms

Why Use the OTel Collector?

The OpenTelemetry Collector is a key component in Paths 3 and 4. It provides:

• Filtering — Drop noisy logs or sensitive data before they reach SigNoz
• Enrichment — Add Kubernetes metadata, host info, or custom attributes
• Batching & Compression — Efficient network usage
• Reliability — Buffer logs during network issues

Learn more: OTel Collector Configuration

Combining Multiple Paths

Many teams use multiple collection methods:

• SDK OTLP for application services where trace correlation matters
• OTel Collector (File or Receivers) for infrastructure logs, databases, and third-party software

If you're on Kubernetes and use both approaches, disable automatic log collection for pods using SDK export to avoid duplicates.

Comparison Summary

Next Steps

Once logs are flowing to SigNoz:

1. Explore logs in the Logs Explorer
2. Set up log-based alerts
3. Use log pipelines for parsing and enrichment

Get Help

If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack.

If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.