Frequently Asked Questions

The Starter plan allows up to 5 GB of log data per day. If you exceed this threshold, LogTrace will continue accepting logs but will downsample entries older than 24 hours until the next calendar day resets the counter. You can monitor your daily usage in real time on the Usage & Billing dashboard.

Starter retains logs for 7 days, Business for 30 days, and Enterprise allows configurable retention up to 365 days. Archived data beyond the active window can be exported to S3-compatible object storage at an additional cost of $0.023 per GB-month.

Starter supports up to 10 concurrent queries, Business up to 50, and Enterprise has no hard cap. Each query is rate-limited to 120 requests per minute per API key. Exceeding the rate limit returns HTTP 429 with a Retry-After header indicating the back-off window.

Yes. Upgrades take effect immediately and you are charged a prorated amount. Downgrades apply at the start of the next billing cycle. Your existing data is never deleted during a plan change — only retention windows and query quotas adjust.

The official image ghcr.io/logtrace/collector is published for linux/amd64, linux/arm64, and linux/arm/v7. Use version tags such as 2.14.0 or latest. The image is approximately 48 MB compressed and runs on Docker Engine 20.10+ and Podman 4.0+.

Add the Helm repository with helm repo add logtrace https://charts.logtrace.io, then run helm install logtrace-collector logtrace/collector --namespace logtrace --create-namespace. The chart deploys a DaemonSet with hostPath mounts for /var/log and /var/lib/docker/containers. Default resource requests are 100 mCPU and 128 MiB per node.

Yes. When the collector runs as a DaemonSet, it monitors the container runtime's log directory and automatically picks up stdout/stderr from every pod. You can also deploy the collector as a sidecar by mounting the target container's log file via a shared emptyDir volume. Both approaches are documented in the Kubernetes Integration Guide.

Yes. A reference docker-compose.yml is included in the repository. Mount /var/run/docker.sock and /var/lib/docker/containers into the collector service, set the LOGTRACE_API_KEY environment variable, and logs begin flowing within seconds. This setup is ideal for development and small staging environments.

Yes. The logtrace-import CLI tool reads directly from Elasticsearch or OpenSearch via the Scroll API. Run logtrace-import es --source https://es.internal:9200 --index "logs-*" --api-key $KEY to begin. The tool preserves timestamps, host fields, and message text. Custom fields are mapped to LogTrace attributes automatically. Typical import speed is 80,000–120,000 events per second per worker thread.

LogTrace does not offer a one-click Splunk dashboard converter, but the Splunk-to-LogTrace Query Reference maps every SPL command to its equivalent LogTrace query syntax. Common patterns — stats count by host, top limit=10 method, and time-based timechart — translate directly. Our migration team can also generate LogTrace dashboard JSON from your Splunk XML exports at no extra cost.

Graylog users can export stream data via the Graylog REST API or by re-pointing their GELF inputs to the LogTrace collector endpoint. Since LogTrace accepts GELF natively, you can switch the transport URL from udp://graylog:12201 to https://ingest.logtrace.io/gelf with zero format changes. Alerts and extractors must be recreated manually; a field-mapping spreadsheet is provided during onboarding.

LogTrace does not delete data from your existing system. The import tool runs alongside your current stack, so you can validate parity before decommissioning. We recommend a 48-hour overlap period where both systems ingest simultaneously. Use the Comparison View in the web UI to verify event counts and field values match.

We test and certify on Ubuntu 20.04 LTS / 22.04 LTS / 24.04 LTS, Debian 11 / 12, CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, and RHEL 8.6+. The collector is a statically linked Go binary and runs on any glibc 2.17+ system. Alpine Linux (musl) is supported starting with collector version 2.12.0.

Yes. The Windows agent is available as an MSI installer and a Windows Service binary. It supports Windows Server 2016, 2019, and 2022, as well as Windows 10/11 for workstation logging. The agent reads the Application, System, and Security event logs via the native Windows Event Log API and forwards them over TLS to the LogTrace ingestion endpoint.

The collector is lightweight: 50 MB RAM idle, 100 MB under typical load (up to 10,000 events/sec). CPU usage stays below 50 m on a single core for most workloads. For production nodes handling 50,000+ events/sec, we recommend 1 vCPU and 256 MB RAM. Disk I/O is minimal since the collector buffers in memory and flushes over the network.

macOS binaries are provided for local development and testing (Intel and Apple Silicon). However, macOS is not a supported production platform. Performance and stability are not guaranteed, and macOS agents are excluded from SLA coverage. For production, use Linux or Windows.