Logs, only when it matters.
You should not have to ship every log line just to understand the incident that woke you up.
Keep routine application logs on your hosts. When a configured incident fires, RouteSpear collects the relevant window and attaches the excerpt to that incident. Get evidence for the investigation without continuously ingesting the full log stream.
Keep the evidence. Skip the full-stream ingest.
The first way to control log volume is to decide what actually needs to leave the host.
A busy application produces logs all day. Continuously forwarding those lines means transferring and storing routine traffic alongside the small window you may need during an investigation. With targeted capture, routine raw logs stay at the source; only configured incident excerpts are uploaded.
You control the capture budget. The default excerpt covers 120 seconds before and 30 seconds after the incident, with up to 200 lines and 32 KiB of text. The configured line and byte limits bound what is returned even during a noisy failure.
Your raw log uploads follow incident frequency and capture limits, rather than every routine line the application writes. How much data this saves depends on your workload and the rules you choose.
From unhealthy test to attached evidence
Choose the evidence before you need it
Create a log ingest rule for an agent file, Windows event channel, or remote file over SSH. Select the agents and tests whose unhealthy incidents should trigger collection. The collector can be on a different machine from the test.
Let the incident trigger the capture
When an incident opens at your chosen severity or escalates to it, the collector gathers a bounded excerpt around that moment. Set the time window, matching patterns, nearby context, and redaction rules.
Read the logs where the investigation lives
Returned excerpts attach to the triggering incident. Open Log evidence to see the capture status, time window, redacted text, and any limits that made the excerpt incomplete.
A checkout failure, for example
Your checkout HTTP test becomes unhealthy. Its incident triggers a collector to read /var/log/checkout/app.log on the application server over SSH. The timestamped excerpt is filtered and redacted before upload, then attached to the checkout incident. Collection does not depend on whether a notification was delivered.
Watch locally. Send a signal.
For local files and Windows event channels, optional Log Beacons watch for known problem patterns. Custom metric rules can count matching lines or extract numeric values. These send small numeric signals through the measurement pipeline while raw log text stays in a bounded local buffer until an incident requests it.
SSH sources support incident captures only. The collector uses a stored password or private-key reference, verifies the remote server’s host key, and reads the configured file. No agent installation is required on the remote log host; it needs SSH access, a POSIX shell, and tail.
A focused excerpt has honest limits.
- This is incident evidence, not a complete log archive. Keep an archive separately if you need every event for audit, historical search, or replay.
- History can be incomplete. Local buffers are bounded. SSH capture scans at most the last 4 MiB of the current file after the capture window closes and does not search rotated files. Supported timestamps and source clock accuracy determine which lines fall in the window.
- Collection limits stay visible. Captures are capped at 500 lines or 32 KiB, can be skipped or fail, and report missing or truncated evidence. An empty excerpt does not prove the application was healthy.
- Evidence has a retention window. Captured text remains on the incident for 14 days. Removing an ingest rule does not erase already captured evidence. Viewing it requires incident-read and agent-management permissions.