Build
Connect & operate
Design & teams
Start hereScope a build in one callBring a spec, a wireframe, or a paragraph. You leave with an architecture, a timeline, and a number.Book a scoping call
AI software
LLM & data systems
Vibe coding
Ready to ship?Put AI where the work isAgents, RAG, and private LLMs wired into the systems your team already uses — not a chatbot bolted to a homepage.Discuss an AI project
Domain firstWe learn your workflow before we model itRegulated, operational, or high-volume — the constraints belong in the schema, not in a training doc.Talk about your domain
Plan smarterEstimate before you commitCost ranges, scope templates, and the questions we ask in discovery — free, no form.Open the cost calculator
Real conversationsTalk with a technical leadNo SDR, no discovery gauntlet. The person on the call is the one who scopes the build.Book a call
Open-Source Observability · carlosedp

cluster-monitoring

Cluster Monitoring is a Kubernetes-native monitoring stack built on Prometheus Operator that bundles Prometheus, Grafana, Alertmanager, and exporters into pre-configured manifests. It supports hybrid ARM/x86-64 clusters and simplifies deployment with jsonnet-based customization and make-based tooling.

Source: GitHub — github.com/carlosedp/cluster-monitoring
754
GitHub stars
199
Forks
Jsonnet
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorycarlosedp/cluster-monitoring
Ownercarlosedp
Primary languageJsonnet
LicenseMIT — OSI-approved
Stars754
Forks199
Open issues4
Latest releaseUnknown
Last updated2025-08-22
Sourcehttps://github.com/carlosedp/cluster-monitoring

What cluster-monitoring is

A jsonnet-based IaC layer over Prometheus Operator that generates Kubernetes manifests for a complete monitoring observability stack including highly available Prometheus/Alertmanager, node-exporter, kube-state-metrics, and Grafana with optional modules for specialty metrics (MetalLB, Traefik, ElasticSearch, UPS). Supports multi-architecture container images (AMD64, ARM64, ARM, PPC64le) and both standard and K3s deployments.

Quickstart

Get the cluster-monitoring source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/carlosedp/cluster-monitoring.gitcd cluster-monitoring# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Hybrid ARM/x86-64 Kubernetes clusters

Purpose-built for mixed-architecture environments where standard monitoring stacks may lack multi-arch image support. Tested on production hybrid clusters with explicit AMD64/ARM64 configurations.

Operator-based Kubernetes monitoring at scale

Leverages Prometheus Operator for declarative metric collection and CRD-driven configuration. Suited for teams already using Operator patterns and needing highly available Prometheus with multi-replica deployments.

Quick-start monitoring on K3s and edge clusters

Streamlined templates for K3s with built-in Traefik metrics support. Lower resource footprint than full kube-prometheus-stack, practical for edge, lab, and resource-constrained environments.

Implementation considerations

  • Requires Go 1.18+ and jb toolchain for any customization; docker make target available to avoid local setup but still requires Docker.
  • Pre-built manifests provided for quick start, but ingress domain/suffix customization via Makefile targets or full vars.jsonnet rebuild may be needed for production.
  • Persistence (PVC/PV) disabled by default; must explicitly enable in vars.jsonnet and verify UID:GID (Prometheus 1000:0, Grafana 472:472) for existing PVs.
  • CRD application may require multiple kubectl apply runs due to ordering dependencies; documented as a known issue with workaround provided.
  • Custom container images mean responsibility for tracking upstream Prometheus/Alertmanager CVEs separately from official channels; no stated patching cadence.

When to avoid it — and what to weigh

  • Need active upstream maintenance and frequent updates — No versioned releases (latest: none), last push August 2025 but no release history published. Unclear frequency of updates to bundled component versions.
  • Require minimal customization friction — Heavy reliance on jsonnet + jb + Go toolchain for customization. Pre-built manifests available but any tuning beyond vars.jsonnet requires full rebuild pipeline; steeper than Helm charts.
  • Need commercial support or SLA guarantees — Single-author open-source project with Patreon funding model. No documented support pathway, SLA, or vendor backing. Community-driven only.
  • Seeking vendor-neutral standard distribution — Uses custom container images (carlosedp/prometheus, carlosedp/alertmanager, etc.) rather than upstream official images. Dependency on personal Docker Hub repositories introduces supply-chain risk.

License & commercial use

MIT License—permissive, allows commercial use, modification, and distribution with attribution and no warranty. No proprietary or copyleft restrictions.

MIT is an OSI-compliant permissive license permitting commercial use without restrictions. However, the project uses custom container images (carlosedp/*) which introduce supply-chain considerations; verify image source and maintenance policies for production workloads. No commercial support offered by the author.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceModerate
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceMedium
Security considerations

No security audit or vulnerability disclosure policy mentioned. Custom container images (carlosedp/prometheus, etc.) shift responsibility for CVE tracking to user; no stated image scanning or update SLA. TLS ingress configurable but no hardening guide. Grafana and Prometheus default credentials/access control configuration not explicitly documented. SMTP relay (Gmail) requires plaintext credential secrets; no encryption at rest mentioned.

Alternatives to consider

kube-prometheus-stack (Helm chart)

Upstream, actively maintained by Prometheus community, official images, Helm packaging reduces deployment friction, broader adoption and support. Best for teams preferring vendor-maintained standards.

Prometheus Operator + custom manifests

Full control over component versions, images, and configuration; no dependency on third-party jsonnet libraries or custom images. Suitable if you need minimalist or tightly audited environments.

Rancher Monitoring (fleet-managed)

Opinionated, multi-cluster focused, tighter Kubernetes/Rancher integration, enterprise support options. Better fit if managing clusters at scale across diverse environments.

Software development agency

Build on cluster-monitoring with DEV.co software developers

Review the maintenance status, image sources, and support model before committing to production. Consider it for quick evaluation labs or hybrid ARM clusters; assess upstream kube-prometheus-stack or managed solutions for mission-critical deployments.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

cluster-monitoring FAQ

Can I use this on production Kubernetes clusters?
Functionally yes—the stack is feature-complete and tested on hybrid clusters. However, there is no SLA, versioned releases, or commercial support. Recommend thorough testing, custom image validation, and internal maintenance ownership before production deployment.
Do I need to install jsonnet and jb to use this?
Not for initial deployment: pre-built manifests are included. For customization beyond the vars.jsonnet file, yes—or use the make docker target to build in a container without local toolchain installation.
What happens if I want to upgrade Prometheus, Grafana, or Alertmanager versions?
Edit image versions in vars.jsonnet, rebuild manifests with make, and reapply. Upgrade strategy (blue-green, rolling, etc.) depends on your Kubernetes setup. No documented upgrade path or breaking change log.
Are the custom container images (carlosedp/*) necessary or can I use official images?
The jsonnet library is built for those images. Switching to official images requires overriding image references in vars.jsonnet and testing compatibility; not officially supported.

From evaluation to production software

Bringing cluster-monitoring into production usually means new services, new interfaces, and new failure modes. DEV.co is a software development agency that builds all three and stays on for the open-source observability maintenance.

Evaluate cluster-monitoring for your Kubernetes observability

Review the maintenance status, image sources, and support model before committing to production. Consider it for quick evaluation labs or hybrid ARM clusters; assess upstream kube-prometheus-stack or managed solutions for mission-critical deployments.