Skip to content

Architecture

Keel ships as a single self-contained virtual appliance. Everything runs inside the VM on your hypervisor; the only outbound dependency is an optional, narrow connection to the license portal (and, if you choose a hosted LLM, to that provider).

Components

A Keel node runs a set of containerized services managed together:

  • Ingest collectors — per-source listeners for OpenTelemetry (OTLP gRPC 4317 / HTTP 4318), Syslog (TCP/UDP 514), and Fluentd (24224). Custom ports are supported.
  • Application engine — the API and processing core: log pipelines, alert routing, incident/RCA generation, the Platform Assistant, reports, and all settings.
  • Log store — a column-oriented database (ClickHouse) holding logs, with a tiered storage policy (hot local disk + optional S3-compatible cold tier).
  • Configuration database — relational store (MySQL) for settings, users, pipelines, etc.
  • Vector index — semantic index (Qdrant) for the Knowledge Base / RAG used to ground RCA.
  • Object storage — internal object store for backups and cold-tier data when configured.
  • Web gateway — TLS termination and the web dashboard (Caddy).
  • Failover manager — keepalived + cluster coordination for High Availability.

Data flow

  sources ──► collectors ──► log pipeline ──► log store ──► search / BI / reports
  (OTLP/Syslog/Fluentd)        (mask, parse,    (hot→cold
                                enrich, route)    tiering)
  alert sources ──► alert pipeline ──► incident ──► AI RCA ──► notification channels
  (Alertmanager/                                    (LLM + RAG    (email/Slack/Teams/
   Datadog/PagerDuty/                                + correlated  PagerDuty/webhook)
   webhook)                                          logs)

Storage tiering

Logs live on a hot local disk for fast queries and age out to an optional cold S3-compatible tier by per-class retention. The cold tier stores compressed data blobs in your object store (e.g. MinIO/S3); the appliance keeps only small local metadata for it. Cold data stays queryable. See storage.

The LLM (you control it)

Keel never embeds a model or sends data to an Infranexis service for AI. Under AI Configuration you select the backend: a local model (Ollama) for fully air-gapped AI, or your own Anthropic/OpenAI(-compatible) key. You can set a primary and a secondary backend for failover. See ai-configuration.

High availability

Keel can run as a multi-node cluster with a floating virtual IP (VIP). The log store and configuration data replicate across nodes; the failover manager promotes a healthy node if the active one fails. See high-availability.

Networking & outbound

The appliance is designed to run locked-down. Inbound is limited to the ingest and dashboard ports you enable. Outbound is limited to: - the license portal (*.infranexis.com:443) for connected-mode activation/heartbeat and updates — not required for air-gapped deployments; - your chosen LLM endpoint, if you use a hosted model instead of a local one.

See network-ssl-firewall and the security overview.