sebk69

Posted on Apr 27

Introducing Logarys — A Lightweight, Scalable Log Monitoring Platform

#monitoring #devops #docker #analytics

Modern applications generate a massive amount of logs.

But let’s be honest:

Logs are often hard to query
Pipelines become over-engineered
Observability stacks get expensive and complex

So I built something different.

Meet Logarys — a simple, scalable log ingestion and querying platform designed for developers who want control without complexity.

Why Logarys?

After working with logging and monitoring stacks, I kept running into the same issues:

Too many moving parts
Heavy infrastructure requirements
Slow ingestion under load
Complex query systems

I wanted something:

Fast to ingest logs
Modular by design
Easy to deploy with Docker or Kubernetes
Simple but powerful to query

So Logarys was born.

Architecture: simple by design

Logarys is built around a few clear responsibilities:

Ingestor: receives logs and normalizes them
NATS JetStream: streams and buffers log events
Storage Manager: persists logs into MongoDB
Console Manager + UI: lets users query and visualize logs

Flow

Application
    ↓
Ingestor
    ↓
NATS JetStream
    ↓
Storage Manager
    ↓
MongoDB
    ↓
Console Manager + UI

This architecture gives Logarys:

Horizontal scalability
Backpressure handling
Separation of concerns
A lightweight deployment model

Key features

Flexible ingestion pipelines

Logarys lets you define how logs are parsed, transformed, and routed.

Pipelines can be used to handle:

JSON logs
Raw text logs
Custom formats
Application-specific parsing rules

Query with RSQL

Instead of requiring a complex query language, Logarys uses RSQL.

Example:

level==ERROR;service==payment

Another example:

timestamp>=2026-01-01;level=in=(ERROR,WARN)

It is readable, powerful, and easy to integrate into APIs.

Web UI

Logarys includes a web interface to:

Search logs
Filter by fields
Explore records
Manage pipelines
Configure ingestion behavior

User management

Logarys includes user management and is designed to be extended with authentication systems such as SSO or Keycloak.

Quick start with Docker

services:
  nats:
    image: nats:2.11-alpine
    command:
      - "-js"
      - "-m"
      - "8222"
      - "-sd"
      - "/data"
    ports:
      - "4222:4222"
      - "8222:8222"
    volumes:
      - nats-data:/data
    restart: unless-stopped

  mongodb:
    image: mongo:7
    ports:
      - "27017:27017"
    volumes:
      - mongodb-data:/data/db
    restart: unless-stopped

  ingestor:
    image: logarys/ingestor:latest
    environment:
      APP_HOST: "0.0.0.0"
      APP_PORT: "3000"
      NATS_URL: "nats://nats:4222"
      MONGODB_URL: "mongodb://mongodb:27017/logarys"
      CONF_FILE: "/conf/pipelines.json"
      CONF_PIPELINES_DIR: "/conf/pipelines.d"
    volumes:
      - ./conf:/conf:ro
    depends_on:
      - nats
      - mongodb
    ports:
      - "3000:3000"
    restart: unless-stopped

  storage-manager:
    image: logarys/storage-manager:latest
    environment:
      NATS_URL: "nats://nats:4222"
      MONGODB_URL: "mongodb://mongodb:27017/logarys"
      LOGS_DB_NAME: "logarys"
    depends_on:
      - nats
      - mongodb
    restart: unless-stopped

  console-manager:
    image: logarys/console-manager:latest
    environment:
      APP_HOST: "0.0.0.0"
      APP_PORT: "3002"
      MONGODB_URL: "mongodb://mongodb:27017/logarys"
      NATS_URL: "nats://nats:4222"
      LOGS_DB_NAME: "logarys"
      JWT_SECRET: "change-me"
    depends_on:
      - nats
      - mongodb
    ports:
      - "3002:3002"
    restart: unless-stopped

  ui:
    image: logarys/ui:latest
    environment:
      PUBLIC_CONSOLE_API_URL: "http://localhost:3002"
    depends_on:
      - console-manager
    ports:
      - "8080:4173"
    restart: unless-stopped

volumes:
  nats-data:
  mongodb-data:

Then open:

http://localhost:8080

Design choices

Why NATS JetStream?

NATS JetStream is lightweight, fast, and well-suited for streaming workloads.

For Logarys, it provides:

Message buffering
Stream persistence
High throughput
Better separation between ingestion and storage

Why MongoDB?

Logs are often semi-structured.

MongoDB is a good fit because:

Log schemas can vary
JSON-like documents are natural to store
Writes are fast
Indexing can be adapted to common fields

Why not another full observability stack?

Tools like ELK, Loki, and other observability platforms are powerful.

But sometimes, you do not need a huge stack.

Logarys focuses on:

Simplicity
Developer control
Fast ingestion
Flexible pipelines
Easy deployment

When should you use Logarys?

Logarys is a good fit if you:

Run microservices
Need fast log ingestion
Want full control over log pipelines
Prefer lightweight infrastructure
Need a simple way to query logs
Want a platform that is easy to understand and operate

Trade-offs

Logarys is still evolving.

It is not meant to replace every enterprise observability platform yet.

Current trade-offs:

Fewer built-in dashboards than mature monitoring suites
Pipeline configuration is required
Alerting and advanced analytics are roadmap items

But in return, you get a focused and lightweight log platform.

Roadmap

Planned improvements include:

Dashboards
Alerts and notifications
Pipeline templates
Metrics integration
More deployment examples
Better documentation

Final thoughts

Monitoring should not feel like running a second infrastructure.

With Logarys, the goal is simple:

Logs should be easy to ingest, easy to query, and easy to scale.

Feedback welcome

If you work with logging or monitoring systems, I would love to hear your thoughts.

What tools are you using today?

What frustrates you the most about logging platforms?

DEV Community