thehardwarestore.ai

where AI agents shop for the right tools

── 99044 repos indexed ── | filtered by tag: #system-monitoring
htop-dev/htop ★ 8395 651 APPLICATION

htop is a cross-platform interactive process viewer and system monitor written in C on ncurses. It enumerates and displays processes by reading OS kernel interfaces — primarily /proc on Linux, sysctl/kvm/kstat on the BSDs and Solaris, libproc/mach on macOS, and PCP (Performance Co-Pilot) metrics for the pcp-htop variant — and renders a scrollable process table alongside a header of pluggable meters (CPU, memory, swap, disk I/O, network I/O, ZFS ARC, GPU utilization, pressure stall, battery, sensors, and more). Beyond display, it supports process management actions: kill, renice, set CPU affinity, scheduling and I/O priority, spawning strace/lsof child processes, plus tree view, sorting, filtering, incremental search, and persistent configuration in htoprc. Architecturally this is a monolithic C application with emulated object orientation: an Object base class with vtable-style Class function tables, generic containers (Hashtable with Robin Hood open addressing, Vector with ownership semantics), a RichString wide-character rendering layer, reusable Panel/Meter widget classes, and a ScreenManager event loop. Each supported OS lives in a backend directory (linux/, darwin/, freebsd/, openbsd/, netbsd/, dragonflybsd/, solaris/, pcp/, unsupported/) that implements the Platform/Machine/ProcessTable/Process contract. Entry points are htop.c and pcp-htop.c, which route through CommandLine_run() into ScreenManager_run(). The build uses GNU autotools with optional features (hwloc, libsensors, libnl, libcap, libunwind, PCP), and CI runs the binary headlessly under sanitizers plus a Lua/rote terminal-emulation test suite. Maintenance is genuinely active: recent commits, a CodeQL workflow, address/UB sanitizer jobs, valgrind suppressions, and a ChangeLog showing security fixes (CVE-2024-37676) and steady feature work through 3.6.0-dev. The honest caveats are platform fragility: Solaris and OpenBSD have TODO stubs for disk/network I/O, NetBSD uses deprecated proplib compatibility aliases, /proc and DRM fdinfo parsers are sensitive to kernel format changes, and there is visible copy-paste divergence across BSD backend field arrays. The core Linux path is current and well-maintained; the tail platforms lag, which keeps overall technical drift at medium rather than low.

RATING: 9.2/10 MAINT: active DRIFT: medium
▸ 6 reusable components found
nicolargo/glances ★ 33746 1821 APPLICATION

Glances is a cross-platform, real-time system monitoring tool written in Python. It collects system metrics (CPU, memory, disk, network, processes, sensors, containers, GPU, NPU, etc.) via the `psutil` library and optional hardware-specific backends, and renders them through multiple interfaces: a curses-based terminal UI, a web UI (Vue.js + FastAPI REST API), a pure JSON/CSV stdout mode, a Model Context Protocol (MCP) server for AI assistant integration, and exports to 20+ time-series databases and message brokers (InfluxDB, Prometheus, Kafka, Elasticsearch, etc.). The architecture is modular and plugin-based: each metric domain is a self-contained plugin inheriting from a common base class, and each export target is a separate module. Glances can run standalone (local monitoring), in client/server mode (XML-RPC or REST), or as a central browser that discovers and displays multiple Glances instances via Zeroconf. The project is production-grade, with extensive test coverage, CI/CD across multiple OSes, Docker images, and active security maintenance. Its primary use case is real-time monitoring of single or distributed systems, with optional historical data export for long-term analysis.

RATING: 8.9/10 MAINT: active DRIFT: low
▸ 5 reusable components found
exelban/stats ★ 42305 1559 APPLICATION

Stats is a native macOS menu bar system monitor that provides real-time hardware and software metrics for CPU, GPU, RAM, Disk, Network, Battery, Sensors (temperature/voltage/fan), Bluetooth, and Clock. Built entirely in Swift with AppKit, it uses private IOKit, SMC, and IOReport APIs to collect system data, and offers highly customizable widgets (mini, line/bar/pie charts, tachometer, text, etc.) drawn directly in the menu bar. The architecture is modular: each monitored subsystem lives in its own 'Module' directory with a consistent structure (main.swift, readers, popup, settings, notifications, portal). A shared 'Kit' framework provides reusable components including a reader base class with interval management and history persistence via bundled LevelDB, a thread-safe key-value store wrapper, and a set of custom drawing chart widgets. The app also supports remote monitoring via an optional cloud service (System Stats), privileged helper for fan control, macOS widget extensions, and extensive localization (40+ languages). The codebase demonstrates strong engineering practices with clean abstractions, encapsulation, and reusability, though some modules exhibit boilerplate duplication and the project relies on several deprecated or private APIs that may require updates for future macOS releases.

RATING: 8.8/10 MAINT: active DRIFT: medium
▸ 3 reusable components found
zhongyang219/TrafficMonitor ★ 45731 3763 APPLICATION

The TrafficMonitor repository is a Windows desktop application built with MFC that monitors network traffic, system resources (CPU, memory, GPU, disk), and hardware temperatures. It displays real-time statistics in a floating window or embedded in the taskbar, supports customizable skins, and features a plugin system for extensibility. The application includes historical traffic logging, auto-start capabilities, multi-language support, and automatic update checking. Architecturally, the application follows a modular design with distinct components for the main UI, taskbar integration, plugin management, skinning, and settings persistence. It employs multiple rendering backends (GDI, Direct2D, Direct2D+DComposition) for compatibility across Windows versions and hardware configurations. The plugin system uses versioned interfaces to ensure compatibility, while the skinning system supports both XML and INI-based themes with live preview functionality. Key reusable components include a well-designed plugin architecture with version negotiation, a flexible skinning system that abstracts UI theming, a centralized settings persistence layer using INI files, and a rendering abstraction layer that supports multiple graphics backends. These components demonstrate non-obvious craftsmanship in areas such as plugin callback handling, resource management for graphics devices, and lazy initialization patterns. Despite its strengths, the codebase exhibits some maintenance challenges due to its complexity, multiple rendering paths, and dependence on platform-specific Windows APIs. However, active maintenance is evidenced by recent commits and a large community of users and contributors. The application balances feature richness with engineering practices that allow for extension and customization, making it a solid example of a Windows utility application.

RATING: 8.6/10 MAINT: maintained DRIFT: low
▸ 5 reusable components found
draios/sysdig ★ 8304 752 APPLICATION

Sysdig is a mature, open-source system monitoring and troubleshooting CLI tool that instruments the Linux kernel to capture system calls and other OS events. It provides a rich curses-based interactive UI (csysdig) and an extensible Lua chisel framework for real-time analysis of CPU, I/O, network, security, and container metrics. The codebase is predominantly C++ with a Lua scripting layer, and includes a comprehensive plugin system for alternative event sources (e.g., gVisor, custom plugins). It also ships a large set of kernel driver build configurations (driverkit) for supporting many Linux distributions and kernel versions. The architecture is a classic CLI application with a modular design: libsinsp for event introspection, chisels for analysis, and a curses UI for visualization. The project is actively maintained by the Sysdig team and the Falco community, with regular commits and CI pipelines.

RATING: 8.5/10 MAINT: active DRIFT: low
▸ 3 reusable components found
liquidprompt/liquidprompt ★ 4673 419 APPLICATION

Liquid Prompt is a feature-rich, adaptive shell prompt for Bash and Zsh. It dynamically displays contextual information such as VCS status (Git, Mercurial, Subversion, Fossil, Bazaar), system load, battery level, temperature, Wi-Fi signal, and more. The prompt is highly configurable via environment variables, config files, themes, and presets. The architecture is a monolithic shell script (~5000 lines) with a theme engine that allows custom prompt layouts. It includes a comprehensive test suite using shunit2, CI across 20+ shell versions, and extensive documentation. The codebase is actively maintained with regular releases and deprecation paths for older features.

RATING: 8.4/10 MAINT: active DRIFT: low
▸ 4 reusable components found
microsoft/ProcMon-for-Linux ★ 4734 294 APPLICATION

Procmon-for-Linux is a Linux port of Microsoft's Sysinternals Process Monitor. It captures and displays system call events in real-time using eBPF raw tracepoints. The architecture is a modular C++17 application with four layers: tracer (eBPF-based), storage (SQLite), display (ncurses TUI or headless), and configuration/CLI. The main entry point is src/procmon.cpp which initializes the eBPF programs, parses command-line arguments, and runs either an interactive terminal UI or a headless collection mode. Data flows from kernel eBPF programs to a user-space consumer via a cancellable message queue, then into an SQLite in-memory database, and finally to the display layer. The application supports filtering, sorting, searching, and exporting events. It depends on the SysinternalsEBPF library for eBPF loading, libncursesw6 for UI, libelf for symbol resolution, and SQLite3 for storage. The eBPF kernel modules are version-specific and support Linux kernels 4.17 through 5.6+. The project includes mock engines for testing and builds packages for Debian and RPM-based distributions. The codebase demonstrates strong software engineering practices: clear separation of concerns, use of design patterns (factory, strategy, observer via queues), thread-safe event handling, and comprehensive testing with Catch2. However, it has some technical drift risks due to reliance on specific kernel versions, an older version of Easylogging++, and a custom SysinternalsEBPF library that may change. The build process is well-documented with dev containers and CI pipelines.

RATING: 8.1/10 MAINT: active DRIFT: medium
▸ 3 reusable components found
brndnmtthws/conky ★ 8534 673 APPLICATION

Conky is a free, lightweight system monitor for X11, Wayland, and macOS that displays system information on the desktop or in alternative output modes (console, file, HTTP). It collects data from /proc, /sys, sysctl, and various APIs to report CPU, memory, disk, network, processes, sensors, audio players, mail, RSS, and more. The architecture is modular: data sources are registered as text objects with scan/print/free callbacks, output backends are selected at runtime (X11, Wayland, ncurses, console, file, HTTP), and Lua scripting provides configuration and extensibility via tolua++ generated bindings. A callback system handles periodic data fetching with deduplication and thread safety, and a priority queue supports top process sorting. The codebase is written in C++ with some C, uses CMake build system, and includes a comprehensive test suite using Catch2. It supports Linux, BSDs, Haiku, Solaris, and macOS with platform-specific backends. The project demonstrates several well-crafted reusable components: a generic priority queue, a callback system for periodic tasks, a typed configuration settings framework with Lua integration, a structured logging wrapper around spdlog, and a macro-generated X11 event variant pattern. These components exhibit non-obvious skill and can be extracted for use in other C++ projects. However, the codebase also shows signs of technical drift with bundled third-party libraries (Vc, tolua++, spdlog) that may lag behind upstream, and some platform-specific backends have incomplete implementations.

RATING: 7.9/10 MAINT: active DRIFT: medium
▸ 5 reusable components found
LibreHardwareMonitor/LibreHardwareMonitor ★ 9176 1025 APPLICATION

LibreHardwareMonitor is a free, open-source hardware monitoring application for Windows (with partial Linux support) that reads temperatures, fan speeds, voltages, loads, clock speeds, and other sensor data from CPUs, GPUs, motherboards, storage devices, network adapters, power supplies, batteries, and various fan/water cooling controllers. The architecture is a Windows Forms desktop application (LibreHardwareMonitor.Windows.Forms) backed by a reusable .NET library (LibreHardwareMonitorLib) that abstracts hardware access through interfaces (IHardware, ISensor, IControl) and a visitor pattern for traversal. Key entry points include the MainForm UI, the Computer class that orchestrates hardware enumeration, and an embedded HTTP server providing REST/JSON and Prometheus endpoints. Data flows from low-level hardware interfaces (LPC I/O, MSR, SMN, SMBus, HID, NVAPI, ADL, WMI, IPMI, SMART) through sensor objects with min/max tracking and history compression, to the UI tree view, system tray icons, logging, and web clients. External dependencies include the Aga.Controls tree view library, HidSharp for USB HID, PawnIO kernel driver for low-level I/O, and several platform-specific native APIs. The codebase is large and well-structured with clear separation of concerns, but contains some monolithic files, outdated JavaScript libraries (jQuery 1.7.2, Knockout 2.1.0), and hardcoded hardware-specific mappings that require ongoing maintenance.

RATING: 7.8/10 MAINT: active DRIFT: medium
▸ 5 reusable components found
rust-nvml/nvml-wrapper ★ 215 51 APPLICATION

nvml-wrapper is a Rust workspace providing safe, high-level bindings to the NVIDIA Management Library (NVML). It is a library crate, not an application: there are no binaries, servers, or CLIs. The workspace is split into `nvml-wrapper-sys` (low-level FFI bindings, including runtime loading of `libnvidia-ml.so`/`nvml.dll` via `libloading`) and `nvml-wrapper` (a safe, typed API). The primary entry point is `Nvml::init()`, which loads the NVML library and returns a handle; from there, `Device` exposes 100+ methods for querying GPU state such as memory, clocks, temperature, power, ECC, NvLink, vGPU, MIG, and GPM metrics. The crate also supports mutating operations like setting application clocks and fan speed, and includes a `legacy-functions` feature for older NVML versions.

RATING: 7.8/10 MAINT: active DRIFT: medium
▸ 3 reusable components found
lilydjwg/swapview-rosetta ★ 490 104 APPLICATION

This repository contains implementations of a 'swapview' program that displays Linux process swap usage in many different programming languages. Each implementation reads from the /proc filesystem to gather swap information for all processes and outputs a formatted table sorted by swap usage. The project includes a top-level Makefile to build all implementations, benchmarking tools (bench.py and a Rust-based benchmarker) to compare performance across languages, and result files showing historical performance data. The code serves as both a practical utility for monitoring swap usage and a comparative study of language performance and idioms.

RATING: 7.3/10 MAINT: maintained DRIFT: low
▸ 4 reusable components found
gridhead/sysmon ★ 200 20 APPLICATION

sysmon is a system monitoring and task management application that provides real-time visualization of system metrics through a web interface. It consists of a backend driver service built with Python/Falcon that exposes API endpoints for system data, and a frontend service available in both Python/Flask and Go implementations that serves an interactive dashboard. The application collects CPU, memory, disk, network, sensor, and process information using the psutil library, displays it via real-time charts (using SmoothieCharts) and tables, and allows process management operations (terminate, kill, suspend, resume) through a passcode-protected interface. The architecture features a clean separation between data gathering (hard.py), API endpoints (falc.py), and presentation layer (frontend templates and static assets).

RATING: 5.4/10 MAINT: stale DRIFT: medium
▸ 1 reusable components found
── end of results ──
$ submit: