Skip to content

Logchef 2.0

Choose a tag to compare

@github-actions github-actions released this 08 Aug 10:46
· 4 commits to main since this release

Logchef 2.0

The largest release in the project's history. Logchef grows from a fast ClickHouse log explorer into an open-source log analytics workspace for ClickHouse and VictoriaLogs: search, live tail, dashboards, alerts, a CLI, and an MCP server, all from one self-hosted binary.

The core idea is unchanged: your logs never move. Point Logchef at the ClickHouse or VictoriaLogs you already run. No new storage layer, no re-ingestion, no parallel pipeline.

The Logchef explorer querying a VictoriaLogs source, with an error histogram and matching structured rows

Live demo · Docs · Full changelog


VictoriaLogs, first class

VictoriaLogs now sits beside ClickHouse as a fully supported datasource. The explorer, LogchefQL, field discovery, histograms, dashboards, alerts, AI query generation, and live tail all work the same on both backends. When an investigation needs backend-specific power, switch to native LogsQL without leaving the page.

Logchef running a native LogsQL query against VictoriaLogs

Sources connect over the VictoriaLogs HTTP API with no auth, basic auth, or a bearer token, plus optional multi-tenant IDs and a server-side scope query enforced on every request. VictoriaLogs guide →

Dashboards, brand new

Logchef 2.0 introduces dashboards: operational views built from log queries. Drag and resize panels directly on the grid, build them in a full-height editor with live query preview, and mix ClickHouse and VictoriaLogs panels on the same dashboard. Time series (line, area, stacked or grouped bars), stats, tables, and category breakdowns as horizontal bars or donuts.

A Logchef dashboard combining ClickHouse and VictoriaLogs panels: stat tiles, time series, a donut breakdown, and an incident table

Dashboards cache panel results server-side (per-dashboard TTL), so a popular dashboard doesn't hammer your backend.

A CLI built for investigations

The CLI (v0.2.1) grew from a query runner into a real investigation tool: draw histograms in your terminal, spot the spike, and pull the matching events without leaving your shell. query, histogram, fields, explain, tail, doctor, and open work across both backends, with stable JSON/JSONL output for scripts and agents.

A terminal session where the logchef CLI draws an error histogram with a visible incident spike, then fetches the matching payment error logs

CLI guide →

Also in 2.0

  • Live tail. Stream matching rows as they arrive, in the browser or the terminal, on either backend, with server-side session and rate guardrails.
  • Run without an identity provider. Built-in email + password login ([auth.local]) with a bootstrap admin. OIDC is now optional, and SSO logins can auto-provision users from approved domains.
  • Agent-native. An MCP server for log investigations (schema discovery, queries, time-window comparison, guided prompts) and a version-matched agent skill shipped inside the CLI.
  • Access control in the open-source build. Teams, roles, collections, scoped service tokens, and provisioning. No enterprise edition.
  • Query history and usage analytics. Reopen your recent queries; admins get per-source and per-user activity trends.
  • AI for every query mode. Generate and validate LogchefQL, ClickHouse SQL, or LogsQL against the active source schema. AWS Bedrock joins OpenAI-compatible providers.
  • Faster and hardened. Large results stream instead of buffering, per-source ClickHouse guardrails cap runaway queries, and auth, dashboards, and the VictoriaLogs connector received a security and reliability pass.

Breaking change: provisioning format

If you provision sources via provisioning.toml, each [[sources]] now requires a source_type and a nested [sources.connection] block. The old flat layout no longer parses, and the server exits on startup with a message pointing at the fix. Teams, members, and non-connection fields are unchanged:

# Before (pre-2.0)
[[sources]]
name = "Production Logs"
host = "clickhouse.internal:9000"
database = "logs"
table_name = "otel_logs"

# After (2.0)
[[sources]]
name = "Production Logs"
source_type = "clickhouse"

[sources.connection]
host = "clickhouse.internal:9000"
database = "logs"
table_name = "otel_logs"

Database migrations run automatically on startup (SQLite 000025–000032, Postgres 000002–000007). One caveat: the email-normalization migration stops for manual resolution if you have case-only duplicate accounts. Details in the changelog.

Install or upgrade

# Docker
docker pull ghcr.io/mr-karan/logchef:v2.0.0

Or grab a binary below for your platform. The quickstart covers configuration, including the new local-auth setup that needs no external identity provider.


Everything else: CHANGELOG.md · v1.7.0...v2.0.0

If your logs already live in ClickHouse or VictoriaLogs, try the demo and tell me what breaks. Issues and PRs welcome.