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 the 10x process exits, Kubernetes restarts the sidecar container automatically while the forwarder keeps running and buffers events until 10x is back.

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:

	Sidecar Container	Embedded Process
Forwarders	Fluentd, Fluent Bit, Logstash, OTel Collector, Vector	Filebeat
Containers per pod	2	1
IPC mechanism	Loopback TCP (shared pod network)	stdin/stdout pipes
Resource limits	Independent per container	Shared with forwarder
Security context	Separate (non-root, read-only rootfs)	Inherited from forwarder
10x lifecycle	Managed by Kubernetes — the kubelet restarts the container on process exit	Managed by the forwarder process

Sidecar Container

Fluentd, Fluent Bit, Logstash, OTel Collector, and Vector run 10x as a separate Kubernetes sidecar container within the same pod. Each container has its own image, resources block, and securityContext. The forwarder and 10x share the pod's network namespace and exchange events over loopback TCP — no shared volumes required.

Kubernetes owns the sidecar lifecycle: if the 10x process exits, the kubelet restarts the container automatically. Each container is monitored, scaled, and rolled independently.

Embedded Process

Filebeat launches the 10x binary as a child process within the forwarder container, with events flowing via stdin/stdout pipes. Filebeat's plugin system handles 10x's process lifecycle. Resource overhead is the JVM footprint only (heap + metaspace + thread stacks). No separate container image, no additional scheduling overhead.

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.