How it works

 your server                                          Logcore
┌──────────────────────────────────────────┐        ┌──────────────────────────────┐
│ log files ─▶ tailer ─▶ filters ─┐        │ HTTPS  │                              │
│                                 ├─▶ sender ──────▶│ logs, host metrics           │
│ CPU / mem / disk ─▶ metrics ────┘        │ (gzip) │                              │
│                                          │        │ dashboard, monitors, reports │
│ your apps ─OTLP─▶ APM forwarder ─────────────────▶│ traces, OTel metrics & logs  │
└──────────────────────────────────────────┘        └──────────────────────────────┘

Logs

1. Finding files. Every 10 seconds, the agent re-checks the paths in your service files, so it picks up new files automatically, for example after log rotation.
2. Following files. The agent reads each file from where it left off. It saves read positions in registry.json in its data folder, so a restart or reboot neither resends nor skips lines.
3. First start. When you add a service, the agent reads its existing files from the end, so old content isn't imported. Files that appear later are read from the beginning. You can change this with logs.start_position.
4. Rotation. The agent identifies files by inode on Linux and by file ID on Windows, so it handles renamed and recreated files correctly. It never stops your files from being deleted or rotated.
5. Processing. The agent joins multiline events, applies your include and exclude rules to decide which lines to keep, and assigns each line a status (severity).
6. Sending. The agent sends lines in batches of up to 1,000 lines, 2 MB or 1 second, whichever comes first. Batches are gzip-compressed and sent over HTTPS. If Logcore can't be reached, the agent retries, waiting from 1 second up to 60 seconds between attempts, and keeps up to 5,000 lines queued in memory. While the queue is full it pauses reading files, so no lines are lost as long as the agent keeps running.

Status (severity)

Every line gets one of these statuses: critical, error, warning, info or debug.

By default, the agent looks for a level keyword in the first 256 characters of each line:

Keyword (any case)	Status
emerg, emergency, fatal, crit, critical, panic	critical
err, error, severe	error
warn, warning	warning
info, notice	info
debug, trace	debug

Lines without a keyword get info. You can change this per service with status overrides.

Host metrics

Every 15 seconds by default, the agent samples CPU, memory, swap, load average, disk usage per mount and network traffic. A heartbeat every 30 seconds keeps the host Online. A host that hasn't reported for 2 minutes is shown as Offline.

APM

When APM is enabled, the agent listens for OpenTelemetry data on localhost:4317 (gRPC) and localhost:4318 (HTTP). It forwards that data to Logcore using its own API key, so apps on the server don't need one. See the APM overview.

Security

• The agent only makes outbound HTTPS connections. By default nothing listens on a public interface.
• On Linux, the agent runs as the unprivileged logcore-agent user. That user is in the adm and systemd-journal groups so it can read /var/log.
• logcore.yaml contains your API key, so only root and the agent can read it (mode 0640).
• The local status API listens on 127.0.0.1:5280 and requires a token that only root or the agent can read.