Skip to content

Migrate to Logchef

Logchef is a query and control-plane UI, not a log storage engine. “Migrating to Logchef” really means two things: re-pointing your log pipeline at a storage backend Logchef supports (ClickHouse or VictoriaLogs), and then using Logchef to explore, dashboard, and alert on what lands there. Your existing shippers usually need only a sink/output change, not a rewrite.

These guides walk through that move from the two most common log stacks:

  • Ingestion: your shipper’s output changes (to a ClickHouse sink, or an Elasticsearch-compatible/native endpoint for VictoriaLogs). The input side — tailing files, scraping Kubernetes pod logs, receiving syslog — usually doesn’t need to change. See Shipping Logs with Vector.
  • Schema: instead of a dynamic mapping (Elasticsearch) or a label set (Loki), you define columns up front, with a Map or JSON column for free-form attributes. See Schema Design.
  • Query language: you write LogchefQL for everyday filtering (it compiles to SQL or LogsQL depending on the source), and drop into native SQL or LogsQL for aggregations the quick-filter syntax doesn’t cover.
  • The UI: log explorer, field sidebar, dashboards, alerting, and saved queries/collections replace Kibana Discover or Grafana Explore for logs specifically. Logchef doesn’t replace Grafana for metrics or Kibana for full-text search products — it’s scoped to log analytics.

Logchef has no ingestion pipeline of its own, so you keep whatever collector you already trust (Vector, Fluent Bit, the OpenTelemetry Collector, or Filebeat/Promtail if you’d rather keep them and just add a second output). Nothing about how logs are produced or collected has to move on day one — only where they land.

Both guides assume you’re moving log storage to ClickHouse. If you’d rather keep a label-oriented, VictoriaMetrics-style backend, Logchef also supports VictoriaLogs as a datasource — closer in shape to Loki, but queried through LogsQL instead of LogQL.