Clusters and the databases behind them

CloudK8s

Cluster inventory and health across EKS, GKE and AKS.

Managed Kubernetes tends to sprawl across accounts and regions until nobody has the full list. CloudK8s inventories every EKS, GKE and AKS cluster with its health, giving one place to see what exists and what is degraded.

• Inventory across EKS, GKE and AKS
• Health status per cluster
• Multi-account and multi-region coverage

Cluster detail

Nodes, workloads and per-namespace cost for a single cluster.

Cluster spend arrives as one large compute line item, which tells you nothing about which team caused it. Cluster detail breaks a single cluster into its nodes and workloads and attributes cost per namespace.

• Node and workload inventory for one cluster
• Per-namespace cost attribution
• EKS, GKE and AKS

In-cluster agent

Collects Kubernetes resources, Karpenter, OpenCost, Prometheus metrics and logs with no manual instrumentation.

Getting Kubernetes data usually means wiring up several exporters by hand and maintaining them afterwards. The agent collects Kubernetes resources along with Karpenter, OpenCost and Prometheus metrics and logs, with no manual instrumentation step.

• Collects Kubernetes resources, metrics and logs
• Reads Karpenter, OpenCost and Prometheus data
• No manual instrumentation required

Database diagnostics

Postgres query stats, index usage, vacuum and wait events, plus MongoDB and Redis health, gathered by the same agent.

The database is often the real cause of a latency incident, but it sits outside every Kubernetes dashboard. The same agent gathers Postgres query statistics, index usage, vacuum activity and wait events, plus MongoDB and Redis health.

• Postgres query stats, index usage, vacuum and wait events
• MongoDB and Redis health
• Collected by the agent already in your cluster