A Grafana Loki alternative for security log management | NXLog

Loki calls itself a log aggregation system inspired by Prometheus, built for application and Kubernetes observability — an accurate description of a good tool. NXLog Platform starts from a different question: can you collect, keep, and search the evidence a security investigation will need? Different question, different design.

Two Grafana log shippers reached end of life four months apart: Grafana Agent in November 2025, Promtail in March 2026. Both migration paths end in a Grafana Alloy rewrite. NXLog Agent keeps one configuration language across every backend it ships to — so when you rebuild your collection layer, you only do it once.

Loki's label guidance is blunt: keep user IDs, IP addresses, and request IDs out of labels, because every unique value spawns a new stream. Those are precisely the fields an investigator pivots on. NXLog Platform includes storage and search with no label schema to design — an IP address is just a field you search for.

Enroll agents, push configuration, watch health, and roll out updates from the NXLog Platform console — included with every plan, running wherever the platform runs. In the Grafana stack, the Fleet Management console belongs to Grafana Cloud; self-managed Alloy fleets typically live in configuration files and GitOps pipelines.

Grafana's own FAQ is upfront: when you self-host, availability, scaling, and maintenance of every component sit with your team — collector, storage, compactor, dashboards. NXLog Platform ships collection, agent management, storage, and search as one supported product, so your engineers spend their week on security work, not stack care.

NXLog Agent drops, rewrites, and reformats events on the host, so only data worth keeping ships anywhere. The Port of Auckland credited NXLog's “filtration abilities that allowed us to ingest only valuable events” with direct savings on volume-priced ingestion (Lajos Varga, Head of Digital Technology). Filtered at the source, a log costs less everywhere downstream — on a Grafana Cloud meter or on your own disks.

Run NXLog Platform in your data center, in your own cloud account, or let us host it for you. Loki self-hosts too — the difference is what you're running. NXLog Platform arrives as one packaged product with support behind it; a self-managed Loki stack is a set of components you compose, size, and keep healthy. Air-gapped networks work in both worlds. With NXLog Platform, so does opening a support ticket.

A source is any distinct system, device, or application NXLog Agent collects from — a server, a firewall, a container cluster. Licensing counts sources and nothing else: no per-gigabyte fees, no events-per-second caps, no volume limits. The Free plan covers up to 10 sources with the full feature set, and volume discounts apply as the fleet grows.

Windows Event Log through the modern API. Event Tracing for Windows for the channels Event Log can't see. Agentless collection from Windows Event Forwarding. Registry monitoring, file integrity monitoring, performance counters, and Microsoft DNS Server log parsing. Legacy modules still cover Windows XP, 2000, and 2003 for the estates where they linger.

NXLog Platform enrolls new agents, distributes configuration from the center, watches agent health, and applies updates remotely. Solution packs ship working pipelines for common routes — Windows to Microsoft Sentinel, syslog to an OpenTelemetry backend, Okta to Google SecOps — so day one starts from a template, not a blank editor.

Filter, rewrite, and convert events on the host — between syslog, JSON, XML, CSV, CEF, LEEF, and GELF — before anything crosses the network. Disk buffering rides out outages, TLS and compression protect the wire, and repeated messages can be de-duplicated. A leaner stream costs less to move, store, and search, whatever sits downstream.

You don't have to pick a side on day one. Loki 3.0 and later ingest OpenTelemetry logs natively, and NXLog Agent exports OTLP over HTTP(S) and gRPC — our blog also walks through shipping UFW logs to Loki with the HTTP output. Put NXLog Agent in front: collect the sources Alloy components don't reach, trim volume at the host, and keep feeding the Loki cluster you already run. Changing or adding a backend later is an output block, not a project.