Receiver

The Receiver runs as a forwarder sidecar and acts on each pattern before events reach your analyzer.

Its actions are pass, sample, compact, tier_down, offload, and drop. The action is set per service and applies to every pattern over its cap in that service. An AI agent sets the action per service through the log10x MCP (configure_engine); the engine enforces it, carried as a config change through the GitOps repo.

Workflow

The Receiver app processes events from a variety of log forwarders, 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.

graph LR
    A["<div style='font-size: 14px;'>🚙 Forwarder</div><div style='font-size: 10px; text-align: center;'>Sidecar Process</div>"] --> B["<div style='font-size: 14px;'>📡 Receive</div><div style='font-size: 10px; text-align: center;'>Stream Events</div>"]
    B --> C["<div style='font-size: 14px;'>🔄 Transform</div><div style='font-size: 10px; text-align: center;'>into TenXObjects</div>"]
    C --> D["<div style='font-size: 14px;'>🎁 Enrich</div><div style='font-size: 10px; text-align: center;'>Add Context</div>"]
    D --> E["<div style='font-size: 14px;'>🚦 Act</div><div style='font-size: 10px; text-align: center;'>Per-Pattern Action</div>"]
    E --> F["<div style='font-size: 14px;'>📤 Output</div><div style='font-size: 10px; text-align: center;'>Write to Forwarder</div>"]

    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 to log forwarders for real-time event analysis

📡 Receive: Read events continuously from log forwarders via IPC

🔄 Transform: Structures log events into well-defined TenXObjects

🎁 Enrich: Applies enrichment rules to augment TenXObjects with intelligent context

📈 Report: Publishes cost insight metrics for visualization and alerting

🚦 Act: Apply the per-pattern action: pass, sample against a per-node budget, compact 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

Architecture

The Receiver executes as a forwarder 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.

Per-Pattern Cap Mute File (GitOps)

The regulator caps the bytes each pattern (symbol identity) may spend in its container over a rolling window (default 4 minutes). The excess takes the container's action, and passes when none is set, while severity floors keep a share of each level. Simple, autonomous, no coordination. See the rate regulator.

Receivers cap each pattern's bytes per container to prevent over-billing.

A declarative file keyed by the joined rateReceiverFieldNames values (e.g. message_pattern, container) caps specific patterns with an explicit sample rate and expiry. Operators (or an AI assistant via the Log10x MCP) append entries based on 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.

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	Logs continue flowing if 10x goes down
Backpressure handling	Disk buffering absorbs spikes so events are not shed under backpressure
Resource requirements	A heap set explicitly, for example 512m in a 768Mi container limit
Rollback	helm uninstall removes the sidecar in about a minute; with fail-open, logs keep flowing at full volume

See the Receiver FAQ for complete operational details, capacity planning, and deployment guidance.

Next: Test