Sidecar

Sidecars execute the 10x Engine as a sidecar process to read and events from a target process (e.g., Fluentd/Bit) running on the same node. This architecture enables 10x to integrate with other observability products without requiring custom builds or code integrations.

In-mem outputs (e.g., Unix, Forward sockets) can write regulated and compact events back to the originating process for processing and shipping.

This launcher employs the Edge or JIT-edge favor.

Use-case:

Forwarder inputs report, regulate and optimize log/trace events before they ship from edge nodes to their output destination (e.g., Elastic, Splunk).

Benefits

Sidecar deployment provides several technical advantages for integrating the 10x Engine with log forwarders:

Native Kubernetes Support

Kubernetes pods co-locate the 10x engine with your forwarder, sharing the pod's network namespace and lifecycle. Depending on the forwarder, 10x runs either as a sidecar container or as an embedded child process — see Deployment Models below.

Efficient Inter-Process Communication

Sidecars enable low-latency protocols like stdio streams for direct piping, Unix domain sockets for zero-copy transfers, Fluent Forward protocol for reliable event forwarding, and OTLP for OpenTelemetry metrics/traces. These minimize overhead compared to network-based alternatives.

Process Isolation and Management

Decouples 10x from the forwarder process, enabling independent monitoring via tools like Prometheus, separate restart policies, and fault isolation. If 10x crashes, the forwarder continues operating without interruption.

Resource Optimization

Shares host resources efficiently. In the sidecar container model, CPU and memory requests are set independently for 10x and the forwarder. In the embedded model, 10x shares the forwarder container's resource allocation — add JVM heap plus overhead to the forwarder's existing memory limit.

Security Boundaries

In the sidecar container model, 10x runs with a separate security context (non-root, read-only root filesystem), allowing distinct capabilities and namespaces while sharing volumes for data exchange. In the embedded model, 10x inherits the forwarder container's security context. Both models reduce the attack surface compared to plugin-based integrations by avoiding custom code within the forwarder runtime.

Deployment Models

Two integration models depending on the forwarder:

	Embedded Process	Sidecar Container
Forwarders	Fluentd, Fluent Bit, Filebeat	OTel Collector, Logstash
Containers per pod	1	2
IPC mechanism	stdin/stdout pipes	Unix domain sockets
Resource limits	Shared with forwarder	Independent per container
Security context	Inherited from forwarder	Separate (non-root, read-only rootfs)

In both models, 10x runs as a separate OS process from the forwarder. If 10x crashes, the forwarder continues operating.

Embedded Process

Fluentd, Fluent Bit, and Filebeat launch the 10x binary as a child process within the forwarder container. The forwarder's plugin system handles process lifecycle — exec_filter for Fluentd, Lua filter for Fluent Bit, JavaScript processor for Filebeat. Events flow via stdin/stdout pipes.

Resource overhead is the JVM footprint only (heap + metaspace + thread stacks). No separate container image, no additional scheduling overhead.

Sidecar Container

OTel Collector and Logstash run 10x as a separate Kubernetes sidecar container within the same pod. Each container has its own image, resources block, and securityContext. Communication uses Unix domain sockets via a shared emptyDir volume.

This model supports independent scaling, separate restart policies, and container-level resource isolation.

Architecture Flow

graph LR
    A["🪵 Log Forwarder<br/>(Fluentd/Fluent Bit/Filebeat)"] -->|"🔗 IPC Protocol<br/>(stdio, unix socket, forward)"| B["🏎️ 10x Engine<br/>(Sidecar Process)"]
    B -->|"🔄 Transform<br/>into TenXObjects"| C["⚡ Process<br/>(Report/Regulate/Optimize)"]
    C -->|"📤 Return<br/>Processed Events"| D["🔗 IPC Protocol<br/>(stdio, unix socket, forward)"]
    D --> A
    A -->|"📡 Ship to<br/>Destinations"| E["🏭 Analytics Platforms<br/>(Splunk, Elasticsearch, etc.)"]

    classDef forwarder fill:#3b82f6,stroke:#1d4ed8,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef tenx fill:#059669,stroke:#047857,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef process fill:#ea580c,stroke:#c2410c,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef ipc fill:#8b5cf6,stroke:#7c3aed,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef destination fill:#6b7280,stroke:#4b5563,color:#ffffff,stroke-width:2px,rx:8,ry:8

    class A forwarder
    class B tenx
    class C process
    class D ipc
    class E destination

Enlarge Diagram

🪵 Forwarder → 🏎️ 10x: Events flow from log forwarder to 10x Engine via efficient IPC protocols

🔄 Transform: 10x Engine transforms raw events into structured TenXObjects

⚡ Process: Engine applies reporting, regulation, or optimization logic

📤 Return: Processed events flow back to forwarder via the same IPC channel

📡 Ship: Forwarder sends processed events to final destinations

The circular flow ensures zero disruption to existing forwarder configurations while enabling 10x optimization at the edge.