4b6817381b
CI (OpenClaw E2E) / openclaw test (push) Has been cancelled
CI / coverage-report (push) Has been cancelled
CI / test-kubernetes (push) Has been cancelled
CI / should-run-thorough (push) Has been cancelled
CI / test-thorough (cloudwatch-demo) (push) Has been cancelled
CI / test-thorough (flink-ecs) (push) Has been cancelled
CI / test-thorough (upstream-lambda) (push) Has been cancelled
CI / test-thorough (prefect-ecs-fargate) (push) Has been cancelled
Release / build-binaries (zip, opensre.exe, onefile, windows-latest, windows-x64) (push) Has been cancelled
Benchmark image — build + push to ECR (any adapter) / build + push (push) Has been cancelled
CI / quality (ubuntu-latest) (push) Has been cancelled
CI / test (tools-runtime) (push) Has been cancelled
CI / test (e2e-general) (push) Has been cancelled
CI / test (cli-runtime) (push) Has been cancelled
CI / test (e2e-provider-and-openclaw) (push) Has been cancelled
CI / test (integrations-and-misc) (push) Has been cancelled
Release / verify (push) Has been cancelled
Release / build-python-dist (push) Has been cancelled
Release / build-binaries (tar.gz, opensre, onedir, macos-15-intel, darwin-x64) (push) Has been cancelled
Release / build-binaries (tar.gz, opensre, onedir, macos-latest, darwin-arm64) (push) Has been cancelled
Release / build-binaries (tar.gz, opensre, onedir, ubuntu-22.04, linux-x64) (push) Has been cancelled
Release / publish-release (push) Has been cancelled
Release / publish-main-release (push) Has been cancelled
Interactive Shell Live (PR + post-merge) / turn-checks (no-LLM) (push) Has been cancelled
CodeQL / Analyze (python) (push) Has been cancelled
Interactive Shell Live (PR + post-merge) / turn-live shard ${{ matrix.shard_index }} (push) Has been cancelled
Release / prepare (push) Has been cancelled
Release / build-binaries (tar.gz, opensre, onedir, ubuntu-22.04-arm, linux-arm64) (push) Has been cancelled
Synthetic Deterministic Tests / Synthetic offline (deterministic) (push) Has been cancelled
108 lines
5.0 KiB
Plaintext
108 lines
5.0 KiB
Plaintext
---
|
||
title: "How It Works"
|
||
description: "Technology overview"
|
||
---
|
||
|
||
## Tracer Technology Benefits
|
||
Tracer offers a set of core capabilities that improve visibility and analysis across scientific workflows compared to traditional monitoring tools:
|
||
- Deep information: enabling faster and more accurate issue detection.
|
||
- Workflow-agnostic: Works with any workflow without required modifications.
|
||
- Advanced Features: driving up value creation such as resource and cost optimization<br/>
|
||
|
||
## How Tracer Can Offer This
|
||
Tracer is built on top of eBPF (extended Berkeley Packet Filter), a Linux kernel technology that allows safe, high-performance instrumentation without kernel modifications. eBPF programs run inside the kernel and expose detailed telemetry to Tracer’s runtime, which correlates system events with pipeline steps, tools, and samples.
|
||
Below is a high-level view of how Tracer uses eBPF during development and runtime:
|
||
|
||
<img
|
||
className="block dark:hidden"
|
||
src="/images/eBPF-Light.png"
|
||
alt="eBPF Overview"
|
||
style={{ width: '100%', height: 'auto' }}
|
||
/>
|
||
<img
|
||
className="hidden dark:block"
|
||
src="/images/eBPF-Dark.png"
|
||
alt="eBPF Overview"
|
||
style={{ width: '100%', height: 'auto' }}
|
||
/>
|
||
|
||
|
||
### Development
|
||
eBPF programs are compiled into safe bytecode and validated by the kernel’s verifier. Tracer distributes precompiled, architecture-compatible eBPF modules through its Go-based agent, so no user compilation is required.
|
||
### Runtime
|
||
At runtime, Tracer’s eBPF modules attach to system call boundaries, network operations, scheduling events, and other kernel hooks. Using eBPF Maps, Tracer aggregates telemetry efficiently and streams enriched metrics to its backend. This enables:
|
||
- Per-tool and per-task CPU/I/O visibility
|
||
- Real-time failure attribution
|
||
- Identification of idle or stuck processes
|
||
- Network and storage performance insights
|
||
- Cost and resource usage mapping at sample, step, and pipeline levels
|
||
|
||
|
||
All instrumentation operates with minimal overhead and without requiring privileged kernel modules.
|
||
|
||
## Why eBPF
|
||
Understanding why Tracer uses eBPF for observability
|
||
Traditional approaches rely on logs, metrics exporters, or code instrumentation.
|
||
eBPF serves four main purposes for Tracer:
|
||
<table className="ebpf-benefits-table">
|
||
<tr>
|
||
<td>
|
||
<span className="block dark:hidden"><Icon icon="eye" size={25} color="#000000" /></span>
|
||
<span className="hidden dark:block"><Icon icon="eye" size={25} color="#FFFFFF" /></span>
|
||
<br/><br/>**See everything**<br/>System calls, process lifecycle, I/O, and scheduling events
|
||
</td>
|
||
<td>
|
||
<span className="block dark:hidden"><Icon icon="feather" size={25} color="#000000" /></span>
|
||
<span className="hidden dark:block"><Icon icon="feather" size={25} color="#FFFFFF" /></span>
|
||
<br/><br/>**Stay lightweight**<br/>Sampling at kernel level without copying large data
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td>
|
||
<span className="block dark:hidden"><Icon icon="shield-check" size={25} color="#000000" /></span>
|
||
<span className="hidden dark:block"><Icon icon="shield-check" size={25} color="#FFFFFF" /></span>
|
||
<br/><br/>**Stay safe**<br/>Verified, sandboxed bytecode that cannot crash your node
|
||
</td>
|
||
<td>
|
||
<span className="block dark:hidden"><Icon icon="globe" size={25} color="#000000" /></span>
|
||
<span className="hidden dark:block"><Icon icon="globe" size={25} color="#FFFFFF" /></span>
|
||
<br/><br/>**Stay universal**<br/>Works with any container, binary, or programming language
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
|
||
This provides low-overhead visibility into black-box tools, which is particularly valuable for bioinformatics and computational biology pipelines.
|
||
|
||
|
||
## How Tracer works, next to eBPF
|
||
Tracer observes pipeline execution directly at the OS level using eBPF and a multi-layer data processing architecture. The workflow consists of four main stages:
|
||
<Steps>
|
||
<Step title="Attach">
|
||
The Tracer agent attaches non-intrusively to running processes and containers. No restarts, code changes, or wrapper scripts are required.
|
||
</Step>
|
||
<Step title="Collect">
|
||
Using eBPF, the agent captures granular system-level signals, including CPU scheduling delays, I/O operations, memory activity, GPU context switches, and other kernel events, while maintaining low overhead.
|
||
</Step>
|
||
<Step title="Correlate">
|
||
Captured events are mapped back to the structure of the pipeline, including jobs, tasks, and steps. This provides context for understanding runtime behavior across diverse tools and workflow engines.
|
||
</Step>
|
||
<Step title="Stream">
|
||
Structured telemetry is sent to the Tracer backend (on-premises or cloud). Data is aggregated, visualized in dashboards, and made available for export through standard interfaces such as APIs.
|
||
</Step>
|
||
</Steps>
|
||
|
||
<img
|
||
className="block dark:hidden"
|
||
src="/images/Tracer-Functioning-Light.png"
|
||
alt="Tracer Functioning Overview"
|
||
style={{ width: '100%', height: 'auto' }}
|
||
/>
|
||
<img
|
||
className="hidden dark:block"
|
||
src="/images/Tracer-Functioning-Dark.png"
|
||
alt="Tracer Functioning Overview"
|
||
style={{ width: '100%', height: 'auto' }}
|
||
/>
|
||
|
||
|