Optimize Logs
Cut Costs by 50%+

The engine identifies repeating structure in your logs — JSON keys, timestamp formats, constant strings — and stores each unique pattern once as a cached template. Only the variable values (IPs, pod names, trace IDs) are shipped per event. Similar to how Protocol Buffers define a schema once and send only field values over the wire.

The AOT Compiler builds symbol vocabulary from your repos in CI/CD; the JIT engine uses those symbols to create and assign templates at runtime. 150+ frameworks are covered by the built-in library.

Result: 50-80% volume reduction with 100% data fidelity. Every field, value, and timestamp remains intact. Real-world benchmark: 64% reduction on Kubernetes OTel logs (1,835 → 662 bytes per event).

Compact vs. compress:

• Compressed data must be decompressed before it can be searched or aggregated. Compact events remain searchable in place — they can be streamed to log analyzers and aggregated to metrics without a decompression step.
• Many SIEMs bill on uncompressed ingest volume — gzip and zstd reduce storage but not the ingestion bill. Edge Optimizer reduces volume before ingestion, cutting both costs.
• The two approaches are complementary: optimize first, then let your SIEM compress on top.

Why not sampling or filtering? Those are lossy — they permanently discard data, eliminating evidence for troubleshooting and security investigations. Edge Optimizer uses only lossless techniques.

How expanding works depends on your analyzer:

• Splunk: The open-source 10x Splunk app (GitHub) transparently expands at search time. A JavaScript hook intercepts search requests and expands compacted events via KV Store template lookup — your searches, dashboards, and alerts work unchanged
• Datadog & CloudWatch: Events are expanded via Storage Streamer from S3 before ingestion — no expansion step needed on the analyzer side. Your dashboards, monitors, and alerts work as-is
• Elasticsearch / OpenSearch: The open-source L1ES plugin (GitHub) transparently rewrites standard queries and decodes results at search time — Kibana dashboards, KQL queries, and alerts work unchanged. For managed services (Elastic Cloud, AWS OpenSearch Service), Storage Streamer expands events from S3 before ingestion

~1.25x query time for both Splunk and Elasticsearch. Datadog and CloudWatch have zero overhead — events are expanded before ingestion.

• Splunk: The 10x for Splunk app expands using native SPL and KV Store template lookups. Per-event expansion is O(1). A 10-second search takes ~12.5 seconds. Compatible with interactive search, scheduled search, alerts, dashboards, REST API, and summary indexing
• Elasticsearch / OpenSearch: The L1ES plugin expands at the Lucene segment level — each shard handles expansion locally. A 100ms query takes ~125ms. Scales horizontally with cluster size
• Datadog, CloudWatch & managed Elasticsearch: Storage Streamer expands events before ingestion — zero query overhead

ROI formula: (daily volume in GB) × (reduction ratio) × (your per-GB cost) × 365 = annual savings

Use the free Dev tool to measure your exact reduction ratio on your own logs, or try the ROI Calculator with your analyzer's per-GB cost. See Datadog, Splunk, Elasticsearch, or CloudWatch pages for vendor-specific savings estimates.

Edge Regulator filters and samples events based on cost and priority policies — events are dropped before they ship. This is lossy but sends directly to your analyzer with no additional infrastructure.

Edge Optimizer compacts events losslessly — no data is discarded. For Splunk, the 10x app expands at search time. For self-hosted Elasticsearch and OpenSearch, the L1ES plugin does the same. For Datadog, CloudWatch, and managed Elasticsearch, events route through S3 and Storage Streamer expands them before ingestion.

Many teams deploy both: Regulator for known low-value events, Optimizer for everything else.

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 Optimizer deploys in your infrastructure — no data leaves your network. Add a tenx blockEdge Optimizer — Helm values:tenx: enabled: true apiKey: "YOUR-LICENSE-KEY" kind: "optimize" runtimeName: my-edge-optimizerFluent 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.