Netdata is a real-time, distributed monitoring and observability platform built as a multi-language agent (C core, Go collectors, Rust sidecars, legacy Python plugins). It collects system, container, application, network, and cloud metrics at per-second resolution, stores them in a custom tiered time-series database (dbengine), and exposes rich query APIs (v1/v2/v3), streaming/replication, ML-based anomaly detection, and an extensive alerting framework. The agent can operate standalone, stream to centralization points, or connect to Netdata Cloud via the ACLK (Agent-Cloud Link) using MQTT and protobuf. It also includes a network topology discovery subsystem, netflow/IPFIX/sFlow ingestion, systemd-journal log management, and an OpenTelemetry-compatible OTLP ingestion path. Architecturally, the repository is a hybrid of a daemon (C) with a plugin system that spawns many independent processes (Go, Python, shell) for metric collection. The Go plugin framework enforces a consistent collector lifecycle (config validation, init, collect, cleanup) with embedded JSON schemas and chart templates. The Rust crates handle high-throughput streams like netflow and journal indexing. The codebase is professionally engineered with extensive test coverage, benchmarks, packaging for multiple Linux distros, Windows, and macOS, and a heavy investment in performance optimizations (arena allocators, lock-free data structures, compressed bitmaps). Despite its size, it exhibits strong modularity and reusable abstractions, though some legacy duplication (e.g., Python vs Go collectors) and a few vendored components remain.
This is the Prometheus monitoring system, a production-grade application that scrapes and stores time-series metrics, evaluates PromQL queries, generates alerts, and supports remote write/read. The codebase is structured as a monolith with clearly separated packages: a time-series database (TSDB) with advanced compression (XOR, varbit, histogram encoding), a PromQL parser and engine, a scrape manager with start-time synthesis for cumulative metrics, a notifier for Alertmanager integration, service discovery for 15+ cloud/container platforms, remote storage adapters, and a REST API with OpenAPI specs. The system runs as a single binary with optional agent mode. Two web UIs (React and Mantine) provide querying, alert management, and configuration views. The architecture is modular: each major component (TSDB, PromQL, scrape, notifier) has a clean interface and can be independently tested or replaced.
Micrometer is a production-grade metrics instrumentation facade for JVM applications, providing a vendor-neutral API to collect and export dimensional metrics to over 20 monitoring backends including Prometheus, Datadog, Dynatrace, OTLP, InfluxDB, and Graphite. The core library defines fundamental meter types (Counter, Timer, Gauge, DistributionSummary, LongTaskTimer) and a higher-level Observation API for tracing-friendly instrumentation. Its modular architecture separates the core API (micrometer-core), common utilities (micrometer-commons), observation framework (micrometer-observation), and backend-specific registry implementations (micrometer-registry-*). Key entry points include MeterRegistry, ObservationRegistry, and annotations like @Timed, @Counted, and @Observed for declarative instrumentation. In production, applications record metrics through the Micrometer API, which aggregates data in-memory using step-based or cumulative counters and timers. The data is then periodically pushed to monitoring backends via push-based registries (e.g., Datadog, InfluxDB) or exposed for scraping (e.g., Prometheus). The library includes extensive binders for JVM internals, HTTP clients/servers (Jetty, OkHttp, Apache HttpClient), gRPC, caching (Caffeine, Guava), databases (MongoDB, JPA/Hibernate, JOOQ), messaging (JMS, Kafka), and logging frameworks. External dependencies include SLF4J for logging, HdrHistogram for percentile calculations, and various backend-specific client libraries. The codebase demonstrates high craftsmanship with comprehensive unit and integration tests, JMH benchmarks for performance-critical paths, JCStress concurrency tests, and a compatibility test kit for registry implementations. It follows clean architectural patterns: composite registries for multi-backend deployment, meter filters for runtime configuration, naming conventions for backend-specific adaptations, and a validation framework for configuration properties. While the project has some deprecated modules (e.g., Wavefront registry, Prometheus simpleclient) and minor duplication of utility classes, it remains actively maintained with frequent releases and strong community adoption.
Grafana Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be cost-effective and easy to operate by indexing only log metadata (labels) rather than the log contents. The system consists of several loosely coupled services (distributor, ingester, querier, compactor, ruler) that can be deployed in a monolithic or microservices architecture. Logs are ingested via various protocols (HTTP, gRPC, Kafka) and integrations (fluent-bit, fluentd, logstash, Docker driver), stored in chunk format in object stores, and indexed by labels in a separate store. Queries are executed using LogQL, which allows filtering by label expressions and log content. The system includes a ruler for alerting and recording rules, a compactor for storage optimization, and a Kubernetes operator for deployment and management.
Grafana is an open-source observability platform for querying, visualizing, and alerting on metrics, logs, and traces. It is a full-stack application with a Go backend and React/TypeScript frontend, featuring a plugin system for datasources, panels, and apps. The architecture is a monolith with Kubernetes-style API extensions, supporting multiple database backends (MySQL, PostgreSQL, SQLite). It includes built-in alerting, dashboard management, provisioning, and RBAC. The codebase is large and well-maintained, with high-quality UI components and data abstractions, but has some technical debt from dual build systems and generated code.
Apache SkyWalking is an open-source APM (Application Performance Monitoring) system designed for microservices, cloud-native, and container-based architectures. It provides distributed tracing, metrics aggregation, log analysis, and profiling capabilities (including eBPF, async-profiler, and JFR). The system features a modular, plugin-based architecture where receivers ingest telemetry data, analyzers process it, storage plugins persist it, and query services expose it via GraphQL, PromQL, LogQL, and TraceQL interfaces. Alarm mechanisms detect anomalies and trigger notifications through multiple channels. The codebase demonstrates strong engineering practices with clear separation of concerns, extensive use of interfaces and dependency injection, and reusable patterns like the module system, storage abstraction, and analysis listener framework.
The prometheus/statsd_exporter is a production-grade Go application that receives StatsD metrics over UDP, TCP, or Unix sockets and translates them into Prometheus metrics. It acts as a drop-in replacement for StatsD, supporting multiple tagging formats (DogStatsD, InfluxDB, Librato, SignalFX) and providing flexible metric mapping via glob or regex patterns. The exporter is designed to run as a sidecar alongside application instances, converting ephemeral StatsD events into persistent Prometheus time series that can be scraped by a Prometheus server. Architecturally, the application consists of several well-separated layers: network listeners (UDP, TCP, Unixgram) that receive raw lines, a line parser that converts text into typed events (counter, gauge, observer), a metric mapper that applies user-defined mapping rules using a finite state machine (FSM) for glob patterns or regular expressions, and an exporter that registers and updates Prometheus metrics via a custom registry. Events are batched through an internal queue to improve throughput. The mapper supports caching (LRU or random replacement) to accelerate repeated lookups. Key entry points include the main.go binary with CLI flags for configuring listeners, mapping files, cache size, relay targets, and tagging options. The primary data flow is: incoming StatsD line → line parser → event queue → mapper → exporter → Prometheus registry. External dependencies are limited to Prometheus client libraries, a YAML parser, and the Go standard library. The codebase is well-tested with unit tests, integration tests, and benchmarks, and follows Prometheus project conventions.
OpenFaaS is a serverless platform that provides an API gateway for deploying, managing, and invoking functions. The gateway handles HTTP routing to functions, collects and exposes Prometheus metrics, implements autoscaling based on invocation rates, includes a built-in AngularJS UI for function management, and supports alerting via integrations like Slack. It uses a plugin architecture for function providers (e.g., Kubernetes, Docker Swarm) via the faas-provider interface, allowing the core to remain decoupled from the underlying runtime. The system processes synchronous function invocations through a reverse proxy and asynchronous invocations via NATS queues.
Vegeta is a versatile HTTP load testing tool and Go library. It simulates constant-rate or oscillating traffic against HTTP endpoints, collects latency and byte metrics, and generates reports (text, JSON, histograms, HTML plots). The core is an attack engine with pluggable pacers, a targeter for reading HTTP request specs, and a metrics pipeline using t-digest for percentile estimates. It includes a Prometheus exporter and a downsampling library for plotting large time series. The codebase is well-structured with clean package boundaries, cross-platform support, and extensive testing including fuzzing.
The NGINX Prometheus Exporter is a production-grade Go service that bridges NGINX and NGINX Plus metrics into Prometheus. In operation, Prometheus scrapes the exporter's HTTP endpoint (default :9113/metrics) and on each scrape the exporter fetches live metrics from either the NGINX stub_status page or the NGINX Plus REST API, converts them into typed Prometheus metrics (gauge/counter), and serves them alongside an nginx_up/nginxplus_up health gauge. The binary supports multiple concurrent scrape targets, TLS client auth against NGINX, unix domain sockets, PROXY protocol v2 outbound connections, and the full exporter-toolkit web configuration surface (TLS termination, basic auth, systemd socket activation). Architecturally it is a compact, idiomatic Go application with three layers: the main package owns CLI flags (kingpin), TLS setup, transport construction, and HTTP server lifecycle; the client package is a minimal self-contained stub_status HTTP client; the collector package implements prometheus.Collector in two variants — NginxCollector for OSS (7 metrics) and NginxPlusCollector for Plus (roughly 300 metrics spanning server zones, upstreams, stream zones, zone sync, resolvers, limit zones, cache, workers, and license state). The Plus collector is the dominant subsystem; its notable design feature is a LabelUpdater interface backed by RWMutex-protected maps that allows an external system (NGINX Ingress Controller) to dynamically inject additional label names and values into upstream/server-zone/cache metrics between scrapes. The release and quality engineering around the code is exceptional: GoReleaser multi-arch builds (10 OSes, 12 architectures), cosign-signed artifacts, SBOM/provenance attestations, multi-registry Docker publishing (DockerHub, GHCR, ECR, Quay), Homebrew/Scoop/Nix distribution, OpenSSF Scorecards, CodeQL, anchore image scanning, and a 60-linter golangci-lint configuration. A retract directive in go.mod cleanly handles a broken v1.5.2 release, indicating disciplined release management. Dependencies are current (Go 1.25, prometheus client_golang v1.24, exporter-toolkit v0.17). The main weakness is that the Plus collector is a single ~3000-line monolith with heavy repetition in metric emission and only minimal unit-test coverage for its most complex paths.
This repository is a collection of shared Go libraries used across Prometheus components. It is not a standalone application but a modular library providing core infrastructure for metric exposition formatting (text, protobuf, OpenMetrics), HTTP client configuration (authentication, TLS, OAuth2, proxy), metric model types and validation, logging, routing, and version information. The architecture is package-oriented with clear interfaces and separation of concerns. Key entry points include `config.NewClientFromConfig` for constructing HTTP round trippers with hot-reloadable TLS and credentials, `expfmt.NewTextParser` for parsing Prometheus text format, and `model.EscapeName` for metric name escaping. The codebase is well-tested, actively maintained, and exhibits strong engineering practices such as interface-based design, table-driven tests, and reusable build infrastructure (Makefile.common). It is primarily consumed by Prometheus server, exporters, and other ecosystem tools.
This is a Kubernetes operator that manages the lifecycle of Prometheus, Alertmanager, and related monitoring components (Thanos Ruler, Prometheus Agent) as Kubernetes native resources. It provides Custom Resource Definitions (CRDs) for declarative configuration and automates deployment, scaling, configuration generation, TLS management, and reconciliation. The operator ensures that Prometheus and Alertmanager instances are correctly configured, updated, and monitored within a Kubernetes cluster, handling tasks such as secret injection, config reloading, and pod repair. The architecture is a monolithic Go binary using the controller-runtime pattern. It includes multiple sub-components: an admission webhook for validation and mutation of CRDs, a prometheus-config-reloader sidecar for dynamic config reload, and a kubelet controller for node endpoint management. The codebase is heavily generated (client-go, apply configurations, informers) and relies on Kubernetes APIs, Prometheus/Alertmanager container images, and optional cloud SDKs (AWS, Azure) for service discovery. Key entry points are `cmd/operator/main.go` (main operator binary), `cmd/admission-webhook/main.go` (webhook server), and `cmd/prometheus-config-reloader/main.go` (config reloader). Data flows: users define CRDs → operator reconciles into StatefulSets/DaemonSets, generates Prometheus/Alertmanager config files with TLS/auth, and manages config reloads. External dependencies include a Kubernetes cluster, Prometheus/Alertmanager container images, and optional cloud services for scrape config discovery.
Robusta KRR is a CLI tool for optimizing Kubernetes resource allocation by recommending CPU and memory requests/limits based on Prometheus metrics. It features a modular architecture with pluggable strategies for recommendation algorithms, multiple output formats, and integrations with various Prometheus-compatible systems. The project includes an enforcer component (mutating webhook) for automatic application of recommendations. The codebase demonstrates good engineering practices with clear separation of concerns, proper error handling, and extensible design patterns.
This repository builds and maintains the `grafana/otel-lgtm` Docker image, an all-in-one OpenTelemetry backend for development, demo, and testing. It bundles Grafana, Prometheus, Tempo, Loki, Pyroscope, and the OpenTelemetry Collector into a single container, providing a complete observability stack with a single `docker run` command. The image supports optional eBPF-based auto-instrumentation (OBI) for zero-code traces and RED metrics, and can export telemetry to external vendors via OTLP. The architecture is a multi-stage Docker build that downloads and verifies each component using checksums or cosign signatures. The container entrypoint (`run-all.sh`) starts all services in parallel, waits for health checks, and handles graceful shutdown. The OpenTelemetry Collector configuration is dynamically extended based on environment variables (debug exporter, external endpoints, custom headers). The repository also includes example applications in Java, Go, Python, .NET, and Node.js that demonstrate OpenTelemetry instrumentation, along with acceptance tests (OATS) that validate traces, metrics, logs, and profiles. CI/CD is comprehensive: automated builds, linting (flint, hadolint, shellcheck, etc.), container scanning with Trivy, CodeQL analysis, and weekly scheduled releases with immutable version tags. Container images are signed with cosign and attested via GitHub Artifact Attestations. The repository is actively maintained with Renovate for dependency updates and a well-defined release process.
Kubenurse is a Kubernetes DaemonSet that monitors network connectivity within a cluster by performing periodic checks on API server access (direct and DNS), service/ingress reachability, and inter-node communication. It exports detailed Prometheus metrics including request duration histograms, error counters, and a neighbourhood incoming checks gauge. The architecture uses a controller-runtime client for Kubernetes API discovery, implements an efficient O(N) neighbourhood filtering algorithm based on SHA256 hashing to avoid quadratic scaling, and leverages Go's httptrace package for granular connection metrics. The application features graceful shutdown, TLS support, readiness probes that respect node schedulability, and extensive configuration via environment variables or Helm values.
M3 is a production-grade, horizontally scalable distributed time series database and metrics platform, originally built at Uber. It provides a storage engine (M3DB) with custom M3TSZ compression, a PromQL-compatible query engine (M3Query), a metrics aggregation service (M3Aggregator), and a coordinator for ingestion and routing. The system ingests metrics via Prometheus remote write, Graphite (carbon), and custom Thrift/Protobuf protocols. It supports clustering, replication, sharding, and downsampling. The architecture is a set of microservices (m3dbnode, m3coordinator, m3aggregator, m3query) that communicate via gRPC, TChannel, and etcd for coordination. Key entry points are the service binaries in src/cmd/services/. External dependencies include etcd, Prometheus client libraries, and custom forks of several Go packages. The codebase is heavily optimized for performance with extensive object pooling, code generation, and custom encoding.
The CloudWatch Exporter is a Java-based Prometheus exporter that collects metrics from AWS CloudWatch and exposes them in Prometheus format. It runs as a standalone web server with an embedded Jetty server, periodically polling AWS CloudWatch APIs based on YAML configuration. The architecture features clear separation of concerns with distinct components for configuration management, AWS API interaction, dimension caching, and metric collection. Key entry points include the WebServer main method which takes port and config file arguments, and the CloudWatchCollector which handles the core metrics collection logic. The exporter supports both GetMetricStatistics and GetMetricData APIs, includes special handling for services like DynamoDB, and provides configuration reload via SIGHUP or HTTP endpoint. External dependencies include AWS SDK, Prometheus Java client, Jetty, Caffeine for caching, and Snakeyaml for YAML parsing.
This is a monorepo of first-party middleware and service implementations for the Fiber web framework (v3). It provides production-grade authentication (JWT, PASETO, SPNEGO/Kerberos), authorization (Casbin, OPA), observability (OpenTelemetry, Prometheus, New Relic, Sentry, custom monitor/uptime dashboards), real-time communication (WebSocket, Socket.IO v5), Web Application Firewall (Coraza), resilience patterns (circuit breaker, CPU load shedding), structured logging (zap, zerolog), internationalization, hCaptcha verification, Swagger UI/OpenAPI docs, profiling (fgprof), and Testcontainers integration for testing. Each package lives in its own Go module under v3/, following a consistent Config+New() pattern and includes extensive test coverage with benchmarks. The architecture is library-oriented: components are imported by Fiber applications, not run standalone. The codebase demonstrates strong engineering practices: config validation at construction, atomic concurrency patterns, lock-free read paths, and protocol-level optimizations (e.g., zero-copy Socket.IO codec, WebSocket write coalescing). Some packages show signs of technical drift (e.g., paseto uses a deprecated library, socketio has mutable package globals), but overall the repository is actively maintained with weekly releases and automated dependency updates.
This repository contains the official Helm charts for deploying SonarQube on Kubernetes, maintained by SonarSource. It provides two charts: `sonarqube` for standard (Community/Developer/Enterprise) deployments and `sonarqube-dce` for Data Center Edition with clustered search and application nodes. The charts are production-grade, supporting a wide range of Kubernetes features including StatefulSets, Deployments, Ingress, NetworkPolicies, PodDisruptionBudgets, Prometheus monitoring, Istio service mesh with strict mTLS, OpenShift integration, and autoscaling via HPA and KEDA. A distinguishing feature is the agentic AI subsystem: the charts deploy an orchestrator, hunter, and remediation agent runtimes, a Squid-based egress proxy for sandboxed runtime isolation, gVisor/Kata sandboxing, and an HKDF-based key derivation hook for secure inter-component communication. The repository also includes integrations for Azure and Google Cloud marketplaces, comprehensive CI/CD pipelines (build, sign, publish, compatibility tests), and migration scripts for PostgreSQL and ingress-nginx to Gateway API/Istio. The codebase demonstrates high craftsmanship in Helm template design, with extensive validation, test fixtures, and golden-file tests covering hundreds of configuration permutations.
Ciao is a self-contained, zero-external-dependency HTTP(S) endpoint monitoring application built with Ruby on Rails 8. It schedules periodic health checks with cron syntax using the in-process rufus-scheduler, stores state in a local SQLite database, and notifies users of status changes via email or configurable webhooks (e.g., Slack, Rocket.Chat). The application also monitors TLS certificate expiration for HTTPS endpoints and sends alerts when certificates are due to expire. It provides a web UI with a dashboard, a RESTful JSON API, optional Prometheus metrics, and HTTP Basic authentication. The codebase is a standard Rails monolith with a single process for web server, scheduler, and background work, making it easy to deploy (Docker, Helm chart, or direct Ruby). The architecture is simple but effective for small-to-medium monitoring needs.