Skip to content

General

Overview

What is 10x

Typically reduces log storage and analytics costs by a modeled ~50–80% (about 65% on the otel demo) by turning log events into typed, class-based objects, not raw text. A stream processor that classifies and optimizes the data your environment already produces.

A lightweight, portable data engine that runs where your data is, locally, at the edge, or in the cloud. Works with your existing infrastructure, log forwarders (Fluent Bit, Fluentd, OTel Collector), log analyzers (Splunk, Datadog, Elastic), and storage (S3, Azure Blobs). See Overview.

What does 10x do

Learns the structure of every log event your environment produces and, at runtime, classifies and optimizes them without regex or manual rules.

Apps, each tackling a different part of the cost problem:

  • MCP: agent-facing control plane. Drives the other apps from a chat session: query top patterns and cost drivers, sample events from the log analyzer, cap noisy types, pull historical events from S3 on-demand.
  • Reporter (DaemonSet alongside your forwarder): shows which log event types cost the most, pre-ingestion.
  • Receiver (sidecar) with two modes: Filter (lossy, cap noisy event types during spikes) or Compact (lossless in-place shrink, a modeled ~50–80% reduction, on Splunk, self-hosted Elasticsearch/OpenSearch, or ClickHouse, via an analyzer-side expand plugin; a no-op on managed destinations like Datadog or CloudWatch).
  • Retriever: offloads selected events to your own S3 bucket and fetches the exact offloaded events back to your analyzer on demand, no re-ingest.
Who is 10x for

SRE, DevOps, and FinOps teams facing:

Where does 10x run

Inside your own infrastructure, k8s, EC2, Lambda, or a local workstation. Log data never leaves your environment.

  • Reporter: DaemonSet alongside your forwarder for pre-ingestion cost visibility. Logs never pass through it.
  • Receiver: sidecar alongside your forwarder for Filter (cap noisy events) or Compact (lossless shrink) execution.
  • Retriever: k8s pods that index events offloaded to your own S3 bucket and fetch selected events back to log analyzers on demand.
  • MCP: agent-facing control plane; runs wherever you run an MCP server (workstation, CI, infrastructure).
  • Dev: CLI (Docker, macOS, Linux, Windows). Test on your own logs locally. Free, no account needed.
What makes 10x different

Predictable pricing : Commercial tools price per GB ingested, so costs spike with traffic. 10x is priced per infrastructure node running log collection. Volume spikes, new applications, and traffic surges have no impact on cost.

No parsing rules : Pipeline tools need regex or hand-written rules for every log format, and those rules break when code changes and take dedicated engineering to keep current. 10x recognizes your log structure on its own, so there are no per-format rules to write, nothing to update when developers ship new code, and no regex to maintain.

Optimize everywhere : The hybrid AOT/JIT engine powers automatic log data optimization at every stage of the pipeline. Test locally, report on costs and regulate billing spikes at the edge, losslessly compact before shipping, ingest from S3 on-demand.

BYO stack : Works with your existing log forwarders, analyzers, time-series databases, object storage, and compute (K8s, Lambda, EC2). No migration required.

Zero egress : The engine runs as a lightweight runtime inside your infrastructure. Log data never leaves your environment. No vendor access to your logs required.

Powering agents : Every event exits the 10x Engine as a typed object with direct field access, not raw text to parse. Aggregation condenses millions of events into compact summaries, so AI agents operate on structured data instead of burning tokens on raw log lines, without exposing customer data to external models.

What tools does 10x work with

The 10x Engine fits your existing infrastructure. A modular extension framework supports integration across your stack:

  • Log forwarders: Fluent Bit, Fluentd, Filebeat, Logstash, OTel Collector, Vector (six native), plus Splunk UF and Datadog Agent via a Fluent Bit file-system handoff
  • Log analyzers: Splunk, Datadog, Elastic, CloudWatch
  • Time-series: Prometheus, Datadog, Grafana, SignalFx
  • Object storage: S3, Azure Blobs, GCS
  • Compute: K8s, Lambda, EC2, Docker

See Inputs, Outputs, and Compute.

Where should I start

Two paths: a free local CLI run on your own logs, or a 20-minute DaemonSet deploy for live log analyzer cost visibility.

  1. Dev (free, no account): run on your own log files locally. See your reduction ratio in minutes.
  2. Reporter: deploy as a DaemonSet alongside your forwarder for pre-ingestion cost visibility. Deploy in 20 minutes.

The Reporter publishes metrics to your time-series backend, where cost dashboards show spend per application, volume by severity, and the top patterns by cost. Act on the findings with the Receiver (Filter or Compact mode) or Retriever.

For agentless analyzer-side analysis without deploying a DaemonSet, the MCP server's SIEM-sample tool offers on-demand log analyzer polling.

Comparisons

Does 10x work with Lambda and serverless

Yes. The DaemonSet Reporter and the Receiver sidecar both assume a long-lived host with a forwarder, so they don't apply directly to ephemeral Lambda functions. For serverless workloads:

  • MCP server: the SIEM-sample tool analyzes Lambda log costs via your log analyzer's API (Datadog, CloudWatch, Splunk). Read-only, agentless, on-demand, no Lambda modification needed.
  • Retriever: offloads Lambda log events to your own S3 bucket and fetches selected events back to your analyzer on demand.

Pricing for serverless is based on the Retriever pods in your cluster, not on the number of Lambda functions.

How does 10x differ from log forwarders (Fluentd, OTel, Fluent Bit)

Complementary. The 10x Reporter deploys as a DaemonSet alongside your forwarder (pattern similar to datadog-agent or otel-collector); the Receiver runs as a sidecar between the forwarder and the analyzer to filter or compact events before they ship.

Log forwarders collect, route, and do basic parsing. 10x adds cost awareness (which event types cost the most), regulation (cap noisy types during spikes), and lossless volume reduction (a modeled 50%+ where the destination supports it: Splunk, self-hosted Elasticsearch or OpenSearch, ClickHouse). No forwarder replacement needed.

How does 10x differ from Cribl

Cribl is a data pipeline you configure separately for each log source. It cuts volume by dropping log lines or replacing groups of them with rolled-up summaries.

Keeping every line. Cribl only lowers the bill by dropping lines or rolling them into summaries, and both throw the original away. Keep every line intact and Cribl saves nothing, so you trade completeness against cost. 10x lowers the bill while keeping every line, and drops or samples only when you choose. For each pattern (one kind of log line, regardless of timestamps and IDs) it picks the cheapest way to keep the line, based on your log analyzer:

  • Compact (shrink the line in place): on Splunk, self-hosted Elasticsearch/OpenSearch, and ClickHouse, 10x shrinks each line to a fraction of its size, and your analyzer still stores it, searches it, and shows the full original.
  • Tier down (move it to a cheaper storage class): when your analyzer sells a lower-cost class you can still search, like Datadog Flex or CloudWatch Infrequent Access, 10x moves the line into it.
  • Offload (park it in storage you own): with any analyzer, 10x sends the line to an S3 bucket in your own account, and fetches the exact original back on demand with no restore step and nothing re-loaded into your log analyzer.

Getting data back. Cribl's only retrieval path is Replay, which reprocesses archived data and loads it back into your log analyzer, where it counts again as billable volume.

Setup and upkeep. Cribl needs a reduction pipeline per source, revised whenever a log format changes. 10x needs no per-source pipeline: it decides what to do with each pattern on its own, and you set a budget and approve the plan it proposes.

Pricing. Cribl charges by the volume it processes, so a tool bought to lower the bill costs more as data grows. 10x is a flat fee per node, published, and does not rise with log volume.

How does 10x differ from Grepr

Grepr is a service you send your logs to. It cuts the feed reaching your log analyzer by sampling it and replacing groups of lines with summaries.

Where your logs go. Grepr reduces your logs inside its own cloud, so the content leaves your environment to be processed. 10x reduces logs inside your own infrastructure, so the content never leaves.

Keeping every line. Grepr samples the feed and replaces groups of lines with summaries, keeping the full lines only in its own data lake. 10x keeps every line, and drops or samples only when you choose. For each pattern it picks the cheapest way to keep the line, based on your log analyzer:

  • Compact (shrink the line in place): on Splunk, self-hosted Elasticsearch/OpenSearch, and ClickHouse, 10x shrinks each line to a fraction of its size, and your analyzer still stores, searches, and shows the full original.
  • Tier down (move it to a cheaper storage class): a class you can still search, like Datadog Flex or CloudWatch Infrequent Access.
  • Offload (park it in storage you own): with any analyzer, 10x sends the line to an S3 bucket in your own account, and fetches the exact original back on demand with no restore step and nothing re-loaded.

Getting data back. When you investigate an incident, Grepr copies the relevant full lines back into your log analyzer, which charges you to take in that volume a second time.

Proving the cut. With 10x you set a budget and approve the plan it proposes, and savings are then measured per pattern over time, so they can be checked rather than taken on faith. Grepr auto-tunes inside its own cloud and commits to no number, stating that results depend on how noisy your logs are.

Pricing. Grepr charges for compute plus the volume you send, and publishes no rate card. 10x is a flat fee per node, published, and does not rise with log volume.

How does 10x differ from Tero

Tero is software that sits between your apps and your log analyzers and screens the traffic. You write rules that tell it to drop lines, sample them, rate-limit them, or blank out sensitive fields before they reach those analyzers.

Keeping every line. Tero cuts log volume one way, by deleting lines before they reach your log analyzer, and what it deletes is gone. 10x cuts the same amount while keeping every line, and drops or samples only when you choose. For each pattern it picks the cheapest way to keep the line, based on your log analyzer:

  • Compact (shrink the line in place): on Splunk, self-hosted Elasticsearch/OpenSearch, and ClickHouse, 10x shrinks each line to a fraction of its size, and your analyzer still stores, searches, and shows the full original.
  • Tier down (move it to a cheaper storage class): a class you can still search, like Datadog Flex or CloudWatch Infrequent Access.
  • Offload (park it in storage you own): with any analyzer, 10x sends the line to an S3 bucket in your own account, and fetches the exact original back on demand with no restore step and nothing re-loaded.

No way back with Tero. Tero keeps no copy, so nothing it deletes can be recovered.

Setup and upkeep. Tero needs reduction rules per source, revised whenever a log format changes. 10x needs no per-source rules: it decides what to do with each pattern on its own, and you set a budget and approve the plan it proposes.

Pricing. Tero publishes no price; you book an assessment and a sales engineer gives you a number. 10x's price is published and charged per node, based on how many nodes you have, not how much log data you send.

How does 10x differ from log analytics tools (Splunk, Datadog, Elastic)

10x partners with your existing platform to cut the bill, you keep Splunk, Datadog, or Elastic; 10x handles cost reduction through sampling, lossless volume reduction, and S3 offload. Your analyzer configuration, dashboards, queries, and alerts all continue working unchanged.

  • Reporter: identifies which event types incur the highest costs (pre-ingestion, DaemonSet)
  • Receiver, Filter mode: caps noisy event types before they ship
  • Receiver, Compact mode: losslessly compacts events by a modeled ~50–80% before ingestion on supported destinations (Splunk, self-hosted Elasticsearch/OpenSearch, ClickHouse)
  • Retriever: offloads selected events to your own S3 bucket and fetches the exact events back to your analyzer on demand

The open-source 10x for Splunk app auto-expands compact logs at search time. For other analyzers, Retriever expands and streams events on-demand.

How does 10x differ from APMs and OpenTelemetry

Different goals. APMs (Dynatrace, AppDynamics) and OTel add instrumentation to your applications, more logging, more profiling, more tracing data. 10x processes the data your environment already produces to reduce its cost.

10x is agentless, no SDKs, no bytecode injection, no runtime overhead. Your application code runs exactly as written. 10x processes the output downstream via the DaemonSet Reporter or sidecar Receiver alongside your log forwarder.

The two are complementary: use APMs and OTel for application insights, then use 10x to reduce the cost of storing and analyzing that telemetry.

How do I extend 10x with custom integrations

Build custom input/output integrations using the 10x API framework:

Integration Type API Description
Log forwarders InputStream or Log4j2 Read from or write to custom log forwarding tools
Log analyzers Apache Camel Read from 400+ analytics sources via YAML routes
Object storage Object Storage Index and query from GCP Storage, MinIO, etc.
Receiver modules JavaScript Define custom regulation rules and filters
Launcher types Launcher Deploy in k8s, Quarkus, or CLI