Sloggo

Product Introduction

1. Definition: Sloggo is a lightweight, open-source log management solution specifically categorized as an RFC 5424 syslog collector and viewer. It ingests logs via TCP/UDP, stores them efficiently using DuckDB, and provides a web-based UI for exploration.
2. Core Value Proposition: Sloggo exists to offer real-time log collection and exploration with minimal resource overhead (CPU/RAM), eliminating the need for complex, heavyweight stacks like ELK or Loki for small-to-medium log volumes. Its primary value is simplicity and efficiency for non-critical logging needs.

Main Features

1. RFC 5424 & RFC 3164 Syslog Ingestion:
   • How it works: Listens on configurable TCP/UDP ports (SLOGGO_TCP_PORT, SLOGGO_UDP_PORT) for syslog messages. Uses the robust go-syslog library for parsing. Supports automatic detection (SLOGGO_LOG_FORMAT=auto), RFC 5424-only, or RFC 3164-only parsing. Handles structured data (SD) elements from RFC 5424.
2. DuckDB-Powered Storage & Querying:
   • How it works: Logs are stored in a local DuckDB database file (./data volume). DuckDB's columnar format and SQL support enable efficient filtering, searching, and aggregation directly within the single Sloggo process. Automatic log rotation is managed via SLOGGO_LOG_RETENTION_MINUTES (default 30 days).
3. Single-Process Architecture & Web UI:
   • How it works: Combines the collector, database, and React-based frontend (data-table-filters components) into one Go binary. Serves the UI and API on SLOGGO_API_PORT (default 8080). Provides real-time log tailing, fast search, and filtering directly in the browser with minimal setup.
4. High-Performance Ingestion:
   • How it works: Optimized Go routines handle concurrent log reception and batching for DuckDB insertion. Benchmarks indicate capability for up to 1 million logs per second ingestion rates under optimal conditions, suitable for bursty traffic.

Problems Solved

1. Pain Point: Overkill and Complexity of traditional log stacks (ELK, Splunk, Loki) for small applications, development environments, or low-volume logging needs, which incur high resource costs (JVM) and operational complexity.
2. Target Audience:
   • Small DevOps/SRE Teams: Needing simple internal log visibility without dedicated infra.
   • Developers/Engineers: Seeking a lightweight log viewer for local development, debugging, or side projects.
   • Bootstrapped Startups/SMBs: Requiring cost-effective, basic log monitoring for non-critical systems.
3. Use Cases:
   • Development/Staging Logging: Centralized log viewing for debugging applications in non-production environments.
   • Edge/IoT Device Log Collection: Lightweight agent for gathering logs from resource-constrained devices.
   • Microservice Sidecar Logging: Companion container for collecting logs from a primary service pod/container.
   • Simple Application Monitoring: Basic uptime checks and error log tracking for small internal tools.

Unique Advantages

1. Differentiation:
   • vs. Heavyweight Stacks (ELK/Loki): Drastically lower resource consumption (single binary, <10MB compressed, no JVM), zero external dependencies (no Elasticsearch, no Promtail, no Kafka), and instant setup via Docker or binary.
   • vs. Other Minimal Collectors (syslog-ng/rsyslog + UI): Integrates storage (DuckDB) and a modern search/tail UI out-of-the-box in a single process, removing the need to chain multiple tools.
2. Key Innovation: The tight integration of DuckDB as the embedded analytical engine within the log collector process. This eliminates network hops for querying, leverages DuckDB's performance for on-disk filtering/aggregation, and enables the rich UI features directly against the log store.

Frequently Asked Questions (FAQ)

1. Is Sloggo production-ready?
   No. Sloggo is explicitly labeled as alpha software ("Warning: currently in alpha release, do not use it for anything serious"). It lacks high availability, redundancy, granular access controls, and long-term support guarantees expected for production.
2. How does Sloggo handle security?
   Sloggo has no built-in authentication or encryption for its API or syslog ports. It must only be deployed within private, trusted networks or placed behind a secure reverse proxy (e.g., nginx, Traefik) handling TLS termination and authentication.
3. What is Sloggo's scalability limit?
   While capable of high ingestion bursts (~1M logs/sec), Sloggo is designed for small-to-medium log volumes. Its single-process nature and local DuckDB file mean storage capacity and query performance are ultimately limited by the resources (CPU, RAM, Disk I/O) of the single node it runs on. It's not a distributed system.
4. Can Sloggo parse non-RFC5424 logs?
   Yes. While optimized for RFC 5424, it supports RFC 3164 (BSD-syslog) format explicitly and has an auto mode (SLOGGO_LOG_FORMAT) that attempts RFC 5424 parsing first and falls back to RFC 3164. It does not support arbitrary log formats like JSON lines out-of-the-box.
5. How is data retention managed in Sloggo?
   Retention is controlled by the SLOGGO_LOG_RETENTION_MINUTES environment variable (default: 43200 minutes = 30 days). Sloggo automatically deletes logs older than this duration. There is no tiered storage or archiving; older data is simply purged.