denet: Lightweight Linux Process Monitor
- denet is a lightweight Linux process-monitoring tool that provides time-resolved metrics via adaptive sampling and structured outputs.
- It reports CPU, memory, disk I/O, network activity, and metadata in formats like JSON, CSV, and JSONL for seamless workflow integration.
- Implemented in Rust with PyO3 Python bindings, denet supports recursive child monitoring and is ideal for benchmarking, debugging, and optimizing data workloads.
Searching arXiv for the primary denet paper and related DENet/DeNet usages. denet is a lightweight process monitoring utility for real-time resource profiling of running processes on Linux, published as “denet, a lightweight command-line tool for process monitoring in benchmarking and beyond” (Carrillo et al., 24 Sep 2025). It reports CPU, memory, disk I/O, network activity, thread usage, exit status, and process metadata for a target process and, by default, its descendants, with adaptive sampling and structured outputs in JSON, JSONL, or CSV. The software is implemented in Rust, exposes a Python API via PyO3 and maturin, and is positioned for benchmarking, debugging, monitoring, and optimization of data-intensive workloads, especially in bioinformatics workflows and other automation-heavy environments (Carrillo et al., 24 Sep 2025). The term “DENet” or “DeNet” is also used in multiple unrelated machine-learning papers, making disambiguation necessary in scholarly contexts.
1. Definition and scope
In its software sense, denet is a process-specific monitoring tool designed to provide time-resolved metrics with minimal overhead and parsing-friendly outputs (Carrillo et al., 24 Sep 2025). Its core goals are to support recursive child monitoring, provide adaptive sampling, and make profiling results easy to integrate into command lines, workflows, CI systems, and notebooks. The paper explicitly situates denet in benchmarking bioinformatics tools and pipelines, debugging long-running data pipelines on HPC clusters and cloud instances, and optimizing workloads by detecting off-CPU time, lock contention, I/O stalls, and memory leaks or peaks (Carrillo et al., 24 Sep 2025).
The software is Linux-first, works on standard workstations, HPC clusters, and cloud instances, and supports containerized workloads. Most monitoring features operate without administrative privileges because they read Linux process metrics primarily from /proc; experimental eBPF-based features for off-CPU analysis and certain kernel-level probes typically require elevated permissions and a Linux kernel with CONFIG_BPF_SYSCALL enabled (Carrillo et al., 24 Sep 2025). This deployment model makes denet suitable for unprivileged performance measurement in shared compute environments, while retaining a path to deeper kernel-level observability where permissions permit.
A plausible implication is that denet occupies an intermediate niche between interactive system monitors and lower-level tracing frameworks: it is process-centric and automation-oriented, but still extensible enough to surface metrics commonly associated with more specialized tooling.
2. Functional model and reported metrics
denet reports aggregated CPU utilization and per-core measurements, using the POSIX-style convention in which 100% ≈ one full core and 400% ≈ four full cores (Carrillo et al., 24 Sep 2025). It reports memory as separate RSS and VMS values, allowing practitioners to distinguish physically resident memory from mapped address space. Disk I/O and network activity are emitted per interval as bytes read, written, received, and transmitted, while thread count and child-process relationships provide additional visibility into concurrency and process-tree structure (Carrillo et al., 24 Sep 2025).
The paper also lists process metadata and run-level state in the output schema: timestamps, PID, command string, executable path, exit code for the parent, runtime duration, and profiling metadata such as base interval, maximum interval, adaptive mode, and whether child monitoring is enabled (Carrillo et al., 24 Sep 2025). Optional GPU observability is available in the form of GPU memory usage and percent utilization when NVIDIA NVML is present.
The standard Linux process-accounting formulas are given explicitly. CPU utilization over a sampling window is described as
while disk and network throughput over a sampling window are derived as
and
respectively (Carrillo et al., 24 Sep 2025). The paper does not claim custom formulas; instead it anchors denet’s semantics to standard Linux accounting conventions.
The distinction between RSS and VMS is especially important for interpretation. RSS is defined as the bytes of physical memory currently mapped by the process, whereas VMS is the total mapped address-space size, including non-resident regions and mappings (Carrillo et al., 24 Sep 2025). This suggests denet is intended not merely for coarse resource tracking but also for diagnostic interpretation of allocation patterns, swapping behavior, and memory mapping.
3. Architecture, interfaces, and implementation
denet is implemented in Rust and organized as a modular library with components named core, cpu-sampler, config, and error, together with PyO3-based Python bindings (Carrillo et al., 24 Sep 2025). The Rust core handles low-level system interaction and sampling, while the Python layer exposes the same monitoring functionality to scripts and notebooks. Packaging is provided through Cargo and PyPI, with installation commands cargo install denet and pip install denet, and the project is distributed as open-source software under the GPLv3 license (Carrillo et al., 24 Sep 2025).
The command-line interface supports colorized terminal output for interactive use as well as structured output for automation. The Python API is centered on denet.ProcessMonitor, which can be configured with a command, adaptive-sampling parameters, in-memory storage, output redirection, and recursive child monitoring, and then run synchronously until process exit (Carrillo et al., 24 Sep 2025). The paper’s example shows monitor.run(), monitor.get_samples(), and monitor.get_summary() as the primary API interactions.
Experimental eBPF support is described as using BCC to instrument kernel events for off-CPU time analysis and low-overhead tracing, and the paper notes that eBPF is namespace-aware and works well with containers such as Docker and Apptainer (Carrillo et al., 24 Sep 2025). At the same time, this functionality is marked experimental and subject to kernel and privilege requirements. The overall architecture therefore combines a default /proc-based monitoring path for broad usability with a more advanced eBPF path for deeper latency and scheduling analysis.
A plausible implication is that the Rust implementation is intended to keep sampling overhead low and output deterministic enough for reproducible benchmarking, while the Python API lowers the barrier for downstream aggregation and analysis in scientific workflows.
4. Sampling strategy, workflows, and operational practice
A central design feature is adaptive sampling. The paper specifies a three-stage schedule: during the first second, denet samples at the highest frequency, exemplified by every 100 ms; over the next nine seconds, it gradually reduces the sampling rate until a user-provided maximum interval is reached; and for processes running beyond 10 seconds, it maintains the maximum interval to reduce monitoring overhead on long jobs (Carrillo et al., 24 Sep 2025). Configuration is available through --interval <ms> and --max-interval <ms> in the CLI and base_interval_ms and max_interval_ms in the API.
This adaptive schedule is meant to preserve high temporal resolution during startup and other dynamic phases while avoiding the sustained cost and data volume of uniformly dense sampling on long-running processes (Carrillo et al., 24 Sep 2025). The paper explicitly recommends values around 100–250 ms for the base interval and 1000–2000 ms for the maximum interval as practical starting points, while noting that values should be chosen according to workload characteristics.
The CLI supports two principal monitoring modes: run, which launches and profiles a command, and attach, which attaches to an existing PID (Carrillo et al., 24 Sep 2025). Examples in the paper include real-time terminal monitoring with denet run sleep 5, JSON output redirection with denet --json run sleep 5 > metrics.json, fixed-interval sampling with denet --interval 500 run sleep 5, and duration-limited PID attachment with denet --duration 10 attach 1234. Recursive child monitoring is enabled by default and can be disabled with --no-include-children.
The paper further recommends JSONL for streaming within workflows, CSV for spreadsheets or rapid plotting, and explicit retention of metadata such as the full command, executable path, and sampling configuration for reproducibility (Carrillo et al., 24 Sep 2025). This suggests that denet’s intended use is not merely ad hoc inspection but durable, machine-consumable telemetry embedded in performance studies and pipeline engineering.
5. Output schemas and benchmarking integration
denet emits JSON, JSONL, and CSV, with schemas designed to remain easy to parse in automated environments (Carrillo et al., 24 Sep 2025). The documented key fields include timestamps, PID, command string, executable path, aggregated CPU percentage, per-core CPU array, rss_bytes, vms_bytes, io_read_bytes, io_write_bytes, net_rx_bytes, net_tx_bytes, thread_count, child-process indicators such as children_pids, the include_children flag, and exit_code for the parent (Carrillo et al., 24 Sep 2025).
The paper provides an example JSONL record with fields such as "ts_ms": 127, "pid": 4321, "cmd": "python script.py", "cpu_percent": 183.4, "cpu_per_core": [95.2, 88.2, 0.0, 0.0], "rss_bytes": 7340032, "vms_bytes": 123456789, "io_write_bytes": 4096, "thread_count": 12, and "children_pids": [4456, 4457] (Carrillo et al., 24 Sep 2025). The corresponding CSV header includes ts_ms,pid,cmd,exe,cpu_percent,cpu_core0,cpu_core1,cpu_core2,cpu_core3,rss_bytes,vms_bytes,io_read_bytes,io_write_bytes,net_rx_bytes,net_tx_bytes,thread_count,parent_pid,depth,exit_code.
The paper positions these schemas against tools such as top, htop, ps, time, pidstat, psutil, psrecord, perf, BCC, bpftrace, dstat, iostat, and netstat (Carrillo et al., 24 Sep 2025). Its comparison is not that denet subsumes all such tools, but that it combines process specificity, structured output, recursive process-tree monitoring, adaptive sampling, optional GPU observability, and selective eBPF exposure in a form well suited to benchmarking and workflow integration.
This suggests denet is best understood as telemetry infrastructure rather than a dashboard: it is optimized for capture, storage, and post hoc analysis of process behavior in reproducible experimental settings.
6. Nomenclature and disambiguation across the literature
The name “DENet” or “DeNet” is heavily overloaded in arXiv-indexed research and does not denote a single method family. In addition to the process-monitoring utility denet (Carrillo et al., 24 Sep 2025), the literature includes “Dynamic Enhancement Network” for partial multi-modality person Re-identification (Zheng et al., 2023), “Dual-Path Edge Network” for infrared small target detection (Zuo et al., 25 Sep 2025), “DeNet” for robust temporal grounding under query and label uncertainty (Zhou et al., 2021), and “DENet: A Universal Network for Counting Crowd with Varying Densities and Scales” (Liu et al., 2019).
The same label also appears in “Disc-aware Ensemble Network” for glaucoma screening (Fu et al., 2018), “DeNet: Scalable Real-time Object Detection with Directed Sparse Sampling” (Tychsen-Smith et al., 2017), AE-DENet for OFDM channel estimation enhancement (Fola et al., 2024), and ODENet for out-of-distribution enzymatic kinetic parameter prediction (Wu et al., 12 Jan 2026). A separate paper on objectness-aware few-shot semantic segmentation treats DENet as a pre-existing baseline architecture rather than the central contribution (Zhao et al., 2020). The related work “Improving Object Localization with Fitness NMS and Bounded IoU Loss” further develops the object-detection DeNet rather than the later process-monitoring utility (Tychsen-Smith et al., 2017).
This naming overlap creates an obvious bibliographic ambiguity. Lower-case “denet” in (Carrillo et al., 24 Sep 2025) refers to software for Linux process monitoring, whereas upper-case “DENet” or mixed-case “DeNet” in earlier papers refers to unrelated neural architectures in computer vision, vision-language grounding, communications, or computational biology. In technical writing, arXiv identifiers are therefore essential for disambiguation.
A plausible implication is that the denet software will often require explicit contextual labeling—such as “the process-monitoring utility denet”—to avoid confusion with established model names in machine learning.
7. Limitations, portability, and significance
The process-monitoring denet is explicitly Linux-centric, with Linux as the target environment in the paper, while macOS is described only as possibly feasible via host APIs and not the focus (Carrillo et al., 24 Sep 2025). eBPF functionality is experimental, requires Linux 4.x+ with CONFIG_BPF_SYSCALL, and usually needs elevated privileges. GPU metrics are available only when NVIDIA NVML is installed, and network metric granularity depends on what the operating system exposes per process, with eBPF able to improve visibility for containerized workloads (Carrillo et al., 24 Sep 2025).
The paper also states that overhead is not quantified, although the implementation is designed to minimize it through /proc-based sampling in Rust, adaptive sampling for long jobs, and optional eBPF for specific analyses (Carrillo et al., 24 Sep 2025). This is an important caveat for benchmarking practice: denet is engineered for low overhead, but the paper does not publish formal overhead measurements, inference-time benchmarks, or kernel-level validation studies.
Within those limits, denet’s significance lies in its combination of process specificity, structured outputs, recursive monitoring, adaptive sampling, and API-level embeddability. For data-intensive pipelines—particularly those in bioinformatics, HPC, and cloud settings—the tool provides a practical layer of instrumentation that can be invoked without root privileges in most cases and incorporated directly into workflow engines such as make, Snakemake, and Nextflow (Carrillo et al., 24 Sep 2025). This suggests its most durable contribution is methodological rather than algorithmic: it standardizes the capture of process-level telemetry in settings where reproducible benchmarking and operational diagnosis are often impeded by unstructured, system-level, or privilege-heavy tooling.
