How Lightbits streams logs to Loki, Rsyslog, and your SIEM — with no proprietary agents and no lock-in.
This feature is available in Lightbits software v3.19.1, which is in tech preview as of this blog post.
Storage that you can’t see is storage you can’t trust. When something goes sideways at 3 a.m. — a noisy tenant, a slow target, a flaky NIC — the difference between a five-minute fix and a five-hour war room is whether the logs are already in the same place as the rest of your telemetry. The new log streaming capability in Lightbits storage v3.19.1 (in tech preview as of this blog post), designed with NVMe over TCP, every service log on every cluster node lands directly in the observability stack you already run, in real time, with no extra agents to manage.
Why log streaming matters for storage
Most storage platforms still treat logs as something the vendor reads after the fact. You file a support ticket, somebody collects a tar.gz, and a week later you get an explanation. That model breaks down the moment storage becomes part of a Kubernetes-native, multi-tenant, audit-regulated cloud.
Modern operations teams have already standardized on a small, opinionated stack — Grafana for dashboards, Loki for logs, Prometheus for metrics, and Rsyslog or a SIEM for compliance. Storage logs need to land there too, alongside everything else, so:
- On-call engineers can correlate a latency spike with the storage event that caused it.
- Security teams get tamper-evident audit trails over mTLS.
- Capacity planners get long-term retention without depending on the vendor, in addition to Grafana/Prometheus metrics and API-driven events.
That’s exactly what Lightbits log streaming delivers.
What Lightbits log streaming is
Log streaming is a built-in capability of every Lightbits cluster. There are no extra packages to install, no sidecars to deploy, and no per-node configuration files to babysit. The whole thing is configured through the same JWT-authenticated REST API — or the same lbcli binary — you already use to manage volumes.
Under the hood, two components do the heavy lifting on each cluster node:
- lightbox-exporter — reads your sources and targets configuration from etcd and renders a pipeline definition.
- Alloy — Grafana’s open-source telemetry collector. It polls lightbox-exporter for the rendered pipeline, tails the local logs, parses them, and ships them to every enabled target.
Because the pipeline is rendered from etcd on every poll, configuration changes propagate cluster-wide within about a minute — with no service restarts.
How it fits together
The diagram below shows the three zones at play: the operator on the left, the Lightbits server in the middle, and the customer’s observability stack on the right.
| Figure 1 — Lightbits log streaming architecture An operator configures sources and targets via lbcli or REST API (HTTPS + JWT). The api-service persists rules to etcd. On every node, lightbox-exporter reads those rules and renders a pipeline that Alloy polls via remotecfg. Alloy tails journald, parses each log line according to its declared format, and pushes the result to one or more enabled targets — Loki, Rsyslog over mTLS, or any compatible aggregator. |
Three things stand out:
- Configuration lives in etcd, not on disk. Updating a source’s minimum log level, disabling a target during maintenance, or rotating a TLS bundle is one API call — picked up cluster-wide without restarts.
- Targets are pluggable. Loki for day-to-day operations, Rsyslog with mTLS for tamper-evident audit, or any combination. Every collected log line is forwarded to all enabled targets, so dual-routing for compliance is a configuration choice, not an architecture rebuild.
- Formats are first-class. Lightbits ships defaults for every well-known service — ZAP_JSON for the Go control plane, DUROSLIGHT_TEXT and GFTL_TEXT for the data-plane daemons, LOGFMT for slog-style services, and UNSTRUCTURED for everything else. Levels and labels get normalized on the way out so Loki selectors work consistently across all sources.
A 30-second walkthrough
To wire a Lightbits cluster into Loki, an operator runs three commands. The same flow works against the REST API directly when you’d rather curl it from a CI job.
1. Point a source at a service
| lbcli -J $JWT create logs sources \ –name=node-manager \ –journald-id=node-manager \ –log-format=zap-json \ –min-level=info \ –enabled |
2. Define a target
| lbcli -J $JWT create logs targets \ –name=loki1 –type=loki \ –url=http://loki.example.com:3100/loki/api/v1/push \ –enabled |
3. Verify the collector is healthy
| lbcli -J $JWT list logs collectors | |||
| NAME c00-s00 | LAST SEEN 2026-02-24T15:46:29Z | ALLOY STATUS ALLOY_ONLINE | PIPELINE OK |
That’s the entire onboarding flow — one source, one target, one health check. Adding the data-plane daemons, layering an mTLS Rsyslog target, or routing event-log files alongside journald all follow the same pattern.
Designed for production observability
- Open by default. Alloy, Loki, and Rsyslog are widely deployed open-source projects. No proprietary collectors, no closed protocols, no vendor-only dashboards.
- Secure by construction. All configuration is over secured connection with cluster-admin JWT. Rsyslog targets use mTLS bundles managed through the same API. Nothing on the customer side ever needs an inbound connection to the cluster.
- Live config, no restarts. Sources and targets can be enabled, disabled, or retuned without bouncing a single Lightbits service. Alloy picks up the change on its next poll.
- Same look and feel as the rest of Lightbits management. If your team already automates volume provisioning with the REST API or lbcli, log streaming slots in with no new tooling to learn.
The right observability story for modern storage
Software-defined NVMe/TCP storage is built for cloud-native operations — disaggregated, multi-tenant, automated end-to-end. The observability layer should match. With log streaming, Lightbits delivers exactly that: an open, secure, declaratively managed log pipeline that drops your storage telemetry into the same Grafana dashboards and SIEM workflows your team already lives in.
Whether you’re running Lightbits behind OpenStack, OpenShift Virtualization, Proxmox, or bare-metal Kubernetes, the same three-step pattern applies — sources, targets, verify. Storage you can see is storage you can trust.
Go deeper
The full configuration reference — every API field, every supported log format, the complete TLS bundle workflow, and pipeline debugging tips — is in the Lightbits product documentation under Log Streaming (Tech Preview) and in the lbcli companion guide.