M3 is a distributed time-series database and metrics platform originally developed by Uber and now under the Linux Foundation. It provides a full-stack solution for collecting, aggregating, storing, and querying high-volume metric data at scale. The system comprises multiple services: m3dbnode (storage node with custom encoding and persistence), m3coordinator (routing and downsampling gateway), m3aggregator (clustered metrics aggregation with quantile estimation), and m3query (PromQL/Graphite query engine). These services communicate via Thrift, gRPC, and HTTP, and are coordinated through an etcd-based cluster management layer that handles placement, leader election, and configuration distribution. The architecture is highly performance-oriented, featuring extensive object pooling, zero-copy I/O, custom bit-level encoding (m3tsz), and an inverted index (m3ninx) backed by FST segments and Roaring Bitmaps for fast metadata search. The codebase is written in a custom Go-like transpiled language and includes generated code for mocks, protobuf, and Thrift bindings. It integrates deeply with Prometheus (remote write, scrape, and query) and Graphite protocols, and provides a React-based admin UI (m3ctl) for namespace and rule management. The repository also contains a comprehensive suite of unit, integration, and property-based tests, along with Docker-based development and CI environments.
This is a Prometheus exporter for NATS server monitoring. It polls NATS server HTTP monitoring endpoints (varz, connz, subz, routez, healthz, jsz, etc.) and exposes metrics in Prometheus format. The architecture is a standalone binary with an embeddable library API. Key entry points are the CLI (main.go) and the exporter.NewExporter function. Data flow: on each scrape, collectors make HTTP requests to NATS monitoring endpoints, parse JSON responses, and convert them to Prometheus gauge metrics. The exporter supports TLS, basic auth, custom metric prefixes, and multiple NATS servers (though one per exporter is recommended). It includes pre-built Grafana dashboards for both NATS core and JetStream metrics. The codebase is well-structured with separate packages for collectors, exporter, and test utilities. It uses reflection-based metric extraction for simple endpoints and custom collectors for complex ones like JetStream, connections, and gateways. The project is actively maintained with recent commits and modern dependencies.
This repository provides a Helm chart for deploying Uptime-Kuma, a self-hosted uptime monitoring tool, on Kubernetes. The chart is well-structured with support for Deployment or StatefulSet, persistent storage, ingress, external database (MariaDB/MySQL), Prometheus ServiceMonitor, and network policies. It includes comprehensive helm-unittest tests, CI/CD pipelines for linting, testing, and releasing, and automated dependency updates via Renovate. The chart is actively maintained and follows Helm best practices.
Sentry is a full-stack application for error monitoring, performance tracing, session replay, and observability. In production, it ingests events (errors, transactions, logs, replays, profiles) from SDKs via a Relay proxy, processes them through Kafka streams, and stores data in ClickHouse (Snuba) and PostgreSQL. It exposes a REST API (Django REST Framework) and a React frontend for dashboards, issue management, alerts, and AI-powered features (Seer). The architecture is a monolith with hybrid-cloud services: a control silo for global state, cell silos for regional data, and an API gateway. Key entry points include the Relay ingestion endpoint, the Django WSGI/ASGI server, and Celery task workers. External dependencies include PostgreSQL, ClickHouse, Kafka, Redis, and cloud providers (GCP, AWS). The codebase also includes a billing/subscription layer (getsentry) and extensive third-party integrations (Slack, GitHub, Jira, etc.).
Vigil is a microservices status page application written in Rust. It monitors distributed infrastructure services via multiple probe modes (HTTP, TCP, SSH, ICMP, push, script, local), aggregates their health status, and serves a public status page with real-time updates. It also sends alerts through various channels (Slack, Email, Twilio, Telegram, etc.) when services go down or recover. The architecture is a single binary with separate threads for probing, aggregation, and HTTP serving, using a shared in-memory state protected by RwLock. The codebase is well-structured, with clear separation of concerns: config reader, prober, notifier, aggregator, and responder modules. It includes an MCP server for AI agent integration. The project is actively maintained with recent commits and CI/CD pipelines.
Updo is a production-grade CLI tool for multi-target website uptime and performance monitoring. It continuously checks HTTP endpoints from the command line or a TOML configuration file, displaying real-time results in an interactive TUI or simple text output. The core monitoring engine performs configurable HTTP requests (GET/POST/PUT, custom headers, assertion text, redirect handling, SSL verification) and captures detailed timing breakdowns (DNS, TCP, TTFB, download). It can also deploy and invoke AWS Lambda functions across 13 global regions for geographically distributed probing, aggregating results from multiple vantage points. The tool integrates with Prometheus via Remote Write for long-term metric storage and visualization, and supports desktop alerts via beeep plus webhook notifications to Slack, Discord, or custom endpoints with auto-detected formatting. Architecture is a monolith Go application built on cobra for CLI management, termui for the TUI, and AWS SDK v2 for Lambda operations. Key entry points are the `updo monitor` and `updo aws` subcommands. Data flows from config or CLI flags through a monitoring loop that calls the HTTP checker or Lambda invoker, accumulates stats (t-digest for percentiles, rolling uptime), and pushes structured logs or Prometheus time series.
This is a Go-based Kubernetes agent that watches cluster events (Kubernetes Event objects and Pod status changes) and sends them to Sentry for error tracking and monitoring. It runs as a read-only sidecar inside a Kubernetes cluster, using client-go informers and watchers to observe Jobs, CronJobs, Deployments, ReplicaSets, Events, and Pods. When a warning or error event occurs, the agent enriches it with Kubernetes metadata (owner references, node names, namespace) and captures it as a Sentry error event. It also supports Sentry Crons monitoring for CronJobs, custom DSN per resource via annotations, GKE integration for cluster metadata, and client-side filtering by event reason or source. The architecture is cleanly separated into watchers, enhancers, filters, and backoff logic, with comprehensive unit tests and CI/CD pipelines.
SigNoz is a full-stack open-source observability platform that ingests OpenTelemetry data (traces, metrics, logs), stores it in ClickHouse, and provides a rich web UI for querying, dashboards, alerts, and infrastructure monitoring. The backend is written in Go with a modular architecture using factory/provider patterns, SQL migrations, and OpenFGA-based authorization. The frontend is a React/TypeScript SPA with Zustand state management, react-query, uPlot charts, and a comprehensive query builder supporting PromQL, ClickHouse SQL, and builder queries. The enterprise edition adds anomaly detection, RBAC, licensing, and usage metering. The codebase is actively maintained with extensive testing (unit, integration, e2e) and CI/CD, though some legacy API versions and deprecated clients indicate ongoing migration.
This repository provides `claude-monitor`, a privacy-first CLI application for real-time monitoring of Claude Code usage. It reads local JSONL session logs, computes token consumption, costs, and burn rates, and displays them via a Rich-based terminal UI. The tool supports multiple subscription plans (Pro, Max5, Max20, Custom), integrates with Claude Code's official rate limits via statusline capture, and offers an opt-in persistent usage warehouse for historical analysis. It is distributed as a PyPI package with command aliases `cmonitor` and `ccm`. The architecture is modular, with separate packages for CLI, core logic, data ingestion/analysis, monitoring, output formatting, terminal management, UI components, and utilities. Key entry points include the CLI main module (`cli/main.py`), snapshot builder (`output/snapshots.py`), and monitoring orchestrator (`monitoring/orchestrator.py`). The application is well-tested with over 700 tests covering snapshot, trust-layer, warehouse, UI, timezone, and CLI paths. While primarily an application, it incorporates data engineering patterns such as sessionization, percentile-based limit estimation, and a versioned JSON warehouse. The codebase demonstrates strong craftsmanship with reusable components like the P90Calculator, PricingCalculator, TimezoneHandler, and UsageWarehouse. However, it has some technical drift risks due to hardcoded pricing rates, dependency on Claude Code's internal log format, and experimental API features that may change.
GPU-T is a Linux desktop utility for comprehensive GPU information and monitoring, positioned as a GPU-Z alternative for Linux. It provides real-time sensor data (clocks, temperatures, power, fan speeds), static hardware specifications from JSON databases and sysfs, and detection of API capabilities (Vulkan, OpenCL, CUDA, etc.) through a modular probe system. The application follows the MVVM pattern with Avalonia UI and features a sidecar process for NVIDIA-specific NVAPI/NVML interactions to ensure stability and isolate native interop. Hardware detection relies on sysfs paths, external tool execution, and vendor-specific databases, with user override capabilities for hardware specifications. The modular design separates concerns into probes for hardware polling, advanced providers for feature detection, and utilities for common tasks like settings management and shell command execution.
This repository implements a threshold-based vertical autoscaling system for Proxmox VE virtual machines. It runs as a systemd service that periodically polls VM CPU and RAM usage via SSH commands (qm, pvesh) and adjusts CPU cores and RAM by 1 core or 512 MB when configurable high/low thresholds are crossed. The system includes host resource safety limits, per-VM threshold overrides, independent cooldowns for CPU and RAM, and optional billing tracking with CSV export and webhook notifications. It also provides a lightweight Prometheus metrics endpoint built on stdlib, supports Gotify and SMTP notifications, and offers a dry-run mode for safe evaluation. The architecture is a single-threaded polling loop with in-memory state, designed for simplicity and reliability rather than horizontal scaling or predictive analytics. The codebase is well-tested with over 290 unit tests and end-to-end tests against real Proxmox nodes, and includes comprehensive documentation via a VitePress site. Key reusable components include a generic SSH client with retry/backoff and host key policies, a thread-safe Prometheus metrics registry without external dependencies, and a configuration validation module that reports all errors at once.
Noti is a cross-platform CLI tool written in Go that monitors the execution of a command (or a PID) and triggers notifications when it completes. It supports a wide array of notification services: desktop banners (macOS NSUserNotification via osascript, Linux Freedesktop via D-Bus, Windows tray icon via PowerShell), speech synthesis (macOS say, Linux espeak, Windows SpeechSynthesizer), and cloud services (Slack, Telegram, Twilio, Pushbullet, Pushover, Pushsafer, Simplepush, BearyChat, Keybase, Mattermost, Google Chat, Zulip, Chanify, ntfy, Bark). The architecture is a monolithic CLI built with Cobra and Viper. Configuration is sourced from YAML files (with schema validation), environment variables (with deprecated-var remapping), and CLI flags, following a clear precedence order. The codebase is well-tested, uses idiomatic Go, and demonstrates clean interface abstraction for extensible notification backends. The repository has moved to Codeberg but the GitHub mirror shows recent active development.
es-mode is an Emacs major mode for editing and executing Elasticsearch queries. It provides syntax highlighting, indentation, and keybindings for interacting with Elasticsearch clusters directly from Emacs buffers. The package includes features such as executing requests with C-c C-c, navigating between requests, copying requests as curl commands, an Elasticsearch Command Center for cluster monitoring, org-babel support for embedding queries in org-mode documents, and an interactive ESQL mode for Elasticsearch's ES|QL language. The architecture follows standard Emacs package conventions with several modular components: es-mode.el provides the core editing functionality, es-cc.el implements a monitoring dashboard, es-copyas.el handles request copying, es-esql.el offers an interactive ESQL interface, and ob-elasticsearch.el enables org-babel integration. The mode communicates with Elasticsearch using HTTP requests via the request library, displaying results in separate buffers with syntax highlighting and optional jq processing. Key strengths include thoughtful integration with Emacs workflows (company-mode completion, proper indentation, hook systems), robust error handling for network requests, and useful features like variable substitution in org-babel blocks and historical metric visualization in the command center. The code demonstrates solid Emacs Lisp craftsmanship with appropriate use of buffers, hooks, and asynchronous operations.
carbon-clickhouse is a production-grade Graphite metrics receiver and storage gateway written in Go. It ingests time-series data over multiple protocols (plain text TCP, UDP, Pickle, gRPC, Prometheus Remote Write, Telegraf HTTP JSON) and persists it to ClickHouse using the efficient RowBinary format. The system is architecturally split into receivers, a writer that rotates and compresses data files, and uploaders that batch-insert data into ClickHouse tables. Receivers handle protocol-specific parsing and drop rules; the writer manages chunking, interval-based rotation, and optional LZ4 compression; uploaders support points, index (hierarchical metric trees), tagged metrics (sorting, dedup, and URL encoding), and points-reverse storage. External dependencies include ClickHouse (HTTP interface), Prometheus protobuf definitions, gRPC, and common Go libraries. The codebase is well-tested, includes end-to-end integration tests with actual ClickHouse containers, and is actively maintained with CI/CD pipelines producing DEB/RPM packages.
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.
This repository is the infrastructure-as-code backbone for Security Onion, a free and open Linux distribution for threat hunting, enterprise security monitoring, and log management. It contains over 1,700 files of SaltStack states, Jinja templates, shell scripts, and Python modules that orchestrate the deployment, configuration, and lifecycle management of a distributed grid of security monitoring nodes. The code manages the entire Elastic Stack (Elasticsearch, Logstash, Kibana), network sensors (Zeek, Suricata), file analysis (Strelka), endpoint monitoring (Elastic Fleet/Agent), authentication (Kratos/Hydra), messaging (Kafka/Redis), metrics (Telegraf/InfluxDB), and the Security Onion Console (SOC) web UI. It is not a standalone application but a deployment and configuration system that transforms a bare OS into a fully operational security operations center. The repository is actively maintained with frequent commits, versioned releases, and a large community. Key architecture patterns include role-based state inclusion via `allowed_states`, consistent Docker container management, Jinja-based configuration merging, and event-driven reactors for rule pushes. Notable reusable components include a self-contained threat intelligence analyzer framework, a YAML manipulation CLI tool, and polling-based beacons that avoid inotify leaks.
This is a full-stack SaaS application for cron job monitoring (cron-job.org). It consists of a React frontend (Material-UI, Redux, i18n), a PHP REST API, a C++ execution daemon named 'Chronos', a WAF validator, and a public status page SPA. The system uses Apache Thrift for inter-service RPC, MySQL for job definitions and user data, per-user SQLite databases for historical execution logs, and Redis for rate limiting. The Chronos daemon implements an efficient async HTTP executor using libcurl, libev, and c-ares, with Prometheus metrics exposure. The codebase is production-grade with features like MFA (TOTP/Yubico), API keys, subscription billing (Stripe/Paddle), status pages with custom domains, and comprehensive i18n. However, it shows signs of technical drift: the frontend uses the deprecated Material-UI v4, password hashing is weak (SHA1+MD5), and the Thrift auto-generated code is fragile. The architecture is well-documented and the core execution engine is highly optimized, but the overall codebase would benefit from modernization of the frontend and authentication layers.
This repository is a comprehensive, declarative NixOS homelab configuration managed with the Clan framework. It defines the entire infrastructure for a multi-machine homelab including servers, desktops, and network devices, all version-controlled and reproducible. The system provisions self-hosted services (Caddy, Grafana, VictoriaMetrics, Vector, Blocky, Miniflux, Linkding, etc.), identity management (Authentik, Zitadel), monitoring and alerting, backup (Borgbackup), and desktop environments (KDE, i3). The architecture is modular: reusable NixOS feature modules under `modules/nixos/features/` follow a consistent pattern using `mkFeatureOptions` for enabling services with standardized options (domain, firewall, monitoring integration). Secrets are managed via SOPS with age encryption, and disk partitioning is handled by Disko templates. The repository is not a software application but an infrastructure-as-code project that demonstrates high craftsmanship in Nix module design, with clear separation of concerns, helper functions, and integration patterns. It is actively maintained but shows some technical drift due to deprecated identity providers and hardcoded IPs.
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.
nodemon is a CLI tool and library that monitors a directory for file changes and automatically restarts a specified command (typically a Node.js application). It parses command-line arguments and configuration files (nodemon.json, package.json) to determine watch paths, ignore patterns, file extensions, and the command to execute. It uses chokidar for file system watching and manages child processes via fork or spawn. When changes are detected, it matches the changed files against configured rules and restarts the child process if appropriate. It supports custom signals, delay, legacy polling, and event hooks. The architecture is monolithic with a library API, key modules include CLI parser, config loader, rule engine, file watcher, and process manager. The codebase relies on non-standard Node.js APIs (e.g., process.stdin.setEncoding, child_process.fork, process.versions.node), indicating significant technical drift from standard Node.js, though the tool remains widely used and actively maintained.