--- title: "Receiver" description: "filter noisy events, and compact survivors losslessly on Splunk and self-hosted Elasticsearch/OpenSearch, before they ship to output" source: "https://github.com/log-10x/modules/tree/main/apps/receiver/app.yaml" icon: "material/pipe-valve" --- The Receiver runs as a forwarder sidecar and acts on each pattern before events reach your analyzer. It picks one action per pattern: **pass, sample, compact, tier_down, offload, or drop**. An AI agent sets the action per service through the [log10x MCP](https://doc.log10x.com/apps/mcp/) (`configure_engine`); the engine enforces it, carried as a config change through the [GitOps](https://doc.log10x.com/engine/gitops/) repo. ## :material-cog-transfer-outline: Workflow The Receiver app processes events from a variety of [log forwarders](https://doc.log10x.com/run/input/forwarder), such as Fluentd, Fluent Bit, Filebeat, and Logstash. Configure the app to process all or a subset of the events, allowing for targeted analysis and per-pattern actions.
```mermaid graph LR A["
🚙 Forwarder
Sidecar Process
"] --> B["
📡 Receive
Stream Events
"] B --> C["
🔄 Transform
into TenXObjects
"] C --> D["
🎁 Enrich
Add Context
"] D --> E["
🚦 Act
Per-Pattern Action
"] E --> F["
📤 Output
Write to Forwarder
"] classDef deploy fill:#7c3aed88,stroke:#6d28d9,color:#ffffff,stroke-width:2px,rx:8,ry:8 classDef receive fill:#9333ea88,stroke:#7c3aed,color:#ffffff,stroke-width:2px,rx:8,ry:8 classDef transform fill:#2563eb88,stroke:#1d4ed8,color:#ffffff,stroke-width:2px,rx:8,ry:8 classDef enrich fill:#059669,stroke:#047857,color:#ffffff,stroke-width:2px,rx:8,ry:8 classDef regulate fill:#dc2626,stroke:#b91c1c,color:#ffffff,stroke-width:2px,rx:8,ry:8 classDef output fill:#ea580c88,stroke:#c2410c,color:#ffffff,stroke-width:2px,rx:8,ry:8 class A deploy class B receive class C transform class D enrich class E regulate class F output ```
🚙 **Forwarder**: Runs 10x as a [sidecar process](https://doc.log10x.com/engine/launcher/sidecar) to log forwarders for real-time event analysis 📡 **Receive**: Read events continuously from [log forwarders](https://doc.log10x.com/run/input/forwarder) via IPC 🔄 **Transform**: Structures log events into well-defined [TenXObjects](https://doc.log10x.com/run/transform/) 🎁 **Enrich**: Applies [enrichment rules](https://doc.log10x.com/run/initialize/) to augment TenXObjects with intelligent context 📈 **Report**: Publishes [cost insight metrics](https://doc.log10x.com/run/output/metric "Time-series outputs provide an extensible method for publishing TenXSummary instances") for visualization and alerting 🚦 **Act**: Apply the per-pattern action: pass, [sample](https://doc.log10x.com/run/receive/rate/) against a per-node budget, [compact](compact/index.md) for search-time expansion on Splunk/self-hosted Elasticsearch/OpenSearch, tier_down, offload to customer-owned object storage, or drop 📤 **Output**: Writes processed events back to forwarder to ship to destination analyzers ## :material-hexagon-multiple-outline: Architecture The Receiver executes as a [forwarder sidecar](https://doc.log10x.com/engine/launcher/sidecar) that applies a per-pattern action (pass, sample, compact, tier_down, offload, drop) *before* events ship to a log analyzer. An AI agent picks the action per service through the log10x MCP `configure_engine` tool; the decision travels as a config change through the GitOps repo. === ":material-car-speed-limiter: Per-Node Budget" The sample action runs against a local hourly budget, using [symbol identities](https://doc.log10x.com/run/transform/symbol/) to track per-event-type spend and probabilistically shed the share of a pattern that pushes it over budget. Simple, autonomous, no coordination. See [per-node budget mode](https://doc.log10x.com/run/receive/rate/).
![Architecture diagram: Receiver sidecar applies per-event-type rate limits to filter noisy events before forwarding to log analyzers](../../assets/tenx-edge-receiver.svg){ align=left }
:white_check_mark: **Receivers** use per-node budgets to prevent over-billing.
=== ":material-file-document-edit-outline: Mute File (GitOps)" A declarative file keyed by the joined `rateReceiverFieldNames` values (e.g. `symbolMessage`, `container`) caps specific patterns with an explicit sample rate and expiry. Operators (or an AI assistant via the [Log10x MCP](https://github.com/log-10x/log10x-mcp)) append entries based on [Reporter](https://doc.log10x.com/apps/reporter/) cost attribution, commit to git, and every receiver pulls the file on its next reload. Each mute is diff-reviewed, self-expires, and maps 1:1 to the field-sets the Reporter attributes cost to. See [mute file mode](https://doc.log10x.com/run/receive/rate/#mute-file-mode-declarative-field-set-caps). ## :material-shield-check-outline: Safety & Reliability The Receiver runs as a sidecar alongside your log forwarder with fail-open design. If the receiver crashes or stops, your logs continue flowing normally at full volume to your analyzer. |Topic|Detail| |---|---| |[Fail-open design](faq.md#what-happens-if-the-sidecar-fails)|Logs continue flowing if 10x goes down| |[Backpressure handling](faq.md#how-does-the-receiver-handle-failures)|Disk buffering absorbs spikes so events are not shed under backpressure| |[Resource requirements](faq.md#which-log-forwarders-does-the-receiver-support)|512MB heap + 2 threads handles 100+ GB/day| |[Rollback](faq.md#what-happens-if-the-sidecar-fails)|`helm uninstall` removes the sidecar in about a minute; with fail-open, logs keep flowing at full volume| See the [Receiver FAQ](faq.md) for complete operational details, capacity planning, and deployment guidance.