Filter Noise
Block Overspend

Edge Regulator applies cost-based sampling to your log pipeline, classifying each event by its event typeEach log event is automatically classified by its stable message structure — variable data stripped, pattern preserved:

Raw log event:
[2025-08-01 22:19:30,905] INFO [controller-1-to-controller-registration-channel-manager]: Recorded new controller, from now on will use node 0.0.0.0:9093 (id: 1 rack: null) (kafka.server.NodeToControllerRequestThread)

Extracted event type:
channel_manager_Recorded_new_controller_from_now_on_will_use_node_id_rack

Timestamps, IPs, and runtime values are stripped. The remaining structure becomes a cost-tracking key — no regex, no manual rules.

How message extraction works → and calculating actual ingestion cost per event (bytes × $/GB).

When an event type exceeds its share of the budget, Edge Regulator samples it down — in real-time at the edge, before expensive data reaches your analyzer. A severity boost ensures ERROR and WARN events are more likely to be retained than DEBUG noise.

Works in local (per-node) or global (cluster-wide via GitOps lookup) mode.

The rate regulator applies cost-based sampling. Each event is either retained or dropped based on how much its event type has spent relative to the budget:

• Under budget — all events flow through normally
• Event type over its max share — that type gets sampled down proportionally (e.g., an event type consuming 60% of the budget with a 20% cap gets sampled to ~33%)
• Severity boost — ERROR events receive a 2x retention boost, making them far more likely to survive sampling than DEBUG noise

The result: noisy event types are automatically throttled while critical events are preserved. Edge Regulator exports metrics tracking exactly what was regulated, so you can tune policies over time.

Two mechanisms protect critical events:

• Severity boost — ERROR and WARN events receive a higher retention multiplier during sampling. Even when their event type is over budget, critical-severity events are far more likely to be retained than DEBUG noise
• Max share targeting — regulation only kicks in when a specific event type exceeds its configured share. Low-volume event types — which security and authentication logs typically are — pass through unaffected

The regulator targets noisy, high-volume event types that dominate your budget — not broad categories.

You configure via YAML (learn more):

• Budget per hour — target ingestion cost rate (e.g., $1.50/hour)
• Max share per event type — prevents any single event type from dominating the budget (e.g., 20%)
• Severity boost — ERROR events get higher retention probability than DEBUG noise

Plain English: "Cap total ingestion at $500/hour, prevent any single event type from consuming more than 20% of the budget, and give ERROR events 5x priority over INFO events."

No. Edge Regulator supports priority tiers: mark security events, authentication logs, and compliance-critical sources as “always forward” regardless of budget limits. Regulation applies only to the noisy categories you explicitly target.

Two safeguards: local threshold regulators use symbol identities to cap specific event type volumes (e.g., 10MB/10sec for DEBUG from service-x), and global policies are GitOps-managed — every rule is version-controlled and reviewable before deployment.

512 MB heap + 2 threads handles 100+ GB/day per node. Both values map directly to Kubernetes resource specs in your DaemonSet manifest.

Full resource details →

Edge Regulator deploys in your infrastructure — no data leaves your network. Add a tenx blockEdge Regulator — Helm values:tenx: enabled: true apiKey: "YOUR-LICENSE-KEY" kind: "regulate" runtimeName: my-edge-regulatorFluent Bit · Fluentd · Filebeat · OTel Collector · Logstash · Splunk UF · Datadog AgentFull deploy guide → to your existing forwarder Helm values and run helm upgrade. For VMs, the CLI and Docker options take under 5 minutes.