Caddy Reverse Proxy

Caddy is a powerful HTTP/2 web server with automatic HTTPS. You can configure Caddy as a reverse proxy for LogScale. If you are not yet familiar with Caddy, we strongly recommend reading through the Caddy documentation before proceeding.

Note

These instructions apply to Caddy v2. Caddy v1 is end-of-life and no longer recommended.

Basic Single Node Setup

For a basic single node LogScale cluster, a minimal reverse proxy configuration is all that is required, though adding access logging is recommended.

caddy
logscale.example.com {
    log {
        output file /var/log/caddy/logscale.access.log
        format combined
    }
    reverse_proxy / http://127.0.0.1:8080 {
        health_uri /api/v1/status
    }
}

Save this as /etc/caddy/Caddyfile and start Caddy with:

shell
caddy run --config /etc/caddy/Caddyfile

Caddy will automatically obtain and renew a TLS certificate for your domain via Let's Encrypt. Ensure your server is publicly reachable on ports 80 and 443 before starting.

Multi-Node Cluster Setup

For a cluster with multiple LogScale nodes, use load balancing across your nodes. The example below uses the least_conn policy, which routes requests to the node with the fewest active connections.

caddy
logscale.example.com {
    log {
        output file /var/log/caddy/logscale.http.log
        format combined
    }

    # Ingest traffic - WebSocket not required
    reverse_proxy /api/v1/ingest logscale01:8080 logscale02:8080 logscale03:8080 {
        lb_policy least_conn
        health_uri /api/v1/status
    }

    # All other traffic, including UI (WebSocket handled automatically)
    reverse_proxy / logscale01:8080 logscale02:8080 logscale03:8080 {
        lb_policy least_conn
        health_uri /api/v1/status
    }
}

# Elasticsearch-compatible ingest endpoint
https://logscale.example.com:9200 {
    log {
        output file /var/log/caddy/logscale.es.log
        format combined
    }
    reverse_proxy / logscale01:9200 logscale02:9200 logscale03:9200 {
        lb_policy least_conn
    }
}

Note

Caddy v2 handles WebSocket connections automatically. No additional configuration is required.

Forwarding and Parsing Access Logs to LogScale

Filebeat can be used to forward Caddy access logs to LogScale for ingestion and parsing.

Filebeat Configuration

yaml
filebeat.inputs:
  - type: log
    paths:
      - "/var/log/caddy/*.log"
    encoding: utf-8

output.elasticsearch:
  hosts: ["$YOUR_LOGSCALE_URL/api/v1/ingest/elastic-bulk"]
  username: $INGEST_TOKEN
  compression_level: 5
  bulk_max_size: 200
  workers: 1

Note

Replace $YOUR_LOGSCALE_URL and $INGEST_TOKEN with your LogScale URL and a valid ingest token respectively.

Log Format

The combined format used above produces log lines in the following structure:

text
{remote} - {user} [{when}] "{method} {uri} {proto}" {status} {size} "{>Referer}" "{>User-Agent}"

LogScale Parser

Use the following custom parser to parse the combined log format in LogScale. Ensure your ingest token is linked to this parser.

logscale
/^(?<remote>\S+) - (?<user>\S+?) \[(?<when>\S+\s\S+)\] "(?<method>\S+?) (?<uri>\S+) (?<proto>\S+)" (?<status>\d+) (?<size>\d+) "(?<referrer>.*?)" "(?<useragent>.+?)"/
| @timestamp := parseTimestamp("dd/MMM/yyyy:HH:mm:ss Z", field=when)

Note

The timestamp is parsed using the timezone embedded in the log line itself. If your Caddy server does not log timestamps with timezone offset, set the timezone parameter explicitly to match your server's local timezone, for example timezone="America/New_York".