Skip to content
Start free

Observe · Log Management

Search every log the way you think.

Filter with KQL, aggregate with ES|QL, or just ask a question in plain language. Anomaly models learn each source, and the forwarder at your edge buffers through outages so nothing is dropped.

Start freeBook a demo
Log Management / Log Explorer
Example
Example: in the Log Explorer, the KQL query service:checkout-api and level:error returns timeout and 502 errors from the checkout service, newest first; one row is expanded to show its fields.

ES|QL analytics

From filter to answer in one line.

Pipe your results through ES|QL right in the explorer — STATS … BY host | SORT … | LIMIT 10 — and get a table back in well under a second.

  • KQL filtering and field statistics
  • Available-fields sidebar and expandable rows
  • Source and identifier picker
Log Management / Log Explorer · ES|QL
Example
Example: in ES|QL mode the query FROM logs-* | WHERE level == "error" | STATS errors = COUNT(*) BY host | SORT errors DESC | LIMIT 10 runs and returns a six-row table of error counts per host, led by app-02.

Semantic search

Search for what happened, not the exact words.

Type “service stopped unexpectedly” and semantic search returns the events that mean that — whichever words the application chose to log it with.

Log Management / Log Explorer · Semantic Search
Example
Example: with Semantic Search on, the question “service stopped unexpectedly” returns four events worded differently — a Windows service that terminated unexpectedly, a worker OOMKilled, an nginx main process exit and a disabled IIS application pool — ranked by relevance, although an exact keyword match finds none.

Anomaly Detection

A model for every source.

Anomaly Detection trains a model per log source, with field mappings and exclusion rules you control, and alerts when behaviour departs from what it learned. Log conditions can raise alerts too.

Log Management / Anomaly Detection
Example
Example: the edge-proxy model, trained with field mappings status and upstream_time and two exclusion rules, watches log volume; the volume line leaves its learned expected band, an anomaly marker reads 4.1× expected, and an alert is raised.

Collection

An outage buffers logs. It doesn’t drop them.

Fluent Bit agents ship to the Ceburu Log Forwarder at your edge. The forwarder keeps a write-ahead log on disk, so a WAN outage queues logs instead of losing them — and recent logs stay searchable locally while the site is disconnected. Long-term archive storage keeps history.

  • Fluent Bit agents
  • Disk write-ahead log at the edge
  • Local search while disconnected
  • Long-term archive storage
Log Management / Log Forwarder
Example
Example: Fluent Bit agents on app-01, web-02 and db-01 ship logs to the Ceburu Log Forwarder at the site edge, which sends them to Ceburu over port 443. During a WAN outage the forwarder's disk write-ahead log buffers 18,420 events with 0 dropped, and recent logs stay searchable locally as on-prem logs.

Capabilities

Everything in Logs

The complete list, as it exists in the product today.

Explore

  • Log Overview and Log Dashboards
  • Log Explorer with KQL filtering
  • Field statistics and an available-fields sidebar
  • Expandable log rows
  • Source and identifier picker

Analyse

  • ES|QL analytics in the explorer — e.g. STATS … BY host | SORT … | LIMIT 10 — with results in well under a second
  • Semantic search: ask a plain-language question such as “service stopped unexpectedly” and get relevant events, not just keyword hits

Detect

  • Anomaly Detection with AI-trained models per log source
  • Field mappings and exclusion rules for each model
  • Alerts on log conditions

Collect

  • Fluent Bit agents ship to the Ceburu Log Forwarder at your edge
  • The forwarder keeps a disk write-ahead log, so a network outage buffers logs instead of dropping them
  • Recent logs stay searchable locally even while a site is disconnected
  • Long-term archive storage

Works with AI Core

Log signals feed AI Core.

Shifts in log volume are one of the signals AI Core correlates, so a burst of errors in the logs and the service that produced them land in the same situation.

How AI Core works

From Logs

  • Log-volume shifts
  • Anomalies from per-source models

Get started

See every signal in one place.

Start with one site and one probe. Add modules as you go — the AI Core gets more useful with every source you connect.

Sign upBook a demoRead the docs (opens in a new tab)

Already have an account? Sign in to the portal