---
icon: material/help-circle-outline
title: "FAQ"
---

The [Receiver](https://doc.log10x.com/apps/receiver/) is the execution arm of the 10x pipeline. The rate regulator finds which patterns are over the byte cap set for their service, and an action decides what happens to that excess. The keep-everything actions (compact, offload, tier_down) cut cost without losing data; sample and drop are lossy actions you opt into; pass leaves the pattern untouched. An AI agent picks the action per service through the log10x MCP (the `configure_engine` tool); the engine enforces it, and the decision travels as a config change through the GitOps repo. The Receiver runs as a sidecar alongside your forwarder.

<div class="grid cards" markdown>

- [:material-information-outline: **Overview**](#overview)
- [:material-cog-outline: **Configuration**](#configuration)
- [:material-compare-horizontal: **Actions & Related Apps**](#modes-related-apps)
- [:material-connection: **Integration**](#integration-deployment)

</div>

### :material-information-outline: Overview

??? tenx-overview "What is the Receiver and how does it control costs"

    The Receiver decides an action per service, applied to the events a pattern spends above its cap:

    - **pass**: forward unchanged.
    - **sample**: forward a rate-limited share against a per-pattern budget. Uses automatic [message enrichment](https://doc.log10x.com/run/initialize/message/){target="_blank"} to identify event types by their symbol identity and calculate ingestion cost per event (bytes × $/GB). When an event type exceeds its share of the budget, the Receiver samples it down, in real time at the source, before expensive data reaches your analyzer. A [severity floor](https://doc.log10x.com/run/receive/rate/){target="_blank"} keeps a minimum share of ERROR and WARN events flowing even when their pattern is over its cap.
    - **compact**: replace repeated lines with an encoded form the destination expands at query time, with no dashboard changes. Lossless only on Splunk and self-hosted Elasticsearch/OpenSearch with the expand plugin installed ([Splunk](compact/splunk.md), [Elasticsearch](compact/elasticsearch.md)). It is a no-op on managed/SaaS destinations (Datadog, CloudWatch, Azure, GCP, Sumo, managed Elasticsearch).
    - **tier_down**: tag the pattern for a cheaper storage tier the destination enforces (Datadog Flex, CloudWatch IA, Azure Monitor Basic/Auxiliary).
    - **offload**: route the pattern to customer-owned object storage (S3 or any S3-compatible bucket) instead of the destination.
    - **drop**: stop forwarding the pattern.

    An AI agent picks the action per service through the log10x MCP (the `configure_engine` tool), which turns a target percent or budget into a per-pattern action set carried as a cap/action CSV. The CSV lands in the config repo through a GitOps PR and hot-reloads on the next pull. The sample action runs in [per-node budget mode](https://doc.log10x.com/run/receive/rate/){target="_blank"} or [mute file mode](https://doc.log10x.com/run/receive/rate/#mute-file-mode-declarative-field-set-caps){target="_blank"}, a declarative field-set keyed cap file committed to git and pulled via GitOps.

    Log10x is normally driven by an AI agent (Claude, or a model the customer brings) through the log10x MCP server, which installs, configures, and queries via MCP tools. The manual steps in these docs are the same operations without an agent.

??? tenx-overview "How do budget policies work"

    Configuration is a YAML file, written by hand or generated by the MCP `configure_engine` tool and delivered through GitOps. The [rate receiver](https://doc.log10x.com/run/receive/rate/){target="_blank"} tracks per-event-type spend using automatic [symbol identity](https://doc.log10x.com/run/initialize/message/){target="_blank"} enrichment. You configure:

    - **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 floors**, ERROR events keep a higher minimum share than DEBUG noise

    Example policy: cap total ingestion at $500/hour, cap any single event type at 20% of the budget, prioritize ERROR over INFO.

    When an event type exceeds its max share, the Receiver samples it down proportionally. For [multi-app environments](https://doc.log10x.com/run/receive/rate/#multi-app-regulation){target="_blank"} (Kubernetes), cap per-app budgets using the [container name](https://doc.log10x.com/run/initialize/k8s/){target="_blank"} field, scaling replicas doesn't bypass limits.

??? tenx-overview "What happens to logs when budget limits are reached (sample action)"

    The [rate receiver](https://doc.log10x.com/run/receive/rate/){target="_blank"} 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 floors**, ERROR events keep a higher minimum share of the over-cap slice than DEBUG noise

    The result: noisy event types are automatically throttled while critical events are preserved. The Receiver exports [metrics](https://doc.log10x.com/run/output/metric/){target="_blank"} tracking what each pattern's action did, so policies can be tuned over time. Routed-away events carry the label `routeState` (for example `routeState="drop"`).

### :material-cog-outline: Configuration

??? tenx-capabilities "Can I set different budgets for different event types"

    Yes. The [rate receiver](https://doc.log10x.com/run/receive/rate/){target="_blank"} tracks spend per event type using configurable field sets. You can scope budgets by:

    - **[Message pattern](https://doc.log10x.com/run/initialize/message/){target="_blank"}**, each distinct event type gets its own budget share
    - **[K8s container name](https://doc.log10x.com/run/initialize/k8s/){target="_blank"}**, cap total spend per application, regardless of pod replica count
    - **Both combined**, cap per event type per application for fine-grained control

    The [severity floor](https://doc.log10x.com/run/receive/rate/){target="_blank"} keeps a minimum share of higher-severity events (ERROR, WARN) flowing when sampling kicks in, without requiring separate budget tiers.

??? tenx-capabilities "How does the Receiver protect critical events"

    The [rate receiver](https://doc.log10x.com/run/receive/rate/){target="_blank"} uses two mechanisms that naturally protect critical events:

    - **Severity floors**, ERROR and WARN events keep a higher minimum share during sampling. Even when their pattern is over its cap, critical-severity events keep flowing at a higher rate than DEBUG noise
    - **Max share targeting**, sampling only kicks in when a specific [event type](https://doc.log10x.com/run/initialize/message/){target="_blank"} exceeds its configured share of the budget (e.g., 20%). Low-volume event types, which security and authentication logs typically are, stay well under their share and pass through unaffected

    The Receiver targets noisy, high-volume event types that dominate your budget, not broad categories. Security events that don't spike beyond their budget share flow through without sampling.

??? tenx-capabilities "How do I monitor budget consumption"

    The Receiver publishes [cost metrics](https://doc.log10x.com/run/output/metric/){target="_blank"} per [event type](https://doc.log10x.com/run/initialize/message/){target="_blank"}, volume, spend rate, and per-action counts. Three ways to consume them:

    - **Cost dashboards**, the metrics feed your time-series backend (Prometheus, Datadog, Elastic, and others), where budget consumption, processed volume, and cost trends per event type are charted in your own tooling
    - **[Prometheus Metrics API](https://doc.log10x.com/api/metrics/){target="_blank"}**, standard REST endpoints for querying all cost and action metrics programmatically via `/query`, `/query_range`, and `/series`
    - **[Native metric outputs](https://doc.log10x.com/run/output/metric/prometheus/){target="_blank"}**, export to Prometheus, Datadog, CloudWatch, or any compatible platform for custom dashboards and alerts

??? tenx-capabilities "How do I configure priority tiers to always forward critical events"

    Use `severityFloors` to set a minimum retention per severity level. The floor is an absolute fraction, not a multiplier, and it beats the cap: a pattern over its byte cap still keeps at least this share of each level, so high-severity events are never fully suppressed.

    **How it works:** the rate regulator engages only once a pattern has spent more bytes than the cap set for its container. From then on, each event of that pattern is kept with the probability its level's floor gives, and whatever the floor does not keep takes the container's action, which is `drop` unless an action file names another. A level with no entry uses `minRetentionThreshold` (default 0.1). The same floor applies to mute-file entries, so a `0` mute never silences ERROR or FATAL.

    Floor keys must match the level vocabulary the [Level Classifier](https://doc.log10x.com/run/initialize/level/){target="_blank"} emits.

    **Config example:**

    ```yaml
    # config.yaml for the Receiver
    rateReceiver:
      fieldNames:
        - symbolMessage
      containerField: container
      absoluteCap: 10485760        # 10 MB per pattern per container per window
      minRetentionThreshold: 0.1   # floor for any level not listed below
      severityFloors:
        - TRACE=0.05
        - DEBUG=0.05
        - INFO=0.1
        - WARN=0.3
        - ERROR=0.5                # half of an over-cap error pattern keeps flowing
        - CRITICAL=0.5
    ```

    No cap ships by default, so `absoluteCap` or a per-container cap file is what turns the regulator on. For Kubernetes, the same settings are set through the [Helm chart](https://doc.log10x.com/apps/receiver/deploy/){target="_blank"}.

    **Real-world scenarios:**

    1. **API Gateway (all errors must be captured):**
       - Cap: 10 MB per pattern per container per window
       - ERROR floor 0.5, DEBUG floor 0.05, so verbose request logs are thinned hardest and errors keep flowing

    2. **Background Job Queue (low signal, high volume):**
       - Cap: 2 MB per pattern per container per window
       - INFO floor 0.1 for job completion messages, CRITICAL floor 0.5 for job-queue-down events

    3. **Kubernetes cluster (health checks vs. pod crashes):**
       - Cap: 5 MB per pattern per container per window
       - DEBUG floor 0.05 for health check spam, ERROR floor 0.5 for pod failures and crashes

    **What the floor does not do:**

    - It does not rank levels against each other. Each level's floor is read on its own, so raising ERROR does not thin DEBUG.
    - It applies only to a pattern already over its cap. Under the cap every event is kept whatever its level.
    - It sets a minimum, not a maximum. The floor decides what share of the excess survives; the container's action decides what happens to the rest.

### :material-compare-horizontal: Actions & Related Apps { #modes-related-apps }

??? tenx-overview "When should I use the sample action vs the compact action"

    sample and compact are two of the actions, each applied to the events a pattern spends above its cap.

    | | sample | compact |
    |---|---|---|
    | **Loss** | Lossy, the over-budget share of a pattern is dropped | Lossless on supported destinations, each event replaced with a compact wire-form the expand plugin restores at query time |
    | **Downstream requirements** | None | Self-hosted [Splunk](compact/splunk.md) or [Elasticsearch](compact/elasticsearch.md)/OpenSearch with the expand plugin installed |
    | **Volume reduction** | Set by the per-pattern sample rate | Set by how repetitive the pattern is, where the destination supports it (Splunk, self-hosted Elasticsearch/OpenSearch); a no-op on managed/SaaS destinations |
    | **Risk profile** | Higher, dropped events are gone; safe defaults = deny | Lower, events survive full round-trip, queryable as normal |
    | **Typical trigger** | A single pattern is over-budget; cap it at a sample rate | Shipping volume is the bottleneck; shrink the wire format |

??? tenx-overview "What happens to events that the Receiver filters"

    Filtered events are not forwarded to your log analyzer. If you want a copy of events you can fetch back later, configure your forwarder to also route a copy of events to your own S3 bucket before the Receiver acts. Each forwarder has a native mechanism for duplicating the event stream, see [per-forwarder S3 configuration](https://doc.log10x.com/apps/receiver/#pair-with-retriever).

    Use [Retriever](https://doc.log10x.com/apps/retriever/) to fetch the exact offloaded events from your own S3 bucket on demand; it returns the stored events without rehydration or re-ingest, at your S3 storage cost.

??? tenx-overview "Can I use the Receiver with Retriever"

    Yes. Configure your forwarder to duplicate events, one copy goes to your own S3 bucket, the other goes through the Receiver (filtered or compact events to your analyzer). Hard-dropped events never reach S3. Retriever fetches selected offloaded events from your S3 bucket on demand.

    This pairs log analyzer cost control with on-demand fetch of the offloaded copies from your own S3 bucket. Events you route to S3 can be fetched back through Retriever on demand. Compact events stored in S3 are also queryable, Retriever expands them on the way out.

    See the [per-forwarder configuration](https://doc.log10x.com/apps/receiver/#pair-with-retriever) for Fluent Bit, Fluentd, OTel Collector, and Logstash recipes.

??? tenx-overview "Can I preview the impact before enabling actions"

    Yes. The [Reporter](https://doc.log10x.com/apps/reporter/) app runs the same enrichment pipeline as the Receiver, severity classification, symbol identity, cost metrics, but does not filter or compact events. Deploy the Reporter first to see which event types incur the highest costs and what the actions would target. When the metrics confirm the expected behavior, enable the Receiver.

### :material-connection: Integration & Deployment

??? tenx-integration "Which log forwarders does the Receiver support"

    The Receiver integrates with all major [log forwarders](https://doc.log10x.com/run/input/forwarder/){target="_blank"}. Six are native, the install wizard automates each:

    - [Fluent Bit](https://doc.log10x.com/run/input/forwarder/fluentbit/){target="_blank"}
    - [Fluentd](https://doc.log10x.com/run/input/forwarder/fluentd/){target="_blank"}
    - [Filebeat](https://doc.log10x.com/run/input/forwarder/filebeat/){target="_blank"}
    - [Logstash](https://doc.log10x.com/run/input/forwarder/logstash/){target="_blank"}
    - [OpenTelemetry Collector](https://doc.log10x.com/run/input/forwarder/otel-collector/){target="_blank"}
    - [Vector](https://doc.log10x.com/run/input/forwarder/vector/){target="_blank"}

    Splunk Universal Forwarder and Datadog Agent integrate through a Fluent Bit file-system handoff: Fluent Bit reads files from disk, the engine processes them, and the UF or agent tails the output folder.

    **Deployment:** runs as a [sidecar process](https://doc.log10x.com/engine/launcher/sidecar/){target="_blank"} alongside your forwarder so it can act on events before they ship to the analyzer. Kubernetes deployment via [Helm chart](https://doc.log10x.com/apps/receiver/deploy/){target="_blank"} (DaemonSet). Setup time: ~30 minutes.

    **Resource requirements:** 512 MB heap + 2 threads handles 100+ GB/day per node. See [Node counting](https://doc.log10x.com/faq/pricing/node-counting/) for sizing details and Kubernetes resource specs, and the [deployment guide](https://doc.log10x.com/apps/receiver/deploy/){target="_blank"} for per-forwarder configuration.

??? tenx-integration "Can the Receiver reduce Kubernetes health check volume"

    Yes. Health checks, liveness probes, and pod lifecycle events are highly repetitive and can represent 20-40% of total log volume in K8s environments. 95% reduction is common for these event types.

    **How it works:**

    1. Set the sample action with a budget cap for health check event types using [rate sampling](https://doc.log10x.com/run/receive/rate/){target="_blank"}
    2. For the surviving events, set the [compact action](https://doc.log10x.com/apps/receiver/compact/){target="_blank"} to losslessly compact them via [templates](https://doc.log10x.com/run/transform/){target="_blank"}
    3. Result: 95% reduction on health checks while preserving all pod metadata (namespace, pod name, container name, labels)

    Failed health checks are retained at top priority and very likely to pass even when the event type is over budget. Works with Splunk Connect for Kubernetes, [Fluentd](https://doc.log10x.com/run/input/forwarder/fluentd/){target="_blank"}, [Fluent Bit](https://doc.log10x.com/run/input/forwarder/fluentbit/){target="_blank"}, OpenTelemetry Collector.

<a id="what-happens-if-the-sidecar-fails"></a>

??? tenx-integration "How does the Receiver handle failures"

    Kubernetes runs 10x as a sidecar container next to the forwarder and manages its lifecycle. If the 10x process exits, crash, OOM kill, panic, the container exits and the kubelet restarts it automatically via the pod's default `restartPolicy`. The forwarder keeps running and buffers in-flight events while the sidecar restarts, so events are not dropped during the restart and unsampled traffic is held back.

    | Scenario | Behavior |
    |---|---|
    | 10x crash or OOM | The 10x process exits and Kubernetes restarts the sidecar container automatically. Forwarder buffers events while the sidecar is down and reconnects on restart. |
    | Volume exceeds 10x capacity | Forwarder buffers locally; 10x catches up. Backpressure signals the forwarder to slow down. |
    | Forwarder crashes | Kubernetes restarts the forwarder container; the pod stays up and the sidecar keeps running. |
    | Network interruption | No effect, both containers share the pod's loopback network. |
    | Downstream analyzer slow or unreachable | Forwarder handles retries to the destination, 10x unaffected. |
    | Rollback | Single `helm uninstall`, forwarder continues unchanged, no data migration. |