Moonin convierte los eventos de tu cluster en una vista operativa clara: qué cambió, qué está afectado y cuál es el siguiente paso.
Un solo Helm chart por cluster. Trazas distribuidas con eBPF, sin instrumentar tu código. Compatible con EKS, GKE, AKS y clusters autoadministrados.
About usPricingSecurity and permissionsPartner programmevs Datadogvs Prometheus & Grafanavs New Relicvs Dynatracevs ELK and ElasticsearchCrashLoopBackOffOOMKilledImagePullBackOffPod stuck in PendingDocumentationDemoSign upContact usArguz, the consultancy
Moonin is an operational observability platform for Kubernetes, built by Arguz SpA in Santiago, Chile. It correlates a cluster’s resources, deployments and events to answer four questions during an incident: what changed, what is affected, who needs to know, and what to do next. It installs as a single Helm chart per cluster.
Moonin keeps a revision history per service and environment, where every deployment is recorded with its image, its commit and its duration. When something breaks, comparing the last working revision against the current one shows the change without reconstructing it from logs or from kubectl history.
No. Moonin collects distributed traces and service-to-service traffic with eBPF, in the node kernel, so there are no libraries to add, no SDK, no sidecars and no deployment pipeline changes. You also do not need to install and maintain a separate APM.
Almost never. The Discovery Agent and the Node Agent query the Kubernetes API read-only, and the 16 MCP tools it exposes are read-only, with the database session opened in read mode. The single exception is the Scaling Rules Agent, which can adjust HPA and replicas: it is optional, ships disabled, and is enabled by an explicit condition. Moonin does not perform automatic remediation.
Yes. Moonin works against the Kubernetes API, so it behaves the same on Amazon EKS, Google GKE, Azure AKS, self-managed distributions and on-premise clusters. What differs between providers is the node detail each one exposes, not the installation or the data model.
It measures the four DORA metrics from DevOps Research and Assessment (deployment frequency, lead time for changes, change failure rate and time to restore service) and adds a fifth view of problem services, ranking services by their contribution to failures. All of them are computed from the cluster’s own deployment history, with nothing to declare by hand.
Pricing rests on a single dimension, the Compute Unit, derived from your clusters’ declared capacity rather than from traffic or user count. One CU equals 1 vCPU or 2 GB of RAM, and the heavier dimension is billed, never the sum of both. Pricing is tiered incrementally: USD 20 per CU per month up to 100 units, USD 18 from 101 to 250, USD 15 from 251 to 500, and negotiated above 500. It includes 10 GB of storage per CU and Standard Support; Premium adds 10% and Enterprise 20% on top of the unit cost.
With a single Helm chart, moonin-agent, applied once per cluster. No sidecars, no deployment pipeline changes, no per-service agent. After installation the inventory of resources, deployments and events appears on its own, continuously.
Arguz measured between 20% and 40% cloud bill reduction across its own projects. The reduction comes from seeing declared capacity nobody uses: extra replicas, oversized requests, and resources left running without an owner.
It solves a narrower problem and costs less because of it: answering what changed in a Kubernetes cluster and what broke as a result. It is not a general-purpose APM or a dashboard engine. It fits when observability spend grew faster than actual usage and what was missing was deployment context, not more time series.