Log management
Search every log line, parsed at the edge
Collect logs from files, journald, Windows Event Log, syslog, Kubernetes pods, cloud services and OpenTelemetry SDKs. Pipelines parse, redact and drop lines in your own collectors, the Log Explorer turns them into patterns and charts, and lifecycle rules decide how long each source is kept.
- Pipelines run in your collectors
- Tested on real samples
- Hot, cold and delete per dataset
How it works
From a raw line to a record you can search
Every line is stored with OpenTelemetry fields such as severity, body, trace_id and resource attributes, under the dataset it came from.
- 01CollectFiles, journald, Windows Event Log, syslog, pod logs, cloud services and OTLP arrive through one collector.
- 02ParsePipelines turn lines into fields with JSON, regex, key-value and CSV steps, compiled to OTTL in your collectors.
- 03Clean upRedact secrets, rename fields and drop noise before anything is stored.
- 04StoreEach source keeps its own dataset in your workspace's database, with its own lifecycle.
- 05SearchFilter with key:value queries, group lines into patterns, chart them and save the views you use.
- 06ExpireLifecycle rules move each dataset to cold storage and delete it on the schedule you set.
Pipelines
Parse at the edge, and test before you publish
A pipeline is an ordered list of steps for one dataset. Tracix compiles it to the OpenTelemetry Transformation Language and runs it in your collectors, after Kubernetes and host metadata are added. Simulate runs the same engine on real samples, so you see each step's output before the fleet does.
- Parse JSON, regular expressions, key-value pairs and CSV, then set timestamps and severity, redact, rename or drop
- Every version is kept, a canary tries a new one on a single collector, and publishing reloads the fleet
- Lines a step could not parse are tagged, so parse failures get their own facet in the explorer
Lifecycle
Keep each source exactly as long as it is useful
Lifecycle rules move data from local disk to object storage after the days you choose and delete it on schedule, for each table and each log dataset. Cold data stays searchable through the same tables, and ClickHouse enforces every rule.
Per dataset
Override the table default for any source, such as keeping auth logs longer than container output.
Your object store
Cold tiers on Amazon S3, S3-compatible storage, Google Cloud Storage or Azure Blob.
Legal hold
Suspend deletion for a dataset while an investigation or an audit needs it.
Preview first
Shortening retention shows how many rows and bytes will go before you apply it.
Search and patterns
Turn a flood of lines into a handful of patterns
The Log Explorer filters with key:value terms, wildcards, exclusions and OR groups, with facets for status, dataset, service, host and source. Group into patterns and ids, addresses and numbers are masked, so a new kind of error stands out.
- Chart any query as a time series, top list, bar chart, table, tree map, pie or scatter plot
- Monitors for log error rate, volume, pattern matches, attribute cardinality and new services
- Saved views keep a query, its columns and its chart behind one link
Better together
Logs are the evidence every team reaches for
Log lines share one workspace with traces, metrics and detections, so the line that explains an incident is never in another tool.
- APM and distributed tracingEach trace's Logs tab shows the lines it wrote, matched by trace ID.Learn more
- Infrastructure monitoringEach host's drawer shows its recent logs beside its metrics.Learn more
- Threat detectionDetection rules read the same log stream, so security and operations work from one copy.Learn more
Log sources
Where logs come from, and how they arrive
Each source is a card in a collector policy or an agentless cloud integration, and every line is stamped with its dataset.
| Source | Collected with | Where it runs | Parsing out of the box |
|---|---|---|---|
| Log files | filelog receiver | Linux, macOS, Windows | JSON lines and multiline options |
| systemd journal | journald receiver | Linux | Built-in pipeline |
| Syslog, RFC 5424 and 3164 | syslog over UDP or TCP | Any collector | Built-in pipeline |
| Windows Event Log | Windows Event Log receiver | Windows | Security, System, Sysmon, PowerShell, Defender |
| Kubernetes pod logs | filelog with the container parser | Kubernetes, Linux nodes | Docker, containerd and CRI-O formats |
| OpenTelemetry SDKs | OTLP over gRPC or HTTP | Any | Already structured, trace context kept |
| AWS | CloudWatch Logs; CloudTrail, GuardDuty and VPC flow logs from S3 | Agentless | Package pipelines |
| Azure | Activity and resource logs through Event Hub | Agentless | Package pipelines |
| Google Cloud | Audit logs through Pub/Sub | Agentless | Package pipelines |
| SNMP traps | SNMP trap receiver | Any collector | Stored as log records |
Pipelines you publish take precedence over built-in and package pipelines for the same dataset. Framing such as multiline grouping and encoding is set on the source, not in a pipeline.
Where do pipelines run?
Does a new pipeline re-parse logs I already have?
Can I use grok patterns?
Can I send some logs to another tool?
Search your first logs in minutes
Install a collector, turn on file, journald or pod logs in its policy, and open the Log Explorer.