Skip to content

LUnA · logrok universal agent

The universal agent that turns endpoint logs into detection

A single static binary for Windows, Linux, and macOS that ships logs to any destination — over syslog, OTLP, or Splunk HEC — and the front door to logrok's AI-driven log intelligence.

Windows Linux macOS

How it fits

From the edge, through a relay, into detection

It ends in detection, not a database

Most collectors stop at moving logs into storage and a search box. logrok adds the layer above: AI-driven analysis, 1,100+ built-in detection rules, including imported Sigma rules, threat intelligence, and compliance report packs. LUnA is how your endpoints reach it.

See the platform

A collector with a future

Agent lines get retired and repackaged: Microsoft's Log Analytics agent was retired in August 2024, and NXLog Enterprise Edition and Manager are no longer sold. LUnA collects Windows Event Log, files, journald and syslog, and the luna-migrate tool converts the configuration of the agent you run now (Splunk Universal Forwarder, Beats, Fluent Bit, Fluentd, rsyslog, syslog-ng, Vector, NXLog and others), reporting anything it could not carry over.

Talk through a migration

Sees the plant floor.

Industrial equipment is the part of the estate a SIEM cannot read — and streaming raw registers into one buries you in millions of rows nobody queries. LUnA polls Modbus equipment — over TCP or straight onto an RS-485 serial line — and receives SNMP traps, then forwards only what a security team can act on: a value changed, a limit crossed, a device stopped answering. The Modbus write function codes are not implemented at all, so the agent is structurally incapable of commanding a controller.

Talk through an OT rollout

Offline. No phone-home.

Sovereign networks can't tolerate an agent that calls a vendor portal to validate its licence. LUnA carries a signed, offline entitlement — no telemetry, no periodic check-in. Air-gap is a normal mode of operation, not a workaround.

How we prove it

Works with what you already run

Takes over the fleet you have

Your current agents can ship through LUnA while you move host by host. It receives from Filebeat, Winlogbeat and the other Beats, from Fluent Bit and Fluentd, from anything that sends to Splunk HEC, from OpenTelemetry SDKs and Collectors, from GELF senders, and from devices that send syslog over TLS. Windows hosts can send with their built-in Windows Event Forwarding, with no agent installed on them.

Converts instead of rewriting

luna-migrate turns another forwarder's configuration into a LUnA one in one command: Splunk Universal Forwarder, Filebeat and Winlogbeat, Elastic Agent, Fluent Bit, Fluentd, Logstash, rsyslog, syslog-ng, Vector, Promtail, the OpenTelemetry Collector, the Datadog Agent, Wazuh, Graylog Sidecar, the Azure Monitor Agent and NXLog. It reports what it could not carry over, never copies credentials, and checks the result with the installed agent.

Delivers where your team already works

13 destinations, listed in full below. Splunk delivery spreads across several indexers or fails over between them, moves on to the next indexer at once when one fails, and sends each event to its own index and sourcetype from a single output.

Windows events that say who

Windows Event Log events carry the account each event is about, resolved on the host to name, domain and type, along with the task, opcode and keywords such as Audit Success, so detections can key on the person, not a raw SID.

logrok Detection Packs: the Windows detection pack, activated per agent group

Everything you'd expect from a serious collector

Collects from (20)

filetail, http_in, journald, syslog_in, beats_in, bsm_audit, etw, fluent_in, gelf_in, hec_in, linux_audit, modbus_in, mqtt_in, openwec_in, oslog, otlp_in, relay_in, snmptrap_in, windows_eventlog, wmi

Ships to (13)

syslog, beats, elasticsearch, fluent, hec, kafka, loki, otlp, relay, s3, sentinel, snare, xsiam

Shapes & reduces (18)

add_fields, expr, filter, parse_csv, parse_json, parse_kv, parse_xml, adaptive_sample, aggregate, dedup, file_hash, lookup, noise_fingerprint, quota, redact, sample, throttle, trim_fields

Holds the line

Events held on disk until they are delivered, encrypted at rest if you choose; inputs resume where they stopped after a restart; acknowledged delivery; limits on its own CPU and memory use, with a free-space floor on the spool disk; every lost event counted by reason; a single static binary, nothing to install alongside it; about 20 MB of memory at 1,000 events per second in our test

Managed from logrok

Configurations signed with your own key, so a compromised control plane cannot push one you did not sign; one-time enrollment tokens; per-agent mTLS certificates with root-CA rotation; configuration by group, with your addresses filled in by placeholders; remote upgrades from the Agents page; signed entitlement delivery; license state and tamper alerts per agent

Everything it collects, shapes and forwards

20 sources, 18 processors and 13 destinations in v2.0.0. Everything below ships in the single binary — there are no plugins to install.

Collects from

20 4 free in Core

Sources the agent reads on the host, and listeners for devices that cannot run one.

  • filetail Core

    Tails plain-text log files (application logs, web server logs, Kubernetes container logs) and forwards each line as an event, surviving file rotation and agent restarts.

  • http_in Core

    Accepts log lines pushed over HTTP(S), for sources such as webhooks, IoT/edge devices and app log shippers that cannot run the agent or speak syslog.

  • journald Core

    Reads the Linux systemd journal and forwards each entry as an event, resuming exactly where it left off after a restart.

  • syslog_in Core

    Listens for incoming syslog (RFC 5424/3164 over TCP, UDP or a local socket) so the agent can act as a gateway for devices that cannot run an agent themselves.

  • beats_in Apex

    Receives events from Filebeat, Winlogbeat and the other Elastic Beats over the Beats (Logstash) protocol, so an existing Beats fleet can ship to the agent as its gateway without changing anything but the destination address.

  • bsm_audit Apex

    Collects the Solaris BSM audit trail — logins, privilege use and file changes — decoded with the operating system's own praudit, so each record arrives with the user, process and session that caused it.

  • etw Apex

    Streams Windows ETW (Event Tracing for Windows) kernel and application telemetry in real time, capturing high-volume activity such as process creation, network connections and DNS that never reaches the Windows Event Log.

  • fluent_in Apex

    Receives logs from Fluent Bit and Fluentd over their Forward protocol, so an existing Fluent Bit fleet (the usual Kubernetes log collector) can ship to the agent as its gateway, acknowledged only once the logs are safe.

  • gelf_in Apex

    Receives GELF (Graylog Extended Log Format) over UDP and TCP, so Docker's gelf logging driver and applications that log to Graylog can send to the agent instead.

  • hec_in Apex

    Receives events sent to a Splunk HTTP Event Collector endpoint, so anything that can send to Splunk HEC (logging drivers, Kubernetes connectors, products with a "send to Splunk" option) can send to the agent instead, answered only once the events are safe.

  • linux_audit Apex

    Collects Linux kernel audit records - process executions, file-access watches, logins, privilege changes - reassembled into one structured event per audit event.

  • modbus_in Apex

    Polls Modbus TCP/RTU industrial devices (PLCs, RTUs, meters) and emits events only on meaningful register changes, threshold crossings or device outages, never a raw telemetry stream. Read-only by construction.

  • mqtt_in Apex

    Subscribes to an MQTT broker and turns each published message into an event, the common ingest shape for IoT/edge sensors and devices.

  • openwec_in Apex

    Receives Windows events from an OpenWEC collector, so Windows hosts that forward their logs with the built-in Windows Event Forwarding — with no agent installed on them — arrive with the same fields as from the agent, and flags events whose claimed host is not the sender.

  • oslog Apex

    Reads the macOS unified log, backfilling the gap since the agent's last run and then following new entries live.

  • otlp_in Apex

    Receives OpenTelemetry logs over OTLP (gRPC and HTTP) from applications instrumented with an OpenTelemetry SDK and from OpenTelemetry Collectors, answering each request only once the logs are safe.

  • relay_in Apex

    Receives events over the agent's own acknowledged relay transport, so a gateway agent can concentrate traffic from edge agents with guaranteed delivery instead of best-effort TCP.

  • snmptrap_in Apex

    Listens for SNMP traps and informs (v1/v2c/v3) from network and OT devices - switches, firewalls, UPSes, PLC gateways - and turns each notification into an event.

  • windows_eventlog Apex

    Collects the Windows Event Log, the OS's structured record of system, security and application activity including Sysmon, with live subscription and resumable checkpoints.

  • wmi Apex

    Polls Windows Management Instrumentation (WMI) via WQL queries for system-inventory and live-state data: running services, installed hotfixes, disk usage, hardware.

Shapes and reduces

18 7 free in Core

Parsing, field shaping and volume reduction, applied at the edge before anything leaves the host.

  • add_fields Core

    Stamps static key/value fields such as tenant, site or environment onto every event so it stays attributable downstream.

  • expr Core

    Applies simple conditional rules to set, remove or rename fields, or drop events, based on their content.

  • filter Core

    Drops events by severity ceiling or field value, the simplest way to cut noise at the edge.

  • parse_csv Core

    Parses delimited (CSV/TSV/W3C) message text into structured, queryable fields.

  • parse_json Core

    Explodes a JSON log line into structured fields.

  • parse_kv Core

    Splits key=value formatted log text into structured fields.

  • parse_xml Core

    Flattens an XML log payload into structured, dotted-path fields.

  • adaptive_sample Apex

    Automatically adjusts the sampling rate to hold event volume near a target as traffic rises and falls, keeping both the start and the tail of a burst visible.

  • aggregate Apex

    Replaces each group's events in each time window with one summary event carrying the count and optional sums.

  • dedup Apex

    Drops duplicate events sharing the same key within a time window, keeping only the first occurrence.

  • file_hash Apex

    Attaches the digest of a changed file to the event that reported the change, so the platform can compare content while the event still carries the user who made the change.

  • lookup Apex

    Enriches events by joining a field's value against a local table such as an asset inventory or CMDB export, e.g. turning a hostname into its owning team and environment.

  • noise_fingerprint Apex

    Drops or marks events whose message matches a noise template decided centrally — the same fingerprint the platform computes at ingest, one hash lookup per event, so noise removed on the host never crosses the wire.

  • quota Apex

    Enforces a hard daily volume cap, in events and/or bytes, on a pipeline, dropping events once the budget is spent.

  • redact Apex

    Removes or masks sensitive values such as emails, credit card numbers or custom patterns from events before they leave the endpoint.

  • sample Apex

    Keeps a configurable 1-in-N fraction of events, either sequentially or consistently by key, to thin high-volume sources.

  • throttle Apex

    Caps the rate of events passed per key, or globally, within a time window, dropping the excess.

  • trim_fields Apex

    Shrinks event size by dropping unwanted fields and truncating oversized values.

Forwards to

13 1 free in Core

Standard syslog to any aggregator, or straight into a named platform's own ingest API.

  • syslog Core

    Forwards every event as standard RFC 5424 syslog over TCP (with TLS/mTLS) or UDP, the vendor-neutral default output any aggregator or SIEM accepts.

  • beats Apex

    Sends events to Logstash or Graylog over the Beats protocol, so the agent can stand in for a Beat in front of an existing Logstash pipeline, with delivery confirmed by the receiver.

  • elasticsearch Apex

    Indexes events into Elasticsearch or OpenSearch as Elastic Common Schema documents in a data stream or index, retrying only what the cluster did not accept.

  • fluent Apex

    Sends events to Fluentd or Fluent Bit over their Forward protocol, so the agent can feed an existing Fluentd aggregation tier, with every request confirmed by the receiver.

  • hec Apex

    Forwards events to Splunk's HTTP Event Collector, with an optional indexer-acknowledgment mode for confirmed-indexed delivery.

  • kafka Apex

    Produces events to an Apache Kafka (or Kafka-compatible) topic with per-record delivery acknowledgment and at-least-once retry.

  • loki Apex

    Pushes events to Grafana Loki's ingest API as labeled log streams.

  • otlp Apex

    Forwards events as OpenTelemetry Protocol (OTLP) logs, over gRPC or HTTP, to any OTel-native collector or backend.

  • relay Apex

    Sends events to another agent over an acknowledged reliable transport, for hops such as an unreliable WAN or an edge-to-hub link where plain TCP syslog isn't safe enough.

  • s3 Apex

    Archives events to an S3 (or S3-compatible) bucket for archive and data-lake pipelines, including a native AWS Security Lake OCSF/Parquet feed.

  • sentinel Apex

    Sends events to Microsoft Sentinel / Azure Monitor Logs via the Logs Ingestion API.

  • snare Apex

    Emits events in the legacy Snare format for SIEMs already built to parse an NXLog/Snare feed.

  • xsiam Apex

    Sends events to a Palo Alto Cortex XSIAM tenant via its HTTP log collector.

Missing a source, a destination or a feature you need? Tell us what you need, and we'll look at building it.

Where it runs, and how we know

15 platform builds ship with every release. We say plainly how far each one is tested, so you can tell a proven target from a compiled one before you deploy it.

Tested on every change

1

race, end-to-end and performance testing on every change

  • linux/amd64

Verified on real systems

11

the actual operating system on the actual CPU architecture, before every release

  • windows/amd64 full test suite
  • darwin/amd64 full test suite
  • solaris/amd64 full test suite, Solaris 11.4
  • freebsd/amd64 full test suite, FreeBSD 15.1
  • openbsd/amd64 full test suite, OpenBSD 7.9
  • netbsd/amd64 full test suite, NetBSD 11.0
  • darwin/arm64 binary and .pkg, Apple Silicon
  • linux/arm64 binary and .deb, Raspberry Pi, Debian 12
  • linux/arm binary and .deb, Raspberry Pi
  • windows/arm64 binary and .msi
  • aix/ppc64 published binary, AIX 7.3, IBM Power

Verified under emulation

3

the full pipeline, run on the emulated instruction set

  • linux/riscv64
  • linux/mipsle softfloat
  • freebsd/arm64 real FreeBSD kernel

For OT gateways, appliances and single-board computers there is LUnA Crescent, a smaller build with the core inputs, the syslog output and store-and-forward on disk, published with every release.

Running an operating system or CPU architecture that isn't listed? Tell us what you need, and we'll look at adding a build for it.

Two ways to run it

Luna Core

Free

Non-commercial use, free alongside logrok, and for commercial fleets of up to 10 agents.

  • Syslog forwarding over TCP/TLS, unmanaged
  • filetail, http_in, journald, syslog_in inputs
  • 7 parsing & field-shaping processors
  • Prometheus self-metrics

Standalone pricing is per agent, volume-banded — request a quote for your fleet. A full-feature trial is available on your real fleet.

See LUnA on your own fleet